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>