Error Messages
From MobileDesign
[edit] Applies to:
User Interface: Included,
Excluded
Hardware: Category: Thing,
Category: Another thing
While error messages are not unique to the mobile space, error messages are frequently mishandled across most platforms.
[edit] Design
In general, error messages should give the user the information needed to solve the problem. In many situations, this means the underlying code needs to better differentiate error conditions.
Log all errors... and fix the problems.
[edit] Body
- Put error codes at the end of the message. This allows any support personnel to get the relevant information without costing the user is time to read it ... or risk having the code push some of the words off the bottom of the screen/window.
- Keep the message short.
- Give clues regarding what the user can do to resolve the situation.
- Be specific.
When looking at your code, see whether there is a large "else" statement (in whatever language you are using). If most of the error conditions fall into that pile, you probably need to be a bit more specific.
Consider using a dialog box rather than a full screen, if your platform and device supports it. If possible, categorize errors into based on whether the user can fix the problem, the user needs to retry later, or an unfixable error has occurred. Of course, many unfixable errors should be fixed by the developer.
[edit] Commands (softkeys, links, or buttons)
Frequently, the best commands are "Retry" and "Cancel." "OK" is rarely a good choice.
Provide the user the ability to do some set of:
- Try the action again (Retry)... used to perform the same action again immediately or restart the process
- Fix the user entry (Edit)
- Abandon the task (Cancel)... returning the user to a logical starting point
- Save the data (Save)... allowing the user to abandon the task without losing context
Also see: Any that apply, Else remove it entirely
