| Expand | ||||||
|---|---|---|---|---|---|---|
| ||||||
|
Description
| Status | ||||||
|---|---|---|---|---|---|---|
|
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
On fields, triggering the validation can occur before or after submitting the form:
- 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
- In most cases the validation will occur after the user left the field
- If the field value is connected to another value in the system, on top of the behaviour described above, as soon as the user try's to leave the field, a pop up message will appear with the options of
- Cancel - 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)
<<TBD - picture of pop-up>>
If a user started editing a field which had a validation indication, the indication will be removed (i.e. it will be treated as if the user had edited the field for the 1st time).
<<TBD animation - show with at spinner field for ease of creating>>
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 validation should be displayed (e.g. the user enters a page already edited with warnings in it)
Structure
The field validation consists of:
- Color frame or & a Small icon on the top right corner - marks the validation type
- A validation message appears upon hover
- A descriptive message next to the submit button
- Error messages have a higher priority than warning. Therefore, Error message will appear first and only of the error was removed, the warning will be displayed)
- In some cases of limited space or a short form, no descriptive message will appear
Examples:
Components | Error | Warning | |
Text field |
|  |
|
Text area |
|  |
|
Combo button (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  | <<TBD - Add in LUX>> | ||
Call To Action with short text |
|
| |
Call To Action with mixed errors
|  | ||
Call to action with long text.
|
| ||
*or any other controls that require user input and needs to be validated. What NotInputs with no validation:
| |||
on Error validation button is disabled
...
Best Practices
Content Guidelines
- 2 options for content of the error message:
- Pre-defined
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
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.
(e.g. zip code cannot contain the spacial character: "%"
- Pre-defined
- For complicated fields an example in the text 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
...