Date: Tue, 22 Apr 1997 00:40:54 -0400 From: Bakul Shah <bakul@torrentnet.com> To: Terry Lambert <terry@lambert.org> Cc: hackers@freebsd.org Subject: Re: disklabel -- owner? Message-ID: <199704220440.AAA03107@chai.plexuscom.com> In-Reply-To: Your message of "Mon, 21 Apr 1997 18:49:07 PDT." <199704220149.SAA24616@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I'd probably ask for what kind of install they were going to do > first, and pick my rules of thumb based on the install they want > to do to cut down on the number of questions you have to ask the > user to get there. First, I was focusing on disklabel issues, not a generic install. Second, just so it is perfectly clear, I meant frequently asked questions *by* the users, not by the program. > You might hedge by saying I'm stuffing the FAQ into the online help, > but I really think the default options should be limited to 5 or > less (based on the Bell Labs HCI study, and recently published > Russian work on Activity Theory as it applies to HCI). HCI issues are separate from the issue of online help. Even in a perfectly designed interface a user may want help, may need guidance. The amount of help he needs is a function of his experience and skill level. FAQs about the *subject* (but not the interface) can quickly give the necessary context to newbies and not-so-newbies because in a sense FAQs are a kind of collective wisdom. Ideally I want an expert *guide* to be there when I need it but only when I need it. [I don't expect a disklabel replacement program to provide such a guide but it can be aimed in that direction] > Yes; but it should be largely a hidden action, and come into play only > when the information is *not* returned. At that point, you have to > "ask the human", and it's better to give him a list with "other" on > it and hope he doesn't need to exercise "other". Sure. You always try to first use the most reliable information. > I didn't get this from your original post -- I didn't think you > meant "expand/shrink", I thought you meant between devices. I simply meant moving bits, regardless of the FS structure. Ideally the FS layer API should provide dump/undump/change-size functions but I am not holding my breath. -- bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704220440.AAA03107>