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.  

Example:

Types

Usage & Behaviour

Internal Logic

On fields, triggering the validation can occur before or after submitting the form:

• In most cases the validation will occur after the user left the field
• In some fields the 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 he 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  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

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 << or should it be a counter>>
  • 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 some cases the text might be different from the tooltip to further explain
• 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
• Text should be kept short and up to 2 rows 
• Tooltip timing should be - Tooltips (see interaction section) 
• Warning and Error has the same tooltip interaction

Tooltips examples: