W3C home > Mailing lists > Public > public-web-and-tv@w3.org > June 2011

Re: Motivation for BBC use cases (was Re: webtv-Issue-20: TV Querying and Control)

From: Scott Wilson <scott.bradley.wilson@gmail.com>
Date: Tue, 7 Jun 2011 10:55:47 +0100
Cc: Matt Hammond <matt.hammond@rd.bbc.co.uk>, public-web-and-tv@w3.org, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>
Message-Id: <3B5F6D66-A3F8-49E3-B97B-7B0E842AE774@gmail.com>
To: Dan Brickley <danbri@danbri.org>

On 7 Jun 2011, at 10:08, Dan Brickley wrote:

> On 7 June 2011 10:56, Scott Wilson <scott.bradley.wilson@gmail.com> wrote:
>> I think its important not to lose sight of the "web" part. What I'm interested in is web applications/W3C widgets being able to interact with the capabilities of the TV and the content. This means that, while UPnP is quite possibly the underlying implementation, there is still a need to expose the capabilities in a way that makes sense for web developers implementing applications in HTML5 and JavaScript rather than low-level native applications directly accessing the hardware layer, which is already possible.
> 
> Yes, Web developers can be impatient creatures. I'm not convinced that
> UPnP is the right level of abstraction.
> 
> That said, WebGL's recent adoption shows that Javascript allows fiddly
> low-level APIs to be encapsulated by nicer toolkits and APIs.
> 
> We need imho two things: an authenticated bidirectional communication
> channel with media centres and devices playing that role. And then
> specific collections of messages and interaction patterns with those
> services. For a Web standard we can't really assume the devices are on
> the same LAN; I think this will be our biggest headaches.
> 
> Re widgets, absolutely. I worked on Joost.com's original Widget
> system, which was pretty much same as W3C widgets plus some TV APIs.
> It was very promising as a platform for extendding TV, ... however
> those widgets were all on-screen rather than second screen, which
> pretty much fails to be useful -- they get in the way of the TV! If we
> can move to W3C widgets on a second screen there is absolutely huge
> potential, but to do this we need that communication channel... Once
> we've got a communication channel, the rest is relatively easy.

Its interesting how many people I know were watching Eurovision the same way - with a laptop or mobile open with the twitter feed live. A very simple "second screen" example, but still a compelling web+tv experience. Another common example is the use of third-party TV guides to augment the EPG - which doesn't have things like social content, reviews, actor bios etc.  I think these types of UCs are easy to explain in user terms, and shouldn't be that challenging to implement in a more connected way without delving into UPnP territory.

In terms of the channel, can we make use of legacy communication channels? For example, if a widget want to trigger a change of channel on the primary screen, then there is the pairing of the device with the TV to act as a controller, and then also the user granting the widget access to the channel-switching API <feature>. The latter could be handled as per DAP and WAC[1]. 

> 
> cheers,
> 
> Dan
> 
> 
>> PS I would take a look at the CEA web binding, but like most web developers I won't spend $450 on a spec document :)
> 
> Well, quite.

[1] http://specs.wacapps.net/2.0/feb2011/core/widget-security-privacy.html
Received on Tuesday, 7 June 2011 09:56:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:05 UTC