Designing and Implementing Android UIs for Phones and Tablets

Google I/O 2011: Wednesday, May 10, 4:15 - 5:15 Speakers Roman Nurik, Adam Powell, Richard Fulcher, Christian Robertson, Matias Duarte

Summary There are a large number of Android tablet devices starting to ship. This session discusses the new APIs and tools available to developers for use in constructing apps that work well on them, and provides guidance on creating good user experience for users of these devices. Notes Agenda: intro to tablets honeycomb visual design UI patterns and features case study: the IO app DESIGN GOALS Its important to decide which things to start with. The Android teams ambitious goal was to advance how we use computers. Also focus on making the best tablet experience. Not just make phone UI bigger. This is just the beginning. The first of many steps for Android. We're making interfaces more tactile and immersive.

Christian comes to stage to talk about visual design for Honeycomb... Wanted to make a UI that makes the user powerful and in control. This requires the UI be dynamic. The visual language needs to move beyond static screens. UI is inspired by holographic displays that morph, look digital, and look like HUDs. Design goals: - Holo theme is flexible and dynamic. Slight blue outlines gives impression of them being digital. "Screens are screens" (not pretending to be something else). Elements can be realized as full three dimensional objects, yet they're still digital and magical. - Design should be simplified and open. Widgets are more flat and well-spaced. Structural boxes are removed, relying more on grids and metrics to define space for widgets. Lists and text boxes are open, instead of being bound by boxes. - Enable extensibility (get out of the way), so diverse apps can express their brands. First choose a dark or light Holo theme. When you override a theme, you must override ALL styles, so that you have a hard-defined theme for everything and things don't change from one device to another.

Developers should focus on promotional graphics. The quality of your icon and rendering is a really strong signal to users to the quality of your application.

Rich now on stage along with Adam Powell to talk about UI patterns and APIs... UI patterns are general solutions to a recurring problem. Not always perfect or restrictions, but guidelines. ACTION BAR: We talked about this last year, in the context of the phone. It's caught on for phones, but we've enhanced what it can do for tablets. It's a replacement for the title bar, presents frequently accessed actions, and access to different views (tabs). It has three key areas: 1. App icon. ("where am I?") Can also be a logo or other branding. Gives a sense of place. Supports "upward" nagivation when there's a back arrow. It moves you up the activity hierarchy. 2. View details. ("what can i see?") Use for non-interactive title bar replacement (for activity title), or for rich navigation such as tabs, drop-down, or breadcrumbs. 3. Action buttons. ("what can i do?") Important actions for the user. Can be text and/or icons. Most important ones should be toward left (come first). Also has overflow menu. Action bar also supports contextual mode. Action bar transformed when items in the activity are selected. Action bar lets you control the lifecycle of the action mode (such as contextual action bar). Adam... When you want to perform an action on multiple items, the contextual action bar is your solution. By implementing the ActionBar using honeycomb APIs, things are consistent and the system handles several performance issues for you. When implementing the action bar on honeycomb, you get the action bar for free. The action items are there for free from the Options Menu items. You can customize the ActionBar class to customize the action bar. You can get an instance of the ActionBar, add items and modify it. When going to phones, some of the ActionBar patterns break down, due to screen real estate. Using the ActionBar APIs will help your app adapt to this.

MULTI-PANE LAYOUTS On a tablet, you want to take advantage of all the space. Get rid of line lengths that stretch the whole screen. Multi-pane layouts allow you to resolve than. Panes should represent content in an ordered manner, from left-to-right... content becomes more detailed. Rule is to maintain functional parity in all screen orientations. We have a few strategies to solve this. You can use all or some. You can either: stretch, stack, expand/collapse, or show/ hide different Ui panes, depending on the screen orientation. Some figures demonstrate these

designs. Implementation should be done with Fragments. A fragment is "a fragment of an actiivty". It's a unit that can be reused across activities. It's something smaller than an activity that shares lifecycle patterns, but is focused on a sub-layout that's separated in your codebase. To use fragments for older devices (down to 1.6), you can use the fragment compatibility library. http://j.mp/fragments-for-all Most of the heavy lifting for screen compatibility is done by the resources system. For example, using different bitmaps for different densities. You can also provide different layouts for different screen sizes. In these layouts, you can embed different fragment configurations (using the <fragment> element). Code demo for how to use different layouts with fragments for different screen orientations.

APP NAVIGATION This has been a dramatic change in honeycomb. There are more ways users can deep dive into an app. Richer notifications, richer home screen widgets, and recent apps. Traditionally, users navigate based on "what just happened" (temporal memory), but not usually remembering what the sequence of what happened. Users are good at structural memory. They remember relationships between screens in an app. To address both, the system now supports navigation UP in addition to BACK. Sometimes they do the same thing. Visual example for how BACK works the same as UP, followed by an example of how it might be different. When user enter Gmail from another app. What we want you to do: Support up if you use the action bar. If you have deep links, make sure the BACK behavior works as expected. To support this, startActivities allows you to reconstruct a back stack.

BEYOND THE LIST There are several different ways to provide users a list. Doesn't have to be a vertical list. To implement these, you should be creative. CarouselView. It's not in the framework, but will be open sourced. Uses renderscript. FragmentPager and Workspace for showing open item or one page at a time. You should not use Gallery widget for this kind of stuff---it's for picking small image items.

Roman Nurik to demo IO app. Starts with tablet app. Describes the different fragments used in each activity. The calendar also uses the Workspace library to swipe between calendar days. On the phone, the home page is just the dashboard, not two fragments. For the action bar, it's custom, because ActionBar apis are not available. The fragments used for phone activities are

the same as the fragments on the tablet. It's a single APK (binary) for phones and tablets. Uses different resource qualifiers for different screen configurations. -xlarge-v11 to ensure that the designs are only for honeycomb tablets. Uses the fragment compatibility library. Some activities are specific for phones or tablets, but they're mostly just shells for the fragments. Roman shows some code for controlling the action bar, to show action items. Tab images are also customized for different platform versions. You don't always have to tweak the entire layout. Instead, you can define different dimensions for different configurations (place the dimension names in the layout and the system loads the appropriate dimensions for that config).

Q and A Will workspace be pacakaged for us? It's in the IO app, but we'll try to offer them elsewhere soon. REdsigning my app. Everything in Honeycomb is the direction for the future. Layout tools? See the Developer Tools talk later. Why use multiple activities instead of just swapping fragments? Both can work, but activities are easier for intents and the back stack. If the user uses a system feature widget, notification, reconstruct the back stack. If they came from another app, probably not. Action Bar for compatibility library? We'll consider it. When will anti-alias support arrive in 2D canvas? We're working on it.