Quick notes on TVs and standards

gistfile1.md

I need to write this up in more detail soon, but in chatting with Patrick, it is clear that 140 chars isn't cutting it.

The way I've been thinking about the web on TVs and consoles is something like this:

• What are the design patterns and interaction models that would make for a successful experience?
• Can we build those experiences now? If not, what would need to change to make it possible?

In my mind, this starts with the basics of designing an interface that works well on a TV and can be interacted with using a remote control. Once we have the basics out of the way, we can proceed to multiscreen interactions.

A basic television layout

There is a pattern for a basic TV interface layout. It is a grid of some sort. The Netflix interface is a good example.

On many TVs, you navigate around the grid using a d-pad. When you hit the end of a row and then select right on the row, additional items come onto the screen. Same with the bottom of the screen.

This is very similar to the way interfaces in the Smart TV's own menus work. And it makes intuitive sense to people.

How do you build something like that?

Building an interface like that using web technology that would work across devices is currently very difficult. Here are some of the challenges I saw when I was testing TVs this year. These are in no particular order:

• Other than UA, you don't know if it is a TV or not.
• You don't know if the remote is using a pointer or a d-pad.
• If it is a pointer and your web page is built to respond to someone reaching the end of the row in order to push in new items, the page will never work for someone with a pointer.
• Oh, and a lot of TVs allow users to switch between pointers and d-pad in the browser which means you may or may not have an intuitive interface.
• To replicate that Netflix interface, you'd like to get rid of the Chrome. 2013 Samsung TVs support the full screen API, but it doesn't get rid of the chrome. Others you can turn on full screen in a menu that is buried. On the Sharp TV, you switch the setting to enable fullscreen and the next time you open the browser, the chrome is back.
• Samsung's browser supports the d-pad, but you cannot capture its events. It will only go from link to link. In fact, they call that Link Browsing mode and it behaves differently than any other TV browser that supports d-pad that I tested.
• The Panasonic TV browser has a persistent left panel with a picture in picture and some bookmarks that you cannot get rid of.
• The LG 60LA7400 allowed you to switch between pointer and d-pad and acted much like a Wii remote in your hand. However, the LG55LN5700 had a more traditional remote that only had a d-pad. Ironically, this TV only supported the pointer in the browser and did not support switching to a d-pad mode at all.

And these are just a handful of the things I saw when testing on TVs.

But these TVs have great standards support!

Really, they do.

• HTML5 Test Scores
• Modernizr results
• CSS3 Test Scores

The LG TVs I tested had better HTML5 and CSS3 test scores than my iPhone 4S running iOS 6 does.

So what's to be done?

Patrick wrote:

so you meant "we need tv browsers to support standards" rather than "we need new standards for tv browsers"? if so, agree!

I think it might be both. I'm not sure yet.

1. At minimum, it seems that TV browsers could benefit from a recipe of standards that are important on TVs and as well as feedback on where the pain points are. "Hey, fullscreen API is a big deal. Stop screwing it up with your implementations." This is similar to how position:fixed to viewport became more important as mobile took off.
2. It seems like there are defacto standards that it might be nice to make sure everyone agrees with and explicitly say we expect. For example, d-pad controls trigger the keycodes for arrow keys.
3. There are clearly gaps such as the way to identity that a 10ft UI is approach for a given screen that beg for either a new standard or common implementations such as lying about device width that would allow developers to be successful.
4. There are other gaps like being able to know what type of input device is being used and being able to define how the d-pad works that it is unclear to me whether they are new standards, existing standards, better browsers, or what.

And that's just to support the basic interface scenario. That's not beginning to look at the really interesting stuff that can be done with multiple screens or new forms of input:

• multiscreen interactions
• Cross Device Design Patterns

All of which is why I said:

I don’t believe you can build something using existing standards that would provide a good exp across TVs & consoles.

Sorry to come back to this, but another aspect that impacts this discussion (and relates to my "your app doesn't live in a vacuum" point) is that I don't think many of the TVs (apart from Google TV perhaps) have the concept of saving a URL to the homescreen, with its (fav)icon side-by-side with native apps. Certainly the devices I tested from Sony (Bravia TV and BluRay player) don't allow this at all (you start the browser, then can access favourites from there, but no way to launch straight from home). Even with halfway attempts like the Opera TV Store app (effectively a chromeless browser) you first have to launch that app, before getting to your hub of web apps to launch. The situation seems similar on Samsung's "lovely" SmartHub.

So yes, on most platforms, even if your web site/app wants to take over the screen and give an app-like experience, it will first have to be accessed not from the homescreen itself, but from the browser.