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

Hi Anssi,

comments inline:

On Tue, Jun 3, 2014 at 10: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.


I believe that most of the existing second screen devices "know" for sure
what content can or cannot run. Chromecast or AirPlay or DIAL devices, for
example. It would be a pretty bad experience if the UA detects a DIAL
device and reports it as available to the website that never had a DIAL
app, the site then would show user some UI to start presenting its content
only to fail later on.

If we consider wireless speakers or picture frames, the try-and-fail
approach looks even worse.

So, the more devices are supported the more important becomes the ability
to filter screens by capabilities. For the devices I mention above it
should be possible to implement by using the same parameters that are
passed to requestShow(). I'd rather make it a kind of initialization call,
navigator.presentation.filterScreensFor("www.example.org"). Then the
existing event/flag are used to detect if any screens matching the filter
are available.

This will not guarantee that the presenting will not fail, however, if, for
example, the UA knows it will use mirroring to present on one of the
available devices but then it will not support the playback type the
website intends to use for the presented content. E.g. YouTube will try to
present PlayReady-encrypted content: it will work in the case of remote
rendering on a Chromecast but it won't work if Chrome on Android will try
to render the video off-screen and send the frames to an external display
via Miracast since Chrome on Android doesn't support PlayReady.

We could add a canPlayType exact parameter to the filterScreensFor() so the
UA could drop the mirroring-only devices if the requested play type is not
supported by the UA. But as you say below, canPlayType is not very reliable.

I still think that filtering as many devices out as possible before the
user is requested to perform any action is very important for a better user
experience.

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

I think the charter already covers the use case. We're just specifying when
and how the website should be able to tell if presenting content on a
second screen is available or not.

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