Date: Mon, 1 Sep 1997 23:37:01 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: Mike Smith <mike@smith.net.au> Cc: "Jordan K. Hubbard" <jkh@time.cdrom.com>, Peter Korsten <peter@grendel.IAEhv.nl>, freebsd-chat@freebsd.org Subject: Re: sysinstall (was Re: Conclusion to "NT vs. Unix" debate) Message-ID: <Pine.BSF.3.96.970901230429.307V-100000@fallout.campusview.indiana.edu> In-Reply-To: <199709010211.LAA00270@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 1 Sep 1997, Mike Smith wrote: > OK; we need more detail then. If we consider the process through the > configuration "screens" as being a set of steps along a path, with > (possible) branches based on some input, and the summary screen at the > end being, in effect, a description of the steps taken to get there, > then the following actions make "sense" : > > - complete a screen and proceed to the next. > - back up from a screen to a previous screen along the path, ie. > "oops". > - return to a particular screen from the "summary" screen, with the > possible consequence that other subsequent screens may have to be > visited, and ultimately a new summary screen generated describing > the new path. Jumping must be done very carefully as it can be disorienting. A little outline of the steps with the proverbial "You are HERE" marker is helpful. Jumping forward can technically only be done if the changed item has no dependencies later in the process. Even when it could technically be done, it might not be good from a usability point of view. I'm not sure on this though, I'll have to think about it. Obviously if the change results in taking a differnt branch through the install process, eg changing from a CDROM install to a network install, you will have to proceed through screen at a time from at least the branch point on. Getting down to the toolkit/mechanics, when proceeding through screens after making a change, it can be helpful to visually highlight any dependent information that may be affected by the change. > From a logical/implementation viewpoint, looking at the "gather" > process as a tree which can be traversed in any direction makes this > possible; is it adequate from the conceptual/user point of view? Lacking a visualization of the tree, a linear model with forward and back would be more consistent with what a user experiences, particularly if they don't make mistakes that cause different branches to be traversed. > Is it adequate to mention the review-before-anything-happens facet > early in the process, or is this likely to be ignored as you've > mentioned before? As Eivind said, if they don't have to interact with it, it may as well not even be there. :) In a previous life working managing publicly accessible computers (in libraries), there were always local quirks that needed some documentation--printing procedure oddities being the most frequent. My supervisor insisted that I put out signs, but it was obvious that anything not on the screen was completely ignored. Things on the screen were usually ignored if there was no forced interaction with the message, and even then it was often ignored. How do I know? Very simple, just work out at the reference desk and observe the frequency of questions for which the answer is clearly spelled out either on a sign, onscreen without interaction, and onscreen with forced interaction. Ultimately, for this particular problem, the most effective solution was to let the mistake happen and then provide a recovery mechanism rather than mistake avoidance. This worked by placing the printing instruction on the printers themselves rather than at the workstations. Users would come over to the printer, and while waiting for the printout that was never going to arrive because they didn't follow the instructions, they had time to stare at the printer, notice, and then read the instructions. Alas, this illustrates the most aggrivating dimension of interface design: there are damn few reliable rules of thumb, and most of those are what NOT to do, which doesn't help out much in figuring out what TO do. -john
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.970901230429.307V-100000>