1. The 10ft Environment
2. TV Displays
3. Sound and the UI
4. Navigation Design
5. User Interface Design
6. UI Zones and Patterns
7. UI Performance
8. Additional Tips

This is a guide to developing user interfaces for Android applications running on Google TV. Although there are few internal differences between an Android application for a phone and one for Google TV, there are differences in the user interface.

The viewing environment of a television is commonly referred to as the ten foot (10ft) environment and the television screen as the 10ft UI. When you create apps for the 10ft environment, remember these basic concepts:

• The 10ft environment is traditionally for consuming content.
  • The 10ft environment is a fun environment, not a work environment.
  • The 10ft environment is usually a social environment, not a single-user environment.
• The viewing experience for a 10ft UI is a mix of computer and TV.
  • TV screens have both computer-like and TV-like characteristics
  • Display resolution is computer-like, but is affected by TV characteristics.
  • Color is different on TV screens.
• TVs have high-quality sound.
  • TVs are usually connected to the best sound system.
  • Unlike computers, users expect sound from a TV and don't find it disruptive.
• The 10ft UI requires simple and visible navigation tools.
  • Set up navigation to progress from left to right and top to bottom.
  • Limit the need for a mouse.
  • Provide visual feedback.
• The 10ft UI works best with well-established UI patterns based on content zones.
  • Zones themselves are independent of device types.
  • The arrangement of zones are particular to device types.
  • Many different UIs can be based on the zone concept.

Read about each of these concepts (and more) in the following sections.

The 10ft Environment

When you create Android applications for the 10ft environment you should remember some basic ideas that differentiate this environment from computers or mobile devices.

The most fundamental idea is that the television has traditionally been for consuming content. It has a long history as a passive system for broadly sending information to people; that is, it's a broadcast system. Google TV changes television from a broadcast to a interactive two-way system, and this is a big change for many viewers. Changes like this can be tough for older viewers, especially those who classify themselves as "computer illiterate". On the other hand, younger viewers who have grown up with the Internet have little difficulty with the change, and may even be eager to accept it.

The idea that TV is fundamentally passive is part of what is commonly called the "lean-back" experience. Even viewers who are willing to interact with their TV don't want to work too hard during the interaction; they want to lean back and enjoy themselves. They don't want the highly-involved experience of computers or smart phones.

In addition, Google TV is aimed at enhancing the traditional relaxed, group, shared experience of TV viewing. You'll be able to differentiate your application from other systems that display on TV screens by working with this more traditional approach.

TV Displays

When you're designing your application, remember that Google TV display is fundamentally different from that of a computer or mobile device. Despite its size, it displays less information overall than for a computer or mobile UI. You'll need to provide less UI, and you may want to automate some tasks instead of asking for user interaction.

Here are some guidelines for your UI design:

1. Use a mobile phone as the model for the UI.

   A modern TV's size is deceptive. Even though modern TVs are usually larger than 40" diagonally, viewers sit proportionally farther from them than from a computer monitor, The viewer's perception is that the TV is smaller than a monitor. To simulate this experience, use a mobile phone as your "model" when you design your UI.

2. To avoid a cluttered appearance on the screen, provide more blank space between elements on the page.

   To do this, use a combination of larger margins and more padding. This is good advice for "touch" UIs as well.

3. TVs are always in "landscape".

   On a TV, available space runs left-to-right rather than top-to-bottom. Put on-screen navigational controls on the left or right side of the screen and save vertical space for content.

High-Definition Display Resolutions

TVs are fundamentally different from computer monitors or mobile device screens. Monitors and mobile screens use (in essence) directly addressable pixels. TVs, in contrast, use a system based on the decades-old analog method of displaying a picture. Knowing the difference is important in working with Google TV.

Computer and mobile device display resolution

A computer monitor has a maximum display resolution that is usually less than or equal to the resolution of the graphics card; it's the graphics card that determines the maximum resolution and the monitor that determines the number of pixels per inch (the pixel density). A mobile device's resolution and pixel density are usually fixed.

Since display resolution for computers is simple, computer operating systems handle resolution and pixel density issues automatically, based on the user's resolution preferences.

Android is designed to handle many types of mobile devices with the same application. To do this, Android scales the UI based on a device's screen size and pixel density. In addition, you can provide alternative resources for your UI to provide the best UI experience for different devices.

TV display resolution

TVs (even the most modern ones) have a display resolution based on scan lines. There are three scan line values available for the HD TV displays supported by Google TV: 720p, 1080i, and 1080p, which stand for 720 progressive scan lines, 1080 interlaced scan lines, and 1080 progressive scan lines (the last two are equivalent to Android). The 720 value means that the TV can "address" 720 distinct lines from the top to the bottom of the screen; 1080 means that the TV addresses 1080 lines from top to bottom.

The horizontal resolution is derived from the TV's aspect ratio. Nearly all TVs now use an aspect ratio of 16:9 (16 horizontal pixels for every 9 vertical ones), so the resulting display resolution for a TV set to 1080 is 1920 x 1080.

How "tall" the lines are, and how "wide" each line is (the actual pixel density) for TVs varies by manufacturer, but Android abstracts the values to a density-independent pixel measurement (abbreviated dp).

Google TV Android applications benefit from Android's scaling technology. In general, you should design your UI for 1080p, and then allow Android to scale your UI down to handle 720p, since downscaling (removing information) is usually better than upscaling (interpolating information). To get the best scaling results for images, provide them as 9-patch image elements if possible. The scaling settings that Android uses for Google TV are listed in table 1.

Table 1. Settings used by Android for Google TV UIs

• Addressable screen size is the number of pixels visible.
• The density identifier is the Android identifier for the number of density-independent pixels (dp). This is described in the section "Alternative resources" in the topic Designing and Developing. You can also read more about alternative resources in the topic Supporting Multiple Screens in the Android Developers Guide.
• To determine the screen size and resolution for the current display, use the dpi and screen resolution from the DisplayMetrics object.

To learn more about display resolution and Google TV, please read the topic Display Guidelines in the Google TV Android Developer's Guide.

Overscan

An additional complication is overscan. For historical reasons, TV manufacturers must set aside margins along the outside of the normal screen size that are addressable by the circuitry but are not used to display the TV signal. These margins are the overscan area (or simply "overscan"). Android applications can't display in the overscan.

Unfortunately, the amount of overscan varies by manufacturer, so the margin around your UI also varies. If you design your UI for a TV that has significant overscan, you may inadvertently use the overscan as a margin between your UI and the TV's bezel. If you then run your application on a TV with almost no overscan, the UI will have almost no margin, and its elements may be hard to read.

To handle this, provide an extra 10% margin for your UI, and use a Layout that does not use absolute positioning. The diagram in figure 1 demonstrates this.

Figure 1. Screen resolutions and dimensions

Color

TV screens have higher contrast and saturation levels than computer monitors. To account for this, follow these guidelines when working with solid colors:

1. Use pure white (#FFFFFF) sparingly. Pure whites cause vibrancy or image ghosting in TV displays. Instead use #F1F1F1 (hex) or 240/240/240 (RGB).
2. Avoid bright whites, reds, and oranges, because they cause particularly bad distortion.
3. Be aware of various display modes that TVs may have, including Standard, Vivid, Cinema/Theater, Game, and so forth. Be sure to test your application in all these modes.
4. Avoid using large spanning gradients, because they may result in banding.
5. If possible, test your application on lower quality displays which may have poor gamma and color settings.

Text

For TV, avoid lightweight fonts or fonts that have both very narrow and very broad strokes. Use simple sans-serif fonts and use anti-aliasing to increase readability. Currently, Google TV only supports the Droid Sans and Droid Serif font families, but you can use font embedding to create a more customized appearance. However, remember that font embedding slows system performance.

Here are some ways to improve the readability of your text:

1. Limit each paragraph to no more than 90 words.
2. Break text into small chunks that users can quickly scan.
3. Keep line lengths around 5 to 7 words per line. Never go shorter than 3 or longer than 12.
4. Light text on a dark background is slightly easier to read on a TV, compared to dark text on a light background.
5. Use Android's standard font sizes. For example, the standard small font size is 14sp, which results in 28 point text on a 1080p screen.
6. Use larger vertical line spacing (more leading) for onscreen text than you would for print text.

Sound and the UI

The TV used with Google TV will often be connected to the best speakers in the household. Sound is not disruptive on TV, as it often is on a computer, so think of ways to use sound in your UI. Keep in mind:

1. Use sounds that are appropriate to a living room environment.
2. Default to a low volume.
3. Assume that your users will be watching TV or listening to music as they use your application. Provide a simple way to mute your application. Don't make interactions entirely dependent on audio cues, and use cues in moderation.
4. Android has the concept of Audio Focus, which allows applications to request exclusive access to playback of audio. So if you primary function of your application depends on Audio (e.g. media player) you should request exclusive Audio Focus, and if you application plays back media in a background service, you should implement an AudioFocusChangeListener and respect other applications requests for Audio Focus. More information can be found here.

Navigation Design

Google TV devices always include a keyboard and a pointing device that controls the cursor. Many users will have these next to them as they view TV. The two may be combined into a single physical device, and this device may also include a mouse controller. The keyboard is obviously provided for text input. The pointing device is a variation of a directional pad (D-pad) that a viewer uses to position the cursor or highlight a UI element. Additional buttons on the keyboard or pointing device (or both) may be provided for more traditional remote control functions such as controlling power, playback, and so forth. If a mouse controller is present, it controls a mouse pointer on the screen and provides buttons for "clicking" the UI under the mouse pointer. Remember again that TV is traditionally a broadcast rather than a conversational system. Your users may not have much practice using a D-pad or cursor. Even experienced computer users will find that using a mouse on a TV is difficult.

Here are some guidelines for designing UI navigation in Google TV Android apps:

1. Depend on D-pad navigation instead of mouse navigation. Users will probably be more familiar with this type of navigation from using it on a TV remote.
2. If you choose to use mouse navigation, use over-large selection surfaces for the mouse. Make clickable buttons big, so that users can easily position the mouser pointer over them.
3. Avoid complex or precise mouse navigation. Don't use drag-and-drop or drop-down menus. These are very hard to control in the TV environment.
4. Provide highly obvious UI feedback to navigation. Expand a selection surface when it receives focus, or highlight it. Use transitions and movements that provide visual cues for proceeding or reversing the action. For example, if the user selects an action that causes a new page to slide in from the right, they may intuitively understand that pressing D-Pad Left will return them to the previous page.

Your goal is to provide a navigation scheme in which the user can quickly learn to predict how to move.

Remember again, a TV is neither a computer nor a mobile device. It does not have a touchscreen, and its mouse (if it has one) is hard to control. To stimulate your thinking about TV navigation, try navigating in a computer application without using the mouse, or in an Android application running on the emulator. How intuitive were the interfaces? What would you do to make them better?

D-pad navigation

The D-pad controller limits movement to up, down, left, and right. Action under the cursor is triggered by an Enter or OK button in the center of the D-pad.

Users need D-pad interactions that are fast and easy. Remember that users are navigating at a distance, and perhaps in the dark!

When you design navigation for D-pad, follow these guidelines:

1. Ensure that the arrow keys can navigate to all the visible controls on the screen.
2. If you use an arrow key to scroll a list, ensure that users can select an element in the list and that the list still scrolls when an element is selected.
3. If there is multiple items to be selected in your application make sure it is always clear which item is currently selected.
4. Make sure you provide all "selected", "focused" and "selected AND focused" states for any D-pad navigable items in your applications UI. Learn More. List

To learn more about D-pad navigation, please read the topic UI Controls Guidelines in the Google TV Android Developers Guide.

Mouse navigation

On a TV screen, the mouse moves a pointer arrow that is small and distant. Mouse control is also difficult because the control itself is usually a pad or ball rather than a traditional mouse "puck". To assist your users with the mouse:

1. Enlarge each UI control that is a mouse pointer target (such as a link or button), and provide ample padding within the control.
2. Add a hover state to controls that changes their appearance when the mouse cursor is over them.
3. Use arrow indicators to make users aware that content is available off-screen. Use the arrows as controls that move to the off-screen content when clicked.

Navigation assistance

Navigation in a 10ft environment will be new to most of your users. Provide them with written help, using a dialog triggered by a help button or action bar icon. Some topics to cover are:

1. The D-pad arrow keys: Do they move between pages? Can they open context or navigation menus?
2. The Back button: Does it move to a previous page? Can it undo an action? Does it close a pop-up?
3. Media keys: What does play/pause do? What do skip forward and skip backward do?
4. Other keys: Are there keys for Cancel or for closing a pop-up? For example, does ESC close a pop-up dialog?

You may want to display the help dialog automatically when a user starts your application for the first time.

Vertical scrolling

Vertical page scrolling, while fundamental on a desktop browser, may not be as appealing on a TV. Scrolling may be jerky and slow, and important information may be hidden off-screen because users don't understand that the scrolling can continue.

Use horizontal layouts instead, and provide visual transitions between pages. If you use vertical scrolling, limit it to your detail area in the center of the page, while leaving your left navigation bar stationary. Besides keeping an understandable context, this will have better perceived performance.

Category navigation

For categories (items you would put in a menu or tabs), use the left side of the screen. On a TV, screen space is plentiful on the sides, but vertical space is precious. Try to keep the category selection on-screen at all times. You may have to reduce the number of categories to do this. If you are migrating an existing phone application to TV, consider reworking or at least testing complicated nested navigation that uses many subcategories.

Selection

On a TV, positioning the cursor for selection can be inexact. To help the user make selections, follow these guidelines:

1. Highlight selection controls when the selection pointer is over them (a "hover state").
2. Make selection controls large and provide extra padding around the text label.
3. Don't use inherently small controls such as "close" boxes in a window corner. These are either impossible to see or very difficult to select, or both.
4. Avoid using mouse clicks to close pop-up dialogs. For example, PC applications often close a dialog when the user clicks elsewhere; this is not obvious in the 10ft environment. Instead, provide an explicit control for closing the dialog, and ensure that D-pad navigation can access it.
5. Don't require the user to select the primary control to make it active. Make the primary or default control active (give it focus) and highlight it to indicate this.
6. If part of the window or dialog requires scrolling, give it focus or allow it to be scrolled without having focus. Requiring the user to click on an element before scrolling it is obtrusive.

Context, selection, and focus

The current state of an application includes a context, a selection, and a focus. The context is usually a set of categories, while the selection is the category the user has selected. The focus is control or element "under" the pointer. Each of these should have its own distinctive highlight, and the highlighting scheme should remain consistent across the application.

For example, if a user is looking at a screen full of movies, the application can provide a row of contextual tabs that offer different categories such as "All Movies", "New Releases", "Popular", "Editor's Picks", and so forth. If a user selects one of the tabs, the selected state of that tab should remain visually distinct from the moving focus state that indicates the current screen position for navigation, as demonstrated in figure 2:

Figure 2. Selection and focus

For a Google TV application, D-pad focus is equivalent to mouse hover state. It is the primary way that users see the application state, and it helps users predict how they should move the focus or make a selection.

Focus and focus prediction

Like hopping stones to cross a stream, a user must think about moving along UI elements that accept focus and avoiding those that can't. One way to help users in this task is to give distinctive visual treatments such as outline boxes to focusable elements (also demonstrated in figure 2). Distinguishing between focusable elements and those that can't get focus is one way you can help your user understand your UI. Another way to help users is to align elements to a grid (figure 3).

Figure 3. Grid pattern for UI navigation

A grid is the most obvious mapping to a D-pad's Up-Down-Left-Right controls. If you don't use a grid, then your elements could align diagonally or on different baselines or on different vertical centers. This either forces the user to switch repeatedly from up-down to left-right, or leaves the user confused about the proper move to make.

Some elements such as scrolling lists may defy exact grid alignment (see figure 4). In this case, you should try to make the default focus as close to a grid as possible.

Figure 4. Scrolling alignment and grid layout

Visual indicators

It's good practice to add indicators or highlights to selectable and navigable items in your UI. These are called affordances. Expecting users to "explore" the UI to find what is and is not selectable is not acceptable, nor is the assumption that your UI is "intuitive". You build user acceptance and loyalty with a UI that is carefully marked out and explained.

Transitions

Transitions in your application can either educate or confuse your user. Ensure that your transitions convey meaning rather than simply provide entertainment. Here are some guidelines:

1. Avoid reloading the entire page, because it causes the largest perceived latency.
2. For any action that affects only a Fragment, keep the transition entirely within the Fragment.
3. Make "progress" messages meaningful and specific. Animated images should indicate how much progress has been made, and how much work is left to do.
4. Don't show a "loading" animation for every element in a grid. Doing this for every item in a grid of 12 items results in a cluttered UI that users find hard to watch.

User Interface Design

When you design your UI, remember the following guidelines:

1. Keep the design consistent.
2. Keep element behavior consistent.
3. Keep all the important actions and options visible, including search, settings, back, and so forth. In the 10ft environment, elements that are not visible are forgotten, even if they're in an off-screen part of the UI or on the remote.

To assist you, Android offers a large set of standard UI controls and several ways of customizing them with a consistent theme.

UIs across devices

You have an Android application for mobile devices that you want to migrate to the 10ft environment. How do you convert a 1ft UI to a 10ft UI? Remember, above all, that bigger is not always better. Tablets are better than smart phones, and computers are better than tablets, but are TVs better than computers?

Figure 5: Comparative screen sizes

You may assume that the 42" screen is the most capable, but this is not the case. A smart phone usually has more processing power than a TV. The HD video and audio coming from a TV is pre-rendered, so all it needs is a high-bandwidth connection to the broadcast source. In other words, most of the processing for normal TV is done by the broadcaster, not by the TV set.

To accommodate this, write applications that minimize user interaction. The more your app does for the user, the better.

UI Zones and Patterns

The easiest way to make a good TV UI is to use a structure of zones and patterns. Together, they emphasize a clean and concise experience built from a visual "vocabulary" of UI elements.

Zones

Zones are a fundamental part of a Google TV UI for browsing content. Each zone corresponds to an Android Activity component. For Google TV, zones use a left-to-right hierarchy instead of the top-to-bottom hierarchy of phone and computer UIs. This reflects a TV's horizontal screen aspect as well as the need for simple navigation noted previously.

Figure 6. Application zones

A TV screen contains three zones (figure 6) that progress hierarchically from left to right. You can adjust their size to match your application needs, or you can simply use their default sizes.

Because the global zone persists throughout the life of the application, you should not allow it to take up too much screen space. In contrast, the detail zone contains the material that users want to see, so you should give it as much screen space as possible. Finally, make the contextual zone an intermediate size that best holds options for the current display without restricting the detail.

Zone example

Figure 7 is an example of a UI based on zones, and figure 8 shows the zones themselves.

Figure 7. Example application.

Global Zone

The global zone (area 1 in figure 8) is the leftmost on the screen. This zone holds all of the top-level "global" items in your application hierarchy. It provides gives quick access to operations that users might want to use from anywhere in your application. It also contains all the categories for your application and your application's logo. A selection in the global zone changes the content to the right of it in the either the contextual zone or the detail zone, depending on the depth of your hierarchy.

Figure 8. Zones in the example application

Contextual Zone

The contextual zone (area 2 in figure 8) is to the right of the global zone in cases where you want context-based details or options. In addition to the details that identify context, the contextual zone can contain sub-patterns such as pagination, menus, filters, and so forth that allow your users to take specific action at this intermediate level. This zone is optional.

Detail Zone

The detail zone (area 3 in figure 8) is rightmost. It is usually the largest zone, and displays your application's content. Like the contextual zone, the detail zone can contain different sub-patterns, including content shelves, episode browsers, lists, and so forth.

The following images show examples of zones and patterns for TVs, tablets, and phones:

Figure 9. TV Zones

Figure 10. TV Patterns

Figure 11. Tablet Zones

Figure 12. Tablet Patterns

Figure 13. Phone zones

Figure 14. Phone patterns

Patterns (Fragments)

Patterns are sub-structures of zones that containing UI controls and displays. Typically, you implement an individual pattern as an Android Fragment. Android provides UI layouts and widgets that help you implement many of the basic needs of applications. Figure 15 shows some patterns within the Google TV zone system:

Figure 15. Patterns and zones

The pattern templates provided by Android include left tabs, menus, lists, filters, paging, and so forth. Google TV patterns correspond directly to familiar patterns on other devices, so you can re-use them. If you have a list in a phone application, you can put the same list into an appropriate zone in your Google TV UI. This simplifies and speeds up porting your applications. Even better, Android defaults to scaling the pattern to the 10ft environment, and the pattern remains recognizable to users who are familiar with your application.

Basic Patterns

Content Shelf

Content Grid

Content List

Cascading Content List

Extended details

Sub-section tabs

Sorting and Filtering

You'll often want to provide ways for the user to sort and filter lists displayed in your UI. On a computer or touch screen, you usually provide these options in a drop-down menu at the top left hand side of the list, or on the left side of the screen. Remember the limitations of D-pad navigation as you review some ways to implement this UI in the 10ft environment.

In figure 16, the orange area marks the area within the pattern that controls sorting and filtering the list below it. Notice that in this minimized state, both the label and selected option are clearly communicated to the user.

Figure 16. Sort and filter pattern

When the user moves into the area, it expands (figure 17) to expose all the available options, and it also displays the option that is currently selected.

Figure 17. Sort and filter pattern, expanded.

You may need more than one list of options if your list contains both sort and filter options. Figure 18 and figure 19 show the multiple option version of the sort and filter pattern in both its minimized and expanded states.

Figure 18. Multiple option lists, minimized.

Figure 19. Multiple option lists, expanded.

Notice that the expanded view demonstrates various ways to make selections and highlight them.

The options under A have bold text if they are selected. Under B, the text All Options is displayed if all options are selected. C uses check boxes to indicate which options are selected. D shows the result if no options are selected.

If possible, you should update the list as users select options. This provides useful feedback to the user, and makes the application appear more responsive. It also eliminates the need for a specific "Apply Filters" button and full screen refresh. Remember that as the user navigates backwards to the left bar or navigates down to the list, you should minimize the options once again, and display the currently selected options.

D-pad interaction traps

The D-pad navigation's interaction with these UI patterns further emphasizes the benefit of a left-to-right hierarchy. In the preferred example (figure 20) in green, the three zones provide a global, list, and confirmation context. As the user narrows a selection from category to item to confirmation, they move left to right. Any inter-zone navigation is confined to up and down. This makes it easy to select an item from a long list and then confirm the selection.

Figure 20. A desirable zone and pattern organization.

In the undesirable red example (figure 21), the hierarchy is the same but it's laid out vertically. Users navigate up and down to move from zone to zone. Intra-zone navigation is inconsistent; in the top and bottom zones navigation within the zone is left to right, but within the center zone navigation is up and down.

On a touchscreen device, this layout is relatively easy to handle, because users can skip between zones by picking up their finger. However, on a D-pad device, users can't skip zones. If users want to move from the global zone at the top to the confirmation buttons at the bottom, they must scroll through every item in the list in the center zone. This is a tremendous burden if the list contains 50 items! Using a left to right hierarchy prevents this trap.

Figure 21. Undesirable zone and pattern layout.

UI Performance

Studies overwhelming show that users prefer fast applications, so you should balance visual appeal with fast performance. Also, TV devices vary considerably in their power, so they may not render as quickly as your workstation. Before you use a large number of complex animations for your application, consider and test the impact on user satisfaction.

Users are the ultimate judges of whether your application performs well.

As you develop your application, try measuring your application performance in terms of how long certain operations take or how many instances of objects are created using Android's testing tools. Remember, though, that these metrics aren't important to end users, who judge performance by different criteria.

For example, users may judge your application based on how quickly and smoothly it operates, and how quickly it responds to input. They may not like your application if it slows down the rest of Google TV. These reactions are the users' perceived performance of your application, and perceived performance is the most important metric.

The way to achieve the best perceived performance isn't always the same as the way to get the absolute fastest performance. Make sure your application never executes so much code that the runtime isn't able to frequently update the screen and gather user input. In some cases, achieving this balance involves dividing up a program task into parts so that at runtime the screen can update between parts.

Here are some performance questions you can ask:

1. Does your application start immediately?
2. Are your application's animations smooth or choppy?
3. Does video content look smooth or choppy?
4. Do audio clips play continuously, or do they pause and resume?
5. Do windows flicker or turn blank while a long operation is running?
6. When you type text into the application, does the text input keep up, or does it lag behind?
7. If you click in the UI is the response immediate, or is there a delay?
8. Do other applications respond poorly when your application is running?

Additional Tips

Successful TV UIs are simple in both concept and design. Remember these tips for producing a UI that is easy to understand and use:

• Identify the vital parts of your interface before you start work.
  • Group your content, controls, and interactions by priority.
  • Discard anything non-essential elements.
• Use one visible mode of navigation or one information hierarchy.
  • Guide users to a mental "model" that works for all of your UI.
  • Rely on habits that your users have picked up from browsers or apps.
• Make the primary action reachable in one click.
  • Make the other onscreen actions prominent. Don't hide key features in a menu.
  • Use only a few key features.
  • Always display an easy way for users to return to their previous location. Don't rely on the back button.
• Anticipate and select the user's next action when you can.
  • For instance, move the insertion point into the next text box, or select the first item in a list.
• Avoid the temptation to use abstract icons.
  • Use short, clear labels and test them with users.
• Limit vertical scrolling.
  • Think about how your content will scale when it increases in size. What if a list becomes ten times longer?
  • If you must scroll, make sure a portion of the lowest section is always visible on the screen.
• Use app widgets.
  • App widgets are a limited set of app features that users can link to from the Home screen.
  • Use them for information shortcuts. For example, use a clock widget to display the time.
  • The Android Developers Guide describes app widget design and coding.
• Use Android's icon guidelines.
  • Icons help guide your users through UI.
  • Android's icon guidelines help ensure your UI will work today and in the future.
  • You can customize any part of your app, including the icons, but custom work may not appear the same in future Android releases.
  • Refer to the Android Developers Guide for more information about icons.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies.