| Table of Contents | ||
|---|---|---|
|
...
Field Validations are a way of making the user understand a mistake, and how to correct it.
...
Types
Type | Usage | Image |
|---|---|---|
| Alerting the user on an action that will not allow them to complete the task. |  |
| Alerting the user on an action that might contain a mistake or a non-fatal error. |  |
Usage &
...
Behavior
Structure
A validation field consists of:
Color frame with a small icon on the top-right corner. This marks the validation type.
A validation Tooltip message, which appears on hover over the validated field.
A descriptive message next to the action buttons:
Error messages have a higher priority than warning messages. When errors are fixed, the warning validation should then be shown.
Where there is limited space or a short form, no descriptive message will appear.
Examples:
Components | Error | Warning | |
 |  |  | |
 |  |  | |
 |  |  | |
 |  |  | |
 |  |  | |
 |  |  | |
 |  |  | |
 | NA |  | |
 | NA |  | |
 | NA |  | |
Single |
 | NA |  |
Checkbox or Radio Button group |  |  |  |
Spreadsheet Tables cell |  |  |  |
 |  |  |
Examples in context:
Call To Action with short text. |  |  |
Call To Action with mixed errors. Error takes priority. |  | |
Call to action with long text. Pop-up size might need to expand in height. |  | |
Unlike Errors, the Warning fields can appear on top of controls which do not have a text field, since a warning can appear when there is a conflict between two controls.
...
Text position can be either near the calls to action (right-aligned) or at the beginning of the row (left-aligned) according to size and available width:
...
Content
Descriptive text near the action buttons.
If only one field hasn’t passed validation, the text near the action buttons should be the same as the tooltip.
If both Warnings and Errors are found, the text should address the Error.
If multiple fields haven’t passed validation of the same type, the text near the action buttons should be ‘X warnings found’.
In cases where the text is very long, the section should get a Scrollbar.
For example:
...
There are 2 options for the content of the error message:
Generic
The content of the message is written in advance and there is no need to refer to the specific text that the user typed, such as This is not a valid zip code.Input based (Preferred where applicable)
The content of the message can dynamically change based on user input. Use it to clarify where the error is coming from. For example:Rather than Invalid input use → Zip codes cannot contain the special character "%".
Rather than You cannot book this flight. Please select another destination or date. Use → Direct flights to Dublin are only available in August. Please select another destination or date.
Rephrasing examples (taken from Verint's Suite):
Before | After |
|---|---|
Percentage must be an integer | Please enter only numbers (e.g. 48) |
Max number of bids allowed (8) for this auction exceeded | You have reached (11) the maximum bids allowed (8) for this auction. Please remove 3 bids. |
Not a valid number, please enter length in minutes | Please enter length in minutes (e.g. 30) |
Invalid selection for employees - single or group | You can select a single employee as well as a single group or organization (not both) |
The form has errors | Please complete all mandatory fields |
Internal Logic
All input fields will display the value entered by the user.
If the input is invalid, an error or a warning message will be displayed.
Prevention of input is not allowed (e.g. not displaying characters in the field as they’re entered).
On Error, the button form Apply/Save button is disabled
Errors and warnings can be triggered by 3 types of action:
Syntax validation.
Validation should be displayed while typing. For example:An illegal character was typed (e.g. numeric instead of alphabetic).
The maximum number of characters has been exceeded (e.g. user input a 3 digit number where only 2 digits are allowed).
Logical validation.
Any validation that is set on the required value (e.g. Max. input of 100). In most cases, the validation will occur after the user has left the field.Missing input on a required field.
Validation is displayed as soon as the user leaves (out of focus) a required input field that has no input.
Note: when a form has a single required field, the validation will appear only after the user tries to submit the form.
...
Some cases require an automatic correction of the invalid input:
The components Pagination and Slider with a numeric input, which have a clear visible definition of a numeric range, will behave as follows.
An invalid value will be indicated.
When the user clicks outside of the field (out of focus), the entered value will automatically change to:
Last valid.
Edge range, if the input exceeds the range of options (e.g. in pagination 0 will auto-correct to 1).
Connected fields. Where different fields are dependent on each other, and the numeric range is dynamic.
When the user clicks outside of the field (out of focus) with an indicated invalid input, a Popup message will appear with the options of:Back - returns the focus to the field with the last used input.
Revert - returns the focus to the field with the latest valid input (the one before the user had changed).
...
Default validation
When a form or page is opened for the first time, and the fields are empty, the missing validations should not be shown. Otherwise, the whole page may be covered in validation messages from the start. However, Syntax and Logical validation should be enabled where appropriate.
Only Syntax errors and warnings will be shown while the user is editing a field (it is in focus).
All other warnings and errors (Logical and Missing) will be hidden while the user is editing a field (it is in focus). They should appear again once the user clicks outside of the field (it is out of focus).
...
Tooltips positioning examples on hover:
Content | Examples | Comments |
|---|---|---|
1 or more rows of text, to the right of the warning or error icon |  | |
Partial coverage of control |  | User can still click the control |
Left position |  |
Best Practices
Use field validations for any user input fields.
Specify why the field information has not been accepted. Your validation messages should tell users exactly why their information got rejected or may have some risk, and how it can be fixed.
If the values entered may impact some other part of the system, briefly explain what may be impacted.
Keep the text short!
For complicated fields, using an example in the tooltip message can help.
Try to avoid negative words. For example: Rather than Password does not meet requirements or Invalid Password use → Password must contain 8 alphanumeric characters.
Additional examples to avoid:
Oops. Oops, something wasn’t right.
Error. This form has errors.
Failed. Form submission failed!
Problem. There was a problem creating your account.
Invalid. Oops, Something has gone wrong.
Prohibited. 3 errors prohibited this user from being saved.
...
Unless otherwise specified, see our general compliance information in Fundamentals - Accessibility.
Design
Zeplin link | Screen thumbnail |
|---|---|
 | |
 |