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.

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 a page, submitting a form, or saving updates. They communicate an applications 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

Linear progress indicators are composed of two required elements:

1. Track - The track is a fixed width rule, with set boundaries for the indicator bar to travel along.
2. Indicator Bar - The bar animates along the length of the track.

Placement and Positioning

The placement of a progress indicator can indicate the scope of a process. Progress bars should only be placed at the top or in the center of a container or component. For example:

• A progress bar at the center of the screen should indicate loading all screen content (and that no interaction is possible until complete)
• A progress bar attached to the top a container, such as a card indicates the process applies to that particular item (and that interaction with the rest of the UI is possible)

Default State

Progress bars should be hidden by default and only appear on screen when they are active. Once complete, the progress bar should return to it's default state (removed from view) in most cases replaced by the content that was loaded.

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