Creating Applications for TV
Designing for television has its own set of demands, different than designing for desktop and mobile implementations. This document outlines the most important best practices for designing applications for TV. Topics include user interface design for TV, color issues, animation and transition effects, file formats for graphical elements, safe zones, and some troubleshooting solutions to reduce impact to bandwidth.
The 10-foot Experience
What makes designing for TV unique? TV is a different user experience. Users are positioned somewhat distant (±10 feet) from the TV screen, in a “lean back” or non-interactive mode, as contrasted to the "lean forward" or actively interactive mode that characterizes the desktop or mobile experience. On TV, the UI design is page based. The users interact with the applications via a directional pad (TV remote control) and possibly a second screen (such as a mobile device). Users do not normally have access to a mouse-style control.
Most likely, the user will have a remote control to navigate your UI. Make sure your application is navigable using the compass keys. Also, design the UI in an uncluttered and consistent manner. For more on navigation, see the article on Navigation.
Text and Fonts
Optimize your text carefully. Limit content length. Avoid using small text as much as possible — make text as large as possible, at least 20 px. Test the readability of text on an actual TV.
Typical on-screen font guidance is also applicable for TV applications. Sans-serif fonts tend to be more readable. Avoid using too many different fonts in one page.
The platform comes with a wide array of fonts. However, if your application requires a specific unsupported font, you should only reference the font via the CSS module@font-face if you have the appropriate license(s).
There are still CRT (cathode ray tube) TVs in use and it is likely many TV applications will be displayed on these TVs. There is a portion of the edge that bends or wraps with the tube. Anything displayed in this zone could be cut off from being displayed. Since all TV displays are different, there is no exact range of the zone but there are some general guidelines. HDTVs are flat but there are displays that still clip the edges. Action safe zone is considered to be 3.5% from the edge and Title safe zone is considered to be 5-10% from the edge.
Title safe area = red. Action safe area = green.
The color gamut is different on TV than a computer monitor. It is easy to over-saturate, so tone down your colors (especially oranges and reds). Non-white background colors are best. White backgrounds produce excessive contrast and can also cause halos. TVs are frequently not calibrated as to color reproduction. Always test on a real TV display that is properly calibrated.
(Under "Downloads" below, the Zip file contains a test sheet with various color samples.)
Keeping colors consistent in the interface will make it easier for users to find the focused element or to recognize recurring interface components such as menus, scrollbars, etc.Take care to use color in a redundant manner, to accommodate users with color vision deficiency.
Use enough contrast between your foreground and background to helps users with color vision deficiency but also users with older television screens. However, be careful not to make everything high contrast; apart from aesthetic reasons, some users such as those with dyslexia (which is about 6% of the population) find it hard to read text with a high contrast. If you use high contrast, try to tweak the luminosity value in the HSL color space or the brightness value in HSB/HSV color space. Try to lighten the light color and darken the dark color. (Changing the saturation is less effective.)
Many design effects can negatively affect the application. Gradients in the background can cause a ‘banding’ effect where heavy pixilation can occur. Also be mindful of bevels and opacity — these can cause additional ‘noise’ when combined with the background.
When producing graphics for your application, avoid drawing horizontal lines that are narrower than 3 pixels in height, as these may cause flickering on interlaced displays. Modern televisions usually have software to reduce this effect, but may also introduce unwanted sharpening artifacts for narrow lines (including vertical ones). Remember to check your application on various devices.
The formats PNG, SVG, GIF, JPEG, and BMP are acceptable for the CloudTV™ H5 platform. The key to selecting a delivery asset is not necessarily the size of the element but the quality. Rasterized images are subject to quality loss in certain situations.
Television is not the best medium to read from. Keep any text in your interface short, understandable, consistent and to the point.
Do not use flickering areas (videos) with a frequency between 3 and 50 Hz. For viewers with photosensitive seizure disorders, this frequency range can cause seizures. This is especially true for a saturated red color.
Depending on the type of network on which the application will be presented, the design could become pixelated with resulting diminished quality of graphics. This usually has to do with the bandwidth selected to display the application. Gradients, radial bursts and graphics with various opacity levels could cause unsightly ghosting and blocking. Selecting flat backgrounds, minimizing gradients and choosing 0% opacity on delivery elements can help reduce graphic inconsistencies when operating under a low bandwidth. It is very helpful to know the bandwidth before designing. If the bandwidth is unknown, plan in advance to be able to toggle the sophistication of various design elements.
Macro Block Grid
CloudTV H5 allows for free design of all elements except for video. Video elements must snap to a 16 pixel grid in order to be functional. Design elements should accompany video fields accordingly. The 16 pixel macro block grid is constant with 480p (NTSC-SD), 720p, and 1080p resolutions.
Applications developed in SD will display correctly on SD and HD screens (although they will display larger and not as crisp as possible), but applications developed in HD need to be scaled down to display on SD screens. Since not all client devices may support scaling down and not all your users may own large widescreen televisions that can display Full HD applications, it may be to better to develop your application in SD.
The displayed size of your interface elements not only depends on physical screen size, but also on display resolution and screen aspect ratio. Applications authored at a higher resolution than can be displayed will be scaled down or may not display at all. Applications designed as 16:9 may be shown letterboxed on 4:3 screens such as older TVs or tablets, which will reduce the size of text and other UI elements. If you expect that your content will be scaled down, ensure that text remains readable and the interface is still usable at the reduced size.