Over the last few months, my company developed an HTML5 video game for several interactive TV (ITV) platforms for a major developer in the ITV gaming space. This project gave us significant insight into how to create high performance apps for ITV. There are many great articles on how to create high performance HTML5 apps; this one on html5Rocks is a must read. However, very little has been written about how to tame app development on ITV: ITV is a different beast. Hopefully other developers can benefit from our lessons learned. This blog post is only a very rough first draft of what I hope to evolve into a longer, more detailed article.

Article contents

Analysis: Know your platform

TV browsers are substantially more limited than PC and even mobile browsers in processing power and even more so in memory that’s available to your application

You can get a decent idea of your your target TV’s level of support of HTML5 specs by visting html5test from your TV’s browser. Don’t trust the existing specs since results can differ drastically for slightly different models from the same manufacturer.

Common tests are just a starting point for discussion. They don’t preclude the need to create small working prototypes that exercise the specific HTML5, javascript, and css capabilities of your app.

Write tests that help you understand your TVs memory and processing limits. Don’t assume that you can load more than a few MB of pixels into memory at a one time. Does your TV silently unload images when its memory gets full?

Design: Keep it simple

Are you using canvas? Know when to use it and when not to use it. Minimize the number of canvases, the size, and the duration of any canvas (and any DOM elements). The general rule is, if you can do what you want to do in DOM, do it in DOM; canvas should be viewed as a fallback. canvas was a good choice for our main game board, a variable sized grid of 100+ creatures that could be moved around and animated. We found out the hard way that canvas was not a good choice for many other areas of our game since the additional pixel memory occupied by subsequent canvases overwhelmed the TV browser performance and/or memory limitations.

Galapago in-game experience. Only the main grid use a canvas. The rest of the screen elements are DOM.

Minimize your images, both in terms of file sizes but perhaps even more importantly in terms of pixels (width x height). TV’s are often very limited in amount of video memory that they allocate to the browser. Use JPGs for full screen images such as backgrounds and PNGs for all other images. Minimize PNGs with TinyPNG or all images with Yahoo SmushIt.

Organize images into sprite sheets in order to minimize the number of files that your app has to load. This design choice can make a significant impact under load. See the article see this article for how use of sprite sheets in one game reduced network bandwidth and loading speed by 10.

For the best user experience, your app is probably a one page app. That means that if your app has multiple screens and dialogs, they’ll all need to share javascript window, document, and body objects.

Events should be attached to the most specific objects possible so that event handlers aren’t stepped on between screens. Even keyboard event handlers can and should be assigned be to specific DOM elements. According to quirksmode, any DOM element that’s not a window element, a hyperlink element, or a form element requires a tabindex property in order to receive focus (and therefore attach events).

If your app needs to support animation on multiple screens, your app should have a central mechanism for started, stopping, and pausing animations. For performance reasons, you most likely don’t want animations on one screen to run when another screen is visible.

Load images intelligently. Typically HTML5 apps preload all images, but this wasn’t an option for our game since the images occupied too many pixels in memory. We started with a game asset loader that wasn’t created with the limitations of TV browsers in mind. That library got us part of the way to loading our game assets, but it required significant modifications. We had to invent on on-screen image cache that was responsible for loading and unloading images every time a screen or dialog was shown.

Does your app support sound? Create a mechanism to globally disable the playing of any sound in your app if necessary. We discovered that some TV browsers crash when trying to play HTML5 audio.

Development: Chunk It

Ensure that a capable developer has access physical access to the target TVs. This kind of development can’t be done remotely!

Minimize the feedback loop: can you point the TV browser to your development workstation, or do you have an extra step in your process where you first need to upload your apps to a server?

TV browsers don’t come with a fancy development console profiler that displays your app’s memory consumption and helps you identify performance bottlenecks. You could roll your own on-screen console with substantial effort, or better you can use a javascript remote debugging toolkit.

Test: Automate

Deployment: Automate

jake.js, grunt

minimize css and js

Maintenance: User error reports

Create a “phone home” for mechanism for your app to upload user error reports to a central location for analysis. You can roll your own or use a javascript error reporting service like Muscula (free as of this writing but converting to a paid service).