Lead:  Liav Nadler  

Issues to cover

• Validations

  • Invalid values

  • Blank mandatory fields

• 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 a further processing.
Forms may appear in workspaces, wizards or dialog popups, popovers,wizards,filter panes, details panes and cards.

...

Types

Type	Description	Example
Configuration forms	Allowing users to update predefined configurations. By default, most of the fields has predefined values.	Entity Image Added
Create / edit forms	Allowing users to create and edit entitiesobjects. By default, most of the fields are blank.

Basic Flow

...

A form may appear when navigating to a workspace or clicking a button.

...

Filling in the form. This can be done in any order.

...

Clicking the Save (or Create or Update) button.

...

Image Added

Usage & Behavior

General guidelines

Structure

• A form consists of two areas: the input area and the action area.

• The input area may contain any set of componentsinput fields, including text fields, dropdown menus, checkboxes, radio buttons etc.

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

• The action area usually consists of two buttons: Save (or Create, or Update) for submitting the form, and Cancel for going back without submitting the form (see interactions below)..

• The action area will always be visible. In case the form fills takes up the entire area of a workspace, the action area will appear at the top of the page.

• In any other case, it will appear below the form:

  • Within the container

  • Exceeds the container

Placement and Positioning

• Forms may appear in workspaces, widgets, wizards or dialog popups.

• In case the form takes the entire area of a workspace

  • In dialog popups, popovers,wizards,filter panes, details panes and cards, the action are will appear at the bottom of the container.

  • In workspaces:

    • If the form exceeds the height of its container, the action area will

  appear at

  • • stick to the

  top

  • • bottom of the

  page

  • • container,

  opposite

  • • allowing users to scroll the

  page title

  • • form above it.

    • If the form

  takes only part of the workspace (e.g., inside a dialog or a widget),

  • • does not exceed the height of its container, the action area will appear

  at

  • • directly below the

  bottom of the container. In this case, the action area will also be sticky, to allow users scrolling along the form, without hiding the action buttons.

  • • last field of the form.

Add examples

Placement and Positioning

• Do we need anything here?

Fields

• Field labels will appear on top of the input field (e.g., a text field or a set of radio buttons).

• On mandatory fields, a mandatory indicator () will be shown next to the label.

• Where relevant, a help icons will appear next to the label.

• In some cases, two or more fields will be dependent. In this case, selecting a value for the dependent fields will not be possible until a value exists in the main field.

...

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

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

• This flow is also relevant when the form is in a dialog popup. In this case, the cancel button is always enabled.

...

• Values have a distinct order.

• There is a default value.

• There are at least three possible values.

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 that label texts are not selectable.

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

...

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

...