Date: Mon, 01 Sep 1997 11:41:53 +0930 From: Mike Smith <mike@smith.net.au> To: John Fieber <jfieber@indiana.edu> Cc: Mike Smith <mike@smith.net.au>, "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: <199709010211.LAA00270@word.smith.net.au> In-Reply-To: Your message of "Sun, 31 Aug 1997 20:03:32 EST." <Pine.BSF.3.96.970831193929.307L-100000@fallout.campusview.indiana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
(Sorry for the quote extent, I can't break this down without losing context...) > On Mon, 1 Sep 1997, Mike Smith wrote: > > > As an issue of curiosity, and for general review does the sequence : > > > > - step sequentially (in some hopefully logocal order) through all the > > required configuration dialogs > > - present the gathered information in summary form, with functionality > > to jump immediately to a particular editing screen if a parameter is > > found to be wrong (by the user) > > - offer a proceed/cancel selection > > > > come closer to the ideal for the gather/review/confirm cycle? > > I've seen this approach a lot, and the review is helpful but not > sufficient. Imagine an installation with 6 screens. You make a > mistake (or a poorly informed decision) on the second screen > which you realize on the third screen. > > With the above scenario, at the best, you must keep that error in > mind as you proceed through the rest of the process to the review > screen. With fairly long installation process, it is easy to > forget about some mistake made near the beginning, for example, > realizing that you actually wanted a separate partition for > /usr/local. This is aggrivated by the density of relatively > complex decisions that must be made during the install process. > In short, the fewer intervening events between realizing an error > and correcting the error, the fewer steps involved and the more > likely that the error will actually be corrected. 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. Please forgive my thickness; I've done quite a lot of UI work, but never been happy with my results, or any of the texts I've found on the topic. Having a real-life example and some people that understand it is a great temptation to learn 8) > At the worst, the mistake may result in taking a wrong fork in > the installation process which cannot be carried through to the > confirmation stage, thus requiring the user to abort the whole > process and start over. >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? Microsoft and their "Wizard" stuff just uses the forwards/back model sans summary, and asks "are you happy" at the end. I always felt that I wanted to know *what*exactly* I was agreeing to... > Also, how does the user know that there will be a complete > review/confirmation stage near the end of the gathering phase? > The ability to review and correct at any point in the process > will reduce anxiety about making mistakes. 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? Thanks mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709010211.LAA00270>