friendly messages
Larry Campbell
campbell at redsox.UUCP
Wed Mar 1 14:22:05 AEST 1989
Having spent the last year or so trying, among other things, to help
our customers use our software, I have developed some very strong opinions
on the subject of error messages:
1. Messages must be accurate and relevant. This should go without
saying, but the infamous "not a typewriter" message reminds me
that it bears repeating.
2. Messages must be complete. If the problem is related to
a particular entity (file, process, device), the entity
MUST be named. "File not found" is useless -- you must
tell me *which* file you were trying to find!
3. Messages must not be excessively scary. Words like "illegal",
"corrupted", "damaged" and the like should be avoided. They
*will* result in telephone calls which *cost* *you* *money*.
4. If there's anything the user can do about the error, the message
must be understandable and must suggest a course of corrective
action. But if it's just a bug the user can't do anything about,
the message should direct the user to call customer support,
and it should display enough information so the poor support
person has half a chance of fixing the problem.
5. It is better to give too much information than too little.
You can always ignore the excess information, but when you're
trying to support a customer six time zones away, you're going
to want as much information as possible to be available. Remember,
the hard problems aren't repeatable, and even if they were, it's
too expensive to keep a customer on the phone trying things out
for you.
I once attended a lecture given by Ben Schneiderman (Univ. of Md.) about
human factors engineering. He pointed out that the best error message he
knew of was the one you get when you misdial a phone number (this was before
divestiture):
"We're sorry, but we are unable to complete your call as dialed.
Please check the number and try your call again, or call your
operator for assistance."
This is an excellent error message, for the following reasons:
1. "We're sorry," It starts out by apologizing! For your mistake!
2. "We are unable..." It blames itself, and not the user!
3. "Please check the number..." It suggests not one, but two
alternative courses of corrective action.
In contrast, if compter programmers had designed the message, it would
probably say something like:
%ATT-F-INVADDR, Invalid or incomplete address, call aborted
or
Not a typewriter
which, to the average user, would be frightening, confusing, and
almost completely uninformative.
--
Larry Campbell The Boston Software Works, Inc.
campbell at bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146
More information about the Comp.unix.wizards
mailing list