DocuWare Design

Guidelines to empower the DocuWare products' inclusivity and accessibility

Docy

Loaders

Estimated reading: 6 minutes 84 views

What are Loader components?

Loaders are progress indicators informing users about the system’s or separate elements’ status of ongoing processes, such as loading, fetching, and submitting.

In addition, Loaders show the completion status of ongoing tasks and indicate whether a user can continue or leave the current context or flow.

 

A good Loader:

  1. Makes a user’s perception of time feel faster.
  2. Gives the sense that the application is making progress.

Loading Patterns

The two main Loading Patterns used in the Design System are Indeterminate Loaders and Determinate. The determining factor is time.

  • Determinate Loaders communicate a sense of duration. They have a starting point and an endpoint. They give users more information on how much time they can expect to wait.
  • IndeterminateLoaders have an uncertain duration. A common example is a looping animation or a spinner. They are less informative but are inevitable.

     

Principles

Loaders are communicative UI elements. They look and animate in ways that reflect the status of ongoing processes in the product and User Interface. They should never be decorative or used as placeholders.

Loaders use animation to capture users’ attention and inform them of an activity’s progress.

Loaders should be applied to all steps of the system processes (such as loading, saving, submitting, fetching, etc.) in a consistent, context-related way.

Loaders notify users that their request is performed. Although they do not provide details, they reassure users that their action is being processed

Loaders can help people decide whether to do something else while waiting for the task to complete, restart the task at a different time, or abandon the job.

Types

Based on the duration of an operation, there are the following types of Loaders:

Loading Spinner

Used for indeterminate, unquantifiable tasks when the operation time is unknown (ex., loading or synchronizing complex data).

Progress Bar

Mainly used for determinate tasks with a well-defined duration.

Skeleton loaders

Used for indeterminate tasks with unknown operation time.

As a general rule of thumb, the following guidelines should be considered:

Duration Loader Type
0–2 seconds
No indication is needed (generally instantaneous to the user).
2–5 seconds
Loading Spinner should be used.
5-10 seconds
Progress Bar should be used

Note: A textual indication of the time remaining is generally recommended in these scenarios.
10+ seconds
Progress Bar alongside Cancel Button should be used. Users should be able to cancel the process.

Note: A textual indication of the remaining time is strongly recommended in these scenarios)

Usage

  • Loaders should be used to step a user through a journey so that they can keep track of their and the system's progress.
  • Only one Loader type should represent each kind of activity in User Interface. For example, if an update action displays a Loading Spinner on one screen, that same action shouldn't use a Progress Bar elsewhere in the product.
  • In case of displaying progress for a sequence of processes, the system should indicate overall progress rather than the progress of each contained activity.
  • Helper text should be used alongside Loaders if the process is complex or has a long waiting time. In this case, the system can show the process explanation or the list of exchanging sub-processes that are taking place.
  • Loaders are transient. They appear only while an operation is ongoing and disappear after it completes.
  • When possible, determinate Loaders, like Progress Bars, should be used to help users estimate how long a task will take.
  • If possible, the system should provide accurate progress reports for specific run times when displaying Loaders.
  • Loaders should keep moving until the task is done or the system reveals the status so people know something is continuing to happen. If a process stalls for some reason, the system should provide feedback that helps users understand the problem and the required next steps.
  • When it's feasible, the system should let users interrupt a process without causing adverse side effects by including a Cancel option. If interrupting the operation might cause negative side effects, the system may provide a Pause option in addition to a Cancel. User Interface should always communicate when halting a process has a negative consequence.
  • Content and user interface must support automatic updates. If necessary, the system can automatically update various controls and content areas. Those updates should not happen simultaneously and block the entire interface. If people expect periodic automatic refreshes, these actions should be as non-interruptive as possible.

Description

The User Interface may also explain why the user is waiting by providing an optional Description. For example:

  • Please wait while we calculate your results.
  • Please wait while we set things up for you.
  • We are gathering your data.
  • 21 out of 30 documents checked.

Accessibility

The Loader components do not have keyboard accessibility since they are intentionally not interactable or navigable. However, Development Team should consider incorporating other accessibility features to help users to go through the flow.

Loading in progress

The primary accessibility consideration for the Loader components is to convey their meaning to assistive technologies so users are aware of status changes. This can be achieved by exposing the title value “loading” of the Loader SVG image/icon to screen readers so users hear “loading” when a Loader component appears on the screen.

Loading has completed

When the Loader components disappear, the system should convey another message – for example, “loading is finished.” There are several possible ways to communicate the message:

  • If new content takes focus when the loading is completed (for instance, after a full page load), users will understand the system is now available. Annotating what component takes focus will ensure this is properly implemented.

  • Where a change of focus is not appropriate when the Loader components disappear, the information can be surfaced through a non-displayed status message that can be conveyed to users through assistive technology. Developers need to obtain information programmatically (annotate) to assistive technology.
CONTENTS
Chat Icon Close Icon