After my flurry of posts about error messaging from my perspective (here and here), I did some reading and researching on other peoples perspectives. What follows are links to some of the most interesting/relevant.

From Non-Fatal Errors: Creating Usable, Effective Error Messages a set of guidelines that I’ve inadvertently been applying to my own work by trying to turn error messages into a mini FAQ:

  • What is the problem?
  • What, if anything, can the user do to fix it or recover from it?
  • What, if anything, can the user do to prevent this problem in the future?

(these are also mentioned in Importance of writing standard Error Messages for better software products)

From Avoid Being Embarrassed by Your Error Messages:

Think about error messages as part of a conversation with users.

Oops! I ruined your life. :) has a lovely collection of screenshots of error messages which contain the word “Oops!”. What made me laugh the most, is that two of the further examples in the paragraph starting

So, people who care about user experience have provided guidance

now serve Oops! pages themselves

flow's page

and

Jim Royal's page

From The web shouldn’t be a comedy of errors:

An engineer who designs the superstructure for a bridge or the frame of an automobile invests time in understanding how things will break. That’s part of what defines real engineers: the ability to see the potential flaws in any design, and build objects with additional support for those flaws in mind. Similarly, writing code for a feature must include understanding the most important error cases and engineering code to support those cases robustly. Particular importance should be placed on the errors that users experience, and how they will experience them

When a user is interrupted from a task by an error, you have to set the right tone. The way they are thinking about the error is always very different from the way you, as the developer, think about the error

If you write solid code, and build robust support for error handling, the most common or severe errors are never even encountered by the user. This can be achieved by automating parts of the user interaction, intelligently offering alternatives to common mistakes users make, or by refining the UI to reduce the frequency with which users get into certain error-prone situations. Great engineers forgo the error messages, and just solve the problems directly.

This article is really good. You should read it.

From Importance of writing standard Error Messages for better software products:

Error messages are supposed to soften the impact of ‘something that has gone wrong’ – they themselves must not add to the confusion. An effective error message must be able to guide the user to the proper action to be taken – if your UI design fails to do so. If your error messages are clear and concise, not only will they help the user move around the product with ease, but you will also be able to retain their interest and attention – thereby building loyalty.

and also some things not to do:

Do not use language that makes users feel that they are being shouted at. Shouting may be perceived when an error message contains exclamation points, long strings of capital letters, and bright red or yellow icons such as stop signs or yield signs.

Do not use urgent or excited terminology such as “fatal”, “critical”, “severe”, “failed”, or “terminate”. Calm language is more likely to produce a calm reaction.

Do not use techie jargon, code, or abbreviations. Humans are reading the error message, so use language a human will understand.

and finally from Michael Bolton’s Review of Error Messages

A well-constructed error message

  • should identify the program that is posting the error message
  • should alert the customer to the specific problem
  • should provide some specific indication as to how the problem may be solved
  • should suggest where the customer may obtain further help
  • should provide extra information to the person who is helping the customer
  • should not suggest an action that will fail to solve the problem and thus waste the customer’s time
  • should not contain information that is unhelpful, redundant, incomplete, or inaccurate
  • should provide an identifying code to distinguish it from other, similar messages

and actually, probably the most important point from all of these articles is that

Our systems for teaching programming almost never discuss error messages, or even error handling

The blog posts/articles linked here are pretty much it, I’ve failed to find much more about error handling. And yet the handling of errors, the wording and the behind-the-scenes stuff is so important. It deserves much more visibility, consideration and planning.