Lead:  Liav Nadler

Issues to cover

• Form-level elements

  • Status tags

  • Messages

• Action buttons

  • Distances between buttons (if more than 2)

• Guidance

  • Form instructions

  • Field help

  • Ask Femi about web SDK form guidance

• Autosave

Description

A form is a collection of input fields, allowing users to enter data that is then sent for further processingstore, retrieve, and update data.

Forms may appear in workspaces, dialog popups, popovers,wizards,filter panes, details panes and cards.

...

either in the main workspace or within other containers, such as Dialog popups, Popovers,Wizards,Filter panes, Details panes and Cards.

In a workspace	In a Dialog popup
Image Added	Image Added

Usage & Behavior

Structure

A form consists of two areas:

• the input area and the action area.The input area may contain Input area, containing any set of input fields , including text Text fields, dropdown Drop-down menus, checkboxes Checkboxes, radio Radio buttons etc.

• The action area usually the Action area, which consists of at least two buttons:

  • a submit button

  (

  • , such as Save,

  or

  • Create, or

  Update etc.) and Cancel

  • Edit.

  • a Cancel button.

  • additional actions, where needed.

The Input Area

• For specific form elements, browse the Components section in LUX.

• Where possible, field labels will appear above the input field (for example, above a text field or a set of radio buttons).

• Where relevant, a red mandatory indicator (*) will show next be shown to the right of the label.

  • Where a majority of fields are mandatory, a message will appear above the form indicating that all fields are mandatory unless otherwise specified.

• Where relevant, a help icon will appear next to the label (aligned to the right side of the field, if possible).

• A collection of related fields can be grouped into a section. For example, fields like Email and Phone can be found under a section called Contact Information.

• For forms with inline inputs, see Inline input.

...

The Action Area

• The action area will always be visible:

• In case the form takes up the entire workspace, the action area will appear at the top of the page (see examples below).

In any other case

.

• Action buttons will be aligned to the right.

• Where the action area appears at the bottom of the main workspace, it will be separated by a horizontal line.

Placement and positioning

In most cases, the action area will appear below the form

...

In workspaces:

...

.

• Within the main workspace, where the form does not exceed the height of

  its

  the container,

  • the action area will appear

    directly below

    beneath the last form field

    of the form

    .

    If

• Within the main workspace where the form

  exceeds

  reaches the

  height

  bottom of

  its

  the container, and within Popups and other modals:

  • the action area will stick to the bottom of the container

    , allowing users to scroll

    .

States

• Forms can have 3 states:

  • Idle - the default state when entering a form. In this state, exiting the form will not save it.

  • the form above

    it. Add example

• Buttons for main actions will be aligned to the right. Buttons for secondary actions, such as Clear or Reset will be aligned to the left.

...

• • Edited state - the state of a form after making changes but before clicking the Save button. In this state, exiting will have a scrollbar.

In some cases, where a form uses the entire workspace and is shown across multiple containers, the action area may appear at the top of the workspace.

Main workspace - less than two thirds height	Main workspace - more than two thirds height	Popup	Entire workspace - form across multiple containers
Image Added	Image Added	Image Added	Image Added

States

Forms have two possible states:

...

Saved - the state of a form after clicking the Save button.

...

The Cancel button is always enabled in all states.

Interaction

The submit button

• Clicking the submit button sends the data for further processing.

• Clicking the Cancel button will close the dialog popup / popover, or direct the user to the original page, without saving the form.

...

• . (For error handling see Validations and errors below).

• In the main workspace, if the form was submitted successfully a success Toast will appear.

  • If the form was triggered from a parent page, the user will automatically be return to that page.

• For forms inside containers, refer to the corresponding pattern documentation. For example:

  • clicking the submit button in a Dialog popup closes it.

  • clicking the Apply button on a Filter pane applies the filter and disables the button.

The Cancel button

• Clicking Cancel on a form with unsaved changes may trigger a warning message, where necessary.

• In the main workspace clicking Cancel will return to user to the parent page, without saving the data.

• For forms inside containers, refer to the corresponding pattern documentation. For example:

  • clicking Cancel will close Popups and Popovers.

  • clicking Cancel may close the Filter pane, depending on the pin state.

Validations and errors

Validation triggers

There are two types of

...

Field validations related to specific inputs, see Field Validation.

Field Validation

• The most common input-level errors are:

  • Invalid input, including invalid characters, invalid format and out-of-range data.

  • Missing mandatory input, 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 input occurs when a field looses focus (“onblur”).

• When invalid input or missing mandatory input 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.

Form Validation

• A form cannot be saved or submitted if one or more of its fields are in error state. Here is a typical flow:

  • When entering a form, the submit button is disabled (the Cancel button is always enabled).

  • On updating any field, the submit button becomes enabled.

  • In case of an input error, the submit button becomes disabled (an additional form-level indication may appear). Only after the error was resolved, it becomes enabled again.

  • After clicking the submit button:

    • it becomes disabled,

    • a toast message appears, indicating that the form was saved.

• This flow is similar where the form is in a dialog popup, but in this case, clicking the submit button closes the popup.

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

...

validation which may affect a form:

Type	Trigger events	Examples	Notes
Client-side validation	Moving focus away from a field. Clicking the submit button on the form.	Invalid values. Invalid formats. Blank mandatory fields.	Client-side issues are either resolved immediately (for example, on deleting an invalid character) or when the field loses focus.
Server-side validation	Clicking the submit button (or Next button in Wizards). Clicking the Save button of an Inline input.	When logical problems are detected, e.g. trying to create an object with a name that already exists.	In some cases, a Dialog popup may appear with additional instructions required to complete the action. When validation takes more than a few seconds, a Progress indicator will appear in a modal. Image Added

Presentation of errors and warnings

Errors and warnings are shown:

• against individual form fields - see Field validation for more information.

• as a message in the action area - see details below.

While the form contains an error, the submit button will be disabled.

...

A dedicated message will appear to the left of the action area. It will include:

• a status icon. If both errors and warnings are present, an error icon will be used.

• descriptive text including a link, and showing the total number of errors and warnings.

Error message	Warning message
Image Added Short form, where necessary: Image Added	Image Added Short form, where necessary: Image Added

Clicking the link opens a Popover, containing additional information. The popover includes:

• general introductory text describing the number of issues and how to resolve them.

• a list of issues, with errors appearing before warnings. Each issue will show:

  • an error or warning status icon.

  • a description of the issue and how to resolve it.

  • a Resolve or Review link, where relevant. Clicking the link closes the popover and sets the focus on the corresponding form field. The form may auto-scroll where necessary.

Examples

Image Added

Image Added

Leaving an incomplete form

When the user navigates away from a form in the Edited state (after updating one or more fields), or while there are errors on the form:

• a Message popup will appear. See Common messages repository for appropriate message text.

• the user will choose to either keep editing the form or leave and discard changes.

In case of unsaved changed	In case of form errors
Image Added	Image Added

Best practices

Use for:

• Creating or updating entities (e.g., such as users, roles, and channels).

• Configuration pages (e.g., services , such as service-level indicators , or storage retention periods).

Don’t use:

• When?

General

• In case of large number of fields, group related fields together, providing a clear title to each group.

• Make sure there is a natural tab order between fields.

• Make sure that label texts are not selectable.

Examples

...

Update screen

...

• Form fields should be arranged in one column. Closely related fields (e.g. First name and Last name) may appear side by side.

• Collections of related fields should be grouped into sections. For example, fields such as Email and Phone may be grouped under a Contact Information section.

Examples in different containers

Main workspace	Widget	Wizard	Details pane
Image Added	Image Added	Image Added	Image Added

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

...

Zeplin link

...

Screen thumbnail

...

.

...

<<Screen with 200 width>>

Code

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