Issue 2 -
April 2000
Writing
user friendly programs
Writer:
Matthew River Knight
What makes a
program good from the users point of view? Clearly a program that
has so few bugs that the user is unlikely to come across one is
on its way to becoming a good program. Clearly, how fast and how
small a program is are aspects of program efficiency, and users
do like programs that get the job done quickly. Just about
everything else is a matter of program elegance. Two programs may
carry out the same job using roughly the same amount of time and
memory, but deliver entirely different degrees of service to the
user. One may be easier to use than the other - this is a
question of program design and the so-called user interface. One
may crash (ie. not complete the job) given only a small amount of
user ignorance or perversity, wheras the other may allow the user
the liberty of completely ignoring any instructions concerning
The 'proper use' of the program. Other important aspects of
elegance are not so obvious. Take, for example, maintenance and
extendability. A program may do the job in hand but what about
tommorow's job? Some programs can be modified easily; others are
such a nightmare that it is preferable to start from scratch!
These and other aspects of elegance are mainly about using a good
programming method and testing the product well, but this is not
true of the degree to which a program is crash-proof. A good
program is well- written and behaves well in the hands of the
user!
In the early
days of computing, the demand was for a program that did the job
and no more. A user would ask a programmer to produce a program
that would solve a specific problem and, if the result was a
program that worked when treated with care, then everything was
fine. Users had to be content with what they got! These days,
however, there is no excuse for producing a scrappy program along
with a list of do's and don'ts. Indeed, the average user demands
a program that not only works in the sence of getting the right
answer and being fairly bug-free; he also wants a program that is
pleasing and easy to use, and does not crash no matter what is
thrown at it.
The main
reason for this is that the number of quality programmers is
increasing. This has led to an increased awareness that things do
not have to be quite so bad. Consider the scenario; you are
demonstarting your program to a group of fellow programmers and
descover that you are the only one capable of driving it without
error messages springing up like weeds. You will quickly find
that this will be considered an unacceptable failure of the
program. Notice that in this case, what is the heart of the
problem is not really a bug, in the sence of an error in the
program. It is simply that the program has no way of dealing with
unexpected events.
In order to
work around these problems, it is necessary that your program is
tested, over and over again, with a view to make it capable of
handling whatever is thrown at it. It would not be unwise to
allow a number of other users to test the program for you, and
then report any errors that occur.
Once you have
a fairly bug-free, uncrashable program, the only way that you can
improve it is to work on the user interface - that is, improve
the way that the program accepts and delivers data to the user. A
popular term that is used to describe a program that a user will
find easy to use is user-friendly. If your program is
uncrashable, then it is well on the way to being user-friendly
and it will take very little extra to make it easy to use. Some
programmers manage to write user-friendly programs without even
thinking about it. Others manage to take the user through the
most unnatural sequence of badly-formed questions and deliver
responses that are totally uncomprehensible! Apart from a list of
hints and tips, there is not very much that can be done to guide
the construction of user-friendly programs. The range of
different user interfaces is just too great. However, there is
one rule that is never to be forgotton - the user is (nearly)
always right. If you allow someone to use your program, listen to
what they have to say about it and the way they use it. Sometimes
users critisise a program because it fails to meet their specific
need. In each case it is up to the programmer to decide if the
critisism or request for extra facilities is justified. Sometimes
the extra facility is desirable but just too difficult to include
in a program. One form of user feedback that should never be
ignored is the mistakes they make in using your program. For
example a program asks:
Largest value
is?
and then
Smallest
value is?
and the users
keep on typing the smallest value first, then change the order of
the questions! Mistakes in answering the programs questions are a
sign that either the questions are badly phrased or are in the
wrong order. Some general points to keep in mind while trying to
improve the user-friendliness of a program are:
1. Always ask
the user clear unambiguous questions and never use jargon unless
it is the users jargon. In fact, employing the users jargon and
well- established abbreviations is one way to ensure that a
program is user- friendly. For example, it is better to use
"VAT" than "value added tax" in an accounting
program aimed at accountants.
2. Always
allow the user to correct any entries that are made as responses
to questions. In other words, avoid the use of INKEY$ to accept
single character responses from the keyboard unless you have a
very good reason. Everything typed at the keyboard should end
with a carriage return to indicate that input is complete.
3. A program
should accept as correct any user responses that make sence to
the user. So, for example, "YES", "Y",
"y", "Yes" or "yes" should all be
acceptable in answer to a question.
4. Do not
give the user too much information at any one time. The best
solution is to give the user control over how fast information
appears on the screen but, whatever happens, output should never
shoot off the top of the screen before the user has had time to
read it. Always use both upper and lowercase. Users can read this
faster than upper case only.
5. If you are
using color and/or sound, use them sparingly. Use color or
inverse video to highlight important messages rather than for
every message and pay attention to the way the whole screen looks
with the use of high- lighting. Use sound only to draw attention
to something on the screen. For example use it when something
first appears, when the user is expected to make a response and
when the user makes a mistake. Good use of sound in graphics
games should make the sound appear to come from whatever it is
drawing attention to on the screen. This can be done by
synchronising sound and vision.
6. Try to
give the user as much control as possible over what happens in
the program. There is nothing more frustrating than finding you
are in the middle of a program and have just caused it to do
something unwanted which not only takes a long time but also
allows you no way of stopping it. It should be possible for the
user to restart the program from any point without having to
reach for the machines reset button.
7. If your
program spends a long time working something out, it is
comforting to the user if it occasionally prints a message to the
effect that it is still awake!
8. When the
user makes a mistake, try to correct the mistake by giving an
appropriate message. Dont think of such messages as error
messages; think of them as correction messages! First tell the
user what was wrong, without using jargon, then suggest what
might be the trouble. It is always tempting to produce error
messages that are either very technical or friendly in the
extreme. Messages such as ** INTEGER RANGE ERROR ENCOUNTERED **
and ** You got it wrong didn't you! ** are both to be avoided.
A list of
hints and tips of this sort could go on forever by becoming
increasingly detailed. The best thing to do is to make your own
by observing and learning from some friendly users!