Exploring opportunities for unification makes perfect sense, and both of the current patterns used for indeterminate progress (bouncing dots and spinner) have an overlap in function. However, there is an aspect of the bouncing dots that we may lose if the unification goes in the direction of the spinner.

The bouncing dots seem to be more connected with content ("content is coming"), while the spinner seems more about the system ("you have to wait while the system is thinking"). I think the former conveys a more positive message, and a more seamless integration in different contexts.

Below I'm sharing some examples where I think the three dots seem to work better than the spinner. This is not intended to surface cases that we need to support but as a way to help us think what is actually different form two patterns that on the surface may look as interchangeable:

Use as a placeholder for content (similar to a skeleton). Let's imagine a list of articles with piece of information that that does not load immediately, and a loading indicator is shown meanwhile. This would result in multiple loading indicators, one per row. Multiple bouncing dots, while not ideal, seem less surprising than multiple spinners since they are more easily associated with the multiple pieces of content.

Use in place of text. For example, a button could replace their label with the three dots bouncing in cases where some checks are done. This is based on an experiment from T75972#1443108. I imagine the spinner being less flexible in this context.

Chat apps using ellipsis to signal that content is coming, A spinner does not seem effective communicating the same (waiting vs. content is coming).

Some relevant references:

• T75972 includes a previous inventory of loading indicators and some discussion around them.
• In T165286 a community request was made to replace the then default loading bars (an image below from a different UI) with a more subtle loading incdicator where the bouncing dots were finally applied

Apologies for the long comment, this is part of my own exploration trying to find why both approaches felt different. Maybe exposure and usage of one versus another is having an influence too. So feel free to take with a grain of salt.

Thanks for your thoughts @Pginer-WMF. I definitely agree with the idea that bouncing dots might feel better suited for tasks where the user can anticipate an end result, especially in regards to messaging contexts. Guessing our constant exposure to the dots in text messaging has created this feeling that something is coming imminently.

It's also interesting that we used some similar examples but came to opposite conclusions, for example I preferred the spinner in the button loading use case because you could keep the text of the button.
We could also repurpose the spinner to not only be indeterminate but determinate which could make it more versatile.

I would propose a flexible approach to our next steps to keep this moving:

1. Continue with the creation of a progress indicator that is a Spinner. With that and the progress bar in Codex, we cover most use-cases. Since bouncing dots aren't currently a Codex component we aren't removing any functionality, it won't impact any past work that is using the bouncing dots.
2. Next up we work on implementing a skeleton / placeholder loading UI that will cover even more use cases.
3. With most use cases covered and generally more feedback and context, we consider whether we should add the bouncing dots as an additional option.

@mwilliams This sounds like reasonable next steps to me. 👍🏼
All of your arguments together with the better scalability of a spinner and clearer universality (inspirational … is still a Latin character (combination) after all. Compare https://hyw.wikipedia.org/wiki/%D5%8E%D5%A5%D6%80%D5%BB%D5%A1%D5%AF%D5%A7%D5%BF or https://zh.wikipedia.org/wiki/%E5%8F%A5%E5%8F%B7 or https://or.wikipedia.org/wiki/%E0%AC%AA%E0%AD%82%E0%AC%B0%E0%AD%8D%E0%AC%A3%E0%AD%8D%E0%AC%A3%E0%AC%9A%E0%AD%8D%E0%AC%9B%E0%AD%87%E0%AC%A6} makes spinner an advantageous choice.

El T377493#10381733, @mwilliams escribió:

Thanks for your thoughts @Pginer-WMF. I definitely agree with the idea that bouncing dots might feel better suited for tasks where the user can anticipate an end result, especially in regards to messaging contexts. Guessing our constant exposure to the dots in text messaging has created this feeling that something is coming imminently.

It's also interesting that we used some similar examples but came to opposite conclusions, for example I preferred the spinner in the button loading use case because you could keep the text of the button.
We could also repurpose the spinner to not only be indeterminate but determinate which could make it more versatile.

I would propose a flexible approach to our next steps to keep this moving:

1. Continue with the creation of a progress indicator that is a Spinner. With that and the progress bar in Codex, we cover most use-cases. Since bouncing dots aren't currently a Codex component we aren't removing any functionality, it won't impact any past work that is using the bouncing dots.
2. Next up we work on implementing a skeleton / placeholder loading UI that will cover even more use cases.
3. With most use cases covered and generally more feedback and context, we consider whether we should add the bouncing dots as an additional option.

I agree with these next steps. The current use cases using bouncing dots can be easily replaced with a spinner (system loading) since we don't have for now any messaging use case to cover.

Our first approach focuses on consolidating the different progress elements into a more streamlined version with fewer elements (T377430). This simplification will make it easier for users to select the appropriate progress element and will also reduce the number of progress components that need to be maintained in the future.

Once we consolidate all progress elements and we include the missing ones (like skeleton) we can always include these bouncing dots if needed later.

I would also add that the three dots are often used now by bot chat interfaces (in addition to messaging with humans), and feels like it more commonly denotes 'thinking' vs. 'loading' for both human and bot input.

Re-designed bouncing dots to spinner and documented them in figma and google doc hence closing this task.

Need to use this task once more for the RTL behaviour cc: @Aaharoni-WMF :
Hebrew with spinner turning clockwise (that would be in alignment with a specific guideline of our bidi guidance):

Hebrew with spinner turning counter-clockwise

Also please note that the captures aren't perfect, I thought I could trim them to the right starting point with my tool, but it's not possible.
This is the starting point of the animation for both cases: