Think on Android TV Designing for better user acquisition

Material is the core approach when we’re designing for our mobile devices and the same applies to how we should take on the TV. Not only does this provide a sense of familiarity and consistency across our applications on different platforms, but this visual language provides an enjoyable and functional experience for our users. Oh, and it also looks great too.

Building on material design allows us to persist the same look and feel across the different platforms that our application is available on.

The design approach across platforms should be consistent with their approach to material design

Unlike other devices we currently use, the TV is not a mobile device – so be sure to remember this when creating for the platform. Content should be your central focus when designing for TV, allow the user to kick back and consume media rather than having to read textual information on screen. And when this media is available, our users also want to be able to access it quickly and easily, meaning it should be no more than a click or two away at any time.

The TV was built for this. Embrace the use of visual imagery and engaging sound, this helps to provide a cinematic experience when using your TV application – after all, this is what the TV was made for! We can achieve this by keeping our User Interface design to a minimum and avoiding the use of text where possible, instead conveying this information with the use of visual delights where possible. It’s all about the viewing.

Like all applications we create, strive to keep it simple. As a user, I want to take the minimal steps possible to get from one stage to another — even more so on a TV where I just want to sit down and watch something without having to perform numerous actions to begin consuming content. We can keep our application simple by:

• Keeping the number of control interactions required to reach a goal to a minimum helps to remove the number of steps in which the user needs to take in order to complete the desired action. This can be achieved by removing any unnecessary navigation steps and user obstructions from the flow at any point where it is not necessary.
• Keeping the UI design to a minimum obviously helps to simplify things. Have a reduced UI reduces the cognitive load on the user, allowing them to make simpler decisions when navigating through your application
• Keeping the textual content your application uses to a minimum helps to cause less distraction while the user is navigation and browsing through content. It’s both quicker and easier to view visual information than reading a paragraph of text displayed on the screen, therefore it’s best to make use of visual components where possible

Users navigate through content on the TV system using a 5-way D-pad controller. This consists of both 4 directional buttons and a central select button, the user also has access to a back and home button on their remote. These controls restrict the user to navigating left, up, right and down through content and back through their flow of navigation. You can account for these constraints by laying out content in lists and grids, providing clear paths on both X and Y axis for the user to easily navigate through.

Android TV uses focus based navigation to allow the user to navigate through the components on the screen. As the user works their way through the content, items become focused on screen – at this point, the user can use the select button to choose the currently selected item. This approach makes it extremely easy to reach the different components on the screen using the provided controls.

To help the user when navigating through these elements, the currently focused item should clearly show its focused state. Every item on screen should have a focused state, this means that there will always be an easy visible focused item – allowing the user to easily find their position on screen. Showing these focused items could be achieved by:

• Scaling the focused item to make it appear larger in size
• Changing the brightness of the item shadow to make it more visible
• Change the opacity of the item, applying transparency to less dominant items and bringing attention to the focused item
• Perform some form of animation on the focused item to show it’s being interacted with

It’s important to ensure that there is always an object on screen which is clearly in focus, this helps to aid navigation when using a D-pad controller. We can use the points above to ensure that this object is clearly indicated.

Note: Android TV applications do not use toolbars and/or overflow menus and it is recommended to not use these in your application. Design for efficiency and make use of the provided components for Android TV and the above becomes redundant anyway!

Because the user has access to different types of controllers for navigation, we should ensure that we support the relevant key codes used by any non-standard input controller for interacting with our application.

Android TV is also compatible with gamepad controllers, giving the user access to several more buttons to perform interactions with applications. If an application does use a game controller, then it should allow navigation functionality from standard controller keys found on the d-pad.

Note: In order to allow the use of gamepad as a primary controller, the application must specify this in the manifest file like so:

<uses-feature android:name="android.hardware.gamepad" android:required="false"/>

We should provide flexible methods data input for our application, with an important method being voice input. Whilst Android TV has a software keyboard that allows textual input via an on-screen keyboard, it can be tiresome when using a d-pad controller (this is slightly easier when using a gamepad). Because of this, voice input is essential to reduce friction.

Note: When it comes to searching for content, the Leanback library provides a Search Fragment that implements all of this for us already. However, if you’re not using this approach then it’s important that you implement voice input into your user input flow.

One other option here is to delegate user input to a mobile device – this is where you allow the user to input textual information into the TV system using their mobile device. To do this, your application could detect a nearby device (possibly using the WiFi network the TV is connected to) and display an option to input text by launching the application to allow user input via the users mobile device.

To boost engagement with our application and aid the users attention, we should be sure to include dynamic features for our application. Most importantly, the content displayed in our application should be dynamic as like any application, the user will get bored if we’re not feeding them new and exciting content to consume frequently. For example, a media based application should load the latest content when the user opens our app rather than recycling previously used content.

Like mobile applications, we should supporting pagination in our applications. Our lists and grids of content should load more content as we reach the last displayed item, allowing the user to continuously consume content as they desire. For some reason a very small amount of Android TV applications are currently doing this – it’s found on mobile so we should take the same approach here.

Google provides what’s known as the Leanback library, this provides a set of fragments and components that implement a lot of the standard functionality required for a building TV applications. These include screens such as the BrowseFragment, SearchFragment, VerticalGridFragment, DetailsFragment, ErrorFragment and GuidedStepFragment.

GuidedStepFragment, VerticalGridFragment and SearchFragment

PlaybackOverlayFragment and BrowseFragment

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:

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.

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.

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!

source – https://medium.com/exploring-android/designing-for-android-tv-9fecd5cd0c8c