Web Intents - Scenario: TV System (part 6)

While this article talks about a TV, I'm really only using a "TV"
because it's something with which most people are familiar. TVs
traditionally have a number of knobs to control unrelated settings, many
also support infrared remote controls. Often we're so lazy that we avoid
walking to our TVs and instead rely on these remotes to control them
instead (or we may claim that by doing this we avoid interrupting everyone
else's view).

I've been meaning to introduce detailed use cases for a while. Home
Media Centers are much more complicated than the TV below, mine
[1] certainly is.

§13 TV Controls Scenario.
Imagine a TV as having the following inputs:

A. Power button
B. Mute button
C. Volume spinner
D. Source selector
E. Channel selector
F. Brightness selector

Each of these is commonly found on a TV, and one can often get a
dozen remotes that can all control some of these items on that same one TV.
There is no requirement that all remotes have buttons to control all of
these items (some remotes are more limited/simplistic than others, some are
less universal than others, and some have been programmed so certain
buttons  control other devices instead).

If we accept controlling each of these as an independent action (and
hopefully you do), then we can assign intents for them. But obviously the
TV wants to advertise supporting all of them. And that's fine.

When I get a programmable remote, I teach it about a device, and then the
device lets me select which actions I want to program for that device.

Supporting roughly that is the goal.

§14 Use Case: Programmable remote control for a Home Entertainment system.

Steps:
1. User's UA discovers HN (TV, Stereo, VCR, DVD)
2. User loads "programmable remote control" web page
3. Page has buttons for:
A. Power button
B. Mute button
C. Volume spinner
D. Source selector
E. Channel selector
F. Brightness selector
4. User presses "power button" (A) on page
5. Page triggers <power> action (Ai)
6. UA offers list of "powerable" devices:
TV, Stereo, VCR, DVD
7. User selects TV
8. UA remembers all Actions the TV supports but only maps TV -power to
page (Ai:TV)
9. Page triggers <power> action (At)
10. UA sends TV the power signal (At:TV) -- wake on LAN?
11. User selects "channel up" (E) on page
12. Page triggers <adjust-channel> action (Ei)
13. UA has a list of channel-adjustable devices:
TV, VCR
* our stereo doesn't do am/fm/xm (don't ask)
14. UA suggests TV indicating it's already used for <power> action by this
page, but offers the user the choice of the VCR
15. User chooses TV
16. UA remembers maps TV-adjust-channel to page (Ei:TV)
17. Page triggers <adjust-channel> action "up" (Et)
18. UA sends TV the adjust-channel "up" signal (Et:TV)
19. User presses "volume up" (C)
20. Page triggers <adjust-volume> action (Ci)
21. UA has a list of volume-adjustable devices:
TV, Stereo, VCR, DVD
22. UA suggests TV indicating it's already used for <power> and
<adjust-channel> actions by this page but offers the user the choice of the
Stereo, VCR and DVD
23. User chooses Stereo
24. UA maps stereo-adjust-volume to page (Ci:Stereo)
25. Page triggers <adjust-volume> action "up" (Ct)
26. UA sends stereo the adjust-volume "up" signal (Ct:Stereo)

We've now mapped 3 actions to our page. User is happy. Ideally the UA
will remember these mappings so the next time the page loads, the user
won't need to map them unless an action fails or the user wants to adjust
them.

Note that in this step list there are two trigger phases. I don't
think this distinction will exist in the API we'll select, although I
could imagine apps cheating by choosing state-query messages for their
initial intent message (or some other null action, e.g. "increase volume by
0").

[1] http://lists.w3.org/Archives/Public/public-device-apis/2011Nov/0087.html