Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Lead:  Liav Nadler

Table of Contents

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.

...

either in the main workspace or within other containers, such as Dialog popups,

...

Popovers,

...

Wizards,

...

Filter panes,

...

Details panes and

...

Cards.

Image Removed

In a workspace

In a Dialog popup

Configuration.pngImage AddedImage Modified

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 the Action area, which consists of:

    • a submit button

    (
    • , such as Save, Create,

    Update etc.) and
    • or Edit.

    • a Cancel button.

    • additional actions,

    if
    • where needed.

  • Inside containers, an additional Cancel button may appear.

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 to the labelbe 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).

  • For inline inputs usage and behavior, see Inline Inputs.

...

The Action Area

  • The action area will always be visible.

    In case the form takes
  • up the entire workspace,

    Action buttons will be aligned to the right.

  • Where the action area

    will appear

    appears at the

    top of the page (see Examples below).In any other case

    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

      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

      .

    • the form above

      it.Inside

      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

...

...

  • Buttons for main actions will be aligned to the right. If needed, buttons for secondary actions, such as clear or delete will be aligned to the left.

...

workspace.

Main workspace - less than two thirds height

Main workspace - more than two thirds height

Popup

Entire workspace - form across multiple containers

Action Area without scroll.pngImage AddedAction Area Scroll.pngImage AddedImage AddedImage Added

States

Forms

...

have two possible states:

State

Usage

Idle / Saved

...

Applies when first entering a form or after

...

saving it. In this case

...

, the submit button is disabled.

...

Exiting the form will not save it.

...

Edited

Applies after changes are made to a form, but before saving or submitting. In this case:

...

  • the submit button is enabled (unless there are errors in the form).

...

  • attempting to leave the form will trigger a confirmation message

...

...

  • .

  • changing all fields back to their initial values will not revert the state to Saved.

The Cancel button is always enabled in all states.

Interaction

The submit button

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

    for

    For error handling see Validations and errors below).

  • In

    workspaces

    the main workspace, if the form was submitted successfully

    :A

    a success

    toast

    Toast will appear

    (see Toasts)

    .

    • If the form was triggered from a parent page, the user will automatically be

      directed back

      return to that page.

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

    .

    Clicking the Cancel button, if exists, will close the corresponding component (if not pinned), without saving the data (a confirmation popup may appear). 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:

Validations and errors

  • For input-specific validations see Field Validation.

  • A form cannot be 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, if exists, is always enabled).

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

    • In case of an input error, the submit button becomes disabled. Only after all errors have been resolved, it becomes enabled again.

    • After clicking the submit button:

      • it becomes disabled,

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

  • 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 the user tries to navigate away from a form after updating one or more fields or while there are errors, a message popup will appear, allowing the user to either keep editing or leave (see Common messages repository).

Validation triggers

There are two types of 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.

Creating Process.pngImage 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-20241013-094024.pngImage Added

Short form, where necessary:

image-20241013-094202.pngImage Added
image-20241013-094317.pngImage Added

Short form, where necessary:

image-20241013-094353.pngImage 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-20241013-094736.pngImage Addedimage-20240820-095524.pngImage 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:

In case of unsaved changed

In case of form errors

Leave Form 1.pngImage AddedLeave Form 2.pngImage Added

Best practices

Use for:

  • Creating or updating entities (for example: , such as users, roles, and channels).

  • Configuration (for example: services , such as service-level indicators , or storage retention periods).

General

  • In general, form Form fields should be arranged in one column. Closely related fields (e.g. , first First name and last Last name) can may appear side by side.

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

Examples in different containers

Main workspace

Widget

Wizard

Details pane

Image AddedImage Modified
Image Removed
Image AddedImage Added

Accessibility compliance

Unless otherwise specified, see our general compliance information in Fundamentals - Accessibilitytext 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

...

<<Short Zeplin link. You
Use this
Image Removed>>

...

<<Screen with 200 width>>

Code

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