Re: [HOME_NETWORK_TF] Some use cases and requirements for broadcast TV applications

On Fri, 08 Apr 2011 17:29:50 +0200, Matt Hammond  
<matt.hammond@rd.bbc.co.uk> wrote:
>
>>> A user watches a television programme (either live or playing back
>>> a recording).
>> Is "television programme" a generic enough term or should we use some
>> other term like "piece of content", "video content", etc?
>
> A more generic term would make sense. But even a word such as 'video' or  
> 'content' could carry assumptions. Perhaps we should, preface its first  
> use with a non-exhaustive list of what could constitute 'content'?
>
> For example:
>
>   * audio or video stored on device(s) in the HN
>   * television or radio programmes ...
>      * downloaded or streamed via IP
>      * received from live broadcasts (terrestrial, satellite, cable etc)
>      * recorded from live broadcasts
>
Fine, I think we can follow this approach (i.e. a basic vocabulary at the  
beginning ot the use cases section)

In this respect, I'll take the freedom to change few things in current  
usecases text to make the wording a bit more generic (so only editorial  
changes).
Let me know in case you don't agree (you can see the changes using the  
diff functionality of the wiki and we can roll them back if needed)

<http://www.w3.org/2011/webtv/wiki/index.php?title=HNTF%2FHome_Network_TF_Discussions%2FUseCasesDualScreen&diff=211&oldid=188>


>
>
>>> 1) A web or native application that provides time-synchronised content  
>>> on a "companion" device
>
>     ...
>
>>> A laptop/tablet/other "companion" device displays a slideshow of  
>>> complimentary content. The slides change to match the different  
>>> segments of the television programme. If the programme is being  
>>> watched as a recording or on-demand, the user can jump to a different  
>>> point in the slideshow and the television will also seek to the  
>>> corresponding segment of the programme.
>>>
>> I would also include a use case where the user can go back/fwd in the  
>> slide show disabling synchronization
>> and re-enable synchronization at any time when he wants to go "back on  
>> track".
>
> +1
>
I added the text "The user can enable/disable content-program  
synchronization at any time."


>
>>> 2) Integration of television viewing into websites
>
>     ...
>
>> Is this use case to be interpreted from the PoV of the "companion"  
>> device?
>> I.e. are you describing a user browsing with his laptop a webside and  
>> discovering in the home network any related piece of content?
>
> Yes, the experience as described is about giving a web based experience  
> on a "companion" device the ability to query and control the TV.
>
> The particular use case we are thinking of requires the ability to  
> recognise that a specific piece of content is available to the TV  
> device. This might be because it is currently being broadcast, or  
> because it features in the TV programme guide data for the next few  
> days, or because it has been recorded onto a device on the home network.
>
> A specific example might be a particular series of cookery programmes: A  
> broadcaster may maintain web pages relating to each show and the  
> recipes. If the home page can discover and recognise that a particular  
> episode is currently being watched on the user's TV then it can  
> prominently feature links to web pages for that episode.
>   If there is a recording of a particular episode available on the home  
> network, then the web pages it can offer to the user to instruct the TV  
> to play that episode. It might also offer to instruct a TV with  
> recording capabilities to record the rest of the series.
>
OK, maybe you can extend the wording of the current proposal to clarify  
this.


>
>
>>> 3) Alternative remote controls
>
>     ...
>
>> This Use Case looks fine but is probably a bit too generic.
>> E.g. if the outcome of the discussion is a JS API, I don't see how a  
>> "simplified device with physical buttons" would benefit from it.
>> If we were defining a new HN protocol, that would make sense, but I'm  
>> not sure we will reach that level (this is up for the TF participants  
>> to discus of course)
>> So I would rephrase a little bit to focus only on the "web page" case  
>> and live out for the moment the native application and physical device
>
> I agree, a focus on only JS APIs will not benefit those classes of  
> device. This was included because I believe that existing protocols are  
> not sufficient. But as you correctly say - this is for the TF as a whole  
> to determine in the ongoing discussions.
>
>
I think that we could split the use case in different usecases,
disregarding at this level which one we want to cover (is good to have  
usecases listed, we can discuss which one is appropriate to cover later in  
the discussion).
I also don't see a stric need to differenciate between "alternative remote  
controls" and "alternative remote controls for accessibility" since once  
you enable alternative remote controls to be delivered you implicitely  
include the possibility that one of these "alternative" is designed for  
accessibility .


So I would suggest to list the following usecases

1) a device with a proprietary interface wants to interact with the TV
2) a device can discover/be offered (and use) one or more alternative  
interfaces (web page?) for the TV
3) a device can discover/be offered (and use) one or more alternative  
interfaces (web page?) for a specific program

I didn't update the text, I'll wait for your (or other people) comment on  
this.

/g

-- 
Giuseppe Pascale
TV & Connected Devices
Opera Software - Sweden

Received on Tuesday, 19 April 2011 10:43:05 UTC