Man Machine Interface

Compendium on user-friendly design by A. Fog, Copenhagen Engineering College, 2000.

Contents

What is Man Machine Interface?

General Principles

Feedback to user The user should be in control Predictability Transparency Never interrupt the user Can I guess what the user wants? Error tolerance WYSIWYG Speak the user's language Design should reflect the user's logic, not the constructor's logic The design of a button should reflect its importance Provide alternative ways out of a situation Accessibility to handicapped users Novices versus experienced users Standardization Open standards

The design process

Convincing decision makers User profile Involve users in the design Usability test Feedback from customers Track user behavior

Specific technical problems

Hardware Software Web design

References

Recommended literature Recommended web sites

What is Man/Machine Interface?

The discipline of Man/Machine Interface is the study of communication between machines and humans. A machine can be anything from a wristwatch to a big factory. The communication can be the human pushing a button or the machine flashing a lamp. You have probably often been frustrated when trying to use some apparatus, whether it's a simple thing like a payphone or a complicated thing like a new computer program: Which button should I press now? Why does it beep now? Why does it do something else than I want it to? The study of Man/Machine Interface is very useful for knowing how to design things that are easy to use. This is also called usability. Some examples of usability problems:

how to design a TV so that the user can easily find the desired channel. how to design a car so that the driver can use all the instruments without taking his/her eyes away from the traffic. how to design a piece of software so that novice users can find out how to use it without reading a big manual, and so that experienced users don't get delayed by having to click their way through a lot of menus. how to design an information system at a train station so that passengers can easily find the right train. how to design the control room of a big factory plant so that the operator can overview all the processes and also get detailed information about a particular process.

how to design a medical apparatus so that the doctor doesn't harm the patient by accidentally pushing a wrong button. how to design an apparatus so that people with various handicaps can use it. how to design an alarm system so that surveillance staff don't get too annoyed by false alarms and don't fall asleep when there are no alarms. how to design a computer mouse so that users don't get strain injury when using it all day. how to design a toilet so that users can choose between small flush and big flush without having to read an instruction.

Every serious company developing machines, user hardware, software, household appliances, or any other technical product used by humans should include usability considerations in their design process. Unfortunately, even the biggest and most renowned companies sometimes sell products with quite a poor and confusing user interface. The study of Man/Machine Interface will teach you what kind of usability problems to be aware of in the design process, how to test the quality of a particular user interface, and how to improve it.

General principles

Feedback to user The user should be in control Predictability Transparency Never interrupt the user Can I guess what the user wants? Error tolerance WYSIWYG Speak the user's language Design should reflect the user's logic, not the constructor's logic The design of a button should reflect its importance Provide alternative ways out of a situation Accessibility to handicapped users Novices versus experienced users

Standardization Open standards

Feedback to user
Whenever a user pushes a button, turns a switch, clicks with a mouse, writes a command, or in any other way issues a command to a machine, there must be a feedback telling the user that the command has been understood. The feedback can be a sound, a lamp lighting, a text on a screen, etc. The ideal form of feedback is allowing the user to see things happen. If you turn on a motor you can hear the noise from the motor and see a wheel turning round. It may be a good idea to paint an asymmetric pattern on the wheel so that it is easy to see that it is turning. Then the user will never be in doubt whether the motor is turned on or off. Mechanical switches, handles, etc. may provide feedback simply by the position you put them in. The fader on a mixer gives an excellent indication of its position by the very nature of its mechanical design. A rotary knob is cheaper, but the position can only be seen from the little marking or arrow that most potentiometer knobs have. The up/down buttons on a typical TV remote control have no feedback except the sound it is controlling.

If a device gives no feedback then the user will assume that the command has not been received and accepted. The user may press the button again or think that the device is not working or that he has done something wrong. The response time is important here. Response times should be predictable and preferably small. I once made a computer program that made various mathematical calculations. Most calculations were fast, but one particular calculation took 30 seconds. My test person clicked the button, and as he didn't see anything happen immediately, he pushed the button again. He got frustrated and clicked the button again

and again. After 30 seconds the result from the first click appeared on the screen. But since he had pushed the button twenty times and the system had a command queue, it executed the time-consuming command twenty times. The result was that the system was unable to do anything else for the next 10 minutes! What we can learn from this story is that if a system cannot respond immediately to a command, then there should be an indication that the system has received the command and is working on it. For example, many systems show an hourglass icon to indicate that the user has to wait for an answer. The hourglass only gives a minimum of information. It tells that the system is working, but not what it is working on. A more informative feedback might include information on which command the system has received, what it is doing, and how long time it is going to take. The progress bar shown below is a good solution. It works well because the user understands intuitively that the process is finished when the bars reach the top. (It is a problem, though, that it is difficult to interpret the icons telling which task each bar indicates).

Let's return to the example with the motor. In most cases, no other feedback is needed because the user can hear and see when the motor is running. But there may be situations where the user would need feedback from the switch itself, namely if the motor is not working. A technician repairing the motor would certainly want to know whether the power switch is on or off. If the source of the problem is that the power is missing, then you would want to make sure the switch is off so that the motor doesn't suddenly start when the power is returning. Therefore, the state of the switch should be visible, even if this information is seldom needed. There was a period in the early 1990'ies when silent computer keyboards were in fashion. Consumers in a buying situation were fascinated by these keyboard which reacted to the light touch of a key. But the problem arises when a busy user accidentally strikes a key lightly without pressing it all way down. The user doesn't know whether

the system has interpreted this touch as a keystroke or not. This process interrupts the user in his line of thought because he suddenly has to focus on the trivial problem of whether a letter has been written or not. Therefore, all keyboards should have a click mechanism. You can not only hear the slight noise from the key, you can also feel the click. The click feeling comes from the fact that the mechanical resistance against your finger suddenly drops off when the key has passed a certain threshold. This is also called tactile feedback. The click feeling is very important for experienced typists because the tactile feedback is a very natural way of knowing whether you have done something right. It enables you to work faster and more relaxed than when you have to look at the screen all the time for feedback. The strength of a feedback should reflect the importance of the situation. The trivial touch of a key should normally give only a light sound, while an action with big consequences, such as the starting of a big and dangerous machine, might produce a somewhat stronger sound and turn on a big indicator lamp. Some machines give a loud beep every time a key is pressed, which can be quite annoying for the user and particularly for other persons nearby.

The user should be in control

Imagine this situation: A man sits in front of a computer screen. A message on the screen says: Enter name. The user writes his name. Nothing happens. The user finds out that he has to press the Enter key. Computer says: Enter address. The user enters his address. After a few more questions the computer says: Enter fax number. The user has no fax, so he just presses the Enter key. The computer repeats: Enter fax number. The user writes 0 and presses the Enter key. The computer says: Illegal entry. Enter fax number. The user looks up the fax number of his wife's workplace and enters the number. The computer accepts the fax number and says: Enter account number. The user has no account number, so he writes 123456789.

The computer says: Illegal entry. Enter account number. By now the user has realized that he has got into something wrong. He writes: Stop. The computer says: Illegal entry. Enter account number. The user writes: Help. The computer says: Illegal entry. Enter account number. The user presses the Escape key several times, but nothing happens. The user turns off the computer and looses his data. What is wrong here? The problem is that the computer issues commands and expects the user to obey. The user would certainly prefer that he can make commands and the computer obey. The computer should be a helpful servant, not a cruel master. How is this possible? The picture below shows the answer:

The user clicks a menu that says new user. Then he gets a dialog box where he can write his name etc. He can see at once which information is needed, so there is no need to write a name and address if he doesn't have an account number. He can enter the details in any order he wants. He can press the Cancel button if he regrets. He can press the Help button or the question mark button if he wants to know what Account number means. In the former situation the user gets stressed and frustrated because the computer is controlling him and taking away his freedom to do what he wants. In the latter situation the user is happy and relaxed because he is controlling the computer and can make it do what he wants.

Predictability
Imagine that you are writing a complicated text. Your screen looks like this:

Now you want to write something more. What happens when you start writing, let's say by pressing the A key? The highlighted text is deleted and replaced with the new text! I am sure all beginners have made this mistake. A novice user would certainly expect the A key to write an A, not to delete text. Even the most experienced users sometimes make this mistake when they are not looking at the screen and have forgotten that there was something highlighted. The problem here is that the behavior of the A key is not always the same. If there is no highlighted text then it just writes an A. If there is highlighted text then it deletes the text and replaces it with an A. You cannot expect the user to look at the screen all the time, so everybody can make mistakes when the same key doesn't always do the same thing. Of course, there is an idea behind the principle that you can make corrections by highlighting the unwanted text and then just writing something else. But it only saves you one keystroke, the Delete key. And the consequence is that you may inadvertently loose a big piece of text that you have problems recalling. (There may be an undo function which can restore the deleted text, but if you don't discover the mistake immediately, it may be too late).

Avoid modes!
There is a similar problem with the CapsLock key. A letter key produces a capital letter when the CapsLock is on, and a small letter when the CapsLock is off. Technically speaking, the keyboard can be in two

different modes: CapsLock on mode and CapsLock off mode. The meaning of the keys depend on the mode. Older systems may also use NumLock, ScrollLock, and Insert keys to produce different modes, but the use of these is avoided in most modern systems because modes always cause usability problems. The CapsLock key still lives because there is no good alternative. When modes are unavoidable then the mode should be displayed in a very conspicuous way on both keyboard and screen, for example by giving the cursor a different shape or color.

Transparency
Transparency means that the user can easily find out what is going on behind the surface. A mechanical device may simply be designed so that the movements of important parts are visible or it may have a control panel showing the state of its internal parts in an intuitively understandable way. In electronic devices there may not be any mechanical parts to show, so the state of internal actions must be visualized with text or drawings. It should be clear where a program stores its files so that the user can make backup copies or delete old files for security reasons.

The picture above shows a queue for a printer. Whenever commands or jobs are queued, there should be a visual representation of the queue, and preferably a way to cancel jobs in the queue or change their priority.

The payphone shown below is an elegant example of making a function visible. You simply place your coins in the slide on top before making a call. The coins then fall down, one by one, as they are needed. It is very

clear to the user what's happening, and nobody can be in doubt how much money he has left to talk for. The user can even remove coins or change their order during the session.

This design is not perfect, though. Rejected coins are returned in a little compartment covered by a metal flap (at the drawing of a twisted coin). The user may be able to hear coins falling down in this compartment, but cannot see them. I would prefer that the coins fall down in an open basket so that they are easy to see and easy to pick up.

Never interrupt the user

Ms Tippy is a fast typist. Right now she is typing a letter from a handwritten draft. Suddenly a box pops up on her screen saying:

Ms Tippy doesn't see the message box because her eyes are at the draft all the time. Her next keystroke is a space, which activates the Yes button and opens her mail program. The rest of her keystrokes go to the mail program where they cause all kinds of funny (or perhaps not so funny) things to happen. Even if Ms Tippy had been looking at the screen, she may have typed several keys in the few seconds it takes to recognize the new situation. These keystrokes could easily cause the message box to close before she had the time to read what it said. An unexpected pop-up box is a serious usability error for several reasons:

It breaks the system's predictability because the unexpected advent of the message box radically changes what the keys do. It violates the principle that the user should be in control. It breaks the user's line of thought, which can be quite annoying.

Need I say more? - Never interrupt the user!

Can I guess what the user wants?

My word processor has a "wonderful" feature. It can guess what I want to write and write it for me. If I write Dear M it will finish the phrase for me and write Dear Mom and Dad.

I just have to press Enter to make it finish the phrase for me, or write something else if I don't want Dear Mom and Dad. But as the previous page explains, the user is not always looking at the screen, and even if he is, you cannot expect him to react immediately to whatever happens to pop up on the screen. What if I actually want to write just Dear M or Dear Mom, followed by a line break. The Enter key does not make a line break, as I expect it to, but instead it makes Dear Mom and Dad. This violates the principle of predictability. My word processor has more "smart" features. If I write the letter i as a separate word, it is changed automatically to a capital I because the dictionary says that the word I is written with a capital I. If I change it back to a small i, the word processor corrects it to the capital I again. It is actually impossible to write a small i, even if I need it as a symbol, an abbreviation, a roman number, or a word in another language. Modern software has many of these "smart" features. But they violate the principle of predictability and the principle that the user should be in control. The software should never do anything on its own initiative, not even correct errors. Neither should it interrupt the user by asking "Do you want to change i to I?". But it may indicate in an unobtrusive way that is has a suggestion for you. For example, it may indicate words not found in the dictionary like this:

Modern web browsers also come up with a suggestion when the user starts to write a URL:

This suggestion is accepted by pressing Enter. This violates the principle of predictability because the Enter key would do something else if the suggestion was not there. The user has to actively delete the suggestion if he doesn't want it. This suggestion is accepted by pressing Tab. The frame that pops up may be disturbing, but at least you can ignore it.

Error tolerance
Human language is generally quite error tolerant. If one word of a sentence is wrong or missing then you can still guess what # meaning should be. Computers are, by nature, quite opposite. A comma instead of a semicolon in a computer program can make a space rocket fall down. This is certainly a usability problem. Humans are not always very careful about the correct spelling of computer commands. Ideally, computers should be error tolerant. For example, it is fairly simple to make a computer accept alternative spellings of a command or a web address. The problem is when you make the computer guess what the user wants and the computer's guess is wrong. As explained on the previous page, the system should never correct what it thinks is an error without confirmation from the user.

WYSIWYG
This acronym stands for what you see is what you get. It is a common buzzword in the design of user interfaces. It means that when you write or draw something in a computer program, then the screen should look exactly as the final document will look when you print it out. The advantage of the WYSIWYG principle is obvious, but it cannot stand alone. Assume that you have made a spreadsheet like this:

Suddenly, you discover an error: The total price should be 90, not 110. On a strictly WYSIWYG view you may be able to change the bottom line from 110 to 90, but you cannot see or change the underlying formula. What you need is a detail view where you can focus on the underlying formula:

Now, you can see that the discount has been added, where it should be subtracted, and you can easily correct the formula.

Actually, I would like to have both a WYSIWYG view and a view of the underlying codes or formulas in any software program that can make a

visual end product. The two views should be shown side by side so that you can focus on a detail in the WYSIWYG windows that looks wrong and then see in the code window why it is wrong and modify the codes to make it right. Whenever you make a change in one of these windows, this change should be reflected immediately in the other window. Word Perfect is the only program I have seen that fully implements this principle. The picture below shows the user interface with the code window below the WYSIWYG window.

Speak the user's language

When I open a document in the so-called PDF format in my web browser, I first get this message:

It is nice that the program tells me what it is doing while I am waiting for the document, but this message is not very understandable. First, the title "Viewing Location" is confusing: I don't want to view a location, I want to view a document. The text "Spawning External Viewer" is even worse: "Spawning" is something that a fish does. It doesn't make sense here, except to a proficient C programmer. The word "External" is also confusing. The viewer is external from the programmer's point of view, because it is provided by somebody else. But as a user, I don't want to think of who programmed which part of my software, I want to concentrate on the contents of the document I am about to see. Therefore: Speak the user's language! You don't have to go to extremes, though. Sometimes users may be offended by a language that sounds too childish, and there may be situations where the users need to learn the technical terms anyway. But in general, you have to use a language that the users understand.

Design should reflect the user's logic, not the constructor's logic
A friend of mine once had a very unfortunate experience with a popular database program. He was working for a non-profit organization and wanted to delete a few persons from the membership file. He did the same commands as he had done many times before, but rather than deleting the selected persons the program deleted the addresses of all 5000 members! When he clicked the undo command the program said that this operation was too big to undo. Need I say that he was terrified...

As my friend had been using this database every day for more than a year, I decided to investigate the program to find out how it was possible for such an experienced user to make such a fatal mistake. The database program was part of a complete package of office programs, including word processor, database, spreadsheet, calendar, etc. The designers of this office package had clearly emphasized to give the different programs in the package a similar user interface. Specifically, the database looked very much the same as the spreadsheet. There was a row for each record and a column for each field, as shown in this figure:

To delete a few records, my friend highlighted the unwanted persons, as shown above, and clicked Delete. The program, not knowing whether he wanted to delete the selected rows or the selected columns, presented a dialog box that looked something like this: Confirm delete

Delete record(s) Delete field(s)

My friend had seen this box many times before, and the program had always made a default selection at Delete records, so that he only had to press the OK button. But for some reason, the program this time made the selection at Delete fields, which he didn't notice. When the OK button was pressed, the program did not delete the selected records, but the selected fields for all 5000 records. Now, let's analyze this problem from a usability point of view. The programmers had decided to give all programs in the office package a similar user interface - good idea. To make the database and the

spreadsheet program look similar, they had decided to present the database as rows and columns. This makes good sense to the user. It makes less sense that you can select a rectangular area covering parts of more than one record as illustrated above. But the core of the problem is that deleting a row and deleting a column are treated as similar operations. This is perfectly OK for a spreadsheet, but certainly not for a database. Deleting a row means deleting a record, deleting a column means changing the basic structure of the database. From the user's point of view, these are certainly not similar operations. The unfortunate event in this example illustrates very well the principle I want to explain here: that the design should reflect the user's logic, not the constructor's logic. From the programmer's point of view, deleting a row and deleting a column are equivalent operations. But from the user's point of view they are fundamentally different. Deleting and creating records in a database is an everyday task. Deleting and creating fields is something you do when you define the basic structure of your database. Probably, this is done only once when you start to make a database. Furthermore, these two operations may not be done by the same persons. Typically, the setting up and definition of a database is done by a technician, while the everyday task of creating and deleting records is done by a secretary. Therefore, the commands for defining or modifying the structure of the database should be put away in a separate part of the user interface where they cannot be confused with the more common commands for modifying records. Generally speaking, operations that represent different working situations to the user should be kept in different parts of the user interface.

The design of a button should reflect its importance

The buttons on a control panel or keyboard should be arranged so that the buttons that are used most often are big and have the most prominent positions, while buttons that are seldom used may be smaller and put away in a corner. Buttons that are used for basic setup and configuration may be put away under a lid, so that people know that these are not for everyday use.

On a photocopier, for example, there is just one button that you use all the time, and that is the big green button you press to make a copy. The picture below shows a bad design of a photocopier control panel. The green copy button is no bigger than the other buttons. For this reason, many people press the gray ON/OFF button to the right instead.

There are certain buttons that cause big consequences when you press them. For example the main power switch at a hospital! Such a button should of course not look like just another switch. This principle is illustrated by the story of Radio X. Radio X is a little non-profit radio station run by uneducated volunteers. New volunteers need to spend time in the sound studio learning how to use all the equipment. Typically, they will play music and say something in the microphones and then mix it together on the mixer. They are told that there is only one button they are not allowed to touch - the one that turns on broadcasting. Nevertheless, it often happened that this button was turned on by accident. The result was that thousands of people could hear the silly things they were saying in the microphones and that another radio station using the same frequency was unable to send. The solution to this problem was to replace the 'on air' switch by a lock with a key. A lock looks very different from all the other buttons and dials. A lock does not say: This is just another button that you can press to see what it does. It says: This is restricted access. Turning this key has important consequences. The key was always sitting in the lock, so nothing prevented deliberate abuse. But that never happened again.

What do these different switches signify?

Provide alternative ways out of a situation

If you have read the page The user should be in control, then you are probably already convinced that there should be more than one way out of any situation. The list below gives typical examples of options that a user might want to have in a critical situation:

Proceed to next step Return to previous step Undo last operation Undo more than one operation Redo undone operation Cancel operation Save data and interrupt operation so that I can resume later Help about this step Help about program in general Leave program

Accessibility to handicapped users

Some countries have laws requiring that devices should be accessible to handicapped users. You shouldn't think of this as a problem, because making a thing easier to use for handicapped people may also make it easier to use for able-bodied people. Remember that even if people are not handicapped, they may not be as agile as you. Children have less physical strength and old people have less precise movements. Some of the handicaps you may consider are:

missing or paralyzed limbs impaired motor skills, shaking or imprecise movements impaired hearing reduced vision, blindness or color blindness reduced cognitive skills

All mechanical devices, like buttons, handles etc., should have a sufficient size and not require small, precise movements. Displays should also have a sufficient size, and the details should not be too small. There should be an appreciable difference in luminance between background and text, as well as other figures that need to be distinguished. A difference in color doesn't suffice. Software should be designed so that it can be used without a mouse. Blind people have reading aids that translate text into synthetic speech or Braille code. In order to support such technical aids, you should design web pages and other text files so that they make sense when read as plain text. All images that contain important information should have an alternative text behind them. Avoid flashing, flickering and animated text and figures. See the page on making web sites accessible for more information. See the list of recommended web sites for references on how to make things accessible.

Novices versus experienced users

Novices

New users that haven't seen your product before need guidance on how to use it. The best guidance may be a self-explaining design that shows what the apparatus can do. If it is a machine then there should be a button or handle for every function. Each button or handle should have a text or an icon telling what it does. If there are many functions then they may be organized into logical groups. There should be no invisible or hidden functions that a normal user would need. In the case of software, the most popular form of self-explaining design is a menu. The items in the menu should be self-explaining so that the user knows immediately which options he has. The user can now click, push or touch the desired item in the menu. A menu with many options should be structured into submenus, each representing a logical category. A hierarchical menu should preferably not have more than 4 5 levels.

Other things you can do to help new users:

Help facilities
A button or menu that gives access to help instructions should be visible everywhere in the program. There should be search facilities so that the user can search for help on a particular topic. A facility that gives instructions about the specific part of the program that the user is in or a specific object that the user is pointing at.

Context help

Fool-proof

Ask for confirmation

Useless or dangerous combinations of commands should be prevented or organized so that they cannot be done by mistake. The program should ask the user for confirmation before carrying out a command that has far-reaching consequences or cannot be undone.

Regret
There should be Cancel and Undo facilities to allow the user to regret his actions.

Experienced users
The heavy user who has to do the same tasks hundreds of times a day will find it annoying if he has to click his way through a lot of submenus every time he does a simple task. Not only is this time-consuming, heavy use of the mouse also causes strain injuries which in the worst case can permanently disable the user. Therefore, there should be shortcut keys for all common commands. Pressing Ctrl+C is definitely faster than clicking the Edit menu and then clicking Copy on the submenu. It is also more convenient because the user doesn't have to move his hand and his eyes from the keyboard to the mouse and back again. The user should be encouraged to use these shortcut keys. A nice way of doing this is to write on the menu which shortcut key the user could have pressed instead:

A user who has discovered the advantage of shortcut keys will soon remember the key combinations for the commands he uses most, while he may still use the menu for seldom used commands. Note that the menu shown above has a third way to the commands: The underlined E in Edit means that this menu can be activated by pressing Alt+E. Some systems allow the user to modify the system to suit his needs. This is called customization. If there is a special command that the user often uses then it is nice if the user can assign a special key combination to this command. Furthermore, the user may define a macro for a long sequence of commands or a phrase that he often needs. Some systems have a lot of menus, icon bars, rulers, status lines, etc. that take up screen space. The user should have the possibility of deciding which of these he wants and remove the rest.

Which user should I optimize for?

The ideal design should of course be suitable to both novices and experienced users. And the customization principle makes this possible in most cases.

There are certain cases where you should pay extra attention to the needs of new users:

Barrier to first use

There is a limit to how much time and energy a user is willing to spend on learning to use a new apparatus. If the user doesn't have success after a few tries he may give up and never come again.

Web sites
A high proportion of the visitors to a website are likely to be firsttime users. They are probably not willing to read any instructions before using the facilities on the website. Therefore, you should resist the temptation of designing a fancy graphical menu that the user can't see is a menu or can't guess how to use. All menus should be self-explaining and have a familiar design.

Public places
Machines in public places for public use have many first-time users. Examples are vending machines, payphones, fire alarms, and information screens in train stations and airports. Such appliances should be designed so that they can be used by anybody, including children, disabled persons, and foreign tourists. Standardization and self-explaining design are important here. If there is a screen with text it may be useful with flags to touch for selecting the language.

Serious consequences
If faulty operation of a machine has serious consequences then you should pay special attention to the usability. Examples are medical equipment and dangerous machines.

Standardization
Which way would you turn the knob on a radio to turn up the volume?

Clockwise of course. No instructions are needed and nobody makes mistakes because a volume control always goes clockwise. The advantage of such a standard is obvious. (The only exception to this standard is a water tap, which goes counterclockwise to open).

The numeric keys on your computer and your pocket calculator are probably placed like this:

While the keys on the remote control for a TV are placed like this:

The keys on a telephone may be placed either way. The lack of a universal standard for numeric keypads is a problem. The user will type faster and make fewer errors if the keyboard layout is always the same. And blind people would certainly prefer that all telephones have the same key placements. Compare the key placements in these pictures:

If you design a control panel or other hardware user interface, be sure to check if there is a standard or common practice for the colors, shapes, and placements of buttons etc. The same applies to software user interfaces. Consistency is important within a system as well as between systems. Does this dialog box look familiar?

A dialog box for saving files looks and works the same in almost all Windows programs. This regularity is obtained by defining the code for such a dialog box in the operating system rather than in the application program. This is a great advantage to the user because he can use a new program immediately without having to learn how to save a file, etc. If you are making a software program, then be sure to make the menus as similar as possible to the menus in other programs (e.g. File to the left, Help to the right, etc.) and use the interface elements that are included in the operating system whenever possible. Some programmers want to design their own dialog boxes in order to add fancy decoration. You should resist the temptation to do so for two reasons. First, the user will need more time to get used to your interface; and second, the standard file dialog in Windows has a lot of extra functionality that you wouldn't include if you were to program it from scratch. Web pages are less standardized, although the need for standardization is high because most of the users that visit a web page have never been there before. If the user has problems figuring out how to use your page and where to click, then he will probably just press the back button and surf somewhere else. A hyperlink should be underlined and colored, preferably blue. Unfortunately, some designers remove the underlining for aesthetic reasons. There is no standard HTML code for menus. Therefore complex menus have to be designed from scratch, and different web pages use very different solutions. The menu on top of this page is designed to be similar to the Windows file manager so that at least experienced Windows users will know how to use it. But of course a more general standard would be preferable.

Open standards
All technical products that have connections with other products need a standardized interface. For example:

A water tube must fit into a standardized threading or fitting A telephone needs a standard plug, standardized voltage levels and standardized number codes A text processor needs to store text files in a standardized format which can be read by other text processors A printer needs standardized plugs, standard paper sizes, standardized commands and text encoding, and preferably a standardized ink or toner cartridge Anything connected to a computer network needs standardized plugs and protocols Any piece of software needs to fit a standardized operating system

There are different kinds of standards and different levels of standardization:

Secret factory standard

The product is intended to be compatible only with other products from the same company. Competing companies need to hack or reverse-engineer these products in order to make something compatible. An example is the format for Microsoft Word documents.

Proprietary standard
The standard is owned by a company and protected by patents or copyright restrictions. Other companies must pay a license fee for making compatible products. Example: the Postscript printer file format.

De facto standard
A de facto standard develops when various companies tend to make their products compatible with existing products from other companies. There is no official agreement, but neither is there any attempt to protect the schemes by secrets, patents or copyrights. Example: Hewlett-Packard Printer Control Language for laser printers.

Official standard

The standard is endorsed and maintained by an official organization. All technical details are specified exactly and published. Example: the HTTP protocol and the HTML language for the World Wide Web.

Open source
A software product is developed by volunteers and the software as well as the complete source code is made public without severe copyright restrictions. Anybody can improve or modify the product and anybody can make compatible products. Example: The Linux operating system. Users need compatibility. Secret and proprietary standards are shunned by consumers because it makes them dependent on only one or a few producers, and they risk that development and maintenance of the products be discontinued. An advantage of the open source principle is that errors and problems can always be fixed, while producers of proprietary software sometimes cover up their bugs or tell the users to just update to the next version (which has other bugs). The disadvantage is that there is no economic incentive to improve the product and its usability.

The design process

Convincing decision makers User profile Involve users in the design Usability test Feedback from customers

Convincing decision makers

The first step in the design of a user friendly machine or software is to convince the decision makers that usability is important and that the usability of existing designs can be improved. The decision makers may be managing directors, marketing department and development engineers in an innovative company. Some of these may have conservative attitudes to design and lack understanding of the importance of user friendly designs.

It is necessary to explain to these persons what usability is. The best explanation is examples. And the most convincing example you can give is probably a videotaped usability test of an existing product from the same company. Persons who are very familiar with such a product cannot imagine that users can have problems using their product until they actually see a video of a user having problems.

User profile
Before starting to design a product you may need to make a profile of the users and the situation of use:

Will each user use the product as a daily routine or only occasionally? Does each user have his own specimen of the product or are many users using the same machine? Is the product likely to be used only by a certain category of people or does it have to be usable by everybody, including children, old people, and handicapped people? Are the users motivated by the fun of using the product, by the improved comfort and convenience that the product provides, by a pressing need, or is the use of this product part of a paid job, etc.? Will the users be discouraged if it takes too long to learn how to use the product? Do the users have the patience to read the instructions or will they want to start using the product right away? Can we expect the users to have a special education or knowledge? Can we expect the users to have received specific instructions or training in the use of this kind of product? Can we expect the users to be able to read instructions in a particular language, or do we need to make instructions in several languages, or may there be users who cannot read at all? Can we expect the users to know technical terms used in the instructions?

This picture shows a ballot from the US presidential election in Florida 2000. The user has to punch a hole in the middle of the ballot at the point indicated by the numbered arrow next to the name of the desired candidate. It turned out that only a few hundred votes separated the two main candidates, George W. Bush and Al Gore. However, several thousand voters punched a hole next to Pat Buchanan though they intended to vote for Al Gore, and many more punched two holes or made other errors. Thus, the slightly confusing design of this ballot may actually have decided who became the president of the United States! The core of the problem here is that the designers haven't taken the user profile into account. The ballot has to be clearly understandable to all adults, including people with lowered visual and cognitive skills. Furthermore, all users are first time users, and they are unlikely to spend more than a few seconds studying the ballot before punching their hole.

Involve users in the design process

Potential users should be involved from the very beginning of the design process. There are two kinds of users that you can involve:

Experienced users
This is the kind of users that have long time experience with using a similar product (a previous version of your product or a

competing product). Experienced users often have many suggestions for things that can be improved.

Novice users
This is the kind of persons that might need your product but have never used a similar product. They are useful for asking the silly questions that you haven't thought about. How do I ... ? Both types of users can be involved in usability tests as soon as you have the first mock-up or even just a drawing of the user interface.

Usability test
The usability test is the most important part of the design of userfriendly devices because this is where you discover the problems. The principle of a usability test is very simple: Tell somebody to use the product and observe him trying to make it work. Write down all the problems he encounters. Remember that the purpose of this test is not to prove that the thing works, but to find errors or problems. You can apply usability tests to any kind of hardware - a can opener, a clock radio, or an aeroplane, and any type of software - a web page, a video game, a word processor, or a scientific program. The type of errors you may find are:

The user has problems finding out how to use the product The user wants to do something that the product cannot do The product doesn't do what the user expects it to The user fails to discover useful features The user uses the product in an awkward way The user gets tired or has ergonomic problems Obviously, you may also discover plain old functional errors

There are many ways to make a usability test. The most common methods are:

Interview the user Tell the user to think loud while he tries to find out how to use the apparatus

Watch the user over his shoulder Leave the user alone and watch him over a closed-circuit television

The last method may require a special set-up or laboratory, while the other tests can be carried out in the field, i.e. in a natural environment for using the product. The TV method may be useful for convincing others that the product has usability problems: The only thing that can convince your old boss that people can't find out how to use the gadget is to show him a video of a user making mistakes. Otherwise, a field test may be more realistic and easier to do.

Test persons and observers

The result of a usability test depends very much on the type of test persons used. Some examples of test user types are:

Novice
This is the person who has no prior experience with this type of apparatus. This type of test person will have the most problems finding out how to use the thing, and hence find many usability errors.

Experienced user
This is a person who has a lot of experience using a similar product. The experienced user will try the advanced features and will know where to look for problems.

Old inexperienced person

Old people learn more slowly and their senses and motor skills are less efficient. For example, my old mom has difficulties doubleclicking because the mouse doesn't tolerate even the smallest movement between the two clicks.

Handicapped user
Letting people with various handicaps test your device can be quite revealing. If test persons with the right handicaps are not easily found then you may study various guidelines for making things accessible to handicapped persons. See the list of references.

Child

Children are curious and adventurous. They want to try everything and may push your device to the limits.

The noble and upright person

This is the type of person who will read the entire manual, including legal disclaimers, before daring to touch the ON button. This is the only person who will find errors in the printed manual, but he will never find out if your program can generate an error message.

The progressive and enthusiastic young man

He will try all the fancy features except the Help button. Tell him to find errors and he will consider it a game to defeat your gizmo. The last two categories of test persons are well illustrated by the following example from my own experience: I wanted to test the program shown below which draws the curves of mathematical functions.

My first test person was a serene elderly engineer. I expected him to be proficient in math. He wrote y = x + 1 in the formula field and pressed Enter. The program showed a straight line. He then wrote y = x + 2. The program showed another straight line parallel to the first one. When he had got to y = x + 8 he stopped testing and said: It works!

The next test person I found was a young technician who suffered from a manic-depressive psychosis. He wrote all kinds of combinations of numbers and symbols without any regard to syntax. Silly as this may seem, it was an excellent opportunity to test if the program could generate useful error messages. At one point he got tired and wrote "I would rather have a beer!" in the formula field. He caught me on that one: I had never thought of what the program should do if the user types plain text (for example a question) instead of a formula. Of course this extraordinary test person tried all buttons and menus in my program. Most of these gave an immediate response, but one complicated root-finding command took 30 seconds to complete. He clicked on this command, and the cursor turned into an hourglass to indicate that the program was working. He ignored this and clicked again and again impatiently. After he had clicked this time-consuming command ten times, frustrated by the lack of immediate response, he tried all the other buttons but got no response. The explanation was that the system served all commands on a first-in-first-out basis. The ten clicks for the time-consuming command were all put into a message queue so that the program was unable to do anything else for the next five minutes. A severe usability error! I had to realize that this crazy man found more usability errors than all my other test persons together. This shows how important it is to have more than one test person. No single test person will find all usability problems in your device. The more test persons you have the more problems you will find. Interestingly, the problems found depend not only on the test person, but also on the observer. Laboratory experiments have shown that the problems found in a usability test depend almost as much on the observer as on the test person. A good test should therefore involve more than one observer as well as more than one test person. You may even observe different types of observers:

The designer
A person who has been involved in the technical construction of the device will observe if the user doesn't behave as expected, but may be inclined to think that the user is at fault rather than the device.

Another user
A person, who has as little knowledge of the internal technical structure as the test person has, can better understand the test person's problems and way of thought.

A usability expert
This type of observer has experience in noticing the test person's problems and frustrations but may not be familiar with the problems specific to this field of application.

Stages in the development

Remember that the attempt to solve one problem may create another problem so that you may have to test again. The complete development process for a new product may involve usability tests at several stages in the process:

Old version
Before starting to develop a new product you may test a similar preexisting product to see what needs to be improved.

Prototype
As soon as you have a mock-up or prototype you may make a usability test. Even a drawing of the user interface on a piece of paper can be used for a primitive test.

Beta version
A beta test may include the aspect of usability.

Final product
The final product should always be tested.

Feed back from customers

No usability test can find all problems because the test situation can never include all the situations that may occur in the real life use of a product. The next page describes how you can use feedback from the end users to find usability problems.

Example

This is the tap in my bathroom. I bought it because it seemed just perfect: The right handle adjusts the temperature while the left handle adjusts the amount of water. Turn the left handle downwards if you want water out of the spout for washing your hands, or turn it upwards if you want a shower. Can you spot any usability problems in this tap? Well, I couldn't until I had installed it. The first time I opened it to wash my hands I got water in my head. Why? Because I am habituated to the fact that you turn a tap counterclockwise to open. On this handle, counterclockwise is up which means shower. It took me a long time to get used to turning the handle the other way, and I still do it wrong sometimes. And every time I have guests and they need to go to the toilet, they come out very angry and wet all over! This is the type of error that you don't find unless you make a usability test.

Feedback from customers

Let's return for a moment to the example of the unfortunate man who lost 5000 addresses in a database by deleting columns instead of rows. Confirm delete

Delete record(s) Delete field(s)

Among the factors that led to this error were:

The user had deleted records in this database hundreds of times before, and every time the program had set the default choice to Delete records. The user was accustomed to just clicking OK. Due to the routine nature of the job, and the fact that he was working overtime Friday afternoon, the user was less alert than normally. The amount of data was too big for the program's undo buffer, so that it was impossible to undo the fatal operation.

None of these factors are likely to be present at a usability test, and possibly not even at a beta test. Hence, it is quite unlikely that this error would be found at a usability test. And even if it were, you might not realize how serious it were, because the user wouldn't feel the terror of loosing 5000 addresses. The only way you can find an error like this is to listen to the feedback you get from the users of your product. User feedback is, in fact, a wonderful source of information which can be extremely useful for improving your product. Unfortunately, most producers fail to utilize this resource. They just consider user inquiries a nuisance and don't use them in any systematic way to improve their products. It is very important to implement a procedure for how to deal with inquiries from customers. All user questions, suggestions, complaints, and requests for support should be filed and analyzed statistically. If several users have the same problem then it is likely to be a usability issue. Users should be rewarded for reporting problems, for example with a letter saying that you are working on the problem, and a free patch or update when a solution has been implemented. This should be part of the quality control organization of any producer of technical equipment. If the users' equipment cannot be fixed and updated right away then you may set up a web page with information to all users on how to deal with known problems. For software products you may make a downloadable patch.

Track user behavior

You may get additional information from tracking actual user behavior. On a web site you can simply use the server logs. Several programs are available for analyzing server logs. On other systems you may set up a system for logging everything that users do. These logfiles can then be analyzed statistically.

If the statistics reveal that many users are making the same errors or have the same problems, then you have found a usability problem that should be solved. The statistics may also be useful for dividing users into categories. If those users that use function A also use function B, while other users use only function C and D, then you can use this information in the design of your menu system so that A and B are in the same submenu, while C and D are in another submenu. If your system has a search facility, then you should make a log of search misses. This will reveal if important topics are missing in your system, if users use synonyms that you haven't predicted, or spell words in peculiar ways. If several users have searched in vain for the same word then that item should be added to the system. The user data in you logs should probably be anonymized to avoid concerns about violation of privacy.

Specific technical problems

Hardware Software Webdesign

Hardware
The following pages describe usability issues concerning specific types of hardware.

Keyboard
There was a period in the early 1990's when silent keyboards were in fashion. The consumer trying a keyboard in a computer shop got fascinated by the silent keyboard that reacted promptly to the light touch of a key. But the silent keyboard is not good for the experienced user. If, by accident, you press a key only halfway down then you don't know if your keystroke has been accepted or not. You have to look at the screen to check it before you press the next key. This interrupts the flow of keystrokes and distracts the brain.

A keyboard should therefore always have the 'click' feeling. This means that the mechanical force against your finger suddenly drops down when the key goes down beyond a certain threshold. This is called tactile feedback, and it makes sure that you are never in doubt whether the key has been properly pressed or not. The size and distance between the keys should of course fit the fingers. The keys should not be too hard to press, but, more important, not too light either. It should be possible to rest the fingers on the keys without pressing them down. A typist will get strain injuries if he cannot rest his fingers on the keyboard. The keys on a keyboard should be organized logically into functional groups. Seldom used keys may be made smaller and put away in a corner or behind a lid. Spaces between the groups of keys make it possible to distinguish the keys by just feeling with the fingers. This is an advantage not only to blind people, but also to trained users who tend to look at the keyboard as little as possible. The QWERTY placement of the keys on an alphabetic keyboard is not optimal but was originally designed like this for mechanical reasons. Other designs are better, but the QWERTY keyboard has become the standard. The same if true for the placement of the numeric keys on computers and pocket calculators, with 789 in the upper rows. Other devices have 123 in the upper row, as shown in the page on standardization. See also the page: The design of a button should reflect its importance.

Mouse
A mouse is a wonderful device to make an interface easy to use for beginners because it enables the user to select or manipulate visual objects. But a mouse has severe disadvantages when it comes to ergonomics. Many people get stress and strain injuries when they have to make precise movements with the mouse. The problems get worse if the mouse ball gets dirty so that it reacts less reliably. Double-clicking is particularly a problem because many systems don't accept even the slightest movement of the mouse between the two clicks. Making a fast movement in one direction (mouse button down

and up twice) and avoiding even the slightest movement in another direction (horizontally) is a stressing task that puts extraordinary demands on your dexterity, and some people are simply unable to do it. All systems should be set up to accept a certain movement between the two clicks or, preferably, have an extra mouse button in stead of the double-click. A lot of alternative pointing devices have been suggested: joysticks, trackballs, pens, touch pads, touch screens, etc., but no perfect solution has so far been found. All systems should therefore have shortcut keys for all common commands in order to enable users to use the keyboard rather than the mouse as much as possible. Using the keyboard is generally faster than using the mouse if the user can remember the commands.

Screens
Computer screens should be so bright that they are easy to read, but not so bright that they irritate the eyes. The brightness should be easily adjustable. The refresh rate should be so high that there is no flickering. A screen should be placed so that there isn't too much light from behind and that reflexes are avoided. Dark text on a light background makes it easier to distinguish small details, but a very bright background is fatiguing to the eyes. A too bright white background should therefore be avoided. A light text on a dark background is more comfortable to read.

Alarms
Do I need to tell you how annoying false alarms are? Of course not. You have no doubt been disturbed countless times by car alarms, burglary alarms, fire alarms, etc. And the false alarms are so common that you probably don't even think of the possibility that the alarm could indicate actual danger. An alarm has no value if it sounds so often that people loose confidence in it.

The volume of the sound should be so high that everybody can hear it, but never so high that it is painful, causes panic, or prevents talking. Surveillance staff who have nothing to do but waiting for alarms get dull and demoralized if they have nothing to do. So dull, in fact, that they fail to react promptly and adequately when an alarm finally occurs. Their job has to be organized in such a way that they have plenty of other work to do when there are no alarms, and they should participate in regular drills to rehearse what to do when an alarm occurs.

Software
The following pages describe usability problems that are specific to software.

Interaction schemes
On the general level, there are very different ways that the communication between human and computer can be implemented. These are called interaction schemes. The most common are:

Batch job

Description
The user enters a series of commands, program code and input data on punched cards, or other storage medium, and puts the pile of cards into a card reader. The reply comes out on a printer. This method was common in the 1970's when personal computers were not available.

Advantages
Technically simple. Many users can share a single computer.

Disadvantages
Difficult to learn the commands. The user has to re-run the whole batch every time he has made a small change.

Command line interface

Description
This is a purely text based communication, typical for text based screens and terminals. The computer issues a prompt, i.e. a sign that it is waiting for a command. The user types a command and presses the Enter key. The computer executes the command and then replies on the next line, reporting the result. A new prompt appears on the next line.

Examples
The command line interface is known from DOS, UNIX, and Matlab.

Advantages
Easy to implement. Uses few computer resources. Fast to use. If the user often uses a certain series of commands then he can store them in a file and execute all the commands by just calling the command file. (In DOS this is called a batch file, in UNIX a shell script, in Matlab an M-file).

Disadvantages
Difficult for beginners: It takes a long time to learn and remember the commands. Misspelled commands cause not very helpful error messages. You cannot see which possibilities you have. You need a printed manual. A user cannot easily handle multiple tasks simultaneously.

Menus

Description
The available commands are listed on a screen or display. The user chooses a specific command by pointing to it or by pressing a key associated with it.

Varieties
On a mouse menu you click with the mouse on the name of the command. A touch screen system is like a mouse system, but the screen is touch sensitive so that you can point with your finger rather than with a mouse. The screen has drawings of keys, each with the name of a command on it. On a keyboard menu there is a function key associated with each command name. The name of the key is usually written to the left of the name of the command. In a softkey system, the function keys are placed right outside

the edge of a screen or display. A text next to each key tells its function. The function of each key depends on the state of the system. In a voice response system, there is a recorded voice saying: Press 1 for this, press 2 for that, ... This is used in telephone exchange systems.

Hierarchical menus
If there are many choices then they are usually structured so that each item in the main menu opens a submenu with more choices. The menus can be structured hierarchically to any depth.

Advantages
Useful for beginners. The user can see immediately which options he has. Instructions are hardly needed.

Disadvantages
Experienced users that often do the same command find it tedious to work their way through several levels of submenus. Detailed information like names and numbers cannot be entered.

Forms

Description
A form has several fields that the user can fill in with information. When all necessary information has been entered, the user presses the Enter key or clicks an OK button.

Varieties
A form can have text fields for entering names or numbers; check boxes for Yes/No information; radio buttons or drop down menus for information with a limited number of choices; indications of whether a particular information is optional or required; cut-and-

paste facilities for copying text from somewhere else; Cancel, Reset, and Help buttons; a what's this facility for explaining a particular field; and tabs for exposing multiple pages of the form.

Advantages
A form is very useful for beginners as well as for experienced users. The interface is self-explaining. The user can see immediately which information is required. He can cancel the operation if he doesn't have the required information. He can fill out the fields in any order. The fields can be pre-filled with default values. Many facilities can be added as mentioned above under varieties.

Disadvantages
The choice of default values can be difficult. The user is likely to use the mouse even though the keyboard may be more effective, because the interface doesn't indicate which keys to use for going to the next field, changing the state of radio buttons and drop-down menus, for activating OK, Cancel, Help, etc. Existing implementations of the what's this context help are not self-explaining so that the novice user who needs it most is unaware of its existence. Likewise, the cut-and-paste function is very useful and time-saving, and most systems have it, but the user is not informed about this facility.

Graphical interface

Description
Objects are shown on the screen and the user can manipulate them directly with a mouse, trackball, joystick, mouse-pen, digitizer, etc.

Examples
In the Windows file manager, you can move a file by drag and drop. You can change the size of a window by dragging its border. Programs for drawing and painting. Video games.

Advantages
Useful for everything that has to do with geometry. Intuitively understandable. Indispensable for software that produces or manipulates images. Useful for manipulating complex data that can be represented graphically.

Disadvantages
Doing precise movements with a mouse or similar device can be very fatiguing and cause strain injuries. Using the keyboard instead may not be possible. The objects on the screen may be intuitively understandable, but it is not obvious to the beginner which objects can be moved, resized, painted, etc., and how.

Speech communication
Description
The system has a voice recognition device for input and a speech synthesis device for output. The system works much like the old command line interface: The user speaks a command and the computer replies with a confirmation that the command has been understood and executed.

Advantages
The user is not tied to a chair, keyboard and screen, but can walk around and use his hands and eyes for other tasks. Useful for controlling machines in dirty working environments.

Disadvantages
Difficult to implement. Error prone. Slow. Useless in noisy environment. The user has to learn the vocabulary and syntax of commands. A printed manual is needed.

Help facilities

Software can have several different kinds of help facilities: printed manual, demo, tutorial, general help, and context help.

Printed manual
Printed manuals are expensive and seldom used. Many users prefer the online help system if they can find out how to use it. A short manual may be helpful, though, for novice users who are unfamiliar with the online help system.

Demo or tutorial
A demo or tutorial can be a very useful introduction for novice users. It should be designed for users with little or no computer expertise, since the more experienced computer users are less likely to use it.

General help

A general help system has many pages, explaining all the features of the program. The general help system should include a structured index that the user can browse through, as well as a search facility for finding a specific topic. The users that need the help system most may not be able to use it. Modern help systems often have a quite complex user interface. The user may not understand the terminology used in the explanations, and may not know which search terms to use for finding a particular topic. The problem of barriers to first use also applies to the help system. If the user has tried a few times to find answers to his problems in the help system without success, then he may never try to use the help system again. If the menu system of the software is self-explaining, then the user may be able to find the right part of the program for performing a particular task, and then use the context help there. This may be easier than finding the topic in the general help index.

Context help

Context help is a facility that gives help information specific to the part of the program that the user is in or a particular object that the user points to. Context help is often implemented in one of the following ways:

Help button

All dialog boxes in a program should have a help button that gives information on the purpose of that dialog box and explains all the fields in the box.

Mouse over

A short text gobbles up when the mouse cursor is held over a particular icon or menu item for more than a second. This can give a short explanation of what the icon is for, but no detailed instructions.

Right mouse click

Clicking with the right mouse button on an object generally gives a pop-up menu of all the things you can do with this object. One of the items should be a What's this? help.

Help cursor

Clicking on a ?-button in the corner of the window or under the Help menu turns the mouse cursor into a question tool. Clicking on an object with this cursor gives a What's this? help for that particular object. The help button is the only one of these four types of context-help that is sufficiently conspicuous and self-explaining for a user with a problem to find it. The mouse-over feature is likely to be discovered by accident, but it would be too disturbing if applied to

all elements on the screen. The right mouse click method is likely to be discovered only by users who know what the right mouse button is for. The help cursor method is likely to be discovered only by the most adventurous user who tries all buttons just to see what they do. Many users never press a button if they don't know what it is for. I would prefer the right mouse click method over the help cursor method because the former fits into the more general principle that the right mouse button gives a menu of all the things you can do with an object. The help button should always be there, because it is the only feature that we can be reasonably sure a user with a problem would find. The text generated by the help button should definitely include information about the other methods for getting help.

Conclusion
Modern help systems are often so complex that they introduce more usability problems than they solve. It is therefore important that you pay special attention to the help system when performing a usability test on a software program. It may even be necessary to subject the help system to a usability test of its own.

Error messages
The best error message is no error message. But error messages can not always be prevented. Error messages should be correct and helpful. It is recommended to use systematic methods for predicting all the errors that may occur in a software system and make sure each error generates a correct error message. Thorough testing is necessary because there may be unpredicted errors which fail to generate appropriate error messages. An error message should explain the nature and origin of the error. Avoid reference to software line numbers or addresses that are useless to the user who has no access to the source code. A short error message may be supplemented with a Help button that gives a more detailed explanation of the error and possible remedies for solving the problem.

An error message may be followed by a menu of choices for how to recover from the situation. Assume, for example, that the user wants to save a file to a floppy disk, and the system gives this error message: "Error writing file A:\hello.txt: Disk defective or not formatted." In this situation the system may present the user to the following choices:

Cancel write operation Replace disk and retry Format disk Save file elsewhere Help

Response time
Long response times may be annoying, but unpredictable response times are worse. It can be very stressing to the user if answers sometimes come fast and sometimes take a long time. This problem is often seen in network systems. You may use local rather than central computing power whenever possible in order to reduce this problem. There should be an immediate feedback to every command the user gives the system. If the final result is delayed then there should be a temporary feedback to tell the user that the command has been received and that the system is working on it. At least the system should indicate that it is working by showing an hourglass, a watch, a turning wheel, or whatever. But preferably, there should be a progress bar or countdown giving the user a chance to estimate how long time the operation will take. There should always be a way to cancel or abort time-consuming operations before they are finished. If the system is capable of setting commands with long response times in a queue and serve them on a first-in-first-out basis, then there should be a way to watch the queue and perhaps also to delete commands from the queue or change their priorities. If no watching of the queue is possible, then the system should rather have no queue at all (at least not for operations that take more than a few seconds). A system with no queue should either refuse to accept any new commands before the execution of the previous command has been finished or canceled, or it may be constructed so that a new command always cancels any previous unfinished operation.

Scrolling
If a text is too big for the screen then the user wants a scroll function so that he can choose which part of the text to see. There are several ways to do this:

Scrollbar
This is a graphical interface that the user can move with the mouse, as shown to the right. The user can click on the arrow icons to scroll one unit up or down. The user can click on the shaded field to scroll a half or a full page up or down. And the user can drag the square button up and down to position the page exactly where he wants it. Simple observations show that most users use the most tedious of all methods: clicking the arrow keys repeatedly until the page is positioned as desired.

Scroll wheel

Some modern mice have a thumbwheel that you can use for scrolling. This is useful for situations where you use the mouse anyway, such as Internet surfing. The scroll wheel is most useful for scrolling small distances. It is not suited for scrolling several pages down.

Keyboard
If the user's hands are on the keyboard, then it is certainly most practical to use the keyboard for scrolling. Many systems only have a PageUp and a PageDown key for scrolling a whole page or frame up and down. It is absolutely incomprehensible to me why not all systems also have keys for scrolling a single unit (one line or character) up, down, left, and right, as these operations are needed all the time . This could easily be implemented in existing

systems by using key combinations such as Alt+Arrowkey. Without scroll keys the user has to use the arrow keys to move the cursor beyond the edge of the screen window, or use the mouse. (Historical note: The ScrollLock key that all PCs have was originally intended for turning the arrow keys into a scroll mode. Because of the usability problems with modes, this key has almost never been used. If it had been designed as a shift key rather than a mode key, then it would be used by everybody today!)

What is up and down?

What does it mean to scroll up? You have probably never thought of this as a problem, but there are actually two opposite definitions: 1. To scroll up means to move the text up relative to the viewing window, so that the text further down becomes visible. 2. To scroll up means to move the viewing window up relative to the text, so that the text further up becomes visible. Usability experiments have shown clearly that the second definition should be used. Pressing or clicking an up button or moving a scrollbar or scrollwheel up should actually move the text down relative to the viewing window, so that the text further up becomes visible.

Defaults
Whenever the user has to fill out a text field in a form or make a selection from a list, the system may preset it to a default value so that the user doesn't have to do anything if this value is acceptable. There are several ways in which the software can determine a default value: 1. Always set it to the same value 2. Set it to the same value as the current user entered last time 3. Try to guess the value from something else the user has entered Method 3 can be quite confusing if it fails and the guessing method is not obvious to the user. Which method to use may be determined by a usability test.

File organization

The files on a hard disk are usually organized into directories or folders. Choosing a suitable folder for storing one's files and finding the files again are tasks that cause more problems than most software designers realize. Many users can't overview the directory structure. When they store a file, they have no idea afterwards which directory they have put their file into. Obviously, they have big problems finding their files again when they need them. I have even seen experienced users storing all their data files in the root of the hard disk, on the workspace, or together with the program files. Any software that allows the user to store files should encourage the user to store his/her files in a suitable place. One solution is to create a directory for data files belonging to the program in question and show this directory as the default the first time the user gets a "Save as" dialog box. The procedures for storing files should of course be the same for all programs running under the same operating system. Don't invent your own file management system - use the standard dialog boxes provided by the operating system.

Installation and uninstallation

Installing a new piece of software is something that beginners often have to do. Therefore it must be easy. The installation procedure should be standardized so that it works the same way for all programs. Preferably, the installation procedure should be part of the operating system. If such a feature doesn't exist as part of the operating system then use a standard software tool. Most software packages use Installshield which gives the installation procedure a well-known interface and takes care of the operating system tasks in a standardized way. A further advantage is that it can install the software from a single installation file. This is useful when the software can be downloaded from the Internet. Let the user download an installation file and execute it, rather than making an online installation procedure, because the latter method may give unpredictable problems if the connection is interrupted while installing or if the download takes longer time than the user can accept.

All files belonging to a particular program should be stored in the same directory or its subdirectories so that the user knows which files belong to which program. Avoid very deep directory structures. Installation procedures often have options about which components to install. This should include a help facility that gives a full explanation of the purpose of each component so that the user can make an informed decision. Installation programs often ask questions of the type: "Do you want to replace version X of this file with version Y?". Some installation program keep asking this kind of questions with unpredictable intervals all through the installation procedure, which may last for a full hour or more. The program should rather ask all questions at the beginning so that the user can take a break or do something else while the installation finishes. Uninstalling a program can be much more difficult than installing it. It is quite common for several programs to share the same files. Such shared files can of course only be deleted when all programs using them are uninstalled. The only way of keeping track of which files are used by which programs is to store this information in a database maintained by the operating system. Programs using shared files must comply with the standards of the operating system for storing such information. Some programs ask you to insert the original distribution CD when you want to uninstall. But what if the original disc has been misplaced, lost or damaged? Then you cannot uninstall the program. This is certainly unacceptable. A proper uninstallation procedure should rely solely on the operating system, and all installation programs should comply with the standards of the operating system for enabling easy uninstallation. Unfortunately, not all operating systems have this feature.

Copy protection
Producers of commercial software have a very reasonable wish to protect their product against unauthorized copying. Many different methods have been invented, but unfortunately all these methods have usability problems as well as problems of distinguishing between legitimate and unauthorized copying:

Original disc is tampered with

A floppy disc supplied as part of the software product is tampered with in a way that is not easily copied, e.g. a specific part of the magnetic layer is removed. Problems:

The user has to insert the disc every time the product is used The user cannot make a legitimate backup copy Requires direct hardware access or a special driver that may be incompatible with future hardware or operating systems Does not work in network systems

Hidden information is stored on the computer

This information may be lost when the user updates hardware or operating system The user may have more than one computer May be incompatible with future operating systems

A fingerprint of the computer hardware is stored

Lost when the hardware is updated or repaired The user may have more than one computer May be incompatible with future operating systems

A dongle
This is a little piece of hardware that has to be connected to the computer. Problems:

Requires direct hardware access or a special driver that may be incompatible with future hardware or operating systems Must be moved all the time if the user has more than one computer May be stolen, misplaced or damaged Difficult to protect against theft May be incompatible with other dongles or other hardware The number of dongles that can be attached to a computer is limited Does not work in network systems

Printed manual
A manual is more difficult to copy than software. Problems:

Users prefer online help

Registration

The user fears that he may receive spam mail

Serial number
The user has to enter a serial number when the program is installed

Hotline
Only legitimate users have access to help from a hotline

Free updates
Legitimate users get free updates and bug fixes Most copy protection schemes contain combinations of these methods. However, most software producers are now using a serial number only or refraining from using any copy protection at all because of the severe usability problems and technical problems they entail. Shareware and freeware products are gaining popularity for similar reasons.

Web design
Usability considerations are important when designing web pages because everybody should be able to access and use them immediately without instructions. The general principles of usability also apply here, as well as the principles listed above under software. The pages that follow discuss some supplementary topics that apply specifically to web design.

Make web pages accessible to handicapped users

It is a good idea to make your web pages accessible to handicapped people, even if this is not your primary target audience, because the guidelines listed below have beneficient side effect that will improve the usability to other users as well. Another interesting side effect comes from the observation that the kind of barriers that prevent blind people from reading your pages also prevent search engines from reading your text. In other words, a page that is accessible to blind people is also more likely to be found by a search engine. Some guidelines from the Web Accessibility Initiative of the World Wide Web Consortium:

Text format
Don't use graphics for making text. Don't make ASCII art. Avoid file formats that can't easily be converted to plain text, such as .pdf files.

Images and animations

Use the alt attribute to describe the function of each visual element.

Image maps
Use client-side map and text for hotspots.

Multimedia
Provide captioning and transcripts of audio, and descriptions of video.

Hypertext links
Use text that makes sense when read out of context. For example, avoid "click here".

Page organization
Use headings, lists, and consistent structure. Use Style sheets for layout and style where possible.

Graphs and charts

Summarize or use the longdesc attribute.

Scripts, applets, and plug-ins

Provide alternative content in case active features are inaccessible or unsupported.

Frames
Make a <noframes> alternative and meaningful frame titles.

Tables
Make line-by-line reading sensible. Summarize.

Check your work

Use the checklist at www.w3.org/TR/WAI-WEBCONTENT/ and the Bobby test at www.cast.org/bobby/.

Navigation
Navigation is how the users find their way around on the internet. If users can't find what they want on your website, you might as well have no website at all.

1. Help users finding your website

Guessing the domain name
Many users try go guess the domain name of a website. The first guess may be www.companyname.com, or www.companyname.dk, if in Denmark. You may register more than one domain name in order to cover everything that users may guess at, including common misspellings of your name. The URL should work both with and without the initial www. The domain name should of course be easy to remember. A name containing a hyphen (-) is not the best, because users may forget the hyphen or put a dot instead.

Search engines
Make sure your website is easy to find with the most popular search engines. It is possible to control which pages on your website are found by the search engines and how they are described in the search result listing. It is also possible to add

keywords that are visible to the search engines but not seen by the user. You may add such keywords to cover all synonyms for the topic of your website, including common misspellings. Technical instructions. Be aware that users may arrive at any subpage in your system. Make sure that all subpages have a title that makes sense out of context and a link back to the main entry page.

Links from other sites

Other people are likely to make links from their sites to your site only if your site contains useful information. The higher the quality of the information on your site, the more incoming links you will get. Make sure your site has logical entry points that others can link to. A subpage within a frame cannot be linked to. Be careful to avoid dead links. Whenever you reorganize your website and remove a page or change its filename, you may actually be breaking a link from some other site, or making somebody's bookmark invalid. To minimize this problem, you have to put a redirection page where the old page was.

2. Help users find their way around on your website

Menus
All pages should have a menu. Make sure your menus or links look like menus or links. If your links just look like text or decoration, then users may never get the idea that they can click on them. By default, links are underlined and blue or purple: Blue for places where you haven't been, and purple for links to pages that you have already visited. The more your design deviates from this standard, the more difficult it will be for users to navigate. Menus should be structured in a logical way, and not too deeply nested. Users may never find a particular page if they can't guess which way to go to find it, or if they don't know that it's available.

Search facilities
A search facility can be very useful for a site that has many pages. But good search facilities are difficult to make. An effective way of testing your search facility is to log search misses. Looking at the

logfile, you can see all the terms that users have searched for without success.

Filename navigation
Some users are using the URL field in their browser for navigation. Therefore, the directory structure and filenames should preferably be simple and structured in a consistent and logical way. For example, if the URL of this page is

www.eit.ihkedu.dk/subjects/mmi/technical/webnavigation.php

then the user may try to navigate upwards in the hierarchy by trying any of these:

www.eit.ihk-edu.dk/subjects/mmi/technical www.eit.ihk-edu.dk/subjects/mmi www.eit.ihk-edu.dk/subjects www.eit.ihk-edu.dk

Each of these URL's should give a useful entry to its respective place in the hierarchy of topics.

Helpful error messages

Don't let your system write HTTP Error 404 when a requested page is not found. Rather, you should show a helpful page with links to your index page and search facilities. Try to misspell the name of this page (for example www.eit.ihkedu.dk/subjek/technical/navigation.html). You will see that the system is trying to locate pages that resemble what you have typed.

3. Help users finding their way out of your website

Some websites have no outgoing links. Such sites are called sticky, because they are trying to keep the user within their site. But a user who can't find what (s)he is looking for on your site and can't get help finding it elsewhere, is not a happy user who wants to come back another time.

Avoid frames
Frames is an HTML technology that divides the screen window into two or more subwindows which can be changed or scrolled independently. Web designers love frames because they can put a menu in one frame and the selected page in another frame. Unfortunately, frames have a lot of usability problems:

It is not always obvious to the user whether a page is divided into frames or not. Does not work well on small screens. Does not work in all browsers. It is difficult for the user to navigate because the address bar of the browser shows the URL of the frameset, not the selected page. The user cannot set a bookmark to an individual page in a frame system. Others cannot make a link to a particular page in a frame system. If you want to inform a friend about a particular page in a frame system then you cannot just give him the URL. You have to give a detailed explanation of which menu items to click on. The browser doesn't show which frame has the focus. When you issue a print command you may print the wrong frame. Users who, for whatever reason, use the keyboard rather than the mouse don't know which key to use for changing the focus from one frame to another. A user may - deliberately or by accident - open a subpage separately rather than as part of the intended frameset. Thereby he looses the context and the navigation menu. Search engines are generally not able to handle frame systems adequately. Web designers often make errors in frame systems. A very common error is that when you click a link to an external web page it is shown inside the same frame system.

The conclusion is clear: Never use frames! If you want the same menu on many pages then use server-side includes or server-side programming. If you prefer to use client-side programming then be sure to test it in different browsers and provide an alternative for browsers that don't support your script or applet.

Animations
Web designers love to make animations for artistic reasons, to attract attention, and to show off their technical prowess. However, animations cause many usability problems:

animations are most often annoying and distracting they detract attention away from informative text not compatible with all client devices, browsers, screens, etc. animations slow down access flashing and flickering objects can cause seizures in people with epilepsy cause problems to people with visual or cognitive handicaps

You should therefore think twice before deciding to make animations on a web page. Informative pages should generally not have animations, while hobby pages and pages selling art and entertainment products may have animations. Never let an animation cover the whole screen. Always place a menu on top of the screen so that the user can quickly get to the point if he doesn't want to spend time watching your animation or wait for it to download and start.

Cookies
A cookie is a tiny piece of information that a web site can store on the user's computer and later retrieve when the user visits the same site again. The advantage of this is that the website can recognize the user so that he doesn't have to enter information that he has already entered previously. However, cookies are sometimes used in a way that is not transparent to the user and may not be in the interest of the user. An organized exchange of information on users between website owners is taking place in order to keep track of user habits. This enables the web operators to target advertisements to the individual user profile. Users may reject cookies for any of these reasons:

The user is unhappy of being spied upon by companies he doesn't trust

The user fears that his family or colleagues can tell from the cookies on his computer which sites he has visited The use of cookies is not transparent to the user, and he doesn't know what they are used for The user fears that the cookie mechanism can be abused by hackers for manipulating his computer The cookies fill up disk space with cryptic information that the user doesn't understand The user may not be using his own computer, hence there is no point in storing personal information Using somebody else's computer, the user may not care to ask the computer owner for permission to store cookies on the computer

These are all good reasons that website operators should accept. Hence, the website should be designed so that operation without cookies is possible. Some websites keep trying to persuade the user to accept the cookies, even after he has rejected them several times. This is very impolite!

Printer-friendly web pages

A user may want to print out a web page if it contains a lot of text or important information that the user wants to save. A page with a light text on a dark background color may look nice on a screen, but not when it is printed out on paper. Furthermore, the page may contain a lot of menu bars and gimmicks that just take up space on the paper to no use. Some web designers want to help their users getting a nice printout without disturbing colors and menus. There are various ways to solve this problem:

Making a link to a printer-friendly version of the same page

This method is easy to understand for the user. Unfortunately, the link to a printer-friendly version rarely fits into the existing menu system: The menu contains topics, not technical options. Putting in a link that doesn't fit into this context disturbs the user. If you place the link elsewhere it will either be too glaring and disturbing, or it will be ignored.

Making a button on the page

This is equally disturbing. The user is likely to prefer the usual printing method, not knowing that this button gives a better

result.

Using style sheets to specify different styles for different media

This method works automatically whenever the user prints a page. A minor disadvantage is that the user doesn't expect the page to look differently when printed out. This page uses the latter method. Try to print out this page, and you will see that the colors and menus disappear! (You can make things disappear by applying the style display:none)

Compatibility of web pages

Web designers must realize that browsers are different and that web pages look different in different systems. Don't tell the user to download a particular browser or plug-in. It is OK to use advanced modern technologies, but make sure there is an alternative for users who don't have this technology or have disabled it for whatever reason. An advanced web site should be tested in many different environments, which may include:

a slow modem connection standards-compliant browsers (e.g. latest versions of Netscape and Opera) browsers with non-standard DOM models (Netscape 4, Explorer) browsers without support for style sheets (Netscape 3) different screen resolutions and numbers of colors different operating systems (Windows, Mac, Sun, Linux) different security settings (e.g. cookies and Java turned off) hand-held devices aural and tactile devices for blind people, if applicable alternative pointing devices (other than a mouse) printing on monochrome and color printers if the page contains text that users might want to print out

In some cases it may be necessary to add a browser-sniffer that detects the user's browser and provides a code that is suitable for that particular browser. (It is a problem to test web pages in different versions of Internet Explorer because this browser is so deeply integrated into the Windows

operating system that each computer can only have one version of Explorer installed, and it is impossible to downgrade it. You may need one computer for each version of Explorer.)

Recommended Literature
English
McCormick, Ernest. Human factor in engineering and design. McGraw-Hill 1976
Theoretical textbook about input/output devices, ergonomics, cognition, psychology.

Newman, W M & Lamming, M G: Interactive System Design. Addison-Wesley 1995.

Textbook with the main focus on user psychology and cognition, including user study, modeling user activity, and systems analysis.

Nielsen, Jacob. Designing Web Usability. Indianapolis: New Riders 2000.

Good and easy-to-understand handbook for web designers. The coverage of usability-testing is insufficient, otherwise the book is very useful and comprehensive.

Nielsen, Jakob: Usability Engineering. Morgan Kaufmann Publishers 1993.

Good textbook with the main focus on computer interfaces. Practically oriented and easy to read, though I would like to have more examples and illustrations.

Norman, Donald A.: The Design of Everyday Things. Doubleday 1988.

Entertaining book packed with examples of good and bad designs. This book can convince anybody about the importance of userfriendly designs.

Preece, Jenny (ed): Human-Computer interaction. AddisonWesley 1994.

University-level textbook. Theoretical but easy to understand, with many illustrations and exercises.

Raskin, Jef: The Humane Interface: New Directions for Designing Interactive Systems. Addison-Wesley 2000.
Theoretical book on human/computer interface and cognitive psychology with detailed discussion of commands, displays, cursors, icons, menus, etc.

Schneiderman, Ben: Designing the User Interface: Strategies for Effective Human-Computer Interaction. Addison Wesley 1998.
Recommended university-level textbook on the design of human/computer interface. Comprehensive.

Recommended Web sites

English
Special Interest Group on Computer Human Interaction
This organization has chapters in many countries, including Denmark. Their website has an extensive bibliography and many links to various resources.

Jacob Nielsen
Home page of the famous web design guru.

Web Content Accessibility guidelines

Technical recommendations for handicap-friendly web design from the official World Wide Web consortium.

www.baddesigns.com
Learn from others' mistakes - and get a good laugh! A wonderful collection of simple things that are difficult to use.

Interface Hall of shame

Examples of bad designs of software interfaces.