Errors

Errors show how crude your software is. Smart software accepts human errors, prevents them, allows undo, or — as a last resort — explains them in a way that lets us understand and fix them ourselves. The better your software is at doing these things, the more efficient and satisfied we will be when using it.

Accepting errors

The best way to handle input errors is, whenever possible, to accept unambiguous input. For example:

• In a field for a phone number, credit card number, or similar, don’t complain about characters like spaces, dashes, or brackets. Instead, just accept these characters, and ignore them internally when using the data.

  Further reading: Steve Friedl, “No dashes or spaces” hall of shame.

• In a field for naming something new, where some characters are prohibited, consider automatically replacing them with equivalent allowed characters. For example, if spaces are not allowed when registering a new login name, the field might replace spaces with dashes as they are typed.
• If compulsory data is missing from a customer record or similar item, consider accepting the record provisionally, but reminding us to complete it later.

Preventing errors

The next best way to handle errors is to prevent errors from happening. For example:

• If people often trigger a particular command accidentally, make it more difficult to trigger. A confirmation alert is the least polite way of doing this. One example of a better method is changing a keyboard equivalent to require two keys instead of one (or three keys instead of two). Another example is physically separating dangerous commands from more common ones — in a menu using separators or submenus, and elsewhere using spacing or an expandable section. [right: something]

• Use the appropriate control for the task, and give it a reasonable default value. For example, if a setting has only a few useful values, consider radio buttons or an option menu instead of a text field. And if asking for a date or time, use a datepicker or timepicker rather than a text field. [wrong: text field used for date, with format caption] [right: datepicker]
• If a button, menu item, or other control can’t be used successfully right now, don’t show an error when it is invoked. Instead, make the control insensitive. Usually, it’s obvious why a control is insensitive. If it isn’t:
  • If there is available space, include a caption giving the reason. [right: “Not connected to the Internet.” next to insensitive “Sign In”]
  • As a last resort, add a temporary tooltip for the control (or extend the existing tooltip for a toolbar button) explaining that it is “Not available because” or “Not available until” something. For example: “Sorts cells alphabetically. Not available until you select some cells.”

  Further reading: Lukas Mathis, “Disabling inactive menu items”.

  On other platforms, insensitive menu items sometimes change their wording when insensitive — for example, “Can’t Undo Partitioning” or “Nothing to Redo”. Don’t do this in Gnome software; it may disorient people who were looking for the original item wording.

• If a field has a minimum or maximum length or value, don’t let me submit a value with a length outside that range.
  • Consider including an error caption or similar element next to the field, describing whether the value is too short or too long. (For example, microblogging clients often feature a count showing the number of possible characters left, and this number becomes negative when there are too many characters.)
  • Don’t ignore excess characters as they are typed, because the characters I will want to remove aren’t necessarily the last ones I typed. Instead, highlight excess characters with the theme’s error color, so that I can see how many I need to remove before submission.
• Before saving or copying files, check that the device is writable and has enough free space.
• Before doing anything requiring an Internet connection, check that there is one.
• If a dialog opened automatically to perform a particular task, close the dialog automatically if the task has since been performed a different way, or otherwise rendered irrelevant.

Occasionally, your desire to prevent errors may conflict with our efficiency. Don’t go overboard.

Further reading: Janko Jovanovic, “Poka-Yoke in UI design”

Heuristic tagging: Use the ux-error-prevention tag in bug reports about preventable errors.

Allowing undo

Presenting errors

If you cannot correct or prevent an error, you will need to explain it. Make clear, near to the error in space in time, what went wrong, why it went wrong, and what we should do next.

Near in space and time

Describe an error as close as possible to the place where it occurred, and as soon as possible after it occurred, without being distracting. For example:

• If one item in a list has a non-urgent error condition, show an error icon at the trailing end of that item, where activating the icon displays more information and troubleshooting options.
• Similarly, if one field in a form is incorrect once it loses focus, highlight that field with the error background color, and describe the error next to the field. (Occasionally, it may be helpful to do the opposite, using a success icon to confirm valid values for difficult fields.)

  Further reading: Luke Wroblewski, “Inline validation in Web forms”

• If you cannot know which of a dialog’s fields are incorrect — for example, in a login dialog where the login name and/or the password are incorrect — consider keeping the dialog open, but changing its primary text to describe the error.
• As a last resort, use a separate error alert.

What went wrong

...

If the error is in the software or hardware itself, be apologetic, because you have let us down. Even if the error is in the hardware, say sorry — though it’s not your fault — because many of us do not distinguish between software and hardware.

...

Why it went wrong

...

What we should do next

...

Further reading: David Travis, “Communicating errors”