W3C home > Mailing lists > Public > public-secondscreen@w3.org > April 2017

Re: [remote-playback] Interoperability concerns by lack of a common denominator in transport

From: Sangwhan <sysbot+gh@w3.org>
Date: Wed, 19 Apr 2017 15:58:41 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-295322075-1492617520-sysbot+gh@w3.org>
@avayvod Yes, you are correct - for some reason that reply slipped through my attention. (I blame a large backlog of mails, but that's mostly an excuse. Apologies to @mounirlamouri .) 

First of all, I understand the rationale for the abstraction - I had a quick chat with @anssiko about the background when I was first tasked to look into this. Unfortunately, it doesn't address the concerns - but more on that below.

>  If the user switches to a browser that only handles AirPlay, the API on this browser will report no available device.

This is the part that I'm worried about. While the Safari-Apple TV and Chrome-Android pairing would be relatively obvious to the user after a bit of trial and error (and the tradeoff of not having to yak shave a transport protocol into the specification for this quirk makes sense) - this requires users to switch browsers for remote playback compatibility, which doesn't quite feel like something an open web standard should be doing.

e.g. For a user with a Apple TV that uses Chrome as their main browser, it would not show up as a playback device. The application running in Chrome wouldn't have any way of knowing that the user has an Apple TV which is incompatible with Chrome, so it wouldn't even have the contextual information needed to notify the user to switch to say, Safari. Users would intuitively need to know when to switch to what browser, based on experience. For a tech-savvy user, this wouldn't be a problem - I'm not sure how well this would work for the average user though. And as noted above, there are obvious pairings - but it's also not entirely obvious what browsers from vendors with no companion device offerings (e.g. Mozilla) would support, even to a tech-savvy user.

My understanding is that websites which plan to use this will need to explicitly make the users aware of the browser-playback device pairing in some form of documentation as their best bet, possibly with a list of working pairs of browsers and devices. This isn't great, both from the content developer or user's perspective.

It is understandable that utilizing existing transport mechanisms were the most logical way forward, and the TAG can't really stop implementations from shipping. The ideal way to deal with this is to implement a cross-implementation compatible transport, but I understand that is a long term goal.

This issue was raised in hope to find a better way to deal with the problem at hand and deliver a better experience to the users. I'd be happy to sit down and throw around ideas to at least make the user experience aspect better if that is the most pragmatic way forward.

(I'm pretty sure this comment could have been made a bit more concise.)

-- 
GitHub Notification of comment by cynthia
Please view or discuss this issue at https://github.com/w3c/remote-playback/issues/74#issuecomment-295322075 using your GitHub account
Received on Wednesday, 19 April 2017 15:58:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 19 April 2017 15:58:50 UTC