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

On 03 Jun 2014, at 15:25, Anton Vayvod <avayvod@google.com> wrote:

[...]

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

We should design the API in such a way we do not discriminate devices that may not be able to "know for sure”.

That said, If you have concrete data on the existing devices’ ability to reliably “know” what content they can consume, please let us know, because I think that would be hugely helpful.

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

Agreed. As a user I would not try to display content using such a DIAL device again if I know (by experience) that it often fails and/or only works on a subset of websites. Instead, I’d likely use a device that I know works for all types of websites that use the Presentation API.

Similarly, I prefer to use a web browser that works with all the websites I visit, instead of a browser that only works on certain websites. Also, even if the site claims that it “only works with Netscape Navigator v2” and I don’t have such a browser installed, I’d rather try it with my current browser and see what happens.

That’s how the Web works: you try, and if that fails, you let the user know or show her fallback content.

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

You mean they’d be more likely to fail? I would have guessed e.g. picture frames would only support say image/jpeg so that’d be rather easy to know.

Do you know what content types these classes of devices typically support? Is it reasonable to try to target there devices with the API?

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

It’d be helpful if you could give a concrete example, e.g. in (pseudo-)code?

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

This is one of the reasons why I think knowing “there may be some screens that are able to display content from example.org/foo” before invoking requestShow('http://example.org/foo') is not that helpful.

You’d end up writing code such as (in pseudo):

if (filterScreensFor('http://example.org/foo').length > 0) {
  requestShow('http://example.org/foo');
}

Or am I missing something? How would you fix the above example?

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

Couldn’t an implementation search for devices and query their capabilities in the background even before the requestShow() is invoked to speed up the process (cf. link prefetching) and thus be able to display the supported devices immediate when the requestShow() is invoked? I think that would provide a good user experience.

Let’s take an analogy, please let me know where this breaks down:

A webpage has <input type=“file”> to allow you to upload a file. You click “Choose file..." to pick a file from your filesystem. Your underlying OS does not expose a filesystem at all. You back off by clicking cancel. I think the UX is not that bad. If you don’t have a filesystem you cannot upload a file from it.

Similarly, requestShow() will show you a screen picker. If no screens are around, you’ll be greeted by an empty list, or perhaps your browser will provide you a software-based fallback a la Chromecast Simulator. The user would think “ok, I have no screens capable of displaying content on this site” and the next time the user visits the site she probably remembers this, and does not retry unless she has purchased a new device to try with.

> I think the charter already covers the use case.

Ok, good.

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

Let’s try to make this work across implementations with known issues in mind, and be prepared to back off if we’re unable to get implementations to interoperate. This is a hard problem to solve, but we can try if we think this use case is an important one relative to other important use cases we need to address.

Thanks,

-Anssi

Received on Tuesday, 3 June 2014 14:33:59 UTC