Lead: Liav Nadler
Inputs
Default values
Field dependencies
Mandatory indicators
Validations
Invalid values
Blank mandatory fields
Leaving the page without saving
Grouping fields
Form-level elements
Status tags
Messages
Action buttons
Top for form-level
Bottom for widget-level, sticky
Distances between buttons (if more than 2)
Guidance
Form instructions
Field help
Autosave
Preventing users from selecting labels
A form is a collection of input controls, allowing users to enter data that is then sent to a server for processing.
Forms may appear in either workspaces, wizards or dialog popups.
This page will focus mainly on forms within workspaces, although many of the guidelines are common for all forms.
There are two basic form types:
Configuration forms - allowing users to change predefined settings (e.g. service level indicators).
Creation forms - allowing users to create new entities (e.g. employee evaluations). In this case, most of the fields in the form will be blank by default.
Some forms consists of both configuration and creation elements.
The user can fill in the fields in any order before saving or applying the form.
After filling in a form, clicking the Save button (in configuration pages) or the main button in dialogs triggers a server-level validation (see below).
Any form consists of two areas: the input area and the action area.
The input area may contain any set of controls, including text fields, text areas, dropdown menus, checkboxes, radio buttons, date and time pickers etc.
The action bar usually consists of two buttons: Save for submitting the form and Cancel for resetting the form (see interactions below).
<<For example, in popups and toast messages>>
Labels above or to the left of input fields.
In configuration forms it is common the most or all fields have default values.
<<Including labels, microcopy, number of items, order of items etc.>>
In some cases, form fields may be dependent on other fields.
Forms can have 3 states:
Idle - this is the default for creation forms. Exiting the form without changing any field will remove
Dirty state - a form switches to this state after making any chang
Saved -
When first opening a configuration form it is defined as saved. Updating any of the fields, switches it to dirty state.
On dirty state the user can either save (or apply) the form
For control-specific interactions see the documentation of that control.
There are two types of validations related to forms: field validation and form validation.
This category includes all validations that are related to specific inputs, including text fields, text areas, sets of checkboxes, date and time pickers, etc.
The most common input-level errors are:
Invalid data, including invalid characters, invalid format and out-of-range values.
Missing mandatory, where a required field was left blank.
Field validations for invalid characters or invalid format occurs while typing (“onkeydown”).
Field validations for out of range data or missing mandatory occurs when a field looses focus (“onblur”).
When invalid data or missing mandatory field was detected, the field changes its status to error.
In some cases, the entered value is valid, but may call for a special attention (for example: a very large value). In this case, the field will change its status to warning, but will not prevent the form from being submitted.
For more information, please refer to LUX Field Validation page.
A form cannot be saved / submitted if one or more of its fields are in error state.
Here is a typical saving flow:
When first entering a form, the Save button is disabled.
On updating a field, the Save button becomes enabled.
In case of a field error the Save button becomes disabled. An additional form-level indication may appear. Only after the error was resolved, the Save button is enabled again.
After clicking the Save button, it becomes disabled again.
This flow is also relevant when the form is in a dialog popup. In this case, the cancel button is always enabled.
Saving “dirty data” in local storage
In case a single Save button applies to multiple areas (tabs, master items in a master-detail layout, etc.), updated values will be saved in a local storage even before clicking the Save button.
In this case, if the user updated a value in the first area, navigated to another area and went back to the first area, all updated values will remain intact.
Edge case: navigating to another area of the form while some fields has errors
In case the user tries to navigate to another area of the form, while the current area has errors, a message popup will appear, allowing him to either continue, while loosing all the updated data, or cancel.
Edge case: exiting an updated form
In case the user tries to navigate away from a form after updating one or more fields, a message popup will appear, allowing her to either save and exit, exit without saving, or cancel.
<<e.g. Slider should display a label its on>>
Use:
<…>
<…>
Don’t use
<…>
<…>
Unless otherwise specified, see our general compliance information in Fundamentals - Accessibility
text highlight when using a keyboard + using arrows when in edit mode (left, up or home to set the insertion point at the beginning; right, down or end to set it at the end).
Zeplin link | Screen thumbnail |
|---|---|
<<Short Zeplin link. You | <<Screen with 200 width>> |
<<a box containing the code - discuss with Femi>>
>>