Reporting and Correcting Errors
- correcting errors during input
- There should be a key for erasing the last character that was typed.
(There is sometimes confusion between the "Backspace" and the "Delete" key.)
Not only the confusion between the function of "Backspace" and "Delete"
is a problem: also the position of these keys is different on different
keyboards. An added difficulty is that the "Backspace" key sometimes
contains a left arrow symbol, but generates a different code than other
left arrow keys on the same keyboard.
- All keyboard input should be correctable before the computer starts
processing it.
Strictly speaking this condition is often not fulfilled,
but the user can't tell the difference.
When typing text in an editor such as emacs every character is
processed immediately.
Typing a character and then erasing it are two operations which
are both processed by the editor.
More problematic are single-character commands that are executed
immediately after being typed, without requiring a confirmation by
pressing "Enter" or "Return",
as is common in the vi editor.
- The user should be able to easily reach the position where the correction
is to be made.
For small cursor movements arrow keys may be most efficient.
For large movements it may be better to use the mouse to possibly first
scroll through the file and then point at the desired location.
- correcting errors right after input
- After activating a menu it should be possible to go back to a
previous (or no) menu without first selecting an item from the menu.
In most window systems not selecting a menu item can be done by clicking
(or releasing) the mouse button outside the menu.
- The user should be able to undo the last operation.
Unfortunately, a user's action may have an effect which lays outside
the current application, and which may not be undoable.
Saving a file in an editor is a prime example of such actions.
- The user should be able to undo the last undo (or "redo" the operation).
Not many systems offer both a way to recursively undo many operations,
and a way to redo the last (undone) operation.
- The user should be able to recall the last question and answer it again.
- correction at a later time
- It must be possible to save intermediate results and be able to
restart the dialog from these results.
In VMS even for simple editor files a (configurable) number of versions
is kept, so after saving a file, previous versions are not immediately
discarded.
Other operating systems have no such facility, but source code control
or versioning systems are used to store and retrieve specific
versions of files.
- Changing some input item should be possible without re-entering all data
that have been entered after that item.
- error messages
- An error message should indicate what went wrong, where it went wrong,
and what the user needs to do to correct it.
The last part: telling the user how to correct the problem,
is the most difficult part.
Finding a simple problem like a syntax error is easy to detect,
but there may be many ways to correct the syntax error in semantically
different ways. (When a closing ")" or "}" is missing, there may be
many places where the syntax lets you add the symbol, but the resulting
command may be semantically different.)
- Error messages should be informative, factual and clear, not
humorous or sarcastic.
Some older version of the Gosling emacs editor would occasionally
call the user a "twit".
- An error message should be displayed near the place where the error
occurred, unless all error messages are displayed in the same place.
- Error messages that require an immediate user reaction should attract
the user's attention by means of flashing or noise. (The user may not be
looking at the screen.)
The Star Trek red alert metaphor works well.
It also shows that you should be able to turn off the siren before
the error is corrected so that you can think straight.
- Error messages should not contain cryptic codes.
When a request for a page from a World Wide Web server fails,
The Cern/3.0 server returns a document with a large title,
like Error 404,
as if Web users should learn the numbers for each possible error.
Other servers produce a title File Not Found for the same error.
- All error messages should be in the same language.
A common problem with Windows'95 is that versions of Windows exist in many
languages, but a lot of third-party software is only available in English.
Whenever the application produces an error message it will be in English,
whereas error messages produced by Windows for the application will be in
another language. Sometimes a single message will have words in more than
one language.
- Error messages should be clear without first consulting a manual.
A message like "Error 25: Inappropriate ioctl for device" may be verbose
but still meaningless to the user.
- on-line help
- Several obvious keystrokes should lead to help, including "h" and "?".
It is annoying that in the "elm" mail reader only the "?" key works for
invoking help, whereas in the "trn" news reader only the "h" key works.
("h" in "elm" produces the current mail message with complete headers,
while "?" in "trn" tries to search for a pattern. For the novice user it
produces a cryptic error message: "Searching...Badly compiled pattern".)
- A help key (or button) should actually lead to helpful information.
The problem with this rule is that the software designer who usually
also writes the help information is too skilled to be aware of what
information a novice user really needs.
As a result, the required help may not exist although the system provides
a help function.
In Windows'95 for instance the help system is unable to provide help
on "how to delete a shortcut". When requesting this information the
help pages explain how to create shortcuts but not how to delete them.
- Help should be available at all times, including in the middle of
inputting some text, while drawing a line, or while loading a file.
The process of grabbing control over mouse and keyboard to
force the user to complete some dialog before continuing may disable
access to the help function.
- When help lists all possible answers to a question it should be
possible to select an answer from within the help function.
The user should not have to type the answer again.
- A help function does not replace a complete manual and advice from
on-site experts.