Date: Sat, 25 Nov 1995 23:26:24 -0500 (EST) From: John Fieber <jfieber@indiana.edu> To: "Jordan K. Hubbard" <jkh@time.cdrom.com> Cc: hackers@FreeBSD.ORG Subject: Re: Thoughts on the install and on Red Hat Linux. Message-ID: <Pine.BSF.3.91.951125223801.4125C-100000@fieber-john.campusview.indiana.edu> In-Reply-To: <16288.817330725@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 25 Nov 1995, Jordan K. Hubbard wrote:
> Can we re-open the traditional (heh heh) dialog on this topic?
[...]
> Comments? Rotten eggs?
Just to keep focus on the ultimate purpose of the installation software,
making installation painless, or even fun, I offer this less technical
description of what is in order for the next great installation. I think
developing a slick new X install program is nifty, but meaningless if some
more basic installation issues are not addressed first.
1. Look at the people who will be installing FreeBSD. Maybe divide them
into a couple groups new users, and upgraders.
2. Write a very high-level description of the "ideal" installation
process for each of the groups. (eg: create boot floppy, boot,
prep disk, install, configure). This will seem over-simplistic given
the hairy realities of PC hardware, but it is a target to shoot for.
3. Make a list of everything about the state of the world that the
installation program needs to know, *and* whether this information
can (a) be *reliably* determined by the installation program, or
(b) it must be supplied by the user. This list will probably grow
as time goes on so keep it handy.
4. For each item on list 3(b), identify where or how the user will
obtain the needed information. This is important and must take
step 1 into account!
5. Show list 3(b) to the wizards and tell them that they *must* figure out
how to *reliably* determine at least 90% of the information without user
intervention. (The big challenge here is to make list 3(b) as small
as possible!)
6. Make a list of every possible thing that could go wrong during the
installation. Describe (a) what the system can do on its own to
recover or (b) what options the user has to recover/abort.
7. Review the information from 4 and group related items related by
information type (eg network IP numbers). Make a rough sequence
mapping based on 2.
8. Make mock-up dialog screens. These will be based on information
from 7. Help screens will be based on 4. Plain text files
work fine for these prototypes. Alternately, make up a set
of html pages that people can flip through.
9. Have people filp through the prototype screens. Observe where they
get confused, what information they can't provide, where they make
incorrect choices. Offer beer if need be.
10. Based on 9, go back to 6 and revise.
11. If there is information people have difficulty determining, go back
to step 5.
12. Build a prototype that presents a realistic interface. The internals
can still be simulated at this point.
13. Test, go back to previous steps if necessary.
14. Wire the interface to the machinery that the wizards have been
working on (see step 3 and 5).
15. Test.
16. Fix bugs, goto 15.
-john
== jfieber@indiana.edu ===========================================
== http://fieber-john.campusview.indiana.edu/~jfieber ============
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951125223801.4125C-100000>