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: gsp@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