Lead:  Yehiel Elad-Certner -  ONGOING  

Description

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

<< Most communicative screenshot of the component >>

Basic Flow

<< Relevant only for patterns that have a more complex flow than the typical control (e.g. drag & drop) >> 

Types 

<< Relevant only if the component has several distinct types (e.g. editable tables, nested tables). In this case each type should be described in a sub-page >>

<<If you are using this section Usage & Behaviour should be used only for the Common functionalities in the page>>

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. Including default values>>

Content

<<Including labels, microcopy, number of items, order of items 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>>

Use:

• <…>

• <…>

Don’t use

• <…>

• <…>

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