Thought I'd add some food for thought here from an old blogpost that I wrote when we were working on improving perceived performance in mobile VE.

Specifically, this paragraph may be helpful:

"We thought of a few different ways to address this, including microcopy telling users what’s happening, skeletons and loading screens. Ultimately, we decided to address this by creating a seamless animation transition. To do this we grey out the read mode and transition it to line up with the edit mode. Then when the editor is ready we seamlessly swap it in. We combined this with a user interface refresh to provide a more reassuring throbber and instructional microcopy. In addition to reassuring contributors, the loading overlay helps editors to maintain their focus on the edit that they initiated the editor with the intention of making."

A proposal from comparing the three types in production and the task description is to update “Progress indicator within views (aka three-dots)” to use Accent50 by default. With designers still being able to override with Base30 in context.

The feedback in recent Design systems meeting was positive. With @pauginer "Our Accent color’s intent was to be limited to interactions, having a loading indicator applying Accent color is somewhat contradicting, should be tried out.”
We will try in the product context.

@Pginer-WMF This would be change with Accent50 as bouncing dots.

Also amended CodePen

Hey, @Volker_E and @Pginer-WMF. In WiKit, we're about to implement the three bouncing dots loader (aka progress indicator) and use the small variant in the dropdown menu of some input types, all in order to signal to users that their input is being processed. For example, when entering dates, or while typing into the Lookup component. Reading the content of this ticket makes me think that this might be the wrong move? Would the recommendation be to use that smaller loading bar instead?

In T266028#6897450, @Sarai-WMDE wrote:

Would the recommendation be to use that smaller loading bar instead?

I'm curious about that TypeaheadSearch bar too. @Volker_E can you provide a link to a place where this can be checked live? I had some questions that are not clear from a static image:

• Is it a determinate or indeterminate progress bar?
• is the TypeaheadSearch example part of of dialogs and menus?

In the previous ticket ( T75972) it seems the intention was to come with two kind of indicators for loading: determinate and indeterminate. It may be worth clarifying why additional ones may be needed.

There's an ongoing discussion about the current TypeaheadSearch's progress indicator for fetching results. Current implementation is incomplete, but got de-prioritized as it's affecting only very slow connections. Will update here as soon as we've made progress on the task.

Change 672799 had a related patch set uploaded (by VolkerE; owner: VolkerE):
[mediawiki/core@master] [WIP] Use Accent50 for progress indicators

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

@iamjessklein brought a good point about considering the low bandwidth case where progress indicators may need to also surface activity to communicate the process is still going on.

On T278126#6941806 I shared some initial idea son how we could surface activity only when the progress is not advancing (in order to keep signals minimal, only when needed). I illustrated some possible examples of the idea:

Note how the activity indicator (color change in the 1st and a moving element on the 2nd) is only shown when the bar gets stuck in the middle of the process.

In T278126#6941488, @Esanders wrote:

The quick fix I implemented (and being used on Patch Demo) is to show the pending texture:

More commonly an animated texture would be applied to the bar itself (the blue part), such as in earlier versions of OSX:

So something like:

In T266028#6942015, @Pginer-WMF wrote:

@iamjessklein brought a good point about considering the low bandwidth case where progress indicators may need to also surface activity to communicate the process is still going on.

On T278126#6941806 I shared some initial idea son how we could surface activity only when the progress is not advancing (in order to keep signals minimal, only when needed). I illustrated some possible examples of the idea:

Note how the activity indicator (color change in the 1st and a moving element on the 2nd) is only shown when the bar gets stuck in the middle of the process.

+1 Pau. I explored some options on codepen very similar to yours, with only variations on the "shimmer" colour:
https://codepen.io/reets/pen/dyNoLmg

In T266028#6942015, @Pginer-WMF wrote:

Note how the activity indicator (color change in the 1st and a moving element on the 2nd) is only shown when the bar gets stuck in the middle of the process.

I think this has to be optional to. For my use case above, the pending element was to show work was still happening in the background, even if the bar was temporarily stuck. In the case where progress is blocked by the user (e.g. using a progress bar to show progress through a multi-step form), it might not make sense to have any pending animation.

I wonder if in updating the animation on these pending progress bars, we should be considering the use of this texture in general? Or is the pending progress bar a special case?

In T266028#6942225, @Esanders wrote:

I wonder if in updating the animation on these pending progress bars, we should be considering the use of this texture in general? Or is the pending progress bar a special case?

Yes,I would be in favour of removing the texture element and replacing it with this gradient/shimmer. It would help simplify the progress bar variations to not have this separate element at all which imo introduces other concerns - like in the example pasted where it is obscuring the text in the input field.

In T266028#6942215, @Esanders wrote:

In T266028#6942015, @Pginer-WMF wrote:

Note how the activity indicator (color change in the 1st and a moving element on the 2nd) is only shown when the bar gets stuck in the middle of the process.

I think this has to be optional to. For my use case above, the pending element was to show work was still happening in the background, even if the bar was temporarily stuck.

The idea is the same, what I tried to convey is that in order to communicate that we don't need the signal all the time. So it may be possible to show it only when the bar is stuck. In this way, users on a fast connection get a simple bar, and those on a slower connection get the additional signal.

This can be an optional property of a single progress bar component, but I think it makes sense to keep it enabled by default.
In this way, progress bars would be supporting slow connections by default, without designers/developers having to think about it.

In the case where progress is blocked by the user (e.g. using a progress bar to show progress through a multi-step form), it might not make sense to have any pending animation.

I think there may be a conceptual mismatch in this case. If the process is blocked by the user, work is not happening (from the system side). So communicating activity in such case does not seem necessary.

+1 to @Pginer-WMF 's solution.

I wonder if in updating the animation on these pending progress bars, we should be considering the use of this texture in general? Or is the pending progress bar a special case?

+1 to @RHo 's thought here - let's use this sparkling bar instead.

@Esanders in general we should be working towards removing all instances of the patterned texture.

@iamjessklein I wasn't fully sure what you referred to with “toolbar” in T278126#6941902. Is everything covered in the task description now from your POV?
The pending issue has been originally captured in T168760.

Change 672799 merged by jenkins-bot:

[mediawiki/core@master] Use Accent50 for progress indicators

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

Note that there is a separate task for 3-dots progress indicator here: T309247: Add BouncingDots component to Codex