Re: Filtering out non compatible displays (was: Draft of Second Screen Presentation Working Group Charter available)

On Tue, Jun 3, 2014 at 2:39 AM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> Hi MarkW, All,
>
> On 30 May 2014, at 18:00, Mark Watson <watsonm@netflix.com> wrote:
>
> > what is the value of the input parameter in
> presentation.requestScreens(…)?
> >
> > ​With this information, the UA can filter out screens that could not
> render that URL. For example, if the URL is www.netflix.com and the UA
> detects a device using DIAL that does not have the Netflix app, the
> presence of that device alone would not trigger the onavailabilitychange
> event.​ Of course if there is another device with the Netflix app, or if
> there is a second screen connected via MirraCast etc., that can render any
> URL, then the event would fire.
>
> If the group wishes to go down this path, I feel that something more
> explicit would be better, along the lines of the isScreenAvailableFor()
> proposal by Francois [1], or something like canShowType(), modelled after
> the canPlayType() [2].
>
> However, I’m not sure that such a mechanism is the right way to solve the
> problem at hand, as developers would not be able to rely on it for real.
> We’d end up returning something vague similar to canPlayType (“maybe”,
> “probably”) and that would not help us solve MarkW’s use case AFAICT.
>
> The best way to figure out if something works on the Web is to try and see
> what happens, and have a good fallback strategy in place. IOW, invoke
> requestShow(), and see if the request fails or not, and act accordingly.
> Even if the UA could technically understand the resource, the end user
> could deny the request, the second screen could be disconnected in between
> the canShowType() and requestShow() etc. and these error cases would need
> to be handled by the web developer anyway if she wishes to provide a good
> user experience.
>

​The point is that we should not show the user the "cast/fling/present"
icon *at all* if there are no suitable screens available. We certainly
can't do a presentation attempt (showing the user a display list, and then
possibly succeeding and showing some content on the remote screen) just to
find out whether to show this icon or not!

When the user clicks the icon, then we call requestShow() and the user
chooses from the available screens. At this point, the UA can certainly
filter screens based on whatever mechanisms it chooses and exact knowledge
of the URL to be presented. The user could choose a screen at this point
and it could still fail. But the two things we don't want the UA to do are:
(1) put screens in the list that the UA knows will fail (e.g. a screen with
only a YouTube app when the URL is a Netflix URL)
(2) show an empty list

My suggestion is just to give the UA the information it presently gets in
requestShow() earlier. The UA follows the same algorithm it would for
requestShow() to determine the list of displays - whatever algorithm that
is - and only fires the onavailablechange event if the list is non-empty.
​
We could, equivalently, though rather awkwardly, have a new method:
isListOfDisplaysEmpty( <url> ) which would return true or false after
following the same algorithm that requestShow() does for determining the
list of screens to show the users. Then the site could suppress the icon
when this method returns true.

But, still, I think it better to integrate this aspect into the API proper
as I proposed.

...Mark





>
> Specifically, the canPlayType() has various known interop issues, and if
> we’d be following a similar path in this group we’d inherit the same issues
> and likely more, as we’d need to query multiple, potentially remote,
> devices for their ability to support the given resource.
>
> This is what the draft charter says currently:
>
> [[
>
> The API will provide a means to identify whether requesting display on a
> second screen is likely successful, i.e. whether at least one secondary
> screen is available for display.
>
> ]]
>
> To clarify expectations: even if this is in the scope of the charter, it
> does not mean the group will necessarily ship an API with this feature. The
> charter gives us the boundaries within which to play. If the feature is
> unable to pass the interop phase, then this feature will be dropped.
>
> All - please let us know if you have ideas how to solve MarkW’s use case,
> or if you have suggestions how for rewording the above text in the charter
> to clarify this.
>
> Thanks,
>
> -Anssi
>
> [1]
> http://lists.w3.org/Archives/Public/public-webscreens/2014May/0058.html
> [2]
> http://www.w3.org/TR/html5/embedded-content-0.html#dom-navigator-canplaytype