I have a patch to demonstrate this, but it sort of depends on T319295 being resolved first.

There is also T317385: Improve loading state animation which I think would address some of these concerns. I was advocating it as low-priority; after all, most of the usage of Phonos (we assume) will be very brief audio.

@NRodriguez We are just triaging this, what do you think about this from the product perspective?

Change 880558 had a related patch set uploaded (by Nardog; author: Nardog):

[mediawiki/extensions/Phonos@master] Animate button background to indicate playback progress

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

Test wiki created on Patch demo by Nardog using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/09d6a3aea2/w

Test wiki on Patch demo by Nardog using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/09d6a3aea2/w/

Test wiki created on Patch demo by Nardog using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/39b81459b9/w

Test wiki on Patch demo by Nardog using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/39b81459b9/w/

Test wiki created on Patch demo by Nardog using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/2c3596da0f/w

Sorry for the spam. Obviously I don't expect my patch to be outright merged, but I hope the demo shows how the UX can be significantly improved.

(I think part of the problem is that hover and progressive share the same background. Only the text and icon color changes when the playback starts or stops unless you move the cursor away, so it's difficult to see what's happening.)

@JSengupta-WMF Can you comment on this? Even if you didn't think the feature as requested was a good idea, I think you'll agree that the UX leaves something to be desired, as the button barely changes when you click it unless you move the cursor away.

Hey there, we talked about this internally and we thought it looked great! cc @nayoub we are working on figuring out how to merge it in and incorporate, thanks for the ping and for the patch! Will move this to the In Review column for Sprint 41 so it can get reviewed over the next two weeks. Thanks Nardog!

I think it's a pretty good solution to show the progress of playback. The demo looks great! I would use a little darker progress bar color (e.g. #A3D3FF) so it's a bit more visible.

Agreed, the demo looks really nice! Regarding the background color, I believe we should be using #eaf3ff to comply with the design system color tokens – which might already be the case in the patch, the blue looks very similar.
More information can be found in the design system documentation here or below :)

Thanks for the feedback! Yes I used @wmui-color-accent90, the same as :hover.

Some things you might want to determine:

• As noted in T320415#8533524, the direction should follow the content language, not the interface language. Not sure how best to achieve this (@noflip and .mw-content-rtl?).
• When/how often should we get the media query? Is matchMedia(...).matches cheap enough that we could do it before every playback, just to make the behavior always follow the device preference even if it was changed after the tab was opened? If not, where should we store the result: mw.Phonos, PhonosButton, PhonosButton.prototype, or a private variable?
• Would it be expensive to fetch the duration server-side? If the server already receives such metadata before rendering the button, it might be a good idea to preemptively put it in the infusion data. On the other hand, if the client-side API (HTMLMediaElement.duration) is cheap and fast enough, it's probably not worth the effort.

Ok makes sense. We are in a discussion whether to add #A3D3FF in the codex but it's not confirmed yet so let's go with the one that's already present. Thanks!

Change 880558 merged by jenkins-bot:

[mediawiki/extensions/Phonos@master] Animate button background to indicate playback progress

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

Depending on the length of the audio and the width of the Phonos label, the way the animation looks with and without the prefers reduced motion option can look quite similar.

I don't know if we will just have to remove the progress bar animation completely in the case of prefers reduced motion.

Without prefers reduced motion:

With prefers reduced motion:

Example is from https://en.wikipedia.beta.wmflabs.org/wiki/Phonos_Loading.

That's more or less intentional (the former video looks too similar to the latter but I assume that's due to the framerate). "Reduced motion" doesn't mean no motion. Just because the user has asked reduced motion doesn't mean they don't want the benefit of being able to see the progress (at least I certainly do, and I have prefers-reduced-motion on my phone), and the benefit is precisely greater for longer files. Of course the regular looks similar to the reduced when the file is long or the button is short, because there's not enough room for the animation to be smooth in the first place. It's the regular motion that's become similar to the reduced motion, not the other way around.

Also, the timeupdate event is debounced by the browser so it's a perfect solution for those who have prefers-reduced-motion for performance reasons. If it's still too fast for others, we could increase the interval by e.g. wrapping the event handler in OO.ui.debounce(). But I'd like to see evidence that any progress indication at all is undesirable before removing it altogether. The progress bar in VideoJS moves even with prefers-reduced-motion after all.

In T326828#8653007, @Nardog wrote:

That's more or less intentional (the former video looks too similar to the latter but I assume that's due to the framerate). "Reduced motion" doesn't mean no motion...

But that blog post says to replace moving animations with other types of animation, like fade. It does not say to replace moving animations with virtually identical moving animations.

Nevertheless, getting advice internally suggests the progress indicator is a low risk for motion sensitive users. This is because the animation is small (although a user could make the Phonos button as long as they want by entering a long IPA string or label) and triggered by user input.

Arguably, the animation can be considered "essential" by W3C's standards in that, if the progress indicator were removed, it[1]

...would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform.

(my emphasis)

...and I cannot think of another way of implementing a progress bar.

On the other hand, I like the idea of allowing users the option to turn off all animations by setting prefers-reduced-motion. With the above solution, we do not give users this option.

@NRodriguez I will move this along, but we could consider getting feedback from motion sensitive users when we roll this out.

References

1. https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html#dfn-essential

Test wiki on Patch demo by Nardog using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/2c3596da0f/w/