Lead:  Liav Nadler  ONGOING 

Issues to cover

• 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

Description

• 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.

Basic Flow

• 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).

Usage & Behavior

General guidelines

Structure

• 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).

Placement and Positioning

<<For example, in popups and toast messages>>

Labels above or to the left of input fields.

Default State

In configuration forms it is common the most or all fields have default values.

Content

<<Including labels, microcopy, number of items, order of items etc.>>

Internal Logic

• In some cases, form fields may be dependent on other fields.

States

• 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

Interaction

• For control-specific interactions see the documentation of that control.

Validations and errors

• There are two types of validations related to forms: field validation and form validation.

Field 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.

Form Validation

• 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.

Best practices

<<e.g. Slider should display a label its on>>

Use:

• <…>

• <…>

Don’t use

• <…>

• <…>

Accessibility compliance

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).

Design

Code

<<a box containing the code - discuss with Femi>>