Loading

Reduces load time frustration and makes the page feel more responsive.

Overview

Our products handle tons of data for our services to run smoothly. Thus, some pages may be technically heavy to load when needing a few API or database calls. To improve the user experience while data is loading, we've defined a loading pattern. It's a temporary animation placeholder representing the page content before it's ready to display.

This animation's main objective is to enhance perceived performance by reducing load time frustration and making the page feel more responsive.

Loading patterns are meant to be used only when pages have to call different technical services to load content. It has been designed for those key moments when users must wait a few seconds before accessing their data.

Do not overuse those patterns for easily accessible content, as it might overload the global user experience.

Skeleton loading

When to use it

Loading State is triggered by the user's navigation or action. It appears when users open a new page or click on an action that reloads content.

In most cases, we already know what the page will look like when fully loaded; we miss the real data for a few seconds. In those cases, we favor the use of the Skeleton Loading Pattern. It provides a low-fidelity representation of the interface. The real content will take the place of the grey skeleton.

How to use it

We use Dark Skeleton on a light background (Greyscale colors) and Light Skeleton on a dark background (for the menu, for example).

This behavior is created by the Skeleton props of the following components:

• Page Title

• Page navigation

• Cards

• Panels

• Modal (only for Modal displaying heavy content, not simple confirmation modal)

Props Loading: True/False are already technically integrated into those components. But each element needs to be set up into its loading state.

As a page will mostly always have a Page Title there are great chances you can start with this component when setting up the Loading Pattern.

Regarding the actual page content, we aim to provide a close preview of the upcoming content, but it doesn't have to be 100% accurate. Be as precise as possible but don't lose yourself in too much detail when creating your prototype.

It's okay to show only two loading panels when the page will provide three panels.

Also, some panels may not call the same API or Database. We authorize asynchronous loading between the different panels, meaning some content elements may load faster than others on the same page. However, inside a single panel, we cannot support asynchronous loading. This means that for panels with tabs (inside navigation), all tabs' content will be loaded at once.

Note that Skeleton Loading Pattern is fully automated for the following components:

• Datatable

• Datalist

How to not use it

• Do not use this pattern if you cannot predict the loading of page content

• If loading data is too unpredictable.

• If you call an external service.

In those cases, use Spinner Loading Pattern.

Spinner loading

When to use it

In rare cases, we cannot predict what the page will look like when fully loaded. It may happen when calling external services (Third-party microservices...). Thus, we cannot provide a low-fidelity representation of the interface loading.

In those cases, we privilege the use of Spinner Loading Pattern. It shows a basic animated spinner in the center of the page content. The actual content will load when all of it is available.

How to use it

There is only one greyed spinner for this animation. It has to be placed in the center of the page.

How to not use it

This pattern must be an exception when we cannot predict a low-fidelity representation of the page content. It must not be used as an easy-lazy loading pattern.

Activity loader

For more information on this component, check the activity loader page.

Loading error

Errors happen. The loading time may be too long, or we cannot retrieve the data needed to complete page content.

Users should not wait more than 10 seconds for something to happen on the page, whether it's a success or a failed loading. If any failed loading happens, we must force the end to Loading State, notify users something went wrong, and provide a solution.

Automatically handled by ROMA.

Learn more about Error messages