| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
Description
Status colour Blue title Done
Field Validations are a way of talking to our users. It is designed to make the user understand a mistake and the ways to correct it.
Example:
Types
| Type | Usage |
|---|---|
| Alerting the user on actions that will not allow him to complete the task. |
| Alerting the user on actions that might contain a mistake or a non fatal error. |
Usage & Behaviour
Internal Logic
Triggering the validation can be by 2 types:
- Syntax validation - validation should be displayed while typing. For example:
- illegal character was typed (e.g. numbers instead of alpha-betic)
- exceed the number of characters (e.g. user input 3 digit number where only 2 digit is 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 left the field
When starting to edit a field with a validation indication on it, the current indication will be hidden (i.e. it will be treated as if the user had edited the field for the 1st time).
If user had entered a form/page/screen for the first time (fields are empty), logical validation should not be enabled. However, syntax validation should be enabled.
In cases where user enters a page that already had input, the warning validation should be displayed (e.g. the user enters a page already edited with warnings in it).
...
- 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 changed it)
See pop-up example:
Structure
The field validation consists of:
- Color frame or & a Small icon on the top right corner - marks the validation type
- A validation tooltip message appears upon hover of the validated field/component
- A descriptive message next to the submit button
- Error messages have a higher priority than warning. In case the error was fixed, the warning validation should be presented.
- In some cases of limited space or a short form, no descriptive message will appear
Examples:
Components | Error | Warning | |
Text field |
|
|
|
Text area |
|
|
|
| Dropdown menu |
|
|
|
Combo box (free text field) |
|
|
|
Spinner (free text field) |
|
|
|
Date Picker (free text field) |
|
|
|
Time Picker (free text field) |
|
|
|
| Search field |
| NA |
|
| Toggle |
| NA |
|
| Slider |
| NA |
|
| Single checkbox |
| NA |
|
| Checkbox group |
|
|
|
| Grid table cell |  |  |
|
| Tab |
|
|
|
Call To Action with short text |
|
| |
Call To Action with mixed errors
|  | ||
Call to action with long text.
|
| ||
* Unlike "field validation error" the warning version can appear on top of controls that does not have a text field, since a warning can appear when there is a conflict between 2 controls. | |||
Text
- Descriptive text near the CTA (e.g. Submit)
- If only 1 field didn't pass validation, the text near the CTA should be the same as the tooltip
- If multiple fields didn't pass validation of the same type, the text near the CTA should be "X warnings found" <<TBD with Docs.>>
For example:
- If both Warning and Error are found, the text should address the Error
- In general
- Specify why field info was not accepted - your validation messages should tell users exactly why their information got rejected or may have some risk
- If the values entered may impact some other part of the system, briefly explain what may be impacted
- Keep it short!
Interaction - validation tooltips
- Any field/tab that has validation indication will also have a tooltip
- The validation tooltip takes priority over a any other tooltip (if exists)
- Location of tooltip is by default on right of the field except when there is no space
- Tooltip timing should be - Tooltips (see interaction section)
- Warning and Error has the same tooltip interaction
Tooltips positioning examples:
| Content | Examples | Comments |
|---|---|---|
| 1 or more rows of text right to the icon of validaton |
| |
Partial coverage of control |
| User can still click the control |
| Left position |
| |
...
Best Practices
Content Guidelines
- 2 options for 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, for EX: "not a valid zip code" - Input based (
Preferred option where applicable)
The content of the message can dynamically change based on the input of the user, use it to clarify to the user where the error is coming from.
Some examples:- Invalid input → zip code cannot contain the spacial character: "%"
- You cannot book this flight, please select another destination or date → Direct flights to Dublin are only available in August. Please select another destination or date
- Generic
- For complicated fields, an example in the text of the tooltip can help
- Try to avoid negative words
- (e.g. "Password does not meet requirements" or "Invalid Password" → could be turned into→ "Password must contain 8 alphanumeric characters")
Accessibility compliance
...