Page MenuHomePhabricator

Videojs player for audio opens a dialog, which is unexpected
Open, Needs TriagePublic

Assigned To
None
Authored By
Krinkle
Feb 24 2020, 8:14 PM
Tokens
"Burninate" token, awarded by czar."Like" token, awarded by Ciencia_Al_Poder."Like" token, awarded by Artushak."Like" token, awarded by Nardog.

Description

This might be a regression, I feel I've seen this work inline at some point in the past.

  1. With the beta enabled.
  2. On articles like https://en.wikipedia.org/wiki/Pagliacci, play an audio clip (I tried "No! Pagliaccio non son!" in Act 2)

a.png (466×696 px, 45 KB)

b.png (798×1 px, 130 KB)

Event Timeline

The alternative would be to replace the player 'inline', but then we'd have to jump through hoops to get subtitles for audio again.

Jdforrester-WMF renamed this task from Videojs beta player for audio sometimes opens unexpected dialog to Videojs player for audio opens a dialog, which is unexpected.Mar 18 2020, 9:34 PM

Would it be significantly more difficult to replicate the functionality of the old player? I would consider this a regression, since it would no longer be possible to read and listen at the same time in the same window. (Even if it has to be in a pop-up overlay, it doesn't mean that the overlay has to cover 100% of the screen.)

This is not a regression. Intentional changes that people don't like don't count.

As a direct UI comparison, SoundCloud and Spotify's websites display a horizontal bar along the bottom of the screen for audio player controls. Usability-wise, I think something like that (if possible with CSS) would be an improvement over the full screen overlay, which seems unnecessary.

This sort of change could be accomplished crudely with minimal CSS changes, at least on the desktop site, although it could take more work to allow the user to interact with the very bottom of the page while the audio player is active, and different CSS would probably be required for the mobile site and mobile apps. For example, removing the rules for .oo-ui-windowManager-modal-active and changing top: 0 to top: 80% for .oo-ui-windowManager-modal > .oo-ui-dialog.oo-ui-window-active were enough for me to make it possible to scroll through the page with the audio player open, although this would probably have to be done through different CSS rules.

As a direct UI comparison, SoundCloud and Spotify's websites display a horizontal bar along the bottom of the screen for audio player controls. Usability-wise, I think something like that (if possible with CSS) would be an improvement over the full screen overlay, which seems unnecessary.

Both of those sites are principally engineered around listening to sound. Consequently it's not a massive burden on users to ship all the related code for listening to sound. Wikimedia pages do not in general have videos or sounds on them (approximately 0.5% of page views do, IIRC). Thus our prioritisation is going to be different.

The alternative would be to replace the player 'inline', but then we'd have to jump through hoops to get subtitles for audio again.

Hm.. in the past I saw a demo of THM/videojs show the subtitles of audioplayers in page-wide overlay toward the bottom of the screen. This was a compromise compared to the old player where it was contextually placed, but I personally quite liked it, and it seems quite reasoable overall. – Better imho than the current state in prod.

As I understand it, you and James seem to agree on the previous state being better for UX, but I gather it had to change as part of T228339. I looked through there again briefly, but couldn't figure out why it affects the display of subtitles. What is the link between lazy-loading the code on-click and the code that is loaded using a video modal vs the subtitle footer?

@Krinkle when we lazy load, we have a dialog and we thus have 'reserved screen real estate' and we can use the that space and offload the task of render the subtitles to native browser functionality. Inline audio players don't have reserved screen real estate and as such you need to handle all subtitle rendering yourself.

We could make the player lazy load inline AND use the subtitle footer, but then we need a 3rd entrypoint into the loading routines, which adds further complexity that needs to be maintained. We are a bit wary of added complexity at this stage I think.

I am now doing QA testing of the player, and I was very surprised when my audio opened in popap. Of course, less than when I found out that these are not control buttons, but an ordinary picture...

Don't just call the OOUI window, maybe just replace the area of the audio placeholder?

Don't just call the OOUI window, maybe just replace the area of the audio placeholder?

That would defeat the purpose:

  • no place for subtitles
  • no place for additional controls which will be added later for control of embedding and subtitles
  • no garbage collection of player instance when it's closed

Don't just call the OOUI window, maybe just replace the area of the audio placeholder?

That would defeat the purpose:

  • no place for subtitles
  • no place for additional controls which will be added later for control of embedding and subtitles
  • no garbage collection of player instance when it's closed
  • Create display:none block, and change it to display:block when subtitres choosen
  • I think there is enough space, but for especially small sizes, remove all settings to the additional menu.
  • I don't quite understand why this is needed :)

no place for subtitles

But there was with Kaltura player, see https://commons.wikimedia.org/wiki/File:%22Zuid-Afrika%22_pronounced_in_Dutch.wav

image.png (111×342 px, 6 KB)

no place for additional controls which will be added later for control of embedding and subtitles

But there was place for additional controls in Kaltura player. And now it looks like a bad joke:

image.png (183×335 px, 5 KB)

no garbage collection of player instance when it's closed

But additional garbage collection was not needed 12 years ago. Why do we need it now?

Wikimedia pages do not in general have videos or sounds on them (approximately 0.5% of page views do, IIRC). Thus our prioritisation is going to be different.

And according to https://stats.wikimedia.org/, Wiktionary is only 0.25% of page views. I understand that WMF has limited capabilities, but given that T248418 has for whatever reason "High" priority, UX regressions such as this should be treated not lower then High too.

I generally don't understand overprotective comments from WMF staff defending modal windows. Current implementation is completely out of possible use cases, initial design mistakes happen to the best of us.

  • no place for subtitles
  • no place for additional controls which will be added later for control of embedding and subtitles

Wouldn't it have been possible to just make the box larger on page load, so that subtitles and controls could expand into the empty space?

I still don't understand why this is being treated as unnecessary to fix. While it might not affect the majority of visitors, it's not too difficult to see how it might affect other readers in a substantial way.

I don't know if this is a regression or not, but it seems the new player, despite having the model etc, does not actually display audio captions:

E.g. at https://en.wikipedia.org/wiki/Bangladesh:

Screenshot 2021-09-25 at 02.43.08.png (344×530 px, 31 KB)
Screenshot 2021-09-25 at 02.42.55.png (750×1 px, 51 KB)

Hmm, the CC state is off by default; maybe we should switch this on for audio files (or just always)?

Oh, so that's what that button does. Yes, maybe we should.

If the main argument for the audio modal is subtitles, wouldn't it make sense to have the mini-player only pop out when the audio file has subtitles? Or give the option of popping out to a modal so the reader can choose? Otherwise readers lose access to the article while the audio is playing.

Having everything have like 8 variants of every single mediawiki UI element is not efficient though, and more importantly a maintenance nightmare. Is this really such a big problem ? How common is this use case? We can’t say, because we never tried it like this, so….. I’m not wiling just on a report of 2 people determine that this is absolutely worse and cannot be deployed

About external consistency: Firefox has released Picture-in-Picture mode in 2020 and YouTube has released Miniplayer in 2021.
The trend is to allow multitask, not to block it.

Well so far we spent 7 years NOT deploying a new video player, and 9 years not making updates to the player, but yeah let’s wait until perfection magically appears.

Well so far we spent 7 years NOT deploying a new video player, and 9 years not making updates to the player, but yeah let’s wait until perfection magically appears.

You (WMF) can be bold and switch the default player to the new one, and be prepared to receive more feedback/criticism :)

If nobody is going to accept and work on the proposals (ability to move the popup window to still allow reading text, inline play of audio), what are we waiting for exactly? I don't see any blockers of T248418 right now (and surprisingly this one isn't a blocker).

Well so far we spent 7 years NOT deploying a new video player, and 9 years not making updates to the player, but yeah let’s wait until perfection magically appears.

You (WMF) can be bold and switch the default player to the new one, and be prepared to receive more feedback/criticism :)

I'm not WMF and never have been. Do I really need to add that to my signature again ? Why do ppl keep thinking I'm WMF just because I've been around for 15 years and help out with MediaWiki development.