Introduction to Error Handling
Handling errors properly and using effective form messages is part of a broader, successful messaging strategy (see Introduction to Messaging). The errors discussed here pertain to user errors, caused by invalid inputs or actions, though system errors from failures in the application may also exist.
Best Practices
Prevent Errors
A well-designed interface limits user errors or prevents them entirely. While the approach taken to achieve this depends on factors like the technology stack used, consider the following:
- Identify required and optional fields in forms.
- Show character counts and limits to indicate how much content can be entered in a field.
- Warn users about destructive actions and provide “Undo” actions so users can recover from unintentional situations.
- Disable inactive controls or options. For example, deactivate the submit button until all required - information is provided.
- Provide brief, help text to explain difficult concepts.
Displaying Errors
When errors do occur, use the following techniques to allow users to quickly resolve the problem:
- Use brief, specific error messages to explain what went wrong and how to fix it.
- Use the appropriate message type. For example, do not show warning messages for critical errors.
- Place the error message in the appropriate and consistent position as determined by Page-Level), Container-Level) and Field-Level) Message components.
- Use the appropriate Voice and Tone) for the error message.
Examples
These examples illustrate different scenarios in which errors could occur, with possible resolutions based on the technology stack in use. Use the toggles to change whether validation occurs on the client-side or server-side.
We highly recommend validating inputs server-side in addition to client-side, particularly when the inputs are stored in a database.
1) Invalid format/data
- Client-side validation, including asynchronous validation, should occur when more than one character has been input and the user pauses or blurs the field.
- Server-side validation should occur when the form is submitted.
Client-side Validation
Asynchronous Validation
Server-side Validation
2) “Levels” of acceptable data
- Client-side validation should occur when more than one character has been input and the user pauses or blurs the field. Asynchronous validation is not required if validation patterns are known and can be done on the client.
- Server-side validation is highly recommended as a redundant system before saving inputs in a database.
Client-side Validation
3) Disabled submit button until all data is valid
- Client-side validation, including asynchronous validation, should occur when more than one character has been input and the user pauses or blurs the field. If on the last field in the form, validation should occur on pause as well as blur if the user rapidly moves away from the field. The submit button should become active if all required fields have been filled.
- Server-side validation cannot occur as a validation mechanism as the Submit button is disabled, but is highly recommended as a redundant system before saving inputs in a database.
- If Javascript is disabled, the Submit button should be made active to allow server-side validation and completion of the form.
Client-side Validation
All fields are required unless marked optional
4) Re-entering data in a field that has an error
- If errors are already present on a field, client-side validation should occur on keypress and when the field is blurred. The same applies for asynchronous validation.
- Server-side validation should occur on submission, and as a redundant system to any client-side validation, particularly when saving inputs in a database.
Client-side Validation
Asynchronous Validation
Server-side Validation
5) Focusing on and then blurring an empty field
- If a field is focused and blurred without any content, validation should not occur as the user might return to the field to complete it.
- Server-side validation should occur on submission, and as a redundant system to any client-side validation, particularly when saving inputs in a database.
Client-side Validation
Additional Guidelines
When multiple errors are displayed, show a summary of the errors and scroll the user to the summary message or the first error message in the series. In addition, show individual messages underneath all errant fields.
Use warning messages for things that might lead to unexpected results e.g. changing the currency used for reports.