Best Practices for User Interfaces

1 Read the UI guidelines

Android is an open platform. As such, you have complete freedom to create innovative applications any way you choose. However, realize that consistency between your application and the Android platform creates comfortable, predictable experiences that help users.

Google has published User Interface Guidelines for icons, widgets, activities, and menus, and more guidelines may follow. Read and understand the guidelines. You'll especially want to follow the guidelines for icons that appear on the application launcher and widgets that appear on the home screen.

2 Understand and design for touch mode

All Android devices have touch screens, and touch mode is one of the most important principles of the Android UI framework. In general, touch mode has no focus and no selection, and moving betwen touch and other modes can make focus and selection disappear or reappear. The exception is a special situation called focusable in touch mode. Romain Guy (Google Android engineer) describes how to handle these in his blog post Touch Mode. 

In addition, make sure that buttons and UI widgets are large enough for a touch interface. Nothing is more frustrating to a user than touching a widget, only to find that they actually touched the one next to it! Be sure that the buttons display well on screens with different resolutions and densities (see Use layouts that adapt to multiple devices).

These buttons are sized well for touch.

3 But, support multiple interaction modes

In addition to handling touch mode, your user interface needs to accept physical input methods. Depending on the device, physical modes can include a keyboard, 5-way navigation pad, trackball, stylus, or other inputs. However, you are probably designing an application for multiple devices, without knowing in advance all the features the devices have.

TAT (short for The Astonishing Tribe), the company that did the early interaction design of the Androd platform, says:

In general, designing an application for Android means designing without knowing what the configuration for the device will be or even knowing which device. Thus, an application needs to support user behavior, assumptions and interactions for both touch and non-touch devices.

You should be able to get information about a specific device configuration either by querying device APIs, using the device itself, or checking the device manufacturer's specification. The question you need to answer is whether your should support all input methods or just a subset. Give this careful consideration when you design and prototype your user interface. Testing and user feedback might be very helpful here.

In Android 1.5, your application also needs to handle onscreen input from a soft keyboard, which appears when a user taps a text entry widget.

To learn how to handle onscreen keyboard input, see Updating Applications for On-screen Input Methods (Dianne Hackborn, Google).

4 Use notifications and the window shade

Notifications send messages that are always visible but non-intrusive. If you're not familiar with notifications, they're in the status bar, at the upper left. Users can pull down the window shade (by touching and dragging a notification) to see all the available notifications and act on them. This video from Chris Nesladek at Google shows a good example.

Even more, because Android is a multi-tasking platform, a user can be in the middle of one task—say, reading a Google Map—and quickly switch into another, such as reading an instant message or opening a browser. This video, also of Chris Nesladek, shows another example of notifications (around 4:55):

5 Support interaction between applications

Developing in Android, as Google says, is fundamentally different than on other platforms. Android allows applications to share both functionality and data—functionality using intents and data using content providers.

Applications are easier to develop because you can build on work others have done to combine features in exciting new ways. This video, Apps Without Borders, shows how developers can share application functionality:

Of course, this means that you must think differently about designing your user interface. Rather than a linear flow, think of your UI as a stream in which users work in your application, then flow out to another application, then another, then back through the stack to your application.

Chris Nesladek, once again, has a good explanation of this (around 10:00):

6 Keep your UI fast and responsive

Mobile devices have far less memory and processor power than desktop computers. You want to keep your Android UI fast and efficient because users work with your application on the go, holding the device with one hand and sometimes navigating with one finger, while juggling many items, running for the subway, and moving in and out of network areas.

If your application does not respond to a user action within 5 seconds, Android displays the Application Unresponsive dialog, which you never want a user to see. However, users will notice a delay of even half a second.

One of the best techniques for keeping your user interface responsive is to watch threading. When a user starts an Android application, Android creates a thread called the main thread or the UI thread. Do not do long processing on the UI thread, which dispatches events to widgets.

In Android 1.5, thread handling has been simplified with the AsyncTask class. Romain Guy of Google explains how to use threading for best UI performance in Painless threading. He also offers many other tips for optimizing UIs in this video:

7 Use widgets and live folders

Widgets and live folders are both displayed on the home screen. Widgets show small tidbits of interesting data, such as the current weather in Paris, that are glimpses into full-featured applications. On this home screen, you can see the Word of the Day widget provided by the Wiktionary application.

Live folders show data provided by an application on the device, such as a list of names with phone numbers, bookmarks, or playlists. The user sees any updates that occur, in the live folder, right away. Here you can see the Phones and Live Contacts live folders.

Widgets and live folders are interesting, fun, and available on the home screeen, so consider adding them to your application. LIve folders display as one of the standard folder icons Google provides. However, widgets offer tremendous design opportunity (read the Widget Design Guidelines first).

8 Handle screen orientation changes

Most Android 1.5 devices allow applications to change screen orientation, from portrait to landscape and back. The behavior varies by device, but many have a setting that allows users to choose whether applications automatically rotate when the user turns the device.

Applications can override the user's setting, to always rotate with the device or remain in one orientation. Even more, if the device has a physical keyboard, applications can also change orientation when the physical keyboard is opened or closed.

This means that your user interface must be prepared for an orientation change, unless your application is designed to always display in portrait or landscape.

In the user interface, the orientation change is handled in layouts, either XML or Java. In many cases, you'll need to design separate layouts for portrait and landscape modes. The Amazon MP3 application is a good example of separate layouts.

Chris Nesladek of Google points out in the video Pixel Perfect Code (around 16:15) that the four buttons are arranged so they are easily visible without scrolling, in both display modes.

9 Use images wisely

Images are one of the most important elements in your user interface. An Android application can use many types of images, but here we'll focus on icons and buttons. (If you want to know more about images used as window backgrounds, read Optimize Window Backgrounds, a few tips collected by us here at MOTODEV.)

Google has published Icon Design Guidelines to help you keep icons consistent with the Android platform. The guidelines cover icons in the application launcher, menus, tabs, dialogs, list views, and the status bar. It's especially important to keep your application launcher icon consistent. The video tutorial Creating an Android Application Icon by Gary Simon is a great introduction to how to create an icon that follows the Icon Design Guidelines.

The other type of image you're likely to use is a custom button. Be sure to use a NinePatch image created with the Draw 9-Patch tool. A NinePatch image has stretchable sections that are resized at display time to handle items with variable sizes. An example is a button with a label that must stretch to accommodate various lengths. The video tutorial Buttons with (nicely) stretched backgrounds explains more about using Draw 9-Patch to create buttons.

You can also use button images that Google provides in android.jar. Tom Gersic describes this in Android: Custom Buttons (a great tutorial, but a bit out of date; the image file names he uses have been replaced with new ones in Android 1.5). Most buttons need three states—normal, focused, and pressed—each with its own NinePatch file.

10 Use layouts that adapt to multiple devices

Many Android devices are being released this year. This means that your user interface layouts needs to adapt to screens of various physical sizes, densities, and resolutions. As far as possible, try to develop your layouts so they adapt to multiple devices.

This image (from the Google I/O 2009 session Supporting Multiple Devices with One Binary) shows what happens if you try to use an absolute layout on devices with different screen resolutions:

Yikes! To correct the shrinking effect:

• Don't use AbsoluteLayout. Choose a layout that adapts, like LinearLayout or RelativeLayout.
• Develop your own custom View or ViewGroup in Java, if needed.
• Use density-independent pixels, which define pixels so they scale across screens with different densities.

First, read Declaring Layout and Available Resource Types in the Google Android documentation.Then, follow the practices Joe Onorato and Romain Guy of Google describe in the Google I/O session: