Lead:  Liav Nadler  

Description

<< Short description of the component and when it is used >>

<< Most communicative screenshot of the component >>

Usage & Behaviour

<< Use a visual for each sub-section >>

General guidelines

<< Describes the component, use sub-section when they are relevant to the components >>

<< In case of a complex component duplicate this section, describing each sub-component separately >>

Structure

• A description of the structure of the component, including areas, sub-components etc.

Placement and Positioning

• For example, in popups and toast messages

Default State

• When there is more than one state for a control or area

Content

• Including labels, microcopy, number of items, order of items, default values etc.

Internal Logic

• For example, controls dependencies in a form

States

<<e.g. active disabled, error, hover, temporary (spinner size), empty etc...>>

Interaction

<<for example, how to change a value – type, arrows, use slider>>

<<use Click target to describe the interaction>>

Validations and errors

<<used for specific components e.g. slider>>

Transitions

<<Used to describe transitions or animations the occurs in any of the interaction stages>>

Best practices

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

Accessibility compliance

<<In general each component should be A11y complied,  please follow the 3 guidelines linked below. At the very least we should document that each component is in compliance with each of the 3>>

Focus management

<<How will the component work with keyboard only - without a mouse. Can be reference if written above

We already set a general guidelines described in /wiki/spaces/UX/pages/308969693 >>

Screen reader support 

<<Make sure the components support screen reader for content or behaviour where needed - see /wiki/spaces/UX/pages/308248620 >>

Contrast & size compliance

<<Visual designers must comply with the minimal of /wiki/spaces/UX/pages/301498483 for each component>>

Design

...

...

Code

<<a box containing the code - discuss with Femi>>An inline editable table is a type of Data Table in which the user can edit data, without the need to navigate to a separate page, a panel or a popup.

...

Basic Flow

An editable table is similar to a standard Data Table, with these exceptions:

• Hovering a row will show an edit icon.

• Clicking the edit icon:

  • Selects the entire row (if not already selected).

  • Changes all relevant cells to input fields. This may include Text Fields, Drop-down Menus, Numeric Steppers, Date Pickers etc.

  • Replaces the action icons with two buttons: Apply (emphasized dialog button) and Cancel (regular dialog button). See Dialog Buttons.

• In edit mode, the user can enter values or update any input field, in any order.

• When finished, the user has two options:

  • Clicking Apply switches the row back to its original state, with the updated set of values.

  • Clicking Cancel (or Esc) switches the row back to its original state, with the previous set of values (before making any changes).

Placement and Positioning

The width of the actions column should leave enough space for all options which will appear on editing, e.g. Apply and Cancel text buttons.

Validations and Errors

• Long inputs in text fields will be treated as regular Text Fields, unless otherwise specified.

• In edit mode, clicking on any element on the page after changing a field will show a popup message, warning about the potential data loss. In this case:

  • If the user chooses to keep editing, the popup will close, and the page will auto-scroll to the relevant row, if needed.

  • If the user chooses to close and discard changes, the row will switch back to normal mode, with the previous set of values.

• In case the table is part of a form with its own Save and Cancel buttons and one of the rows is in edit mode:

  • Clicking the Save button will apply all changes that were made to that row (as if the user also clicked the Apply button).

  • Clicking the Cancel button will revert all the fields in that row to their previous values.

Best Practices

Use:

• when the table is relatively simple (up to 8 columns).

Don’t use:

• where selecting a row is the first step of a complex flow.

• where the table contains more than 8 columns.

• where one or more of the fields can hold large amounts of text.

Accessibility compliance

Focus management

In edit mode:

• By default, the first input field will be in focus.

• See thefocus management sectionin the main data tables page for more information.

Unless otherwise specified, see our general compliance information in Fundamentals - Accessibility.

Design

Zeplin link	Screen thumbnail
https://zpl.io/29Wxw6z	Image Added

Code

...