Page MenuHomePhabricator

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

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)

Event Timeline

Krinkle created this task.Feb 24 2020, 8:14 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 24 2020, 8:14 PM
Krinkle updated the task description. (Show Details)Feb 24 2020, 8:14 PM
brion added a subscriber: brion.Feb 25 2020, 6:37 PM

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.

Jc86035 added a comment.EditedApr 1 2020, 4:31 PM

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.

Krinkle added a comment.EditedApr 2 2020, 2:28 AM

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?

TheDJ added a subscriber: TheDJ.Apr 2 2020, 9:05 AM

@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.

brion moved this task from Backlog to Audio UX on the VideoJS player board.Apr 2 2020, 6:16 PM

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?

brion added a comment.Aug 3 2020, 5:51 PM

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 :)
Nardog awarded a token.Aug 7 2020, 6:34 AM
Nardog added a subscriber: Nardog.