Re: Web Intents and Home Networking Scenarios

On Thu, 15 Dec 2011 19:24:13 -0000, Greg Billock <gbillock@google.com>  
wrote:

> Here I'm collecting my thoughts about the applicability of Web Intents to
> various pieces of the "Requirements for Home Networking Scenarios"
> document [1].

Hi,

I participated in the Web and TV Home Networking Task Force, and I've just  
been catching up with subsequent discussions here. It is good to see such  
a detailed discussion and analysis taking place.

 From the perspective of enabling some of the HNTF use cases using Intents,  
I believe RPC style Intents may make it difficult to create good user  
experiences. I'm inclined to favour Intents as a means of discovery, then  
establishing a communication channel:

Of particular interest to me is enabling "Second screen" or "dual screen"  
services as hinted at by the time synchronisation use cases [1]. In  
particular, being able to do these from pure browser based applications,  
and have them work both for live broadcast programmes and on-demand or PVR  
recorded programmes. This means accessing a wide range of  
services/functions on the home media devices and creating an application  
that is not simply a 'remote control'. [2] is a short video of a browser  
based prototype we developed. It lacked discovery, but used a RESTful web  
API we developed [3] for controlling and querying the TV.

> The time synchronization use cases also need some kind of notification  
> channel
> which doesn't fit the model as well. Perhaps a time-synchronized  
> pseudo-device
> can fit the model if the user agent knows how to construct one...

Not necessarily a notification channel, but certainly a means of having  
continuous communication - e.g. regular polling - between the TV and the  
web application.  and access to several functions of the TV - both control  
and querying - some of which may be considered non obvious to the user.  
For example, a single web application providing a dual screen services for  
several TV shows would need too:

  * determine what programe, stream or TV channel is currently being
    shown on the TV

  * regularly check the current playback time index

  * retrieve information about (the currently playing) programme
    (e.g. globally unique content identifiers - as distinct from
     identifiers used within the TV or media serving device,
     that may be generated locally)


If the web application also wants to be able to initiate the playing of  
the programme, it will also need to be able to:

  * search or enumerate available content on device(s) in the home
    (not necessarily just the TV)

  * check compatibility of media formats with the playback device
    (if needed, e.g. in UPnP)

  * initiate playback of a piece of content / change TV channel etc

  * seek to a different time index within the programme


A web application may want to perform this second group of actions before  
even proffering the user the option to select/play content, in order to  
avoid presenting options that cannot be fulfilled.

Whilst ensuring transparency and control for the user, it could result in  
a poor user experience if the user is being prompted for many individual  
actions (even if only the first time for each), rather than more general  
permission to communicate with the TV and other device. The individual  
actions may not, in the user's mind, correspond well with the task they  
think they are trying to perform, whereas general permission to  
communication with a particular device or collection of services on a  
device may make more sense.


> Web Intents can provide such control functions to web applications. The  
> role
> of the Web Intents API is more generic, but we can imagine a set of
> action/type intents which would address these requirements. The  
> limitation is
> that Web Intents are user-initiated and RPC-style.
>
> This makes it easy to perform some needed operations, but others which  
> rely
> on persistent connections need more thought.

I think this second set actually encompasses a fairly large set of  
possible web applications - certainly if interest lies beyond just  
replicating the buttons on the remote control.
The dual screen example just described will have similar requirements.

We've prototyped remote controls that attempt to improve usability,  
particularly for disabled users ([4] is another short video demo). An  
important aspect of usability is conveying the state of the device in the  
interface (e.g. listing the currently showing programme, or not showing  
any channel change controls when the TV is off). This requires a return  
path for notifications of state changes.

If a web application needs to know about state changes, then it will also  
need to know if the UA switches to a different intent provider (e.g. a  
different device/service). Obviously I appreciate that there is a tension  
between this and the desire to improve privacy and security by the UA  
keeping as much as opaque as possible!



regards


Matt

[1]  
http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#u12.-time-synchronization
[2] http://www.bbc.co.uk/iplayer/episode/p00km95s
[3] http://www.w3.org/TR/2011/NOTE-hnreq-20111201/#bbc
[4] http://www.bbc.co.uk/iplayer/episode/p00km8ww

-- 
| Matt Hammond
| Senior Research Engineer, BBC R&D, Centre House, London
| http://www.bbc.co.uk/rd/

http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Thursday, 22 December 2011 17:14:02 UTC