Lead: << Your name/s >> << Select the status - ONGOING WAITING DONE PUBLISHED ON HOLD >>
Related Pages: << Links to related pages, if relevant >>
Description
Progress indicators express an unspecified wait time or display the current completed ratio of a process or action.
Types
Linear and circular
LUX offers two visually distinct variations of progress indicators: linear and circular progress indicators. Only one type should represent each kind of activity in an app. For example, if a refresh action displays a circular indicator on one screen, that same action shouldn’t use a linear indicator elsewhere in the app.
Type | Usage | Image |
|---|---|---|
For operations in which the length of the process is known. Determinate operations display the indicator increasing in width from 0 to 100% of the track, in sync with the process’s progress. |  | |
Circular progress indicators display progress by animating an indicator along an invisible circular track in a clockwise direction. The behaviour of the indicator is dependent on whether the progress of a process is known. They can be applied directly to a surface, such as a button or card. |
Usage & Behaviour
Progress indicators 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
Structure
Linear progress indicators are composed of two required elements:
Track - The track is a fixed width rule, with set boundaries for the indicator bar to travel along.
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
Progress bars don not support user interaction, they are solely used to provide a visual status indicator.
Best practices
Don’t stop a progress bar - A progress bar makes users develop an expectation for how fast the action is being processed. As a result, any unexpected freezes will be noticed and will impact user satisfaction. The worst possible case is when progress bar approaches 99% and suddenly stops. Most users will be frustrated by this behavior because it makes them think the app is frozen. There is a simple solution — you can disguise small delays in your progress bar by moving it instantly and steadily.
Explain why the user is waiting - Many times, if users are informed, they may be more patient. It can be helpful to add additional clarity by including text that tells the user what is happening or explains why the user is waiting.
Provide a general time estimate for time-consuming tasks - Don’t try to be exact, a simple, “this might take five minutes” can be enough for the users and encourage them to wait it out.
Accessibility compliance
A progress bar indicates that the user's request is received and is in the process of executing the task. Content authors should provide values of aria-valuemin, aria-valuemax and aria-valuenow where the aria-valuemax is known. Further guidelines for optimum compliance can be found at ARIA progressbar role.
Focus management
Progress bars a purely visual indicator that contains no user interaction and therefore cannot be focused on.
Screen reader support
Following the recommendations provided above for ARIA support will also provide the necessary tools for screen reader support. Users are notified about the existence of a progressbar on the page when they encounter the ARIA progressbar role. Make sure the corresponding content areas also supports screen readers for content and behaviour - see Screen Reader Guidelines
Design
Zeplin link | Screen thumbnail |
|---|---|
 |