Error Handling
Error Prevention | Error Handling for Fields | Error Handling in Tables
Beside help, error handling is an important aspect of user support. Error handling helps users to overcome problem situations and to continue their work.
Typically, error handling is done by indicating the location where the error occurred and by sending an error message that notes the error, explains the reason for it and - ideally - provides hints on how to remedy the error situation.
For details on message texts see chapter Formulating Messages in the SAP Reference Lists on the SAP Design Guild.
This page covers three areas: (1) error prevention, (2) error handling for fields, and (3) error handling in tables.
Error Prevention
Error Prevention Comes First!
Before handling errors, you should first ask how errors can be prevented. Generally, you should design iViews and Web applications so that errors cannot occur. Preventing errors - instead of remedying them - has the following benefits:
- Users cannot come into error situations - many users have problems with recovering from errors.
- The users' work is not interrupted by error messages.
- Users are not confused or puzzled by (often cryptic) error messages.
- There is no need for a screen area that display errors.
If it is not possible to prevent errors, follow the guidelines presented below.
How You can Prevent Errors
Often it needs some rethinking and the giving up "old habits" to find design solutions that prevent errors instead of sending an error message after an error has occurred.
In the following we provide some ideas and examples that may stimulate your imagination when looking for ways how errors can be prevented.
Prevent Wrong or Invalid Inputs - General
- Use precise descriptions and instructions - do not be too short (especially for Web applications)
- Indicate required fields (through a red asterisk *) and an explaining text
Prevent Wrong or Invalid Inputs
- Numeric fields: Prevent users from entering letters by parsing the input string.
- Date and time fields: Provide "intelligent" date and time fields that are preformatted, or provide selection controls instead of input fields (dropdown lists, spin buttons, calendar controls).
- Currency fields: Use preformatted fields.
Prevent Incomplete Inputs
- Indicate required fields (through a red asterisk *) and an explaining text
Prevent Invalid Actions
- Disable buttons that cannot be used in the current context.
- Do not offer functionality that is not needed.
Prevent Disastrous Actions
- If actions can have severe consequences for the user, add explaining texts to the respective buttons and inform the users about the consequences
- Send dialogs if users can loose data
Use Controls in the Correct and Intended Ways
- Do not use screen elements where uses expect to use them in any order,
if there are dependencies or if a certain sequence of steps has to be
followed.
Example: Do not use tabstrips for views that depend on each other and cannot be viewed at random. At best, do not force users to perform steps in a fixed sequence. - In general, do not use controls in other than the intended ways. "Creative"
use of controls clashes with the users' expectations and may lead to
severe usage problems.
Example: Do not misuse checkboxes as radiobuttons just because you like the look of the checkboxes better.
Make the Page/iView and its Purpose Clear to the User
- Often important information is hidden while unimportant information dominates the page. In other cases users simply have no clue what an application's purpose is. Thus, provide the necessary information and arrange it so that relevant things are recognized first - this way users realize what to do on a screen and how.
- Use precise descriptions and instructions - do not be too short (especially for Web applications)
Error Handling for Fields
Set the field or fields where an error occurred to the error state (see input field) and place an error message as close to the field where the error occurred as possible (if there is more than one field, place the message at the first error field). Place the cursor into the (first) error field.
Avoid Popups!
Popups interrupt the users' work flow and thus annoy them.
Exception: You may use popups for severe errors like aborts that
need direct user intervention.
Future Development
After validation of a field, the error message will appear in a line directly below the field. As this change in layout can be performed locally, there will be no major screen flicker.
iViews: In addition, iViews (trays) will have a status bar where a general error message will appear. This status bar may also display warnings and success messages (an icon will indicate the type of the message). The location of the status bar can be either below the title bar or at the bottom of the tray (open). The status bar may be hidden by the application.
Error Handling in Tables
Errors can appear in table views for different reasons. For example, a user may enter invalid data, or certain items from a set cannot be posted. These cases have to be handled differently.
Input Errors
If a user enters invalid data, highlight the erroneous fields and scroll the table to the first field where an error occurred.
If an error message is needed, place it below the table view or - if possible - in a table row directly below the row where the error(s) occurred.
Future Development
Table views will have a status bar, where the error message will appear. Place the cursor into the error field and scroll the table to make the field visible in case it is hidden from view.
If there is more than one error field, display the message for the first error field, place the cursor into that field and scroll the table to make it visible if necessary.
If the cursor is placed into a subsequent error field, display the message for the respective field. If an error is corrected move the cursor to the subsequent error field if there is one and display the respective error message.
If the focus is outside the table view, display the first error message again.
iViews: In addition the planned status bar of an iView (tray) may display a general error message.
Posting Errors
Posting errors often do not require to cancel the whole posting process. It is only necessary to correct and re-post those items that were erroneous. Therefore, redisplay the table view with the erroneous items only and provide the user with a possibility to correct the items. Place an error message above the table.
Future Development
Place the error message inside the status bar of the table view.
