Lead:  << Your name/s >> << Select the status -  ONGOING WAITING DONE PUBLISHED ON HOLD >>

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

Description

Progress bars express an unspecified wait time or display the current completed ratio of a process or action.

<< Most communicative screenshot of the component >>

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

Progress bars inform users about the status of ongoing processes, such as loading an app, submitting a form, or saving updates. They communicate an app’s state and indicate available actions, such as whether users can navigate away from the current screen.

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