Page MenuHomePhabricator

[EPIC] ProgressIndicator: Add ProgressIndicator component to Codex
Open, Stalled, LowPublic

Assigned To
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 ProgressIndicator (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. As documented in this component's Guidelines, we will not use a ProgressIndicator for Menu loads; instead, we will use an Inline ProgressBar.

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

Open questions

Design spec

A three-dot progress indicator that animates to show loading status. This component maintains consistency across desktop (Vector 22) and mobile (Minerva) layouts.

Core Properties
  • Initial size: @size-75 (12x12 pixels at 100% scale)
  • Maximum size during animation: @size-100 (16x16 pixels at 133.33% scale)
  • Spacing: @spacing-35 (6 pixels between dots)
Animation Specifications
  • Type: Bouncing effect with scaling
  • Duration per cycle: @animation-duration-medium
  • Animation timing function: @animation-timing-function-bouncing
  • Animation delay: @animation-delay-medium
  • Iteration: @animation-iteration-count-base
Animation Keyframes
  • 100% of initial size (12x12 pixels) at 0%, 50%, and 100% of the animation cycle
  • 133.33% of initial size (16x16 pixels) at 20% of the animation cycle

Guidelines


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.
  • Include the component's Guidelines in Codex

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.

Details

Other Assignee
bmartinezcalvo

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

CCiufo-WMF moved this task from Later to Supporting on the Design-System-Team (Roadmap) board.
CCiufo-WMF changed the task status from Open to In Progress.Jul 4 2024, 5:27 PM

Hello team, after exploring both spinner and bouncing dots options, we're thinking of proceeding with bouncing dots to maintain consistency with our current product usage.
I've started initial designs in Figma file. Some of the open questions I am thinking

  • I'm thinking of proceeding with two versions: 12x12 for larger screens and 8x8 for smaller screens. Do we think one size could suffice for all use cases?
  • We're planning to use progressing color (#3366cc). This can work for both light and dark modes.
  • In its existing usage in different places (recent changes, CX, etc.), do we define a maximum display time for bouncing dots before showing any other message?
  • For naming purpose, do we have a preference that describe its function? some examples are - Bouncing dots, Progress dots, Activity indicator, Status indicator.

Let me know if we have any other questions or suggestions for the loading indicator design.

Hello team, after exploring both spinner and bouncing dots options, we're thinking of proceeding with bouncing dots to maintain consistency with our current product usage.
I've started initial designs in Figma file. Some of the open questions I am thinking

  • I'm thinking of proceeding with two versions: 12x12 for larger screens and 8x8 for smaller screens. Do we think one size could suffice for all use cases?

Since we are planning to introduce the different size modes, it makes sense to me to define 2 different sizes and use it according to each mode/screen size. @DTorsani-WMF wdyt?

  • We're planning to use progressing color (#3366cc). This can work for both light and dark modes.

I agree. As we discussed during our last catch up, it makes sense to use this @background-color-progressive Since it's the color we use to indicate progress in other indicators, such as the ProgressBar.

  • In its existing usage in different places (recent changes, CX, etc.), do we define a maximum display time for bouncing dots before showing any other message?

I'm not sure if a message is combined with these bouncing dots. Maybe the engineers can give you more context on this @Catrope @egardner @AnneT @lwatson @Volker_E

  • For naming purpose, do we have a preference that describe its function? some examples are - Bouncing dots, Progress dots, Activity indicator, Status indicator.

I would avoid using so generic names such as "LoadingIndicator" since this could apply to any other loading indicators such as spinners, and I would also avoid using concrete names like "Dots" that can affect future iterations. So, what about "BouncingLoader"?

At the moment, we aren't implementing the different font modes for components, and we also don't respond component sizing for different screen sizes, even though in Figma some components are designed this way. My suggestion for now, for the sake of consistency would be to design the version that feels best for all screen sizes until we can spend time on considering responsiveness and font modes more.

As discussed internally, we plan to rename this component to "ProgressIndicator" to align it with the ProgressBar component. I'm updating the title in the various tasks.

bmartinezcalvo renamed this task from LoadingIndicator: Add LoadingIndicator component to Codex to ProgressIndicator: Add ProgressIndicator component to Codex.Jul 30 2024, 8:49 AM
bmartinezcalvo updated the task description. (Show Details)
bmartinezcalvo updated the task description. (Show Details)

@CCiufo-WMF this component is ready for implementation.

CCiufo-WMF renamed this task from ProgressIndicator: Add ProgressIndicator component to Codex to [EPIC] ProgressIndicator: Add ProgressIndicator component to Codex.Aug 23 2024, 7:04 PM
CCiufo-WMF updated the task description. (Show Details)
CCiufo-WMF removed a subscriber: Sarai-WMDE.

We've built a version of this in Vue previously: see the Vue component and separate Less file. The Less probably needs to be updated to match the spec exactly, but hopefully this can be used as a starting point.

CCiufo-WMF changed the task status from In Progress to Stalled.Oct 21 2024, 2:42 PM