Page MenuHomePhabricator

LoadingIndicator: Add LoadingIndicator component to Codex
Open, Needs TriagePublic

Assigned To
None
Authored By
Sarai-WMDE
Sep 8 2023, 2:30 PM
Referenced Files
F42210237: image.png
Feb 28 2024, 12:18 PM
F42209927: image.png
Feb 28 2024, 12:03 PM
F42209916: image.png
Feb 28 2024, 12:03 PM
F42209967: image.png
Feb 28 2024, 12:03 PM
F42209959: image.png
Feb 28 2024, 12:03 PM
F42209896: image.png
Feb 28 2024, 12:03 PM
F42209886: image.png
Feb 28 2024, 12:03 PM
F42208491: Captura de pantalla 2024-02-28 a las 11.41.42.png
Feb 28 2024, 10:55 AM

Description

Background

A loader-type animation displaying three dots that progressively change in size is currently used within some components and areas in Wikimedia products to indicate that something is loading or a process is in progress.

We should collect and analyze existing use cases in order to define the recommendations and styles (sizes, colors, animation) of this potential Codex component.

Description

The LoadingIndicator (name TBC) is aimed at communicating to users that the system is actively working to retrieve information or complete a task, thus managing their expectations by indicating that waiting is required.

This loading element is usually displayed in page areas of different sizes, as well as within components.

Find a code prototype of the element in this Codepen.

User stories

  • As a designer and developer, I want to be able to reuse a loading animation component to indicate that the system is actively working on a task requested by a user

History

  • This component has been identified/documented in different tasks:

T266028: Add “Progress indicators” to DSG
T289989: Add loading spinner component.

Known use cases

image.png (622×1 px, 38 KB)
Special:RecentChanges/RCFilters
Watchlist/RC filter loading panel
Screenshot 2023-09-08 at 16.22.57.png (230×456 px, 23 KB)
Wikibase Date input component: the loader indicates that the input is being processed

Existing implementations

These artifacts are listed for historical context. The Figma spec, linked below, is the source of truth for the new component.

Wikimedia community:

External libraries:

  • Add links to any examples from external libraries

Codex implementation

Component task owners

  • Designer: add the main designer's name
  • Developer: add the main developer's name

Open questions

Design spec

Once a component spec sheet has been created in Figma, remove the note stating that the spec is missing and link to the spec below.

A component spec sheet has not been created yet.

Component spec sheet
Anatomy

Designer should list the structure and properties of the component.

Style

Designer should list the visual features of the component.

Interaction

Designer should list interaction specifications.

Documentation

Designer should describe how the component should be documented, including configurable and standalone demos.


Acceptance criteria

Minimum viable product

This task covers the minimum viable product (MVP) version of this component. MVP includes basic layout, default states, and most important functionality.

MVP scope

  • List all parts of the MVP scope for this component

Design

  • Design the Figma spec sheet and add a link to it in this task
  • Update the component in the Figma library. This step will be done by a DST member.

Code

  • Implement the component in Codex

Future work

  • If applicable, list future work that should be done for this component after the MVP is implemented as part of this task. You should open new, standalone tasks for all future work.

Event Timeline

I wonder if the use case described here would eventually be covered in the Skeleton Loader (T311874). I feel like a comprehensive audit + exploration of "content loading states" is needed, if it hasn't been done already.

Hey, @CCiufo-WMF. We do need that general exploration, indeed. We could repurpose this old ticket: T266028
I do agree that some of the use cases documented here could be covered by the skeleton (loading of static page areas after navigation, like in Special:RecentChanges), while others (showing that the user's input is being processed and will be displayed in place) seem to require other sorts of indicators (spinner, dots, inline progress bar).

Hey, @CCiufo-WMF. We do need that general exploration, indeed. We could repurpose this old ticket: T266028
I do agree that some of the use cases documented here could be covered by the skeleton (loading of static page areas after navigation, like in Special:RecentChanges), while others (showing that the user's input is being processed and will be displayed in place) seem to require other sorts of indicators (spinner, dots, inline progress bar).

That makes sense to me. I'm going to backlog this for now, but we can discuss how the exploration should be prioritized relative to other components + responsiveness as it relates to the Wikit migration.

CCiufo-WMF renamed this task from BouncingDots Loader: Add BouncingDotsLoader component to Codex to LoadingIndicator: Add LoadingIndicator component to Codex.Feb 27 2024, 10:02 PM
CCiufo-WMF updated the task description. (Show Details)

Known use cases

image.png (622×1 px, 38 KB)
Special:RecentChanges/RCFilters
Watchlist/RC filter loading panel
Screenshot 2023-09-08 at 16.22.57.png (230×456 px, 23 KB)
Wikibase Date input component: the loader indicates that the input is being processed

The Indeterminate Progress Bar implemented in Codex communicates that a process is happening. The elevated bar communicates an ongoing process on a page, while the inline bar communicates it within other components.

Captura de pantalla 2024-02-28 a las 11.41.42.png (1×1 px, 106 KB)

The use cases described in this task for BouncingDots could potentially be addressed using elevated and inline progress bars. Unless there are additional use cases that necessitate BouncingDots, we may consider not implementing this component.

Known use cases

image.png (622×1 px, 38 KB)
Special:RecentChanges/RCFilters
Watchlist/RC filter loading panel
Screenshot 2023-09-08 at 16.22.57.png (230×456 px, 23 KB)
Wikibase Date input component: the loader indicates that the input is being processed

The Indeterminate Progress Bar implemented in Codex communicates that a process is happening. The elevated bar communicates an ongoing process on a page, while the inline bar communicates it within other components.

Captura de pantalla 2024-02-28 a las 11.41.42.png (1×1 px, 106 KB)

The use cases described in this task for BouncingDots could potentially be addressed using elevated and inline progress bars. Unless there are additional use cases that necessitate BouncingDots, we may consider not implementing this component.

cc @Pginer-WMF and @JFernandez-WMF if they have additional use cases where bouncing dots are located in the centre of a block of loading content - Content Translation and Welcome survey > Language selector respectively, where the progress bars are likely not fit for purpose in their current state. The places from above:

"cxspinner" on CX dashboard
image.png (682×1 px, 64 KB)
loading
loaded
image.png (1×2 px, 306 KB)
Translating an article loading
image.png (1×1 px, 118 KB)
loaded
image.png (1×1 px, 820 KB)
Welcome survey languages question loading
image.png (352×1 px, 50 KB)
loaded
image.png (244×1 px, 36 KB)
RHo attached a referenced file: F42209916: image.png. (Show Details)
RHo attached a referenced file: F42209967: image.png. (Show Details)
RHo attached a referenced file: F42209959: image.png. (Show Details)
RHo attached a referenced file: F42209896: image.png. (Show Details)
RHo attached a referenced file: F42209886: image.png. (Show Details)

Additional usage on Commons MediaSearch:

image.png (1×2 px, 306 KB)

I would in general advise to check on https://codesearch.wmcloud.org/search/ and with design teams for additional use-case collection