From owner-freebsd-chat Mon Sep 1 04:41:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA21321 for chat-outgoing; Mon, 1 Sep 1997 04:41:07 -0700 (PDT) Received: from bitbox.follo.net (bitbox.follo.net [194.198.43.36]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA21316 for ; Mon, 1 Sep 1997 04:41:04 -0700 (PDT) Received: (from eivind@localhost) by bitbox.follo.net (8.8.6/8.8.6) id NAA17567; Mon, 1 Sep 1997 13:40:23 +0200 (MET DST) Date: Mon, 1 Sep 1997 13:40:23 +0200 (MET DST) Message-Id: <199709011140.NAA17567@bitbox.follo.net> From: Eivind Eklund To: Mike Smith CC: jfieber@indiana.edu, peter@grendel.IAEhv.nl, freebsd-chat@FreeBSD.ORG In-reply-to: Mike Smith's message of Mon, 01 Sep 1997 11:41:53 +0930 Subject: Re: sysinstall (was Re: Conclusion to "NT vs. Unix" debate) References: <199709010211.LAA00270@word.smith.net.au> Sender: owner-freebsd-chat@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > > 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. Sounds right to me. > > 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? Yes, as long as the users selections make the traversal _(s)he sees_ into a straight line from the top down (with the possibility of going back and forth). Ie, you need to be able to ask 'are the disks already set up' and then skip or include a set of screens depending on the answer. You need to be able to ask (hyptotetically, until somebody implement this) 'Do you want BSD slicing or DOS partitions as your partitioning scheme?" and get different screens depending on the answer. And - each screen must be possible to enter with a part of the data already filled in, if the user go back and forth to change some error on the last screen. I started to implement code for this (it should be fairly nicely representable as a MageWalker and a MageScreen class) and came up with a quirk: I was thinking along this tree being kind of static - built by hand, so dependencies could easily be just set up. It can't be - think of e.g setting up a set of disks, where you may well want the user to go through the same dialogs for each disk. (I'll see if I can finish off the code tonight, and throw it in as a more consistent point in the discussion - not that it have to be used, but it should make it easier to play with the ideas). > > 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? That's likely to be ignored. In fact, any text the user doesn't _have_ be involved in is likely to be ignored. However, I can't see a better way to present it - a user that can't read will be anxious no matter what we do. (Set up a speech synthesis system? ;-) Eivind.