...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Status | ||||
---|---|---|---|---|
|
Table of Contents | ||||
---|---|---|---|---|
|
...
Status | ||||
---|---|---|---|---|
|
Description
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.
...
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:
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!
...
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 | ||
Some cases allow the user to auto-correct the entered input - Validation applies in the background.
...
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, 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
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
...
Zeplin link | Screen thumbnail |
---|---|
https://app.zeplin.io/project/5970b366bee38cf87b2de932/screen/5baca0fa7044c49e813fe220 | |
https://app.zeplin.io/project/5970b366bee38cf87b2de932/screen/5baca11066034667cc35f576 |
Code
<<a box containing the code - discuss with Femi>>
...