|
- Make errors impossible.
- Give positive feedback.
- Audit, don't edit.
This article is inspired by (and is a summary of)
"Ban the bomb" by Alan Cooper,
from the Visual Basic Programmers Journal.
Presenting error messages to your users is to be avoided at all costs.
Error messages are a form of negative feedback;
humans do not respond well to negative feedback.
Humans DO respond well to positive feedback.
When a program receives input from a user that it does not understand,
it should not assume that the data is "invalid".
The input came from a human, and a human is much more important than
the program, so the input must be correct.
Instead of soimply rejecting the input,
the program must work harder to to understand and reconcile confuding input.
There are three fundamental ways to eliminate error messages:
- Make errors impossible.
- Give positive feedback.
- Audit, don't edit.
Make the user select from a list or click on a map,
rather than enter text in a field.
Use sliders/counters for numerical input (of limited range).
Make it impossible for the user to enter a bad state.
Where possible fill in default information, like the user's name,
the current date/time, or the most-recently-accessed file or directory.
The best way to give positive feedback to users is with sound
(make sure that they can turn it off,
or that they will wear headphones in an office environment).
In real life many events indicate success with sound:
shutting a door, lighting a gas stove, starting a car engine.
Good keyboards click softly when we successfully press their keys.
When you hear your computer's hard-drive making a lot of noise you know it is busy.
Our programs would be much friendlier and easy to use if they
issued barely audible but easily identifiable sounds when user actions were correct.
The audible feedback must be very quiet,
no louder than the sound of the keyclicks on a notebook computer.
The program should make some sound every time the user directs the program
correctly or every time the user enters information that the program understands.
Many programs require users to enter certain data at points in the workflow which,
from the users point of view, are not the points at which that data is necessary
for them to perform the task.
If, for example, the user enters an invoice for an invalid customer number,
the program could accept the transaction and make a special notation to itself
that indicates that the user must eventually validate it.
The program would then watch to make sure the user entered the necessary
information to make that customer number valid before the end of the month book-closing.
In fact, this is the way most humans actually work. They don't usually enter "bad" codes.
Usually, they just enter codes in a sequence that the software isn't prepared to accept.
We make the assumption that a customer account must be established before an invoice
credited to that account can be valid, but nowhere is this carved in stone.
Why can't software accept invoices independently of account information and
merely assume that things will be explained to it in due course?
If the human forgets to fully explain things to the computer by month end,
the program can dump irreconcilable transactions into a suspense account.
The program doesn't have to bring the proceedings to a halt with an error message.
After all, the transactions in the suspense account will almost certainly amount
to only a tiny fraction of the total sales and so will not be a significant
factor in the business reporting cycle.
Why stop the entire process because something inconsequential is missing?
Why ground the airplane because the bar is short one little bottle of Scotch?
| 