Yes, this was an intentional part of T228339: VideoJS needs to be lazy-loaded on click before we can release it by default.

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

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.

In T246035#6019631, @Jc86035 wrote:

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.

In T246035#5917206, @brion wrote:

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?

In T246035#6357153, @Iniquity wrote:

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

In T246035#6357180, @brion wrote:

In T246035#6357153, @Iniquity wrote:

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

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:

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:

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.

In T246035#7611263, @TheDJ wrote:

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

In T246035#7611973, @Ciencia_Al_Poder wrote:

In T246035#7611263, @TheDJ wrote:

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.

I see five or six different paths to move forward here, there is cost benefit to each one and we need to discuss which way we can solve this. Some are mutually exclusive some are not. This is also not exhaustive and more ideas are welcome.:

• Have a user option to have all audio files being inline, the user will lose the subtitles but if that's what they want, we can go that way.
• Have a user option to disable TMH altogether and let the browser handle media playback for the user.
• Create/suggest a js gadget to make it inline when there is no subtitle or in all audio files.
• Incorporate the above option into TMH (it would be a bit of work)
• Add a button to minimize the modal. I couldn't find anything in the options of videojs but I might have missed something.

@Jdforrester-WMF The dialog opens regardless of whether there are subtitles to show. I find your change to the title misleading.

@Ladsgroup I can't think of a situation where it is preferable to show a modal and hide everything else on the page, even where subtitles must be shown. Seriously, what website does that? The only sane way I can see is to make the embedded player an actual player (or show a fixed player like SoundCloud) and show subtitles some other way, be it above the player like Kultura or fixed on screen like VideoJS used to.

One way I'd like is to add a button on the player that pops up all subtitles, or the "transcript", time-coded and the current line highlighted, much like YouTube, C-SPAN, etc. (which would be handy for videos too!).

In T246035#7720411, @Nardog wrote:

@Jdforrester-WMF The dialog opens regardless of whether there are subtitles to show. I find your change to the title misleading.

I'm sorry, but that's what "to support" means. Titles are powerful, and failing to explain the 'why' is actively misleading when a task suggests changing something. If I'd meant "only if there are subtitles to show" I would have written as such. Please remember to have more faith when engaging in technical spaces, per the Code of Conduct.

that's what "to support" means.

I know. But most people don't, and a lot of them will read it as only relating to audio that accompanies subtitles and think it's unrelated to their problem and create duplicate tasks. It might be an improvement from a developer's perspective but certainly not from an end user's. I'm astonished at your apparent characterization that my simple suggestion of this exhibits a lack of "faith". I apologize for not being more specific but I think you took my comment less charitably than was called-for.

Change 768170 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/TimedMediaHandler@master] videojs: play audio clips without subs inline

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

Change 768170 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] videojs: play audio clips without subs inline

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

This looks good to me: https://en.wikipedia.beta.wmflabs.org/w/index.php?search=File%3ATest+files+ogg.ogg&title=Special:Search&profile=advanced&fulltext=1&ns0=1

I'm inclined to simply close this ticket. Any objections? If none, I'll close it by weekend.

I don't think this resolves the issue. However, I do think that to the extent we were holding back deployment of videojs, this is more than enough to unblock it. It's a decent short-term compromise to remove use of the unwanted modal from many files.

I believe the below is agreed upon and known, but stating it here for transparency and to uncover mistakes/disagreement:

• I don't think subtitles are an accurate proxy for guessing whether it's likely that a file is best listened to modally. People add subtitles to all sorts of files. There are contexts where you probably want to carefully listen to every word and not see the article (but have no subtitles), and plenty of contexts where you just want to listen to it in the background but the file happens to have lyrics or other subtitles.
  • A major example of this is country anthems and other music samples. It's nice to be able to read the lyrics in contexts, but it's rather unfortunate that the majority of readers of country articles now have to either sit still and stare at the player to really listen, or decide it's not worth it and read without it.
  • Another major example is "Spoken Wikipedia". With these modal players there is now an active reason to delete or stop contributing subtitles because with them you can't visually navigate along with the article while listening.
• This compromise won't change most audio interactions. The stats quoted are about files stored, not files played. In my experience, the vast majority of page views where someone plays an audio file, that audio file has subtitles. (Thus not counting files unused, in unpopular articles, or in articles but rarely played; e.g. a country article's anthem is played more often than its spoken article.)
• I don't think the modal experience is preferred for any audio file, and possibly not even for most video files, as the default experience upon playback. I don't mind being on the oppposite side if I am, but as far as I know this isn't currently a topic of disagreement. It's a known compromise to get it out. We may offer modal as an option, but as a general direction if we had unlimited resources I believe none of us would want it to be the default all situations.
• I think it's an improvement to avoid the modal when the main feature we currently limit to modals (subtitles) isn't available.

Take for example the article in the task description of this task (Pagliacci). That music file happens to have lyrics offered as subtitles. I imagine most don't want the larger, distraction-free experience where the article is inaccessible/unreadable while listening. It's nice that someone made the lyrics are available, but I think for most people listening to it their curiosity has not yet reached the point where they want to leave the article and now actively be required to sit and wait and/or read the lyrics. This is a different kind of commitment and a different kind of intent/interaction. Offering subtitles passively (as the old player did) is fine, as it didn't take over the screen.

Having said that, if we want to rescope this task to not include the example in the task description and continue on at T303387, that's fine by me.

@Krinkle I agree with you (I think this already addresses the issue in wiktionaries though) but I think fixing that properly requires UX resources (to at least do user research and interviews), PM resources, possibly AB testing, etc. to understand our users better and I'm not sure we are there yet. Your response is not invalid, it's just out of capacity for a group of volunteers. Maybe I'm missing something.

I just discovered this ticket (I don’t know how I missed it so far, even though I was the one who strongly advocated for this in T248418#7719001). I generally like the new experience, but the loading indicator appearing on the top of the page even for inline players looks a bit out of place. Couldn’t that also be shown inline, where the actual player will appear?

In T246035#7776333, @Tacsipacsi wrote:

I generally like the new experience, but the loading indicator appearing on the top of the page even for inline players looks a bit out of place. Couldn’t that also be shown inline, where the actual player will appear?

Oh I like that idea; might not be too tricky to do, by just positioning the element appropriately. Would feel more grounded in what you clicked on.

Can you open a new ticket for that? I'm hoping to help finish up a few more of these polish issues, it's easier to track them separately at this point. :D