This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex

Errors

An error doesn’t become a mistake until you refuse to correct it.

—Orlando Battista

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:

Preventing errors

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

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:

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

...

Bad example

Good example

Print error: Out of paper. (( OK ))

The printer “Printasonic 4850” is out of paper. Only 4 of 7 pages in “Gaming roster” have printed. ( Stop ) (( Resume ))

Further reading: David Travis, “Communicating errors


2024-10-23 11:03