[95235] in RedHat Linux List
RE: downfall of linux? my my editorial ..
daemon@ATHENA.MIT.EDU (Braden N. McDaniel)
Fri Oct 16 04:12:48 1998
Reply-To: <braden@endoframe.com>
From: "Braden N. McDaniel" <braden@shadow.net>
To: <bobj@eskimo.com>
Cc: "Red Hat Mailing List" <redhat-list@redhat.com>
Date: Fri, 16 Oct 1998 04:13:12 -0400
In-Reply-To: <362623EF.8A9E668A@eskimo.com>
Resent-From: redhat-list@redhat.com
> -----Original Message-----
> From: bobj@eskimo.com [mailto:bobj@eskimo.com]
> Sent: Thursday, October 15, 1998 12:34 PM
> To: braden@endoframe.com
> Subject: Re: downfall of linux? my my editorial ..
[snip]
> Braden N. McDaniel wrote:
> >
> > > -----Original Message-----
> > > From: bobj@eskimo.com [mailto:bobj@eskimo.com]
> > > Sent: Sunday, October 11, 1998 3:14 PM
> > > To: redhat-list@redhat.com
> > > Subject: Re: downfall of linux? my my editorial ..
> >
> > [schnip]
> >
> > > It seems there is contention about at least two issues. One is
> > > whether it is best for Linux to grow to a larger user base, and
> > > therefore probably in the direction of more applications, and
> > > more user crutches, and less required user knowledge.
> >
> > [mo' schnip]
> >
> > Anyone who thinks that enhancing a user interface is about supplying
> > "crutches" has totally missed the point.
> >
> Yes, I suppose I am guilty of thinking along this overly narrow line.
> I'll try to widen my scope. I know the UI technology addresses a much
> more comprehensive goal.
>
> > An "ideal" UI should be totally self explanatory. There
> shouldn't need to be
> > a manual, because the user will be able to accurately intuit what will
> > happen based on easily-parsed information displayed.
> >
> I agree here too. But, for example, I found the Mac icons not so
> intuitive when I had to use that system a few years ago. Ditto the
> MSW screen interface, and in this case the menu system didn't impress
> me favorably.
As I said, it's an ideal... A picture may be worth a thousand words, but
your average UI icon isn't even worth three if the person looking at it
doesn't recognize the context it is supposed to suggest.
Realistically, there is only a handful of actions for which you can pick an
icon that will give 100% of people an accurate hint of what what will happen
100% of the time.
Much of visual UI design is concerned with finding good "idioms." An icon is
a kind of idiom in this context, but UI idioms don't have to be strictly
pictoral. Drag and drop is an idiom. Generally, an idiom will be a
simplified way of looking at a potentially complex set of actions. There
just *aren't* accurate "real world" analogies to all the things a computer
can do, so we have to find idioms that are unique to the context of
computing. So idioms aren't automatically intuited (say, by someone who has
never used a computer before). They have to be learned. But once they are
learned, idioms can build upon other idioms, and users familiar with a few
fundamental idioms can learn new ones relatively easily (as long as they are
well-designed).
Remember that "intuition" is *not* instinctive. It's learned. So it should
be no surprise that the intuition one can have for what a computer will do
is also developed by using the computer. It is not the responsibility of a
good UI to *change* this (I would argue that that can't be done), but to aid
a user in developing the appropriate intuition.
Sometimes providing this learning path threatens to impinge upon the
efficiency with which experienced users use the interface; however, I think
this can usually be avoided. When it can't, a compromise must be struck.
> Yet Linux, with its command line and multiple xterms,
> makes me feel able to completely understand what I am doing. I admit,
> though, that I often use a temporary xterm to test what a command is
> going to do before I launch it and make a bad mistake.
I use a command line for many things too; but it's not a UI that will ever
be popular with the mainstream, because it demands that the user first learn
how to talk to the computer. Most people *expect* the computer to know how
to talk in *their* language these days, and that's what a GUI can offer. And
a good UI will provide safeguards of some form to prevent a user from
unwittingly making an egregious error.
> > That's an ideal. It's probably not possible, but we've come a
> long way since
> > the command line was the state of the art, and I think we can
> get quite a
> > bit farther.
> >
> > "Less required user knowledge" is a *good* thing. You don't
> have to know how
> > a CRT works to channel surf on a TV, and you don't have to know how to
> > rebuild your engine to drive to the Quick E Mart to get some
> milk. And just
> > because someone doesn't know how to write a shell script doesn't mean
> > they're computer illiterate--there *are* fields of expertise
> out there other
> > than Unix.
> >
> > Braden
>
> And here too I agree. I'm an engineer, and computer usage is just a
> means to an end for me. I'm not an expert at all. I often need help.
> Fortunately the Linux community abounds with helpful people. I want
> to observe, though, that often knowing *exactly* what a command will
> do *is* important. I don't think icons can tell me that.
With most functions that will be available in applications, the best way for
a user to find out what happens is to experiment. UIs should encourage
experimentation--this is why Undo is so important.
There are a few situtations in which Undo cannot really be implemented, in
which case measures need to be taken to make it perfectly clear to users
what will happen. Ultimately, however, I think the user's learning
experience for such aspects amounts to "once bitten, twice shy." Given most
persons' tendency not to look before they leap, I'm not really sure this is
avoidable.
> And knowing
> where all of one's files are located seems to be important; I don't like
> assigning the locations of my files to the UI (as in MSW). Of course,
> in a computing environment such as discussed by Gelernter in "Machine
> Beauty", where one's files are located on computers all across the
> internet, my preference is clearly short sighted and outdated.
I'd also suggest reading what Cooper has to say about this in "The
Essentials of User Interface Design" (this book is kinda Windows oriented,
but provides excellent coverage of many concepts that are universally
applicable). He notes that the disc filing system is mostly an artifact of
implementation, which should probably be hidden from the user. He suggests
that a more flexible, abstract filing system be presented in the UI, in
which users can organize their files independently of how they appear on the
disc (or, potentially, the network).
> I guess that a streamlined, simple, intuitive UI would be a GUI. Is
> that right? If so, what do you think about the statement below? I
> got this from Paul J. Bell, in response to a posting I made:
>
> ("Paul J. Bell" <paulb@nomurany.com>)
>
> "a small aside, IMHO, (humble yes, but backed by more that 40 years
> of experience) is that windows, including 3.x, 9n and nt, has a basic
> flaw, that is, the window manager/gui is an integral part of the
> operating system. among other things this means that any flaw in
> the gui will crash the system. in a multi-user system (which windows
> surely isn't) this is unforgivable. in Unix (linux) 'X' (and it's
> window manager) are just another user program, so a crash just
> affects that user, the system continues to run. in other threads i
> have mentioned systems that i am aware of (in Wall Street financial
> institutions) Sun systems that have not been re-booted for more that
> 4 years, 1-2 years is common. with windows this just isn't possible
> since the gui will never stay up that long."
I agree, but this is not something that is necessarily unique to a GUI. A
CLI that is similarly tied to the underlying infrastructure would be just as
much of a handicap if it were to crash. GUIs, however, are generally much
more complicated programs than CLIs, and thus more likely to be crash prone.
A robust system will provide a layer of abstraction between *any* UI and the
underlying subsystem, and a way of restarting the UI if it fails for some
reason.
> I'm not computer literate enough to know whether this suggests that
> a *very* intuitive UI would necessarily suffer from this "basic flaw".
> I also don't know whether the MSW flaky behavior derives from this
> flaw or not. But it adds to my concern about getting further and
> further from the command line, at least for the type of work I do.
I don't think it does: interface should be separable from implementation. I
don't see anything special about GUIs that would prevent that from being
possible.
> Thanks again for responding. I apologize for being so verbose. I
> hope that at least some of what I have said makes sense, even though
> I suppose it's wrong nevertheless.
Sheesh... Have a little more conviction. ;-)
Braden
<http://www.endoframe.com>
--
PLEASE read the Red Hat FAQ, Tips, Errata and the MAILING LIST ARCHIVES!
http://www.redhat.com http://archive.redhat.com
To unsubscribe: mail redhat-list-request@redhat.com with
"unsubscribe" as the Subject.
