Lead: Liav Nadler  

Description

An inline editable table is a data table type of Data Table in which the user can edit data inside the row, without the need to navigate to a separate page, a panel or a popup.

Image Removed

Usage & Behaviour

General guidelines

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

States

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

Interaction

• Clicking the 

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

...

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

Code

...

https://zpl.io/29Wxw6z

Image Added

Code

...