One of the requests that apps for TV (be they Android/Amazon, Roku, Apple, or WD) have is that they make it very clear what element on the screen has focus.

Sometimes this can be done by shadows and border highlights. Sometimes this can be done by a zoom. Sometimes the UI library you are using will automatically highlight, other times not. That highlight may be enough by the tester's standards, or it may not.

In the case of SubFire, I chose a combination of the default JQueryMobile highlights for icon-buttons and text fields, but added a zoom for text in the config buttons and in the lists because they didn't have a default focus setting. This worked reasonbly well enough for the FireTV (there are always times you can tweak the appearance - save them for when you need to clear your head of the technical stuff and have some time to think about nothing else, because they can get obsessive), but it started to cause problems on the Chrome web version.

The biggest problem was that when clicking on the (new to 0.7.0) play button in a folder list item, the zoom applied to the list's text and button would jolt the button out from under the mouse click. This resulted in the app going into the folder, rather than playing it as desired. It also just looked ugly popping up like that out of any context, where-as the TV version always has something highlighted, so you're aware that it is the normal thing.

This leads to the issue both of coding the CSS to only focus under certain circumstances, and then to detect that circumstance when the most common detection mechanism, the user-agent string, is unreliable. Why? It turns out there is almost no distinction at all in the FireOS version between the TV and the Tablet (and FirePhone). I do not know why they chose to do this, but it is frustrating to say the least. In addition, this may end up on other TV boxes in the future, and for the web version, there are a dozen different user-agent strings this may support. So just like in the classic days of the browser wars, one has to code by feature detection rather than user-agent.

Let's get back to that after dealing with the CSS. The normal focus the SubFire app has is, for example,

#configscreen button:focus,
.ui-listview a:focus {
    font-size: 120%;
}

Though there are a lot of ways to try to make such code optional, the easiest is to just control it by a class name on the overall document (the body itself). When the body has a setting, this is on. If the body doesn't, this is off. Really simple:

.focuszoom #configscreen button:focus,
.focuszoom .ui-listview a:focus {
    font-size: 120%;
}

Positive or negative is your own preference. I'm going positive here, but in the app I decided to go negative.

To make this the default, just add that class to the body tag as <body class="focuszoom">, or via the code (using JQuery, $('body').addClass('focusZoom');

Next I need to know when I need to use that class. Here one has to think about the interaction between the user and the app a bit. What I came up with as a clear distinction between the web and the TV is the mouse. So that's what I went with. By default, use the focus zooms. However, if there is any detection of a mousemove, then I know I have a mouse and the zoom selection states aren't necessary. A simple one-shot JQuery handler should do the trick:

function removeFocusZoom(evt) {
  $('body').removeClass('focuszoom');
  // always turn this kind of observer off after it has fired
  $('ul').off('mousemove', removeFocusZoom);
}
  $('ul').on('mousemove', removeFocusZoom);

I'd originally wanted to just watch $('document'), but that just didn't work. Still, I don't have too many ul's in my app to worry about so this isn't adding that much overhead.

So now I have it - no mouse motion in the TV means the focusZoom is always on. First detection of a mousemove in the web version and the focusZoom turns off. All by one className and one 4-line handler.

Granted, I haven't addressed the issue of distiguishing between a TV and a tablet (which also doesn't have a mouse), but that's what I'll be working on later this weekend...