hollombe@ttidcc.UUCP (The Polymath) (05/01/85)
Some weeks ago I posted a request for discussion of the concept "user
friendly". Below is a summary of the responses I've since received in the
mail. Many were very helpful in the writing of a mid-term paper for a
class in systems analysis. Sorry, the paper isn't on the system here.
It's not my best work in any case -- my real-world job got into a panic
state and the paper wound up being written in one night ( :-) sound
familiar? (-: ).
My sincere thanks to all who replied and my apologies for not making time
to respond to you individually.
==============================================================================
"user friendly" should be banished. It has little meaning, but has come to
denote an overzealous system that continually gives prompts, reminders, and
questions, even when you don't want them.
But the intention of your question is the intention of the whole field of
human-computer interaction. There have been books written about it. (I
myself just finished one.) One cannot reduce the complexities of the
issues to a simple sentence (or page or even chapter).
I suppose that if there must be a single answer it would be one about the
attitude of the designer, not only to think of the needs and demands of the
user, but to test, retest, and retest the ideas. Multiple prototyping.
And to pay attention to the problems of the users.
------------------------------------------------------------------------------
Your question is not too elementary, it is too complex. First, the term
"user friendly" should be banished. It has little meaning, but has come to
denote an overzealous system that continually gives prompts, reminders, and
questions, even when you don't want them.
But the intention of your question is the intention of the whole field of
human-computer interaction. There have been books written about it. (I
myself just finished one.) One cannot reduce the complexities of the
issues to a simple sentence (or page or even chapter).
I suppose that if there must be a single answer it would be one about the
attitude of the designer, not only to think of the needs and demands of the
user, but to test, retest, and retest the ideas. Multiple prototyping.
And to pay attention to the problems of the users.
------------------------------------------------------------------------------
The two references that I consider sacred texts are:
"The Adventure of Getting to Know a Computer", John M. Carroll
Computer (IEEE) Nov. 1982 pgs 49-58
"What Makes Computer Games Fun", Thomas W. Malone
Byte Dec. 1981 pgs 258..277
The strongest point of the first is its list of eight pairs of problems
and solutions. These provide an excellent terminology for describing
unfriendlyness (eek-- what a gross word) of a system.
Both have extensive and excellent bibliographies.
I'd be interested in reviews of any later work by these two authors.
------------------------------------------------------------------------------
The problem with your question is not that it is too elementary, but that
it is too general, and therefore too difficult. It is the same question
as "How should I use computers" and "How can I get rich" and "How can
I be happy". All we know how to do is show the systems that are easy
to use (the Mac) or hard to use (JCL) and try to figure out why. There
are a few books that give generalizations, but I am not sure how good
they are. Good luck on your paper!
------------------------------------------------------------------------------
get some users together and test it out!
(user friendly is subjective and needs to be determined empirically)
------------------------------------------------------------------------------
Try Paul Heckel's "The Elements of User-Friendly Software,"
Warner Communications, I think.
larry
------------------------------------------------------------------------------
I don't think your questions are too elementary at all. In fact, I think
they are very good questions. The term "user friendly" gets tossed about
more than a softball on a Saturday afternoon, and sometimes people know
as little about what constitutes "user friendly" as they know about what
constitutes a softball.
My name is Steve Daniels, and I work at Bell Communications Research in
Piscataway, NJ. I've been doing human performance engineering work
both here and at South Central Bell for about 4 years. I'll be happy to
share my opinions and experience, but I must caution you that what I'm
saying here are my own thoughts and not necessarily those of my employer;
I'm not presuming to espouse corporate policy. If you have any questions,
please feel free to call me at (201) 981-3394 before 5:30 EST. Here goes.
User friendliness boils down to knowing your users very, very well.
For example, I work with systems that are used in telephone companies.
My user population is both male and female, young and old, anywhere
from junior high education to postgraduate education, with wide variations
of language skills and knowledge of the the telephone industry.
Different subgroups of users have different functions within the system.
When I design screens, reports, and transactions, I have to ask,
either of actual users, myself, or others who can "speak for" the users,
a whole string of questions so I can "get inside the heads" of the users.
The questions you have to ask can get very basic. For example...
1. What EXACTLY is the user trying to accomplish by sitting down at this
terminal?
2. What does the user know *before* sitting down at the terminal about the
task at hand, either with or without the system?
3. What does the user already know about this system or similar ones?
4. How can I build upon this knowledge?
5. What other tasks does the user do which I can compare and contrast this
task to?
6. What terms are already in the user's vocabulary? I either reuse those
terms or teach new ones.
7. How often will this system be used? You design and training for systems
used all the time is much different from that of systems used occasionally.
Once I know my user(s), I can get down to the real question,
"How do I design the system/application/transaction to best fit
the task at hand?" It can be a very tedious task, trying to understand
where your system "fits" in the designs of the user, but that information
is vital. Otherwise, your system's success is based on chance.
As you can see, I tend to base my work on task analysis. Because my users
are rather diverse and are in a production mode, I also tend to design with
the production, ongoing operation in mind rather than the training mode.
You can't neglect training, however, because a discouraged user becomes
a non-user very quickly. The tightrope between "easy to learn" and "boring
to repeat" is sometimes about the size of piano wire. My preference on
walking that tightrope is to have a simple, thematic design for the
system/task overall, one that the user can relate to without lots of prompts
or menus. Prompts and menus for repetitious tasks get boring so quickly
that the user begins to count the time wasted on answering questions from
a machine. That sometimes means my final design is not as easy to train
as it might have been if I opted for a design more geared toward training,
but the end result is not usually to have a system that is easy to teach;
the end result is usually to have a system that is easy to use day-in and
day-out.
As for training and documentation, I like to write material probably a lot
like your paper is going to be like. Sort of like this.
1. This is what we're going to do.
2. This is why we're doing it.
3. Before you start, get A, B, and C, and you must know D, E, and F.
For each specific task/function, I answer 1 and 2 again for the task,
then go through a few more steps.
4. This is how you do it (and show pictures, examples, etc.).
Usually the examples and instructions are step-by-step, "do this, do
that" sort of thing.
5. Okay, now you do it (test on the knowledge).
6. Give them the answers and pat them on the back for doing it so well.
When it's all over...
7. Tell them what they just did.
-----
I know I've rattled on a lot, but I hope this is helpful. Simply put,
my advice on any user issue is to keep it as simple as possible
and be sure your design accomplishes the same things your user wants
to accomplish.
------------------------------------------------------------------------------
Just one thing I neglected to mention, but you probably have realized this
already. The approach I take may be fine for a production system where the
users are known and the tasks are identifiable, but it may not work so well
for a new system where there are more variables. The principles still
apply--knowing your users and what they are trying to accomplish--but you
might have to add a few steps before this point, like determining who your
users are going to be and what they are going to do.
------------------------------------------------------------------------------
I can only give my own views here. These do NOT represent the findings of any
sort of independant survey.
The main issues are WHEN the system is to output information, HOW MUCH to give,
and of course WHAT.
WHEN is always if asked. For a competat UN*X user, it's never if unasked (look
at ed(1) and the prompt (what prompt?)). For a naive user, more info is often
helpful. The important thing is to be reasonably terse at all times. No-one
likes wading through piles of output to find something out (well, OK, I don't).
The WHAT is accurate, to-the-point, clear information. Israelites may like
parables, but I don't appreciate circuitous documentation.
It's also good to keep typing down to a minimum whilst retaining mnemonic names.
I prefer rm/cp/ls/mv to remove/copy/list/move, but then, I know why they're
named like that. I certainly DON'T like dsw for remove, but it's OK for "delete
from switches".
If a menu pops up, it must pop away again leaving the screen exactly as it was,
as far as is appropriate. As an extreme example, if "delete window" is
selected, the menu must go away before the window is deleted, so that the user
sees it happen. Avoid unseen changes. Here are some randomly ordered points:
Terseness: the system shouldn't offer overwhelming amounts of unwanted
information.
problem - how do we know what's wanted? In particular, some users want more
than others. Could remember how much info each user likes (UN*X example is to
have a HELPLEVEL shell(1) variable).
Orthogonality: system commands & behaviour should be consistant.
example - in a text editor, there should be an obvoius similarity between the
commands to delete a word, delete a character, move forward a word/character.
problem - many commands don't fit into a clean paradigm.
Robustness: the system must recover from errors gracefully. This allows
users to be confident and to experiment without fear of losing work or of
getting hopelessly confused.
Documentation: all of the system commands/utilities must be documented on
paper in a clear fashion. A "Wally Guide" for naive users that can be taken
away and read at leisure is INVALUABLE.
Online documentation surves several purposes, and should be presented
accordingly - "what does the SPLATZ command do?" ; "what is the command to
colour a FRITZ pink?" ; "remind me how to X" ; "let's browse through the stuff
and relieve our boredom". You may find other partitions. Whatever they are,
it is helpful to make them clear at the user level.
Note that more experienced users want terser documentation; they are also
likely to be unwilling to wait long for it, if they're anything like me!
Diagnostics: a systam that spouts
FILE foo.s LINE 45:ERROR SEVERITY 14:LABEL syntactical:TAG SC0194
is disturbing to say the least. When the system reports an error or event, it
must do it in a way that helps the user to understand what's gone wrong, not
leave him [or her...] cowering in the corner. Better would possibly be
foo.s line 45:syntax error - "SPLATZ" unexpected; see ehelp SC0194
and better still if the user doesn't have to remember the TAG (the computer
invented it, so....). It is possible - and undesirable - to be extremely
verbose here. (FLAME at PRIMOS...).
overall: verbosity of output desired by the user is often an inverse
function of the user's competance at using the system.
orthogonal commands anf functionality sets can greatly enhance
the power of system by assisting the user's memory.
there is a tradeoff between terseness and helpfulness that
is related to the user's expertise and irritability.
------------------------------------------------------------------------------
In this light, I am also wondering about the difference between "easy to
learn" and "easy to use" interfaces. An example of something that is
easy to use but is difficult to learn is EMACS (so many commands, and
funny control and meta characters).
------------------------------------------------------------------------------
I had once glanced through a book called "Interactive programming
Environment" by Barstow & ??? which had a lot of interesting observations
and suggestions on user friendly programming. You might find it useful
if you have not seen it yet. Meanwhile if you get your paper on the system
I would like to have a copy.
==============================================================================
--
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
The Polymath (aka: Jerry Hollombe)
Citicorp TTI
3100 Ocean Park Blvd.
Santa Monica, CA 90405
(213) 450-9111, ext. 2483
{philabs,randvax,trwrb,vortex}!ttidca!ttidcc!hollombe