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!