Discuss flexibility of media experience in media control

[tidoust]

@ingararntzen suggested: "Media Control. One aspect of media that could additionally be addressed here relates to flexibility. For example, can a media experience be controlled from two devices or by multiple users? Can control easily be handed over from one device to another? In a group, can media control be symmetric (everybody can control) or asymmetric (only a select few can control). This would be an area were exploratory work is covered by the Multi-device Timing CG." (see https://lists.w3.org/Archives/Public/public-web-and-tv/2017Oct/0005.html)

The Multi-Device Timing CG is already mentioned in the exploratory work section, but the description can certainly be improved.

[ingararntzen]

Yes. I felt that the one-line intro to this section didn't say all that much, and I saw this as an opportunity to broadening the scope a little. On the other hand, if the intro should rather be brief this should perhaps go in a subsection.

In any case, media control used to be a fairly straight forward theme, with different media components providing their own built-in controls. Now, with the introduction of distributed playback as a theme in both media rendering [1] and media orchestration [2], there are a bunch of new concerns that need to be addressed. I just thought it would be a good thing to put this out there from the get go.

Some new concerns regarding media control:

• media controls may apply to multiple (possibly heterogeneous) media components
• media controls may apply to media components on different devices
• built-in media controls may need to be disabled (properly), if media component is controlled externally
• media control functions may need to be available in multiple views on multiple devices for multiple users, and possibly be switched between devices dynamically
• media control functions may need to take different visual forms, possibly becoming reusable UI components in their own right
• access to media control functionality may be different for different users (e.g. some users may press pause/play, while others can only follow progress)

This is a spoonful for sure, so I won't suggest cramming all of that into the introduction.

What do you think? Mention this in the introduction, and then elaborate under exploratory work?

[1] http://w3c.github.io/web-roadmaps/media/rendering.html [2] http://w3c.github.io/web-roadmaps/media/synchronized.html

[tidoust]

That sounds good to me. The main difficulty of the exercise is to strike the right balance between simplicity and comprehensiveness. The goal is to provide a short overview of existing or potential technologies, and main use cases they would enable, without entering into details, so that the document can remain short enough.

Now, we can certainly point at other documents for more details. For instance, in this case, the Timing Object spec both has an extensive Introduction and a list of Use cases and requirements that could be worth pointing at directly.

[ingararntzen]

Pointing to documents for details is a good idea. In addition to Timing Object spec, maybe Presentation-API or Remote Playback API could be relevant too?

Also, with regards to striking the right balance I think @tidoust is better positioned. Feel free to use some of my text if needed, or better still - put it in your own words all toghether :)