RE: writing error messages for software application

[Chuck Martin <CMartin -at- serena -dot- com>]

It can be fairly easy to provide guidelines for writing useful error
messages. But then I noticed that you're designing the GUI, and so I say, in
a nutshell, do the design so that users can't make errors.

But that's not nearly as simple, and someone noted a few weeks ago a problem
with that approach, namely, what about actions that users can do with the
keyboard as easily as they can from within the GUI, such as deleting an
item. I have been stewing about this one since I read that post with no good
answer. 

To address the actual authoring of error messages, instead of veering from
minimalist to too much, do both. That is, layer the information. Provide
users with enough information to tell them what happened and how to resolve
it, then provide a way to get more information if needed or wanted. The
information that goes in both places depends, of course, on your audience.

However, a better goal is to design, as much as possible, the interface so
users can't make errors, or at least will have a more difficult time making
errors. This can be done in many ways, including labeling, but the entirety
of methodology is too much for a simple list posting. You can also use
pop-up windows, as described on page 250 in the book "Microsoft Windows User
Experience" to provide additional guidance before users take action.

Some of the things to think of in this area:
- Don't make controls available until it's reasonable. That means, for
example, if it's required that all fields in a dialog box be filled in,
disable the OK button until all the fields have valid entries (that means
programmatically doing validation as a user enters information). Or when a
document is saved, disabling the Save button and command until some change
has been made to the file. And so on.
- If procedures have to be done in sequence, consider a Wizard to lead users
through that sequence. Wizards should always be bi-directional.
- Use standard, familiar controls.
- Remember that most people scan from upper left to lower right, so consider
what users need to do and when they need to do it when designing windows and
dialog boxes.
- Design based on user goals, not software function.

The last point is by far the most critical.

For more information, read Alan Cooper's "About Face."


> -----Original Message-----
> From: Mason, Catheryn [mailto:CMason -at- INFINITEC-COM -dot- com]
> Sent: Tuesday, February 29, 2000 3:07 PM
> Subject: writing error messages for software application
> 

> I'd like to gather advice on writing error messages that are concise,
> helpful, and not intimidating to the user. I'm designing a 
> Windows GUI for
> our software and I'm finding that writing good error messages 
> is the hardest
> part of the project (for me, anyway). Anybody have any 
> success stories or
> tips to share? Anything, as a user of software applications, 
> that you either
> really like or hate to see in an error message? 
> 

> I seem to veer between two extremes  -- one is a "just the 
> facts, ma'am"
> minimalist approach (as in "System date and time could not be 
> reset"), the
> other is loading the user down with way too much feedback and 
> including
> information in the error message that might belong 
> appropriately in a pop-up
> box or a help file (as in "System date and time could not be 
> reset. Ensure
> that x and x and x conditions are met").  I want to be helpful but not
> verbose. 

-- 
Chuck Martin
Sr. Technical Writer, SERENA Software

"People who use business software might despise it, but they are getting
paid to tolerate it....Most people who are paid to use a tool feel
constrained not to complain about that tool, but it doesn't stop them from
feeling frustrated and unhappy about it."
          - "The Inmates are Running the Asylum" 
            Alan Cooper


***********************************************************************
This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they   
are addressed. Any unauthorized review, use, disclosure or distribution 
is prohibited. If you are not the intended recipient, please contact 
the sender by reply e-mail and destroy all copies of the original 
message. 
***********************************************************************