Date: Mon, 21 Apr 1997 18:49:07 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bakul@torrentnet.com (Bakul Shah) Cc: imp@village.org, hackers@FreeBSD.ORG Subject: Re: disklabel -- owner? Message-ID: <199704220149.SAA24616@phaeton.artisoft.com> In-Reply-To: <199704212313.TAA02238@chai.plexuscom.com> from "Bakul Shah" at Apr 21, 97 07:13:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> [And I disagree with Terry when he says if you need a FAQ it is
> an interface design error].
If the Questions are "Frequently Asked", then your defaults are
wrong, or you need to offer classes of defaults instead of defaults.
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.
Any place you do have a question, "?" should be a valid option,
and it should explain the consequences of whatever A/B choice is
being offered.
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). There's
a reason that phone number are 7 digits: the average human can
only keep 5-9 items straight at a time. Offer them more options,
and the melt down into "Where's The FAQ?" or "WTF?" mode...
> What I meant is that it should *not* use partition info. since that
> is not a property of a disk. Also, like MIB, PPD etc. it should be
> in a OS/{scsi,ide,...} neutral fashion and disktab is not quite it.
> For old disks a database like this is very useful as they don't
> always return the info or the driver doesn't do the right thing.
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".
> > : - It should allow *moving* a partition or a slice.
>
> > Beyond the scope of my time for some time to come, unless someone
> > wants to fund this at my usual rate :-)
>
> Notice I said *move* not expand/shrink. Think of this as equivalent
> to `memmove()' instead of `memcpy()'! Not hard to do.
I didn't get this from your original post -- I didn't think you
meant "expand/shrink", I thought you meant between devices. I'm
still not sure that this isn't a "newfs"-type level option that should
be logically seperate... even if the user interface hides the
distinction.
Regards,
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704220149.SAA24616>