Where possible, it is a great idea to utilise these components as not only do they conform to material design standards but they provide a lot of standard functionality pre-implemented - allowing us to re-use many components!

We should make use of the large screen available to us, which we can do so by showing beautiful visual backgrounds in our application. Whilst this can easily be done using the BackgroundManager class from the Leanback Library, we also have the ability to change the background on the home screen of the android TV system using our displayed contents data.

When browsing their home screen for recommendations, this background image is also displayed here as the system background when the content cards switch focused state. This is easily achieved by attaching the image source to the data objects that we use when displaying content cards. It’s also best practice that is different from the image used on these cards, so if possible then a different thumbnail image from that shown on the card should be used for the background - this provides a complimenting visual difference when browsing content.

Whilst the background image should be sized at 1920 x 1080 px, we have to account for motion events by adding 5% onto this size, giving us a resolution of 2016 x 1134 px. If the background image does not meet these requirements then the system will automatically scale the background.

Note: There should be no transparency on the background that you use.

The Android TV system provides a recommendations service that allows applications to display new and relevant content in the recommendations row on the users home screen. This helps to reduce the number of steps in which the user may be required to take to begin consuming content from their TV. I know for sure when I sit down in front of my TV, I want to turn it on and find something to watch in as little steps as possible! Making use of this service allows you to provide both great and easily accessible content to your users from outside of your applications context, boosting application engagement at the same time.

Recommendations should be chosen based off of any user data you have around your application. This could be information such as what they’ve previously watching, listened to or viewed from the context of your application. When done so, these recommended items are shown on the first row of the Android TV home screen.

Recommendations that you create should be used to return the user to a previous viewing or recommend them to new / related content to their previous viewings. There are several types of recommendations that we can display to the user - let’s take a look at these in a bit more detail:

Continuation content

These are recommendations that allow the user to either continue watching or listening to content that they were previously consuming, or even moving on to the next item in a collection or series. This again allows the user to pick up where they left off with minimal friction.

New content

This card is used when there is new content available in relation to something that the user has already watched or listened to. For example, your application knows I watch a specific program so it should recommend new content to me for that program when available.

Related content

These cards allow you to recommend new content that you feel is appropriate to your user. If you know that the user watches a certain theme of programs or genres of music, then you can build recommendations for alternative content that they may also enjoy.

So we know the different types of recommendations that we’re going to display, but how should we handle the display of these items on the TV home screen?

When refreshing recommendations that are being displayed on the screen, don’t just reload the previous recommendations that were displayed. Any content that has been opened and played should be removed from the list of recommendations - refreshing content should produce new and appropriate content for the user to consume.

We have the ability to customise our recommendation cards in several different ways, this allows us to give our cards some style and branding when they’re shown. Whilst the card attributes allow use to provide a short title and subtitle, we should use the card imagery to portray the item to the user - the image alone can be enough to educate the user about the content.

You have the ability to group recommendations based on the source of the recommendation, such as grouping content that may be completely new to the user and then separately grouping recommendations of content that they are already subscribed to. These recommendations can be easily grouped by the used of tags, such as as “trending”, “new” or “related” — this allows us to easily group recommended content into recognisable categories.

Whilst we have the ability to assign a weight to recommendations to decide the order in which they’re shown, recommendations for each group are ranked and ordered separately from each other to ensure that more dominant recommendations are not ordered incorrectly.

Iconography can not only make our application more aesthetically pleasing and fun, but it can be used to help to portray information to our users just as well as text. This should be the approach where possible, as we’ve previously pointed out we should approach the TV with visuals over textual content.

Using a single colour for header icons keeps them simple and isn’t too distracting during navigation. Obviously, this is dependant on the navigation background colour in your application and the icons in use.

These icons are all simple. There’s no complex shapes and they’re all material design influenced icons which are taken directly from the Google Material Design Icons resource. You don’t have to use these, but any icons you design should have a material influence to match the overall look and feel of your application.

The icons should relate to the content which they’re displayed with. It should compliment the content it’s being displayed with, no complicate.

Just like mobile applications have their launcher icons, TV applications have what’s known as a banner - this will be displayed in the Android TV app launcher once your application has been installed.

Note: If your app is listed as a game, then it’ll appear in the Games row. You can list your app as a game by declaring so in the manifest:

<application

...

android:isGame="true"

...

>

This banner should be an XHDPI resource and sized at 320 x 180 px. It’s good practice to display the name of application in the image - I feel that this really depends on the application and how identifiable the app is from an icon alone. This way the application is easily identifiable when browsing through the application banners on the home screen.

Note: If your application is available in multiple languages then you must provide a version of the banner image for each language that you’re supporting.

We can use sound within our TV application to enhance the cinematic experience that we provide. Sounds, if used correctly, are a great way of complimenting visuals without the need to use textual notifications. It’s easy to go overboard with sounds and exaggerate their purpose, so designing complimentary sounds is important.

Sounds are a great alternative from displaying visual notifications on screen. Not only can these be obstructing from the current view, but the system components (such as toast and dialogs) don’t tend to be the prettiest when displayed on a TV screen. Playing a sound for events such as when the user tries to interact with a disabled component or reaches the end of a list are great examples of when this could occur.

Providing feedback in the form of sound also allows you to notify the user when they are only partially engaged with the TV - which sometimes tend to be the nature of a users behaviour with a TV. That way, if the user is chatting to a friend or reading a book with the TV as background noise, we can let them aware that something has happened.

To begin with, when designing the screens for your application it’s important to ensure that all interfaces have a landscape orientation. We should also be sure to create layouts that are easy to navigate using the focus based navigation. To do so, we can layout our content using rows, lists, grids and any other layout formats for collections of focusable content that are easy to navigate using the X and Y axis.

It’s good to avoid trying to re-use layouts used on phones and tablets, the TV is a completely different experience so it’s likely that these layouts won’t be appropriate. Other components from these platforms we should avoid are:

Toolbars and Actionbars are not components designed to be used with TV interfaces and shouldn’t be avoided. Other than not being suitable for TV, elements of these bars (such as an overflow menu) would be difficult to navigate

Components that are designed to have touch interaction (such as ViewPagers, ScrollViews) are not intended to be used on TV interfaces and should be avoided as they wouldn’t be easily navigable on screen

Any layouts that we do create should fill the entire screen - we should avoid showing previous views underneath transparent activities when designing layouts for TVs. Again, this point stems off of the fact that we’re now designing for TV and not mobile experiences.

Overscan is the areas of the TV display that are not always ‘safe’ to display content on without obscuring any content. We need to ensure that we account for overscan and that no text or components are in any way obscured by the edges of the TV screen.

We can account for this by adding a margin sized 5% of our screen size, this will help to avoid any content being obscured by overscan. As shown in the example above, a 1920 x 1080 screen would have a 27 px vertical margin and a 48 px horizontal margin.

Note: If using the leanback library, then overscan is automatically accounted for in the framework

When it comes to TV, we need to be aware that the rendering on screen can be pretty imprecise when we compare it to that on our mobile devices. This could be due to the TV settings, filters or any smoothing that may occur on the TV - these can all cause hue or brightness differences to be either undistinguishable or exaggerated on screen, it’s important to bear this in mind.

To help avoid any serious issues with colours we can take the following approaches:

Avoid large empty areas of pure white on the screen, this colour can appear very bright and isn’t a nice view on a large screen. The same applies to any areas where highly saturated colours fill large parts of the screen

Very dark colours should also be avoided as contrast settings can cause these to appear almost unidentifiable to the user

Be sensible with the colours you choose. Using the recommended combination of primary, primary dark and accent colours can help to create a pleasing set of colours to display on screen

Note: When it comes to colours, I tend to use both material palette and coolers for some great inspiration.

Whilst textual content should be kept to a minimum when designing our TV applications, that doesn’t mean we shouldn’t be using any text at all. In cases where we will be using text, there’s some pointers we can use to ensure that the text we do display is both readable and navigable from the viewing distance of the TV in use. Here are some recommended fonts and sizes to use for typography in your application:

Note: Because Android runs on a wide range of manufacturer devices, we have to bear in mind that these all have different ways of displaying content in terms of contrast, sharpness and colour. Because of this, we should avoid using thin and/or light font faces as this can make our content difficult to read.

As we’ve previously mentioned, text within TV apps should be kept to an absolute minimum when possible. Most users are going to be sitting from a distance that makes it difficult to read text, this behaviour isn’t expected when watching TV anyway! However, when we do need to use text:

We should break the text into small sections so that the text can be easily scanned. Use iconography where possible to aid this behaviour.

Choose the text and background colours carefully. Light text on a darker background is much easier to read on a TV than dark text on a light background.

San-Serif fonts can help to improve the readability of text on the screen - light fonts and fonts that use narrow or broad strokes should be avoided as they will have a negative affect on readability.

If we’re going to be displaying any web content in our applications, we need to ensure that we make use of the standard WebView component provided by the Android framework. There is no web browser on the android TV, so we shouldn’t be trying to launch an browser intent at any point in our application.

For example, we can use the WebView component to allow users to authenticate access from third-party applications such as Facebook or Twitter.

Be creative! On the TV we have access to location services - for apps that make use of the users locations (such as nearby events, train stations or any other location based data), this could be great for allowing users to interact with your services from the comfort of their arm chair. The possibilities are endless!

And that’s all for now!

I hope this summary has been an educational read for now, I’ll be adding to this list as I learn more about crafting for the platform. I’d love to hear of any TV projects you’re working on or any of your own advice for building apps for Android TV ! But please, feel free to drop me a tweet to share any of your own experiences!