Lead:  Liav Nadler   ONGOING     

Related Pages: << Links to related pages, if relevant >>

Description

A tree table is a type of data table, where each row can be expanded to reveal related child rows

Basic Flow

A tree table is similar to a basic table, with the exceptions described below:

• The first column of the table (e.g Name):
  • Cannot be moved
  • Contains icons on each row, allowing the user to expand and collapse them
• By default all rows are collapsed
• Expanding a row reveals at least one child row
• On child rows:
  • The text of the first column is indented in relation to parent rows
  • All other cells may be similar to the parent rows or blank (if child row does net share the same values)
• If the table has a checkboxes column, clicking a parent checkbox will check all child checkboxes. For more information see Checkboxes 
• Table rows may be draggable (see example above). For more information see Drag & Drop
• Sorting behavior?
• Best practice - expand all collapse all?

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