Description

ONGOING 

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 validation should be displayed while typing
  • 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)
• 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 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, validation should not be enabled. in cases where he 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		on Error validation button is disabled
Call To Action with mixed errors  error takes priority
Call to action with long text.  Pop-up size might need to expand in height
*or any other controls that require user input and needs to be validated.  What Not: inputs that have default selection only (e.g. radio buttons or some dropdown menus) inputs that does not have text entry option, (when selection is done from a dropdown for example, we need to limit his selectable options to be only the valid ones)

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 - 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:

Current appearances in our products