Re: Introduction, Use-case and a comment

Hi Mark,

indeed, thanks for your feedback and contributions!

Hmm, I had imagined a slightly different flow:
* a site has content that it can render on a second screen. It calls getScreen().
* the UA begins the discovery process
* when the first device is discovered, the UA shows the Cast etc. icon
* later, the user decides they wish to send content to a second screen. They click the UA Cast etc. button and the UA shows the drop-down list.
* The user selects a device, implicitly giving their permission for the site to send content to that device
* the site received the "device selected" even and begins sending content to the device

It seems that if we want a consistent user experience and especially if the site should not be informed about the existence of devices before selection than the UA, not the site, should render the Cast etc. button. The button should only be rendered to the user if both the site supports second screen and there is a second screen available (at least this is the existing UX with Cast / AirPlay etc.).


I see certain issues with the UA displaying the cast icon. I would see benefits in the content displaying it, for the following reasons:
- Implementors tend to want to reduce and have control over what is displayed in the UA’s chrome. For example on mobile, Chrome does not display any browser chrome at all any more while you’re scrolling down. Browsers like Opera Coast also try to reduce Browser chrome as much as possible.
- If you think about a case where a page gives the user multiple options of what kind of content goes to the secondary screen, the cast icon should be close to the content. For example a multi-party videoconference where you can decide which participant of the conference should be put on the big screen. In this case, the cast icon should be close to the content that the user would send to the other screen for reasons of associating the send-to function with the content. If there’d be only one UA chrome button, the association wouldn’t be easy to figure out.
- If you ask for permission for a particular screen first, without using it, only for the availability check, the screen might go away, become unreachable before use, which might require re-prompting etc.

So, I'd imagine two steps: First simple yes/no discovery, then on cast-request the UA would show the selection dialog.  In that sense, with regards to prompting:

- We can probably give away one bit of information “Display(s) available or not” without prompting. This would be a simple event-based availability check.
- Later, the user clicks a cast button in the content, then the UA displays the display selection dialog, and informs the page that a screen was selected and is now showing the content for the secondary.

Would this still be compatible with the use-cases you had in mind?

Dominik

Received on Monday, 17 February 2014 15:02:48 UTC