Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site ulysses.UUCP
Path: utzoo!linus!decvax!harpo!gummo!whuxlb!pyuxll!eisx!npoiv!npois!
hogpc!houxm!ihnp4!cbosgd!mhuxi!mhuxa!ulysses!gsp
From: g...@ulysses.UUCP
Newsgroups: net.cog-eng
Subject: User-Friendly Re-Defined Access-Efficient
Message-ID: <579@ulysses.UUCP>
Date: Sun, 28-Aug-83 13:50:04 EDT
Article-I.D.: ulysses.579
Posted: Sun Aug 28 13:50:04 1983
Date-Received: Tue, 30-Aug-83 13:46:30 EDT
Organization: Bell Labs, Murray Hill
Lines: 84
User-Friendly Re-Considered
User-Friendly. We have all used the term and many of us have come to
cringe when we hear it. To many inside software development, it means
menu after menu of verbose interaction, but to compu-phobics it means
much wanted hand-holding. The term has become synonymous with
designing for the novice and a selling point for software houses.
I have discarded the term because of its negative components:
exclusive menu access to resources
excessive verbiage in outputs
repeated requests for confirmation
These are not bad concepts to incorporate into a user-interface,
but when they are the ONLY interaction mechanisms, I don't like them,
and I think experienced users try to avoid them.
It is useful to clarify the purpose of a user-interface. I think:
A USER_INTERFACE SHOULD PROVIDE EFFICIENT ACCESS TO RESOURCES.
Let me explain this statement in more detail.
First, a RESOURCE is any capability provided by a system.
It does not have to be a software system, but suppose for now it is.
Second, in providing ACCESS to RESOURCES,
a user-interface must let people know two things:
WHAT RESOURCES EXIST
HOW TO USE THE RESOURCES
Third, a user-interface should make users efficient by doing two things:
LETTING USERS ACT QUICKLY
LETTING USERS ACT ACURATELY
Despite the simplicity of this definition, it has many implications,
especially about so-called "user-friendly" systems. If users do not
know what resources are avaiable, it is the obligation of the
user-interface to make them aware. Menus can be useful for this
purpose. On the other hand, if users are already aware of what is
there, menus are a nuisance. If users do not know how to use a
resource, some sort of form-filling or syntax-directed editor can be
useful. Simliar to menus, if users know how to use a resource, such
mechanisms can be more a bother than an aid. Such schemes insure
access to resources, but not efficiency for users who know what they
are doing.
People who claim that because X is bad, the opposite must be good
irritate me. Such dogmatism is rooted in ignorance. If you take my
definition of user-interface seriously, and I hope you do, you can see
user-friendly in a different light. User-interfaces are not supposed
to be useful to novices and a hinderance to experts, but are supposed to
take all the different types of users into account. They must be
verbose when needed, but not otherwise. They must be watchful when
needed, but not otherwise.
Using my definition of the purpose of a user-interface, let's see how I
might design a user-interface. My first concern is that users know
about what resources are available. I check their OPTIONS to see if
they say they know what is there. (Assume they have somehow set
options telling me about themselves.) If they don't know what is there
they see a menu, form, or whatever. If they do, they have to initiate
the interaction. After I know what they want to do, I check their
options to see if they know how to use it. If they do not, I initiate
help. Otherwise, they must specify what to do. If self-proclaimed
experts decide they need help with some new part of a resource, they
should be allowed to get it, using a pop-up menu or some other scheme.
They should not be forced into using a system that exclusively uses
such verbose forms of cummunication. Conversely, users who have not
proclaimed themselves knowledgable should be allowed to escape the
clutches of a hand-holding interface. There are many reasons for this,
but the most important is that:
THERE ARE NO NOVICES AND THERE ARE NO EXPERTS
With systems of even moderate complexity, no one is knowledgable
with all aspects of the system. With parts of the system that I
am knowledgable, I want a terse system, but with parts I am not,
I may want some help. It's really that simple:
A USER-INTERFACE SHOULD GIVE HELP WHEN AND ONLY WHEN IT IS NEEDED
I think the term "user'friendly" has developed ill feelings because
of the presumption by some implementers that talkative caretaking
menu systems are what EVERYBODY wants. They are not what ANYBODY
wants, not all the time. I have changed to the term "access-efficient"
to describe "good" user-interfaces because it is more descriptive
of what I think user-interfaces should accomplish.
Gary Perlman BTL MH 5D-105 (201) 582-3624 ulysses!gsp
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!ittvax!wex
From: w...@ittvax.UUCP (Alan Wexelblat)
Newsgroups: net.cog-eng
Subject: Re: User-Friendly Re-Defined Access-Efficient
Message-ID: <976@ittvax.UUCP>
Date: Tue, 30-Aug-83 09:31:13 EDT
Article-I.D.: ittvax.976
Posted: Tue Aug 30 09:31:13 1983
Date-Received: Wed, 31-Aug-83 12:50:05 EDT
References: ulysses.579
Lines: 35
I think Gary Perelman has an excellent set of ideas, but I see two problems
with his multi-functional schema:
1) Cost in programmer time. There are an awful lot of "hooks" involved in
writing code with pop-up menus and many-layered HELP systems. Mind you,
I'm not saying that these are bad things in and of themselves, but I'm
trying to point out that they'll end up costing the system user a lot
of $$ in programmers' and debuggers' salaries. If you automatically
design this much complexity into systems, you may end up pricing yourself
out of most people's markets (look at the Xerox workstations for an excellent
example: the Dorado (?) is amazing in terms of its abilities, but it costs
$140,000!)
2) Cost in machine space/time. It's true that machines are getting faster
and faster, and that memory is getting cheaper and cheaper. But you can
still easily over-design for the space and speed of the machine that you're
building on. Heck, our VAX experiences significant slowdown in the presence
of three or four TROFF jobs! If you have a user group using this complex
multi-functional system, it's entirely possible that you'll end up with a
too-slow response or a too-large demand on your customer's machine.
Moral: don't over-generalize. When you're building a system, get an idea of
the people who will be using it, the equipment they'll be using it on, and
so forth. Then design in as much 'human factors' as you think necessary.
A shop of UN*X hackers won't care about the same things a brokerage house
would. And (this is for you, Laura) don't let the customers tell you how to
build your product! You're the programmer. You can listen to their suggestions,
but if you let them dictate HOW you build your system, then you're doing a poor
job.
Yes, I know this really isn't a solution, but I doubt you're going to be able
to concoct a good, general solution. The best you can do is set up guidelines
which can be loosely followed. Sorry to pontificate so much.
--Alan Wexelblat
decvax!ittvax!wex
(soon to be decvax!ucbvax!wex.UPenn@UDel-Relay)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!chris
From: ch...@umcp-cs.UUCP
Newsgroups: net.cog-eng
Subject: Re: User-Friendly Re-Defined Access-Efficient
Message-ID: <2259@umcp-cs.UUCP>
Date: Tue, 30-Aug-83 22:27:23 EDT
Article-I.D.: umcp-cs.2259
Posted: Tue Aug 30 22:27:23 1983
Date-Received: Thu, 1-Sep-83 04:04:55 EDT
References: ulysses.579, <976@ittvax.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 38
From: w...@ittvax.UUCP (Alan Wexelblat)
I think Gary Perelman has an excellent set of ideas, but
I see two problems with his multi-functional schema:
1) Cost in programmer time. There are an awful lot of
"hooks" involved in writing code with pop-up menus and
many-layered HELP systems.
That's what libraries are good for! (What else would the author
of the Maryland window library say?) With some reasonable
datastructures, pop-up menus and such are actually quite simple
once someone's done the work once. Jim Lyle has written a menu
package that sits on top of my windows; it does most anything a
programmer might want to do with menus, including side-by-side
display, "masked select", . . . Now, we haven't even started
working on "novice/expert/casual_user" systems here, though.
2) Cost in machine space/time. . . . Heck, our VAX
experiences significant slowdown in the presence of three
or four TROFF jobs!
True, although your example isn't a particularly good one. TROFF
leans heavily on the time side of the time/space tradeoff. There
are *so* many things in there I wanted to rewrite, when I realized
what they were doing! (A quick profile showed that for an 80K
document, one routine was called over 300,000 times! I quickly
made a macro for the push-back character part of that.)
In short (one sentence short), yes, you have a point, but I think
we've already got the machine- and software-tool power to make building
easy-to-use systems easy.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@UDel-Relay
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site ulysses.UUCP
Path: utzoo!linus!decvax!harpo!eagle!mhuxt!mhuxi!mhuxa!ulysses!gsp
From: g...@ulysses.UUCP
Newsgroups: net.cog-eng
Subject: Re: User-Friendly Re-Defined Access-Efficient
Message-ID: <590@ulysses.UUCP>
Date: Wed, 31-Aug-83 22:30:52 EDT
Article-I.D.: ulysses.590
Posted: Wed Aug 31 22:30:52 1983
Date-Received: Thu, 1-Sep-83 10:11:24 EDT
References: <976@ittvax.UUCP>
Organization: Bell Labs, Murray Hill
Lines: 107
Alan Wexelblat (decvax!ittvax!wex) has genuine concerns about programmer
investments and run-time efficiency, but he has put forth the programmers'
"party line" that we have heard for years. His ideas are plain wrong,
and I think dangerous. I will summarize his ideas, explain why they are wrong,
and provide a solution.
His first idea is that my last name is spelled Perelman. It is Perlman.
His two problems with the concept of "access efficient" software
(my backlash at "user friendly") follow. My comments are indented.
(1) Programmer time: It takes a lot to put pop-up menus (etc.) into programs,
and this will cost money for end-users.
This is wrong on two counts. First, if programmers were given good
tools to build user interfaces, having a pop-up menu would be no
more time consuming than using printf to prompt for input.
Because of the lack of good tools, I have worked on the Interface Arsenal,
a set of C libraries for developing user interfaces
(presented at the last USENIX). Second, programmer time is a negligable
investment compared to fixed costs like equipment and risks like
marketing.
I should point out that one of the major programming investments
in the Interface Arsenal has been to make it easy for PROGRAMMERS
to program user-interfaces. Of course, these tools are supposed to
make the programs easy to use by USERS. The point is that good
tools can do powerful things with little effort; that is why we
build libraries.
2) Cost in machine space/time. Having all this fancy software will
slow our machines.
There is some truth to this, but it is not reason enough to
throw away the idea of building good user-interfaces.
Two points: First, much user-interface software is poorly written
(it is often done by well meaning psychologists who don't know about
program efficiency). Huge imporvments in most programs are possible.
Second, user-interface software is io intensive, not compute bound
(typically), and so does not necessarily slow down a system. It
usually does not slow down a user as most processors are fast enough
to keep up with user reading and typing speeds.
Moral: don't over-generalize. When you're building a system, get an idea of
the people who will be using it, the equipment they'll be using it on, and
so forth. Then design in as much 'human factors' as you think necessary.
A shop of UN*X hackers won't care about the same things a brokerage house
would. And (this is for you, Laura) don't let the customers tell you how to
build your product! You're the programmer. You can listen to their suggestions,
but if you let them dictate HOW you build your system, you're doing a poor job.
Knowing your end-user population is highly desirable, but designing
exclusively for "what you think they are" can get you into trouble.
You may find your programs used by people you never anticipated,
and they will have troubles if you did not provide a general solution.
Then people like Don Norman will write nasty articles about you in
Datamation.
Knowing the equipment they will be using is a similar problem.
If you design for systems like 1200 baud dumb terminals, you may
find your software is outgrown. Certainly fancy things can be done
on fancy terminals, and trying to do them on dumb terminals is a
mistake. While a menu might be good at 9600 baud, it might be
a nuisance at 1200 or, ugh, 300. By developing user-efficient
software, I really mean it has to bee efficient for the users'
time, so in many cases, the software must be baudrate/terminal/etc.
sensitive. To design for one hardware configuration is wrong
in most cases (that means for a blit as well as for a printer).
Designing adaptable software is harder, but with libraries,
it can be done. Look at termcap (forget curses for now) for
terminal independence! Years ago, people would have said,
"It can't be done. I won't listen. Look, I'm blocking my ears."
Shortsighted. We must have vision and hope.
Telling a programmer to "design in as much human factors as you
think necessary" is like telling soldiers to exercise as much
force as is necessary, except in the opposite direction.
Programmers do not know best. It is just that simple.
I'm not saying psychologists do, nor end-users, but I put most
programmers just above marketing types when it comes to insight
in these areas. When I program, I lose track of many objectives
and need outside criticism to get a clear view. I think everyone does.
Don't forget that UN*X hackers and brokers are all people
who have similar cognitive limitations. To say they are completely
different (X doesn't care about what Y wants) is shortsighted.
That last part about not listening to customers is also shortsighted
and a huge overgeneralization.
I don't like to shoot down what people say, but that article was
rediculous. I would not have cared, except that his ideas are
dangerous, of the bipolar type I have argued against. You can't
get up on a pedestal and shout out ideas without weighing all sides.
Developing user-interfaces is a complex balence between user AND
programmer AND hardware limitations. What must be done is:
IDENTIFY WHAT MUST BE DONE AND WORK TOWARD IT
I do not like to find myself in the company of people who say "can't."
Yes, I know this really isn't a solution, but I doubt you're going to be able
to concoct a good, general solution. The best you can do is set up guidelines
which can be loosely followed.
Ugh!
Gary Perlman BTL MH 5D-105 (201) 582-3624 ulysses!gsp
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!decvax!ittvax!wex
From: w...@ittvax.UUCP (Alan Wexelblat)
Newsgroups: net.cog-eng
Subject: Re: User-Friendly Re-Defined Access-Efficient
Message-ID: <985@ittvax.UUCP>
Date: Thu, 1-Sep-83 09:20:30 EDT
Article-I.D.: ittvax.985
Posted: Thu Sep 1 09:20:30 1983
Date-Received: Thu, 1-Sep-83 17:08:04 EDT
References: <976@ittvax.UUCP> ulysses.590
Lines: 43
Hmmm. First, Gary, let me apologize for misspelling your last name. I hate
it when people goof mine, and I'm sorry I wasn't more careful with yours.
Second, let me explain where I'm coming from. I agree that I overgeneralized.
That's wrong in itself. But most of my experience in interface design hasn't
been on nice powerful UN*X machines, with libraries and directory trees and
tools galore. Most of the businesses that I'm familiar with are at the level
of a PC or two, or perhaps slightly above. I'm lucky if I have a Pascal to
work with. If I'm really unlucky, I'm stuck trying to customize/improve
something that someone else has written, in assembler or (YEECH -- are you
listening, Mr Pournelle?) BASIC.
On machines like these, space and speed definitely ARE factors to be considered.
Furthermore, most of the companies I'm doing this work for are only going to
use it in-house; so, the cost of my time is quite significant. Also, they're
not likely to upgrade equipment all that fast (they usually don't need it, or
can't afford it).
I think this is a significant problem. Look at how many businesses own PC's
vs how many own VAXEN. Just because they have a micro is no reason for them
to have a bad user interface, but there's a limit to what I can do, given
that it is a micro. And this problem is going to get bigger, not go away.
Lastly, I want to defend my statements on the programmer as human-factors
designer. I'm sorry if I over-generalized, but I'll bet dollars to
doughnuts that I know better than the customer HOW to build a user
interface. I need to hear suggestions and criticism about WHAT goes into
the interface, but the methods should be left to the programmer. Of
course, there are exceptions. If I build something and the customer says
"I hate it; it's hard to use," then I've failed and should redo it. No
doubt about that. But far more often, the customer insists on "a menu system,"
or something (as in Laura's example) that is really counter-productive.
If the programmer does not talk the customer out of such ideas, then s/he is
not doing the job properly.
Maybe you're right. Maybe the average programmer does build lousy interfaces.
In that case, I apolgize again, since I put a "we" where I meant to put "I".
I think I design good systems, and the people I have worked for seem pleased
by them.
--Alan Wexelblat
(until 9/2: decvax!ittvax!wex)
(after 9/12: ucbvax!wex.UPenn@UDel-Relay)