Page MenuHomePhabricator

[Indeterminate InlineProgressBar] Adjust behavior of indeterminate ProgressBar to improve inline indicator
Closed, ResolvedPublic

Description

The indeterminate InlineProgressBar component was recently added to Codex. While the visual properties of this variant are based on those of its parent (the indeterminate ProgressBar), the inline element is meant to be used in different context: in small spaces where the bar is the only indicator that loading is underway, and thus should remain visible to remove any potential confusion.

There are a couple of adjustments that we could apply to the indeterminate ProgressBar to make its variant satisfy the inline use case a bit better without creating a big departure from the parent component:

  1. Make clear that loading is still going on by reducing the waiting time between bar iterations (keeping the loading indicator visible for as long as loading lasts). This would basically involve:

    1.1. Adjusting the value of the translate() in the 100% keyframe of the cdx-progress-bar_bar... animation to 300% in the LTR animation, and -300% in the RTL animation.

    1.2. Adjusting the speed of the indeterminate progress bar animation from 2s to 1.6s. (This also prevents the bar from slowing down when wrapped in small containers).
  1. Width: right now, we're applying a 40% width to the bars, which is not part of the spacing scale/tokens. We should apply a width of 33% instead, which we'll be able to replace by a token soon.

Note:

The listed changes will also need to be applied to the indeterminate ProgressBar in OOUI, in order to keep both libraries visually and interactively consistent.

Acceptance criteria
  • Make the change in Codex
  • Make the change in OOUI

Event Timeline

Sarai-WMDE renamed this task from [Indeterminate InlineProgressBar] Adjust behavior of indeterminate ProgressBar to [Indeterminate InlineProgressBar] Adjust behavior of indeterminate ProgressBar to improve inline indicator.May 3 2022, 1:05 PM
Sarai-WMDE created this task.

Change 788788 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] ProgressBar: Update indeterminate animation

https://gerrit.wikimedia.org/r/788788

Change 788788 merged by jenkins-bot:

[design/codex@main] ProgressBar: Update indeterminate animation

https://gerrit.wikimedia.org/r/788788

@Sarai-WMDE this has been merged, so you can review the changes on the live site. Let me know if you want any adjustments! Once we have this finalized in Codex, I'll move on to trying to update this in OOUI.

Thanks for applying the changes, @AnneT! There's definitely room for fancy improvement when it comes to this loading animation pattern, but I think that these changes helped alleviate the main issue we were trying to solve: the waiting time between bar iterations has been reduced to the minimum, so the loading state is communicated in a persistent way by the inline progress bar 👍🏻

STH triaged this task as Medium priority.May 17 2022, 5:42 PM

Hey @AnneT 👋🏻 wondering if I should have moved this task back to Ready for development, or if it would be better to create a separate task to apply the changes in OOUI?

AnneT removed AnneT as the assignee of this task.May 18 2022, 2:53 PM
AnneT updated the task description. (Show Details)

@Sarai-WMDE thanks for the reminder, I've added acceptance criteria to the task so we can just reuse this one!

Change 799302 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):

[oojs/ui@master] Style: Adjust behaviour of indeterminate ProgressBar

https://gerrit.wikimedia.org/r/799302

STH changed the task status from Open to In Progress.May 26 2022, 12:22 AM

Change 799302 merged by jenkins-bot:

[oojs/ui@master] Style: Adjust behaviour of indeterminate ProgressBar

https://gerrit.wikimedia.org/r/799302

Changes are being correctly displayed by the indeterminate progress bar in OOUI, which is now aligned with its corresponding Codex component. Thanks, @SimoneThisDot!

Unfortunately, both default progress bars (Codex and OOUI) are displaying an issue in Safari (v15.5 on MacOS Monterey). I'm not sure of the cause, so I can't be certain of whether the bug was caused by the recent changes. As you can see in the gif included below, the bar doesn't respect the border radius of its wrapper. I guess this might be an issue related to position or border-radius, but couldn't figure it out:

bar.gif (142×638 px, 37 KB)

In case the problem is not related to this ticket, I'll open a separate bug report and move this task to Functional testing.

Good find, @Sarai-WMDE!

I think it's very unlikely that this change introduced the bug: the code changes related to the width of the bar, the timing, and the animation distance, not the border radius or overflow behavior. That said, we should definitely fix this bug, no matter when it originated! I think opening a new ticket for it sounds like a good plan.

Thanks for checking, @AnneT! This ticket can then be signed-off. I'll open a separate bug report 👍🏻

AnneT added a subscriber: SimoneThisDot.
DAbad claimed this task.
DAbad subscribed.

closed

Change 811300 had a related patch set uploaded (by Simone Cuomo; author: Simone Cuomo):

[oojs/ui@master] themes, ProgressBar: Display incorrect overflow behavior in safari

https://gerrit.wikimedia.org/r/811300

Change 811300 merged by jenkins-bot:

[oojs/ui@master] themes, ProgressBar: Display incorrect overflow behavior in Safari

https://gerrit.wikimedia.org/r/811300

Change 813630 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] Update OOUI to v0.44.1

https://gerrit.wikimedia.org/r/813630

Change 813630 merged by jenkins-bot:

[mediawiki/core@master] Update OOUI to v0.44.1

https://gerrit.wikimedia.org/r/813630