Brandon Nolte, profile picture
Uploaded byBrandon Nolte
6,199 views

Android Design Guidelines 4.0

The document outlines Android design principles, emphasizing the importance of aesthetics, simplicity, and user empowerment in app development. It introduces key elements of the user interface, including home screens, notifications, and various UI components, as well as design metrics like typography, color, and iconography. The document ultimately aims to guide developers in creating visually appealing and functional applications that enhance user experience across diverse devices.

Embed presentation

Downloaded 570 times
1 / 142
2 / 142
3 / 142
4 / 142
5 / 142
6 / 142
Most read
7 / 142
8 / 142
9 / 142
10 / 142
Most read
11 / 142
12 / 142
13 / 142
14 / 142
15 / 142
16 / 142
17 / 142
18 / 142
19 / 142
20 / 142
21 / 142
Most read
22 / 142
23 / 142
24 / 142
25 / 142
26 / 142
27 / 142
28 / 142
29 / 142
30 / 142
31 / 142
32 / 142
33 / 142
34 / 142
35 / 142
36 / 142
37 / 142
38 / 142
39 / 142
40 / 142
41 / 142
42 / 142
43 / 142
44 / 142
45 / 142
46 / 142
47 / 142
48 / 142
49 / 142
50 / 142
51 / 142
52 / 142
53 / 142
54 / 142
55 / 142
56 / 142
57 / 142
58 / 142
59 / 142
60 / 142
61 / 142
62 / 142
63 / 142
64 / 142
65 / 142
66 / 142
67 / 142
68 / 142
69 / 142
70 / 142
71 / 142
72 / 142
73 / 142
74 / 142
75 / 142
76 / 142
77 / 142
78 / 142
79 / 142
80 / 142
81 / 142
82 / 142
83 / 142
84 / 142
85 / 142
86 / 142
87 / 142
88 / 142
89 / 142
90 / 142
91 / 142
92 / 142
93 / 142
94 / 142
95 / 142
96 / 142
97 / 142
98 / 142
99 / 142
100 / 142
101 / 142
102 / 142
103 / 142
104 / 142
105 / 142
106 / 142
107 / 142
108 / 142
109 / 142
110 / 142
111 / 142
112 / 142
113 / 142
114 / 142
115 / 142
116 / 142
117 / 142
118 / 142
119 / 142
120 / 142
121 / 142
122 / 142
123 / 142
124 / 142
125 / 142
126 / 142
127 / 142
128 / 142
129 / 142
130 / 142
131 / 142
132 / 142
133 / 142
134 / 142
135 / 142
136 / 142
137 / 142
138 / 142
139 / 142
140 / 142
141 / 142
142 / 142
Android Design
Table of Contents I. Getting Started 1) Creative Vision 2) Design Principles 3) UI Overview II. Style 1) Devices and Displays 2) Themes 3) Touch Feedback 4) Metrics and Grids 5) Typography 6) Color 7) Iconography 8) Writing Style III. Patterns 1) New in Android 4.0 2) Gestures 3) App Structure 4) Navigation 5) Action Bar 6) Multi-pane Layouts 7) Swipe Views 8) Selection 9) Notifications 10) Settings 11) Compatibility 12) Pure Android IV. Building Blocks 1) Tabs 2) Lists 3) Grid Lists 4) Scrolling 5) Spinners 6) Buttons 7) Text Fields 8) Seek Bars 9) Progress & Activity 10) Switches 11) Dialog 12) Pickers
I. Getting Started 1) Creative Vision Ice Cream Sandwich (Android 4.0) marks a major milestone for Android design. We touched nearly every pixel of the system as we expanded the new design approaches introduced in Honeycomb tablets to all types of mobile devices. Starting with the most basic elements, we introduced a new font, Roboto, designed for high-resolution displays. Other big changes include framework-level action bars on phones and support for new phones without physical buttons. We focused the design work with three overarching goals for our core apps and the system at large. As you design apps to work with Android, consider these goals: Enchant me Beauty is more than skin deep. Android apps are sleek and aesthetically pleasing on multiple levels. Transitions are fast and clear; layout and typography are crisp and meaningful. App icons are works of art in their own right. Just like a well-made tool, your app should strive to combine beauty, simplicity and purpose to create a magical experience that is effortless and powerful. Simplify my life Android apps make life easier and are easy to understand. When people use your app for the first time, they should intuitively grasp the most important features. The design work doesn't stop at the
first use, though. Android apps remove ongoing chores like file management and syncing. Simple tasks never require complex procedures, and complex tasks are tailored to the human hand and mind. People of all ages and cultures feel firmly in control, and are never overwhelmed by too many choices or irrelevant flash. Make me amazing It's not enough to make an app that is easy to use. Android apps empower people to try new things and to use apps in inventive new ways. Android lets people combine applications into new workflows through multitasking, notifications, and sharing across apps. At the same time, your app should feel personal, giving people access to superb technology with clarity and grace. 2) Design Principles These design principles were developed by and for the Android User Experience Team to keep users' best interests in mind. Consider them as you apply your own creativity and design thinking. Deviate with purpose. Enchant Me Delight me in surprising ways A beautiful surface, a carefully-placed animation, or a well-timed sound effect is a joy to experience. Subtle effects contribute to a feeling of effortlessness and a sense that a powerful force is at hand. Real objects are more fun than buttons and menus Allow people to directly touch and manipulate objects in your app. It reduces the cognitive effort needed to perform a task while making it more emotionally satisfying.
Let me make it mine People love to add personal touches because it helps them feel at home and in control. Provide sensible, beautiful defaults, but also consider fun, optional customizations that don't hinder primary tasks. Get to know me Learn peoples' preferences over time. Rather than asking them to make the same choices over and over, place previous choices within easy reach.
Simplify My Life Keep it brief Use short phrases with simple words. People are likely to skip sentences if they're long. Pictures are faster than words Consider using pictures to explain ideas. They get people's attention and can be much more efficient than words.
Decide for me but let me have the final say Take your best guess and act rather than asking first. Too many choices and decisions make people unhappy. Just in case you get it wrong, allow for 'undo'. Only show what I need when I need it People get overwhelmed when they see too much at once. Break tasks and information into small, digestible chunks. Hide options that aren't essential at the moment, and teach people as they go.
I should always know where I am Give people confidence that they know their way around. Make places in your app look distinct and use transitions to show relationships among screens. Provide feedback on tasks in progress. Never lose my stuff Save what people took time to create and let them access it from anywhere. Remember settings, personal touches, and creations across phones, tablets, and computers. It makes upgrading the easiest thing in the world. If it looks the same, it should act the same Help people discern functional differences by making them visually distinct rather than subtle. Avoid modes, which are places that look similar but act differently on the same input.
Only interrupt me if it's important Like a good personal assistant, shield people from unimportant minutiae. People want to stay focused, and unless it's critical and time-sensitive, an interruption can be taxing and frustrating. Make Me Amazing Give me tricks that work everywhere People feel great when they figure things out for themselves. Make your app easier to learn by leveraging visual patterns and muscle memory from other Android apps. For example, the swipe gesture may be a good navigational shortcut.
It's not my fault Be gentle in how you prompt people to make corrections. They want to feel smart when they use your app. If something goes wrong, give clear recovery instructions but spare them the technical details. If you can fix it behind the scenes, even better. Sprinkle encouragement Break complex tasks into smaller steps that can be easily accomplished. Give feedback on actions, even if it's just a subtle glow. Do the heavy lifting for me Make novices feel like experts by enabling them to do things they never thought they could. For example, shortcuts that combine multiple photo effects can make amateur photographs look amazing in only a few steps.
Make important things fast Not all actions are equal. Decide what's most important in your app and make it easy to find and fast to use, like the shutter button in a camera, or the pause button in a music player. 3) UI Overview Android's system UI provides the framework on top of which you build your app. Important aspects include the Home screen experience, global device navigation, and notifications. Your app will play an important part in keeping the overall Android experience consistent and enjoyable to use. At the end of this chapter we introduce the main elements for achieving this goal in your app. Read on for a quick overview of the most important aspects of the Android user interface. Home, All Apps, and Recents
Home screen Home is a customizable space that houses app shortcuts, folders and widgets. Navigate between different home screen panels by swiping left and right. The Favorites Tray at the bottom always keeps your most important shortcuts and folders in view regardless of which panel is currently showing. Access the entire collection of apps and widgets by touching the All Apps button at the center of the Favorites Tray.
All apps screen The All Apps screen lets you browse the entire set of apps and widgets that are installed on your device. Users can drag an app or widget icon from the All Apps screen and place it in any empty location on any Home screen.
Recents screen Recents provides an efficient way of switching between recently used applications. It provides a clear navigation path between multiple ongoing tasks. The Recents button at the right side of the navigation bar displays the apps that the user has interacted with most recently. They are organized in reverse chronological order with the most recently used app at the bottom. Switch to an app by touching it. Remove an item by swiping left or right.
System Bars The system bars are screen areas dedicated to the display of notifications, communication of device status, and device navigation. Typically the system bars are displayed concurrently with your app. Apps that display immersive content, such as movies or images, can temporarily hide the system bars to allow the user to enjoy full screen content without distraction. 1. Status Bar Displays pending notifications on the left and status, such as time, battery level, or signal strength, on the right. Swipe down from the status bar to show notification details. 2. Navigation Bar New for phones in Android 4.0, the navigation bar is present only on devices that don't have the traditional hardware keys. It houses the device navigation controls Back, Home, and Recents, and also displays a menu for apps written for Android 2.3 or earlier. 3. Combined Bar
On tablet form factors the status and navigation bars are combined into a single bar at the bottom of the screen. Notifications Notifications are brief messages that users can access at any time from the status bar. They provide updates, reminders, or information that's important, but not critical enough to warrant interrupting the user. Open the notifications drawer by swiping down on the status bar. Touching a notification opens the associated app. More on Notifications
Most notifications have a one-line title and a one-line message. The recommended layout for a notification includes two lines. If necessary, you can add a third line. Timestamps are optional. Swiping a notification right or left removes it from the notification drawer. Common App UI A typical Android app consists of action bars and the app content area. 1. Main Action Bar The command and control center for your app. The main action bar includes elements for navigating your app's hierarchy and views, and also surfaces the most important actions. More on the Action Bar 2. View Control Allows users to switch between the different views that your app provides. Views typically consist of different arrangements of your data or different functional aspects of your app. 3. Content Area The space where the content of your app is displayed. 4. Split Action Bar Split action bars provide a way to distribute actions across additional bars located below the main action bar or at the bottom of the screen. In this example, a split action bar moves important actions that won't fit in the main bar to the bottom.
II. Style 1) Devices and Displays Android powers millions of phones, tablets, and other devices in a wide variety of screen sizes and form factors. By taking advantage of Android's flexible layout system, you can create apps that gracefully scale from large tablets to smaller phones. Be flexible Stretch and compress your layouts to accommodate various heights and widths. Optimize layouts On larger devices, take advantage of extra screen real estate. Create compound views that combine multiple views to reveal more content and ease navigation.
Assets for all Provide resources for different screen densities (DPI) to ensure that your app looks great on any device. Strategies So where do you begin when designing for multiple screens? One approach is to work in the base standard (medium size,MDPI) and scale it up or down for the other buckets. Another approach is to start with the device with the largest screen size, and then scale down and figure out the UI compromises you'll need to make on smaller screens. For more detailed information on this topic, please visit Supporting Multiple Screens. 2) Themes Gmail in Holo Light.
Settings in Holo Dark. Talk in Holo Light with dark action bar.
3) Touch Feedback Use color and illumination to respond to touches, reinforce the resulting behaviors of gestures, and indicate what actions are enabled and disabled. Whenever a user touches an actionable area in your app, provide a visual response. This lets the user know which object was touched and that your app is "listening". States Most of Android's UI elements have touch-feedback built in, including states that indicate whether touching the element will have any effect.
Communication When your objects react to more complex gestures, help users understand what the outcome of the operation will be. For example, in Recents, when you start swiping a thumbnail left or right, it starts to dim. This helps the user understand that swiping will cause the item to be removed.
Boundaries When users try to scroll past the upper or lower limit of a scrollable area, communicate the boundary with a visual cue. For example, if a user attempts to scroll past the first home screen panel, the screen content tilts to the right to indicate that further navigation in this direction is not possible. Many of Android's scrollable UI widgets (e.g. lists or grid lists) already have support for boundary feedback built in. If you are building custom, keep boundary feedback in mind and provide it from within your app. 4) Metrics and Grids Devices vary not only in physical size, but also in screen density (DPI). To simplify the way you design for multiple screens, think of each device as falling into a particular size bucket and density bucket. The size buckets are handset(smaller than 600dp) and tablet (larger than or equal 600dp). The density buckets are LDPI, MDPI, HDPI, and XHDPI. Optimize your application's UI by designing alternative layouts for some of the different size buckets, and provide alternative bitmap images for different density buckets.
Space considerations Devices vary in the amount of density-independent pixels (dp) they can display. To see more, visit the Screen Sizes and Densities Device Dashboard. 48dp Rhythm Touchable UI components are generally laid out along 48dp units. Why 48dp? On average, 48dp translate to a physical size of about 9mm (with some variability). This is comfortably in the range of recommended target sizes (7-10 mm) for touchscreen objects and users will be able to reliably and accurately target them with their fingers. If you design your elements to be at least 48dp high and wide you can guarantee that:  your targets will never be smaller than the minimum recommended target size of 7mm regardless of what screen they are displayed on.  you strike a good compromise between overall information density on the one hand, and targetability of UI elements on the other.
Mind the gaps Spacing between each UI element is 8dp. Examples
5) Typography The Android design language relies on traditional typographic tools such as scale, space, rhythm, and alignment with an underlying grid. Successful deployment of these tools is essential to help users quickly understand a screen of information. To support such use of typography, Ice Cream Sandwich introduced a new type family named Roboto, created specifically for the requirements of UI and high-resolution screens. The current TextView framework supports regular, bold, italic, and bold italic weights by default.
Download Roboto Specimen Book Default type colors The Android UI uses the following default color styles:textColorPrimary and textColorSecondary. For light themes use textColorPrimaryInverse andtextColorSecondaryInverse. The framework text color styles also support variants for touch feedback states when used inside UI elements. Typographic Scale Contrast in type sizes can go a long way to create ordered, understandable layouts. However, too many different sizes in the same UI can be messy. The Android framework uses the following limited set of type sizes:
Users can select a system-wide scaling factor for text in the Settings app. In order to support these accessibility features, type should be specified in scale-independent pixels (sp) wherever possible. Layouts supporting scalable types should be tested against these settings. 6) Color Use color primarily for emphasis. Choose colors that fit with your brand and provide good contrast between visual components. Note that red and green may be indistinguishable to color-blind users.           Palette Blue is the standard accent color in Android's color palette. Each color has a corresponding darker shade that can be used as a complement when needed. Download the swatches
7) Iconography An icon is a graphic that takes up a small portion of screen real estate and provides a quick, intuitive representation of an action, a status, or an app. Launcher The launcher icon is the visual representation of your app on the Home or All Apps screen. Since the user can change the Home screen's wallpaper, make sure that your launcher icon is clearly visible on any type of background.
Sizes & scale  Launcher icons on a mobile device must be 48x48 dp.  Launcher icons for display on Google Play must be512x512 pixels. Proportions  Full asset, 48x48 dp Style Use a distinct silhouette. Three-dimensional, front view, with a slight perspective as if viewed from above, so that users perceive some depth.
Action Bar Action bar icons are graphic buttons that represent the most important actions people can take within your app. Each one should employ a simple metaphor representing a single concept that most people can grasp at a glance. Pre-defined glyphs should be used for certain common actions such as "refresh" and "share." The download link below provides a package with icons that are scaled for various screen densities and are suitable for use with the Holo Light and Holo Dark themes. The package also includes unstyled
icons that you can modify to match your theme, in addition to Adobe® Illustrator® source files for further customization. Download the Action Bar Icon Pack Sizes & scale  Action bar icons for phones should be 32x32 dp. Focal area & proportions
 Full asset, 32x32 dp Optical square, 24x24 dp Style Pictographic, flat, not too detailed, with smooth curves or sharp shapes. If the graphic is thin, rotate it 45° left or right to fill the focal space. The thickness of the strokes and negative spaces should be a minimum of 2 dp. Colors Colors: #333333 Enabled: 60% opacity Disabled: 30% opacity Colors: #FFFFFF Enabled: 80% opacity Disabled: 30% opacity Small / Contextual Icons Within the body of your app, use small icons to surface actions and/or provide status for specific items. For example, in the Gmail app, each message has a star icon that marks the message as important.
Sizes & scale  Small icons should be 16x16dp. Focal area & proportions  Full asset, 16x16 dp Optical square, 12x12 dp Style
Neutral, flat, and simple. Filled shapes are easier to see than thin strokes. Use a single visual metaphor so that a user can easily recognize and understand its purpose. Colors Use non-neutral colors sparingly and with purpose. For example, Gmail uses yellow in the star icon to indicate a bookmarked message. If an icon is actionable, choose a color that contrasts well with the background. Notification Icons If your app generates notifications, provide an icon that the system can display in the status bar whenever a new notification is available.
Sizes & scale  Notification icons must be24x24 dp. Focal area & proportions  Full asset, 24x24 dp Optical square, 22x22 dp Style
Keep the style flat and simple, using the same single, visual metaphor as your launcher icon. Colors Notification icons must be entirely white. Also, the system may scale down and/or darken the icons. 8) Writing Style When choosing words for your app: 1. Keep it brief. Be concise, simple and precise. Start with a 30 character limit (including spaces), and don't use more unless absolutely necessary. 2. Keep it simple. Pretend you're speaking to someone who's smart and competent, but doesn't know technical jargon and may not speak English very well. Use short words, active verbs, and common nouns.
3. Be friendly. Use contractions. Talk directly to the reader using second person ("you"). If your text doesn't read the way you'd say it in casual conversation, it's probably not the way you should write it. Don't be abrupt or annoying and make the user feel safe, happy and energized. 4. Put the most important thing first. The first two words (around 11 characters, including spaces) should include at least a taste of the most important information in the string. If they don't, start over. 5. Describe only what's necessary, and no more. Don't try to explain subtle differences. They will be lost on most users. 6. Avoid repetition. If a significant term gets repeated within a screen or block of text, find a way to use it just once. Examples 1. Keep it brief. From the setup wizard: Too formal Consult the documentation that came with your phone for further instructions. Better Read the instructions that came with your phone. 1. Keep it simple. From the Location settings screen: Confusing Use GPS satellites When locating, accurate to street level. Better GPS
GPS Let apps use satellites to pinpoint your location. 1. Be friendly. Dialog that appears when an application crashes: Confusing and annoying—"Sorry" just rubs salt in the wound. Sorry! Activity MyAppActivity (in application MyApp) is not responding. Force close Wait Report Shorter, more direct, no faux-apologetic title: MyApp isn't responding. Do you want to close it? Wait Report Close 1. Put the most important thing first. Top news last 77 other people +1'd this, including Larry Page. Top news first Larry Page and 77 others +1'd this. Task last
Touch Next to complete setup using a Wi-Fi connection. Task first To finish setup using Wi-Fi, touch Next. 1. Describe only what's necessary, and no more. From a Setup Wizard screen Signing in... Your phone needs to communicate with Google servers to sign in to your account. This may take up to five minutes. From a Setup Wizard screen Signing in... Your phone is contacting Google. This can take up to 5 minutes.
III. Patterns Design apps that behave in a consistent, predictable fashion. New in Android 4.0 1) New in Android 4.0 Navigation bar Android 4.0 removes the need for traditional hardware keys on phones by replacing them with a virtual navigation bar that houses the Back, Home and Recents buttons. Read theCompatibility pattern to learn how the OS adapts to phones with hardware buttons and how pre- Android 3.0 apps that rely on menu keys are supported.
Action bar The action bar is the most important structural element of an Android app. It provides consistent navigation across the platform and allows your app to surface actions. Multi-pane layouts Creating apps that scale well across different form factors and screen sizes is important in the Android world. Multi-pane layouts allow you to combine different activities that show separately on smaller devices into richer compound views for tablets. Selection The long press gesture which was traditionally used to show contextual actions for objects is now used for data selection. When selecting data, contextual action bars allow you to surface actions.
2) Gestures Gestures allow users to interact with your app by manipulating the screen objects you provide. The following table shows the core gesture set that is supported in Android. Touch Triggers the default functionality for a given item.  Action Press, lift Long press Enters data selection mode. Allows you to select one or more items in a view and act upon the data using a contextual action bar. Avoid using long press for showing contextual menus.
 Action Press, wait, lift Swipe Scrolls overflowing content, or navigates between views in the same hierarchy.  Action Press, move, lift Drag Rearranges data within a view, or moves data into a container (e.g. folders on Home Screen).  Action Long press, move, lift
Double touch Zooms into content. Also used as a secondary gesture for text selection.  Action Two touches in quick succession Pinch open Zooms into content.  Action 2-finger press, move outwards, lift
Pinch close Zooms out of content.  Action 2-finger press, move inwards, lift 3) Application Structure Apps come in many varieties that address very different needs. For example:  Apps such as Calculator or Camera that are built around a single focused activity handled from a single screen  Apps such as Phone whose main purpose is to switch between different activities without deeper navigation  Apps such as Gmail or the Play Store that combine a broad set of data views with deep navigation Your app's structure depends largely on the content and tasks you want to surface for your users. General Structure A typical Android app consists of top level and detail/edit views. If the navigation hierarchy is deep and complex, category views connect top level and detail views.
Top level views The top level of the app typically consists of the different views that your app supports. The views either show different representations of the same data or expose an altogether different functional facet of your app. Category views Category views allow you to drill deeper into your data. Detail/edit view The detail/edit view is where you consume or create data. Top Level
The layout of your start screen requires special attention. This is the first screen people see after launching your app, so it should be an equally rewarding experience for new and frequent visitors alike. Ask yourself: "What are my typical users most likely going to want to do in my app?", and structure your start screen experience accordingly. Put content forward Many apps focus on the content display. Avoid navigation-only screens and instead let people get to the meat of your app right away by making content the centerpiece of your start screen. Choose layouts that are visually engaging and appropriate for the data type and screen size. The Play Store app's start screen primarily allows navigation into the stores for Apps, Music, Books, Movies and Games. It is also enriched with tailored recommendations and promotions that surface content of interest to the user. Search is readily available from the action bar. Set up action bars for navigation and actions All screens in your app should display action bars to provide consistent navigation and surface important actions. At the top level, special considerations apply to the action bar:  Use the action bar to display your app's icon or title.  If your top level consists of multiple views, or if switching between data from different user accounts is a significant use case, make sure that it's easy for the user to navigate between them by adding view controls to your action bar.  If your app allows people to create content, consider making the content accessible right from the top level.  If your content is searchable, include the Search action in the action bar so people can cut through the navigation hierarchy.
Email is about productivity, so an efficient, easy-to-skim list with higher data density works well. Navigation supports switching between accounts and recent labels. Icons for creating a new message or searching are prominent in the split action bar at the bottom. Create an identity for your app Creating an identity for your app goes beyond the action bar. Your app communicates its identity through its data, the way that data is arranged, and how people interact with it. Especially for media-rich applications, try to create unique layouts that showcase your data and go beyond the monotony of simple list views.
The 3D carousel celebrates cover art and establishes a unique identity for the Music app. Defaulting to the Recent view keeps the focus on music the user has been listening to lately. Categories Generally, the purpose of a deep, data-driven app is to navigate through organizational categories to the detail level, where data can be viewed and managed. Minimize perceived navigation effort by keeping your apps shallow. Even though the number of vertical navigation steps from the top level down to the detail views is typically dictated by the structure of your app's content, there are several ways you can cut down on the perception of onerous navigation. Use tabs to combine category selection and data display This can be successful if the categories are familiar or the number of categories is small. It has the advantage that a level of hierarchy is removed and data remains at the center of the user's attention. Navigating laterally between data-rich categories is more akin to a casual browsing experience than to an explicit navigation step. If the categories are familiar, predictable, or closely related, use scrolling tabs (where not all items are in view simultaneously). Keep the number of scrolling tabs at a manageable level to minimize navigational effort. Rule of thumb: no more than 5–7 tabs.
The Play Store app uses tabs to simultaneously show category choice and content. To navigate between categories, users can swipe left/right on the content. If the categories in the tabs are not closely related, favor fixed tabs, so that all categories are in view at the same time.
YouTube uses fixed tabs to switch between different, relatively unrelated functional areas. Allow cutting through hierarchies Take advantage of shortcuts that allow people to reach their goals quicker. To allow top-level invocation of actions for a data item from within list or grid views, display prominent actions directly on list view items using drop-downs or split list items. This lets people invoke actions on data without having to navigate all the way down the hierarchy.
Music allows the user to act upon a data item (song) from within the category view (album), thereby removing the need to navigate all the way down to the song's detail view. Acting upon multiple data items Even though category views mostly serve to guide people to content detail, keep in mind that there are often good reasons to act on collections of data as well. For example, if you allow people to delete an item in a detail view, you should also allow them to delete multiple items in the category view. Analyze which detail view actions are applicable to collections of items. Then use multi-select to allow application of those actions to multiple items in a category view. Details The detail view allows you to view and act on your data. The layout of the detail view depends on the data type being displayed, and therefore differs widely among apps. Layout
Consider the activities people will perform in the detail view and arrange the layout accordingly. For immersive content, make use of the lights-out mode to allow for distraction-free viewing of full- screen content.
Google Books' detail view is all about replicating the experience of reading an actual book. The page-flip animation reinforces that notion. To create an immersive experience the app enters lights-out mode, which hides all system UI affordances. The purpose of the People app's detail view is to surface communication options. The list view allows for efficient scanning and quick access of phone numbers, email addresses and other information items. Split items are used to combine calling and messaging into one compact line item. Make navigation between detail views efficient If your users are likely to want to look at multiple items in sequence, allow them to navigate between items from within the detail view. Use swipe views or other techniques, such as filmstrips, to achieve this. Gmail using swipe views to navigate from detail view to detail view.
In addition to supporting swipe gestures to move left or right through images, Gallery provides a filmstrip control that lets people quickly jump to specific images. Checklist  Find ways to display useful content on your start screen.  Use action bars to provide consistent navigation.  Keep your hierarchies shallow by using horizontal navigation and shortcuts.  Use multi-select to allow the user to act on collections of data.  Allow for quick navigation between detail items with swipe views. 4) Navigation with Back and Up Consistent navigation is an essential component of the overall user experience. Few things frustrate users more than basic navigation that behaves in inconsistent and unexpected ways. Android 3.0 introduced significant changes to the global navigation behavior. Thoughtfully following the guidelines for Back and Up will make your app's navigation predictable and reliable for your users.
Android 2.3 and earlier relied upon the system Back button for supporting navigation within an app. With the introduction of action bars in Android 3.0, a second navigation mechanism appeared: the Up button, consisting of the app icon and a left-point caret. Up vs. Back The Up button is used to navigate within an app based on the hierarchical relationships between screens. For instance, if screen A displays a list of items, and selecting an item leads to screen B (which presents that item in more detail), then screen B should offer an Up button that returns to screen A. If a screen is the topmost one in an app (that is, the app's home), it should not present an Up button. The system Back button is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy. When the previously viewed screen is also the hierarchical parent of the current screen, pressing the Back button has the same result as pressing an Up button—this is a common occurrence. However, unlike the Up button, which ensures the user remains within your app, the Back button can return the user to the Home screen, or even to a different app.
The Back button also supports a few behaviors not directly tied to screen-to-screen navigation:  Dismisses floating windows (dialogs, popups)  Dismisses contextual action bars, and removes the highlight from the selected items  Hides the onscreen keyboard (IME) Navigation Within Your App Navigating to screens with multiple entry points Sometimes a screen doesn't have a strict position within the app's hierarchy, and can be reached from multiple entry points—such as a settings screen that can be reached from any other screen in your app. In this case, the Up button should choose to return to the referring screen, behaving identically to Back. Changing view within a screen Changing view options for a screen does not change the behavior of Up or Back: the screen is still in the same place within the app's hierarchy, and no new navigation history is created. Examples of such view changes are:  Switching views using tabs and/or left-and-right swipes  Switching views using a dropdown (aka collapsed tabs)  Filtering a list  Sorting a list  Changing display characteristics (such as zooming) Navigating between sibling screens When your app supports navigation from a list of items to a detail view of one of those items, it's often desirable to support direction navigation from that item to another one which precedes or follows it in the list. For example, in Gmail, it's easy to swipe left or right from a conversation to view a newer or older one in the same Inbox. Just as when changing view within a screen, such navigation does not change the behavior of Up or Back.
However, a notable exception to this occurs when browsing between related detail views not tied together by the referring list—for example, when browsing in the Play Store between apps from the same developer, or albums by the same artist. In these cases, following each link does create history, causing the Back button to step through each previously viewed screen. Up should continue to bypass these related screens and navigate to the most recently viewed container screen.
You have the ability to make the Up behavior even smarter based on your knowledge of detail view. Extending the Play Store example from above, imagine the user has navigated from the last Book
viewed to the details for the Movie adaptation. In that case, Up can return to a container (Movies) which the user hasn't previously navigated through. Navigation into Your App via Home Screen Widgets and Notifications
You can use Home screen widgets or notifications to help your users navigate directly to screens deep within your app's hierarchy. For example, Gmail's Inbox widget and new message notification can both bypass the Inbox screen, taking the user directly to a conversation view. For both of these cases, handle the Up button as follows:  If the destination screen is typically reached from one particular screen within your app, Up should navigate to that screen.  Otherwise, Up should navigate to the topmost ("Home") screen of your app. In the case of the Back button, you should make navigation more predictable by inserting into the task's back stack the complete upward navigation path to the app's topmost screen. This allows users who've forgotten how they entered your app to navigate to the app's topmost screen before exiting. As an example, Gmail's Home screen widget has a button for diving directly to its compose screen. Up or Back from the compose screen would take the user to the Inbox, and from there the Back button continues to Home. Indirect notifications When your app needs to present information about multiple events simultaneously, it can use a single notification that directs the user to an interstitial screen. This screen summarizes these events, and provides paths for the user to dive deeply into the app. Notifications of this style are called indirect notifications.
Unlike standard (direct) notifications, pressing Back from an indirect notification's interstitial screen returns the user to the point the notification was triggered from—no additional screens are inserted into the back stack. Once the user proceeds into the app from its interstitial screen, Up and Back behave as for standard notifications, as described above: navigating within the app rather than returning to the interstitial. For example, suppose a user in Gmail receives an indirect notification from Calendar. Touching this notification opens the interstitial screen, which displays reminders for several different events. Touching Back from the interstitial returns the user to Gmail. Touching on a particular event takes the user away from the interstitial and into the full Calendar app to display details of the event. From the event details, Up and Back navigate to the top-level view of Calendar.
Pop-up notifications Pop-up notifications bypass the notification drawer, instead appearing directly in front of the user. They are rarely used, and should be reserved for occasions where a timely response is required and the interruption of the user's context is necessary. For example, Talk uses this style to alert the user of an invitation from a friend to join a video chat, as this invitation will automatically expire after a few seconds. In terms of navigation behavior, pop-up notifications closely follow the behavior of an indirect notification's interstitial screen. Back dismisses the pop-up notification. If the user navigates from the pop-up into the notifying app, Up and Back follow the rules for standard notifications, navigating within the app.
Navigation Between Apps One of the fundamental strengths of the Android system is the ability for apps to activate each other, giving the user the ability to navigate directly from one app into another. For example, an app that needs to capture a photo can activate the Camera app, which will return the photo to the referring app. This is a tremendous benefit to both the developer, who can easily leverage code from other apps, and the user, who enjoys a consistent experience for commonly performed actions. To understand app-to-app navigation, it's important to understand the Android framework behavior discussed below. Activities, tasks, and intents In Android, an activity is an application component that defines a screen of information and all of the associated actions the user can perform. Your app is a collection of activities, consisting of both the activities you create and those you re-use from other apps. A task is the sequence of activities a user follows to accomplish a goal. A single task can make use of activities from just one app, or may draw on activities from a number of different apps. An intent is a mechanism for one app to signal it would like another app's assistance in performing an action. An app's activities can indicate which intents they can respond to. For common intents such as "Share", the user may have many apps installed that can fulfill that request. Example: navigating between apps to support sharing To understand how activities, tasks, and intents work together, consider how one app allows users to share content by using another app. For example, launching the Play Store app from Home begins new Task A (see figure below). After navigating through the Play Store and touching a promoted book to see its details, the user remains in the same task, extending it by adding activities. Triggering the Share action prompts the user with a dialog listing each of the activities (from different apps) which have registered to handle the Share intent.
When the user elects to share via Gmail, Gmail's compose activity is added as a continuation of Task A—no new task is created. If Gmail had its own task running in the background, it would be unaffected. From the compose activity, sending the message or touching the Back button returns the user to the book details activity. Subsequent touches of Back continue to navigate back through the Play Store, ultimately arriving at Home.
However, by touching Up from the compose activity, the user indicates a desire to remain within Gmail. Gmail's conversation list activity appears, and a new Task B is created for it. New tasks are always rooted to Home, so touching Back from the conversation list returns there.
Task A persists in the background, and the user may return to it later (for example, via the Recents screen). If Gmail already had its own task running in the background, it would be replaced with Task B—the prior context is abandoned in favor of the user's new goal. When your app registers to handle intents with an activity deep within the app's hierarchy, refer to Navigation into Your App via Home Screen Widgets and Notifications for guidance on how to specify Up navigation.
5) Action Bar The action bar is arguably the most important structural element of an Android app. It's a dedicated piece of real estate at the top of each screen that is generally persistent throughout the app. The main purpose of the action bar is to:  Make important actions (such as New or Search, etc) prominent and accessible in a predictable way.  Support consistent navigation and view switching within apps.  Reduce clutter by providing an action overflow for rarely used actions.  Provide a dedicated space for giving your app an identity. If you're new to writing Android apps, note that the action bar is one of the most important design elements you can implement. Following the guidelines described here will go a long way toward making your app's interface consistent with the core Android apps. General Organization The action bar is split into four different functional areas that apply to most apps. 1. App icon The app icon establishes your app's identity. It can be replaced with a different logo or branding if you wish. Important: If the app is currently not displaying the top-level screen, be sure to display the Up caret to the left of the app icon, so the user can navigate up the hierarchy. For more discussion of Up navigation, see the Navigation pattern.
App icon with and without "up" affordance. 1. View control If your app displays data in different views, this segment of the action bar allows users to switch views. Examples of view-switching controls are drop-down menus or tab controls. If your app doesn't support different views, you can also use this space to display non- interactive content, such as an app title or longer branding information. 2. Action buttons Show the most important actions of your app in the actions section. Actions that don't fit in the action bar are moved automatically to the action overflow. 3. Action overflow Move less often used actions to the action overflow. Adapting to Rotation and Different Screen Sizes One of the most important UI issues to consider when creating an app is how to adjust to screen rotation on different screen sizes. You can adapt to such changes by using split action bars, which allow you to distribute action bar content across multiple bars located below the main action bar or at the bottom of the screen.
Split action bar showing action buttons at the bottom of the screen in vertical orientation. Layout Considerations for Split Action Bars When splitting up content across multiple action bars, you generally have three possible locations for action bar content: 1. Main action bar 2. Top bar 3. Bottom bar If the user can navigate up the hierarchy from a given screen, the main action bar contains the up caret, at a minimum. To allow the user to quickly switch between the views your app provides, use tabs or a spinner in the top bar. To display actions and, if necessary, the action overflow, use the bottom bar.
Contextual Action Bars A contextual action bar (CAB) is a temporary action bar that overlays the app's action bar for the duration of a particular sub-task. CABs are most typically used for tasks that involve acting on selected data or text.
Contextual action bar shown in Browser and Gmail The selection CAB appears after a long press on a selectable data item triggers selection mode. From here the user can:  Select additional elements by touching them.  Trigger an action from the CAB that applies to all selected data items. The CAB then automatically dismisses itself.  Dismiss the CAB via the navigation bar's Back button or the CAB's checkmark button. This removes the CAB along with all selection highlights. Use CABs whenever you allow the user to select data via long press. You can control the action content of a CAB in order to insert the actions you would like the user to be able to perform. For more information, refer to the Selection pattern.
Action Bar Elements Tabs Tabs display app views concurrently and make it easy to explore and switch between them. Use tabs if you expect your users to switch views frequently. There are two types of tabs: fixed and scrollable. Scrollable tabs Scrollable tabs always take up the entire width of the bar, with the currently active view item in the center, and therefore need to live in a dedicated bar. Scrollable tabs can themselves be scrolled horizontally to bring more tabs into view. Use scrollable tabs if you have a large number of views or if you're unsure how many views will be displayed because your app inserts views dynamically (for example, open chats in a messaging app that the user can navigate between). Scrollable tabs should always allow the user to navigate between the views by swiping left or right on the content area as well as swiping the tabs themselves. Scrolling tabs in the Play Store app. Fixed tabs Fixed tabs are always visible on the screen, and can't be moved out of the way like scrollable tabs. Fixed tabs in the main action bar can move to the top bar when the screen orientation changes.
Default fixed tabs shown in Holo Dark & Light. Spinners A spinner is a drop-down menu that allows users to switch between views of your app. Use spinners rather than tabs in the main action bar if:  You don't want to give up the vertical screen real estate for a dedicated tab bar.  You expect your app's users to switch views infrequently. Action bar spinner from Calendar application. Action buttons Action buttons on the action bar surface your app's most important activities. Think about which buttons will get used most often, and order them accordingly. Depending on available screen real estate, the system shows your most important actions as action buttons and moves the rest to the action overflow. The action bar and the action overflow should only present actions to the user that are available. If an action is unavailable in the current context, hide it. Do not show it as disabled. A sampling of action buttons used throughout the Gmail application. For guidance on prioritizing actions, use the FIT scheme. F — Frequent  Will people use this action at least 7 out of 10 times they visit the screen?  Will they typically use it several times in a row?  Would taking an extra step every time truly be burdensome?
I — Important  Do you want everyone to discover this action because it's especially cool or a selling point?  Is it something that needs to be effortless in the rare cases it's needed? T — Typical  Is it typically presented as a first-class action in similar apps?  Given the context, would people be surprised if it were buried in the action overflow? If either F, I, or T apply, then it's appropriate for the action bar. Otherwise, it belongs in the action overflow. Pre-defined glyphs should be used for certain common actions such as "refresh" and "share." The download link below provides a package with icons that are scaled for various screen densities and are suitable for use with the Holo Light and Holo Dark themes. The package also includes unstyled icons that you can modify to match your theme, in addition to Adobe® Illustrator® source files for further customization. Download the Action Bar Icon Pack Action overflow The action overflow in the action bar provides access to your app's less frequently used actions. The overflow icon only appears on phones that have no menu hardware keys. Phones with menu keys display the action overflow when the user presses the key. Action overflow is pinned to the right side. How many actions will fit in the main action bar? Action bar capacity is controlled by the following rules:  Action buttons in the main action bar may not occupy more than 50% of the bar's width. Action buttons on bottom action bars can use the entire width.  The screen width in density-independent pixels (dp) determine the number of items that will fit in the main action bar: o smaller than 360 dp = 2 icons o 360-499 dp = 3 icons o 500-599 dp = 4 icons o 600 dp and larger = 5 icons
In the above table "o" denotes an action bar item and "=" an overflow icon. Sharing data Whenever your app permits sharing of data, such as images or movie clips, use a share action provider in your action bar. The share action provider is designed to speed up sharing by displaying the most recently used sharing service next to a spinner button that contains other sharing options.
The Gallery app's share action provider with extended spinner for additional sharing options. Action Bar Checklist When planning your split action bars, ask yourself questions like these: How important is view navigation to the task? If view navigation is very important to your app, use tabs (for fastest view-switching) or spinners. Which of the app's actions need to be consistently available directly from the action bar, and which can be moved to the action overflow?
Use the FIT scheme to decide if actions are displayed at the top-level or can be moved to the action overflow. If the number of top-level actions exceeds the capacity of the main action bar, display them separately in a bottom action bar. What else is important enough to warrant continuous display? Sometimes it is important to display contextual information for your app that's always visible. Examples are the number of unread messages in a messaging inbox view or the Now Playing information in a music player. Carefully plan which important information you would like to display and structure your action bars accordingly. 6) Multi-pane Layouts When writing an app for Android, keep in mind that Android devices come in many different screen sizes and types. Make sure that your app consistently provides a balanced and aesthetically pleasing layout by adjusting its content to varying screen sizes and orientations. Panels are a great way for your app to achieve this. They allow you to combine multiple views into one compound view when a lot of horizontal screen real estate is available and by splitting them up when less space is available. Combining Multiple Views Into One On smaller devices your content is typically divided into a master grid or list view and a detail view. Touching an item in the master view opens a different screen showing that item's detail information.
Because tablets have more screen real estate than phones, you can use panels to combine the related list and detail views into a single compound view. This uses the additional space more efficiently and makes navigating the app easier.
In general, use the pane on the right to present more information about the item you selected in the left pane. Make sure to keep the item in the left pane selected in order to establish the relationship between the panels. Compound Views and Orientation Changes Screens should have the same functionality regardless of orientation. If you use a compound view in one orientation, don't split it up when the user rotates the screen. There are several techniques you can use to adjust the layout after orientation change while keeping functional parity intact.
Stretch/compress Adjust the column width of your left pane to achieve a balanced layout in both orientations. Stack Rearrange the panels on your screen to match the orientation.
Expand/collapse When the device rotates, collapse the left pane view to only show the most important information. Provide an expand control that allows the user to bring the left pane content back to its original width and vice versa.
Show/hide After rotating the device, show the right pane in fullscreen view. Use the Up icon in the action bar to show the left panel and allow navigation to a different email. Hide the left panel by touching the content in the detail panel.
Checklist  Plan in advance on how your app scales to different screen sizes and screen orientations.  Identify the most appropriate method for the panels in your compound views to reorganize themselves when screen orientation changes.  Look for opportunities to consolidate your views into multi-panel compound views.  Make sure that your screens provide functional parity after the screen orientation changes. 7) Swipe Views Efficient navigation is one of the cornerstones of a well-designed app. While apps are generally built in a hierarchical fashion, there are instances where horizontal navigation can flatten vertical hierarchies and make access to related data items faster and more enjoyable. Swipe views allow the user to efficiently move from item to item using a simple gesture and thereby make browsing and consuming data a more fluent experience. Swiping Between Detail Views An app's data is often organized in a master/detail relationship: The user can view a list of related data items, such as images, chats, or emails, and then pick one of the items to see the detail contents in a separate screen.
Master (left) and detail (right) views. On a phone, since the master and detail are on separate screens, this typically requires the user to jump back and forth between the list and the detail view, aka "pogo-sticking". In cases where users will want to view multiple detail items in succession, avoid pogo-sticking by using the swipe gesture to navigate to the next/previous detail view.
Navigating between consecutive Email messages using the swipe gesture. Swiping Between Tabs People app with swipe gesture navigation between top-level screens. If your app uses action bar tabs, use swipe to navigate between the different views. Checklist  Use swipe to quickly navigate between detail views or tabs.  Transition between the views as the user performs the swipe gesture. Do not wait for the gesture to complete and then transition between views.  If you used buttons in the past for previous/next navigation, replace them with the swipe gesture.  Consider adding contextual information in your detail view that informs the user about the relative list position of the currently visible item.
9) Selection Android 3.0 introduced the long press gesture—that is, a touch that's held in the same position for a moment—as the global gesture to select data. This affects the way you should handle multi-select and contextual actions in your apps. What has changed? In previous versions of Android, the long press gesture was universally used to display contextual actions for a given data item in a contextual menu. This pattern changed with Android 3.0. The long press gesture is now used to select data, combining contextual actions and selection management functions for selected data into a new element called the contextual action bar (CAB). Traditional use of the long press gesture to show contextual menus. Using the contextual action bar (CAB) The selection CAB is a temporary action bar that overlays your app's current action bar while data is selected. It appears after the user long presses on a selectable data item.
From here the user can:  Select additional data items by touching them.  Trigger an action from the CAB that applies to all highlighted data items. The CAB then automatically dismisses itself.  Dismiss the CAB via the navigation bar's Back button or the CAB's checkmark button. This removes the CAB along with all selection highlights. Selecting CAB actions You can decide which actions and elements appear in the CAB. Use the guidelines in the Action Bar patternto decide which items to surface at the top level and which to move to the action overflow. Dynamically adjust CAB actions In most cases you need to adjust the actions in the CAB dynamically as the user adds more items to the selection. Actions that apply to a single selected data item don't necessarily apply to multiple selected data items of the same kind.
Adjusting actions in the CAB as additional items are selected. Checklist  Whenever your app supports the selection of multiple data items, make use of the contextual action bar (CAB).  Reserve the long press gesture for selection exclusively. Don't use it to display traditional contextual menus.  If you don't support multi-selection within a list, long press should do nothing.  Plan the actions you want to display inside of a CAB in the same way you would plan the actions inside your app's action bar. 10) Notifications The notification system allows your app to keep the user informed about important events, such as new messages in a chat app or a calendar event. To create an app that feels streamlined, pleasant, and respectful, it is important to design your notifications carefully. Notifications embody your app's voice, and contribute to your app's personality. Unwanted or unimportant notifications can annoy the user, so use them judiciously. When to display a notification
To create an application that people love, it's important to recognize that the user's attention and focus is a resource that must be protected. To use an analogy that might resonate with software developers, the user is not a method that can be invoked to return a value. The user's focus is a resource more akin to a thread, and creating a notification momentarily blocks the user thread as they process and then dismiss the interruptive notification. Android's notification system has been designed to quickly inform users of events while they focus on a task, but it is nonetheless still important to be conscientious when deciding to create a notification. While well behaved apps generally only speak when spoken to, there are some limited cases where an app actually should interrupt the user with an unprompted notification. Notifications should be used primarily for time sensitive events, and especially if these synchronous events involve other people. For instance, an incoming chat is a real time and synchronous form of communication: there is another user actively waiting on you to respond. Calendar events are another good example of when to use a notification and grab the user's attention, because the event is imminent, and calendar events often involve other people. When not to display a notification There are however many other cases where notifications should not be used:  Don't notify the user of information that is not directed specifically at them, or information that is not truly time sensitive. For instance the asynchronous and undirected updates flowing through a social network do not warrant a real time interruption.  Don't create a notification if the relevant new information is currently on screen. Instead, use the UI of the application itself to notify the user of new information directly in context. For instance, a chat application should not create system notifications while the user is actively chatting with another user.  Don't interrupt the user for low level technical operations, like saving or syncing information, or updating an application, if it is possible for the system to simply take care of itself without involving the user.
 Don't interrupt the user to inform them of an error if it is possible for the application to quickly recover from the error on its own without the user taking any action.  Don't use notifications for services that the user cannot manually start or stop.  Don't create superfluous notifications just to get your brand in front of users. Such notifications will only frustrate and likely alienate your audience. The best way to provide the user with a small amount of updated information and to keep them engaged with your application is to develop a widget that they can choose to place on their home screen. Design Guidelines
Make it personal For notifications of items sent by another user (such as a message or status update), include that person's image. Remember to include the app icon as a secondary icon in the notification, so that the user can still identify which app posted it. Navigate to the right place When the user touches a notification, be open your app to the place where the user can consume and act upon the data referenced in the notification. In most cases this will be the detail view of a single data item (e.g. a message), but it might also be a summary view if the notification is stacked (see Stacked notifications below) and references multiple items. If in any of those cases the user is taken to a hierarchy level below your app's top-level, insert navigation into your app's back stack to allow them to navigate to your app's top level using the system back key. For more information, see the chapter on System-to-app navigation in the Navigation design pattern. Timestamps for time sensitive events By default, standard Android notifications include a timestamp in the upper right corner. Consider whether the timestamp is valuable in the context of your notification. If the timestamp is not valuable, consider if the event is important enough to warrant grabbing the user's attention with a notification. If the notification is important enough, decide if you would like to opt out of displaying the timestamp. Include a timestamp if the user likely needs to know how long ago the notification occurred. Good candidates for timestamps include communication notifications (email, messaging, chat, voicemail) where the user may need the timestamp information to understand the context of a message or to tailor a response. Stack your notifications If your app creates a notification while another of the same type is still pending, avoid creating an altogether new notification object. Instead, stack the notification.
A stacked notification builds a summary description and allows the user to understand how many notifications of a particular kind are pending. Don't: Do: If you keep the summary and detail information on different screens, a stacked notification may need to open to a different place in the app than a single notification. For example, a single email notification should always open to the content of the email, whereas a stacked email notification opens to the Inbox view. Clean up after yourself Just like calendar events, some notifications alert the user to an event that happens at a particular point in time. After that moment has passed, the notification is likely not important to the user anymore, and you should consider removing it automatically. The same is true for active chat conversations or voicemail messages the user has listened to, users should not have to manually dismiss notifications independently from taking action on them. Provide a peek into your notification
You can provide a short preview of your notification's content by providing optional ticker text. The ticker text is shown for a short amount of time when the notification enters the system and then hides automatically. Make notifications optional Users should always be in control of notifications. Allow the user to silence the notifications from your app by adding a notification settings item to your application settings. Use distinct icons By glancing at the notification area, the user should be able to discern what notification types are currently pending. Do:  Look at the notification icons the Android apps already provide and create notification icons for your app that are sufficiently distinct in appearance. Don't:  Use color to distinguish your app from others. Notification icons should generally be monochrome. Interacting With Notifications
Notifications are indicated by icons in the notification area and can be accessed by opening the notification drawer. Inside the drawer, notifications are chronologically sorted with the latest one on top. Touching a notification opens the associated app to detailed content matching the notification. Swiping left or right on a notification removes it from the drawer. On tablets, the notification area is integrated with the system bar at the bottom of the screen. The notification drawer is opened by touching anywhere inside the notification area. Ongoing notifications Ongoing notifications keep users informed about an ongoing process in the background. For example, music players announce the currently playing track in the notification system and continue to do so until the user stops the playback. They can also be used to show the user feedback for longer tasks like downloading a file, or encoding a video. Ongoing notifications cannot be manually removed from the notification drawer. Dialogs and toasts are for feedback not notification Your app should not create a dialog or toast if it is not currently on screen. Dialogs and Toasts should only be displayed as the immediate response to the user taking an action inside of your app. For instance, dialogs can be used to confirm that the user understands the severity of an action, and toasts can echo back that an action has been successfully taken.
10) Settings Settings is a place in your app where users indicate their preferences for how your app should behave. This benefits users because:  You don't need to interrupt them with the same questions over and over when certain situations arise. The settings predetermine what will always happen in those situations (see design principle: Decide for me but let me have the final say).  You help them feel at home and in control (see design principle: Let me make it mine). Flow and Structure Provide access to Settings in the action overflow Settings is given low prominence in the UI because it's not frequently needed. Even if there's room in the action bar, never make Settings an action button. Always keep it in the action overflow and label it "Settings". Place it below all other items except "Help".
Avoid the temptation to make everything a setting Because Settings is a few navigational steps away, no matter how many items you have, they'll never clutter up the core part of your UI. This may seem like good news, but it also poses a challenge. Settings can be a tempting place to keep a lot of stuff—like a hall closet where things get stashed when you tidy up before company comes over. It's not a place where you spend lots of time, so it's easy to rationalize and ignore its cluttered condition. But when users visit Settings—however infrequently—they'll have the same expectations for the experience as they do everywhere else in your app. More settings means more choices to make, and too many are overwhelming. So don't punt on the difficult product decisions and debates that can bring on the urge to "just make it a setting". For each control you're considering adding to Settings, make sure it meets the bar:
If you still have lots of settings, group related settings together The number of items an average human can hold in short-term memory is 7±2. If you present a list of 10 or more settings (even after applying the criteria above), users will have more difficulty scanning, comprehending, and processing them. You can remedy this by dividing some or all of the settings into groups, effectively turning one long list into multiple shorter lists. A group of related settings can be presented in one of two ways: 1. Under a section divider 2. In a separate subscreen You can use one or both these grouping techniques to organize your app's settings. For example, in the main screen of the Android Settings app, each item in the list navigates to a subscreen of related settings. In addition, the items themselves are grouped under section dividers. Grouping settings is not an exact science, but here's some advice for how to approach it, based on the total number of settings in your app. 7 or fewer Don't group them at all. It won't benefit users and will seem like overkill.
8 to 10 Try grouping related settings under 1 or 2 section dividers. If you have any "singletons" (settings that don't relate to any other settings and can't be grouped under your section dividers), treat them as follows:  If they include some of your most important settings, list them at the top without a section divider.  Otherwise, list them at the bottom with a section divider called "OTHER", in order of importance. 11 to 15 Same advice as above, but try 2 to 4 section dividers. Also, try the following to reduce the list:  If 2 or more of the settings are mainly for power users, move them out of your main Settings screen and into an "Advanced" subscreen. Place an item in the action overflow called "Advanced" to navigate to it.  Look for "doubles": two settings that relate to one another, but not to any other settings. Try to combine them into one setting, using the design patterns described later in this section. For example, you might be able to redesign two related checkbox settings into one multiple choice setting. 16 or more If you have any instances of 4 or more related settings, group them under a subscreen. Then use the advice suggested above for the reduced list size. Design Patterns Checkbox Use this pattern for a setting that is either selected or not selected.
Multiple choice Use this pattern for a setting that needs to present a discrete set of options, from which the user can choose only one.
Slider Use this pattern for a setting where the range of values are not discrete and fall along a continuum. Date/time Use this pattern for a setting that needs to collect a date and/or time from the user.
Subscreen navigation Use this pattern for navigating to a subscreen or sequence of subscreens that guide the user through a more complex setup process.  If navigating to a single subscreen, use the same title in both the subscreen and the label navigating to it.  If navigating to a sequence of subscreens (as in this example), use a title that describes the first step in the sequence. List subscreen Use this pattern for a setting or category of settings that contains a list of equivalent items. The label provides the name of the item, and secondary text may be used for status. (In this example, status is reinforced with an icon to the right of the label.) Any actions associated with the list appear in the action bar rather than the list itself.
Master on/off switch Use this pattern for a category of settings that need a mechanism for turning on or off as a whole. An on/off switch is placed as the first item in the action bar of a subscreen. When the switch is turned off, the items in the list disappear, replaced by text that describes why the list is empty. If any actions require the switch to be on, they become disabled.
You can also echo the master on/off switch in the menu item that leads to the subscreen. However, you should only do this in cases where users rarely need to access the subscreen once it's initially set up and more often just want to toggle the switch. Individual on/off switch Use this pattern for an individual setting that requires a more elaborate description than can be provided in checkbox form. The on/off switch only appears in the subscreen so that users aren't able to toggle it without also being exposed to the descriptive text. Secondary text appears below the setting label to reflect the current selection. In this example, Android Beam is on by default. Since users might not know what this setting does, we made the status more descriptive than just "On".
Dependency Use this pattern for a setting that changes availability based on the value of another setting. The disabled setting appears below its dependency, without any indentation. If the setting includes a status line, it says "Unavailable", and if the reason isn't obvious, a brief explanation is included in the status. If a given setting is a dependency to 3 or more settings, consider using a subscreen with a master on/off switch so that your main settings screen isn't cluttered by lots of disabled items.
Defaults Take great care in choosing default values for each of your settings. Because settings determine app behavior, your choices will contribute to users' first impressions of your app. Even though users can change settings, they'll expect the initial states to be sensible. The following questions (when applicable) may help inform your decisions:  Which choice would most users be likely to choose on their own if there were no default?  Which choice is the most neutral or middle-of-the-road?  Which choice is the least risky, controversial, or over-the-top?  Which choice uses the least amount of battery or mobile data?  Which choice best supports the design principle Never lose my stuff?  Which choice best supports the design principle Only interrupt me if it's important? Writing Guidelines Label clearly and concisely
Writing a good label for a setting can be challenging because space is very limited. You only get one line, and it's incredibly short on the smallest of devices. Follow these guidelines to make your labels brief, meaningful, and scannable:  Write each label in sentence case (i.e. only the first word and proper nouns are capitalized).  Don't start a label with an instructional verb like "Set", "Change", "Edit", "Modify", "Manage", "Use", "Select", or "Choose". Users already understand that they can do these things to settings.  Likewise, don't end a label with a word like "setting" or "settings". It's already implied.  If the setting is part of a grouping, don't repeat the word(s) used in the section divider or subscreen title.  Avoid starting a label with a negative word like "Don't" or "Never". For example, "Don't allow" could be rephrased to "Block".  Steer clear of technical jargon as much as possible, unless it's a term widely understood by your target users. Use common verbs and nouns to convey the setting's purpose rather than its underlying technology.  Don't refer to the user. For example, for a setting allowing the user to turn notifications on or off, label it "Notifications" instead of "Notify me". Once you've decided on labels for your settings, be sure to preview them on an LDPI handset in portrait to make sure they'll fit everywhere. Secondary text below is for status, not description… Before Ice Cream Sandwich, we often displayed secondary text below a label to further describe it or provide instructions. Starting in Ice Cream Sandwich, we're using secondary text for status. Before Screen timeout Adjust the delay before the screen automatically turns off After Sleep After 10 minutes of activity Status in secondary text has the following benefits:
 Users can see at a glance what the current value of a setting is without having to navigate any further.  It applies the design principle Keep it brief, which users greatly appreciate. …unless it's a checkbox setting There's one important exception to the using secondary text for status: checkbox settings. Here, use secondary text for description, not status. Status below a checkbox is unnecessary because the checkbox already indicates it. The reason why it's appropriate to have a description below a checkbox setting is because—unlike other controls—it doesn't display a dialog or navigate to another screen where additional information can be provided. That said, if a checkbox setting's label is clear enough on its own, there's no need to also provide a description. Only include one if necessary. Follow these guidelines to write checkbox setting descriptions:  Keep it to one sentence and don't use ending punctuation.  Convey what happens when the setting is checked, phrased in the form of a command. Example: "Allow data exchange", not "Allows data exchange".  Avoid repetition by choosing words that don't already appear in the label.  Don't refer to the user unless it's necessary for understanding the setting.  If you must refer to the user, do so in the second person ("you") rather than the first person ("I"). Android speaks to users, not on behalf of them. Writing examples The following are examples of changes we made to labels and secondary text in the Settings app in Ice Cream Sandwich. Before Use tactile feedback After Vibrate on touch In this checkbox setting, we eliminated the throwaway word "Use" and rephrased the label to be more direct and understandable. Before Screen timeout
Screen timeout Adjust the delay before the screen automatically turns off After Sleep After 10 minutes of activity In this multiple choice setting, we changed the label to a friendlier term and also replaced the description with status. We put some descriptive words around the selected value, "10 minutes", because on its own, the meaning could be misinterpreted as "sleep for 10 minutes". Before Change screen lock Change or disable pattern, PIN, or password security After Screen lock Pattern This setting navigates to a a sequence of subscreens that allow users to choose a type of screen lock and then set it up. We eliminated the throwaway word "Change" in the label, and replaced the description with the current type of screen lock set up by the user. If the user hasn't set up a screen lock, the secondary text says "None". Before
NFC Use Near Field Communication to read and exchange tags After NFC Allow data exchange when the phone touches another device In this checkbox setting—although it's technical jargon—we kept the "NFC" label because: (1) we couldn't find a clear, concise alternative, and (2) user familiarity with the acronym is expected to increase dramatically in the next couple of years. We did, however, rewrite the description. It's far less technical than before and does a better job of conveying how and why you'd use NFC. We didn't include what the acronym stands for because it doesn't mean anything to most users and would have taken up a lot of space. Checklist  Make sure each item in Settings meets the criteria for belonging there.  If you have more than 7 items, explore ways to group related settings.  Use design patterns wherever applicable so users don't face a learning curve.  Choose defaults that are safe, neutral, and fit the majority of users.  Give each setting a clear, concise label and use secondary text appropriately. 11) Backwards Compatibility Significant changes in Android 3.0 included:
 Deprecation of navigation hardware keys (Back, Menu, Search, Home) in favor of handling navigation via virtual controls (Back, Home, Recents).  Robust pattern for the use of menus in action bars. Android 4.0 brings these changes for tablets to the phone platform. Adapting Android 4.0 to Older Hardware and Apps Phones with virtual navigation controls Android apps written for Android 3.0 and later display actions in the action bar. Actions that don't fit in the action bar or aren't important enough to be displayed at the top level appear in the action overflow. Users access the action overflow by touching it in the action bar. Phones with physical navigation keys Android phones with traditional navigation hardware keys don't display the virtual navigation bar at the bottom of the screen. Instead, the action overflow is available from the menu hardware key. The resulting actions popup has the same style as in the previous example, but is displayed at the bottom of the screen.
Legacy apps on phones with virtual navigation controls When you run an app that was built for Android 2.3 or earlier on a phone with virtual navigation controls, an action overflow control appears at the right side of the virtual navigation bar. You can touch the control to display the app's actions in the traditional Android menu styling.
12) Pure Android Most developers want to distribute their apps on multiple platforms. As you plan your app for Android, keep in mind that different platforms play by different rules and conventions. Design decisions that make perfect sense on one platform will look and feel misplaced in the context of a different platform. While a "design once, ship anywhere" approach might save you time up-front, you run the very real risk of creating inconsistent apps that alienate users. Consider the following guidelines to avoid the most common traps and pitfalls. Don't mimic UI elements from other platforms Platforms typically provide a carefully designed set of UI elements that are themed in a very distinctive fashion. For example, some platforms advocate rounded corners for their buttons, others use gradients in their title bars. In some cases, elements may have the same purpose, but are designed to work a bit differently. As you build your app for Android, don't carry over themed UI elements from other platforms and don't mimic their specific behaviors. Review the Building Blockssection in this styleguide to learn about Android's most important UI elements and the way they look in the system default themes. Also examine Android's platform apps to get a sense of how elements are applied in the context of an app. If you want to customize the theme of UI elements, customize carefully according to your specific branding - and not according to the conventions of a different platform. Sampling of UI elements from Android, iOS and Windows Phone 7. Don't carry over platform-specific icons
Platforms typically provide sets of icons for common functionality, such as sharing, creating a new document or deleting. As you are migrating your app to Android, please swap out platform-specific icons with their Android counterparts. You can find a wide variety of icons for use in your app on the Downloads page. Sampling of icons from Android, iOS and Windows Phone 7. Don't use bottom tab bars Other platforms use the bottom tab bar to switch between the app's views. Per platform convention, Android's tabs for view control are shown in action bars at the top of the screen instead. In addition, Android apps may use a bottom bar to display actions on a split action bar. You should follow this guideline to create a consistent experience with other apps on the Android platform and to avoid confusion between actions and view switching on Android. For more information on how to properly use action bars for view control, see Action Bars.
Android dialer with tabs in an action bar vs. bottom tabs in iOS. Don't hardcode links to other apps In some cases you might want your app to take advantage of another app's feature set. For example, you may want to share the content that your app created via a social network or messaging app, or view the content of a weblink in a browser. Don't use hard-coded, explicit links to particular apps to achieve this. Instead, use Android's intent API to launch an activity chooser which lists all applications that are set up to handle the particular request. This lets the user complete the task with their preferred app. For sharing in particular, consider using theShare Action Provider in your action bar to provide faster access to the user's most recently used sharing target.
Link to other apps with the activity chooser or use the Share Action Provider in the action bar. Don't use labeled back buttons on action bars Other platforms use an explicit back button with label to allow the user to navigate up the application's hierarchy. Instead, Android uses the main action bar's app icon for hierarchical navigation and the navigation bar's back button for temporal navigation. For more information, please review theNavigation pattern. Follow this guideline to provide a consistent navigation experience across the platform.
Android action bar with up caret vs. iOS labeled "Back" button. Don't use right-pointing carets on line items A common pattern on other platforms is the display of right-pointing carets on line items that allow the user to drill deeper into additional content. Android does not use such indicators on drill-down line items. Avoid them to stay consistent with the platform and in order to not have the user guess as to what the meaning of those carets may be.
Android settings without right-pointing carets in line items vs. iOS settings. Device Independence Remember that your app will run on a wide variety of different screen sizes. Create visual assets for different screen sizes and densities and make use of concepts such as multi-pane layouts to appropriately scale your UI on different device form factors. For more information, read Devices and Displays as well as Multi-pane Layouts in this design guide.
IV. Building Blocks Your inventory of ready-to-use elements for creating outstanding apps. Tabs 1) Tabs Tabs in the action bar make it easy to explore and switch between different views or functional aspects of your app, or to browse categorized data sets.
Scrollable Tabs Scrolling tab controls can contain a larger number of items than a standard tab control. To navigate to the next/previous view, swipe left or right. Scrolling tabs in the Play Store app. Fixed Tabs Fixed tabs display all items concurrently. To navigate to a different view, touch the tab. Tabs in Holo Dark & Light. Tabs in the YouTube app. Stacked Tabs If view navigation is essential to your app, you can break out tabs into a separate action bar. This permits fast view switching even on narrower screens.
2) Lists Lists present multiple line items in a vertical arrangement. They can be used for data selection as well as drilldown navigation.
1. Section Divider Use section dividers to organize the content of your list into groups and facilitate scanning. 2. Line Items List items can accommodate a wide range of data types in different arrangements, including simple single-line items, multi-line items, and custom items with icons, checkboxes, and action buttons. 3) Grid Lists
Grid lists are an alternative to standard list views. They are best suited for showing data sets that represent themselves through images. In contrast to simple lists, grid lists may scroll either vertically or horizontally. Generic Grids The items in a grid list are arranged in two dimensions, one of which is fixed when scrolling content. The scrolling direction dictates the ordering of the items within the grid list. Since the scrolling direction is not deterministic, make it easy for the user to determine the orientation by cutting off grid items to communicate where the overflow is located. Avoid creating grid lists that scroll in two dimensions. Vertical scrolling Vertically scrolling grid list items are sorted in traditional western reading direction: left-to-right and top-down. When displaying the list, cut off the items in the bottom row to communicate that
the user can scroll the list down to show additional items. Be sure to retain this scheme when the user rotates the screen. Horizontal scrolling Horizontally scrolling lists fix the vertical axis of the item grid. Compared to vertically scrolling lists, the sorting changes slightly to a top-down and left-to-right arrangement. Employ the same technique of cutting off the items in the rightmost column to indicate the scrolling direction. Don't use scrolling tabs as a means to switch views in conjunction with horizontally scrolling grid lists, because the horizontal gesture for view and content navigation will conflict. If you show scrolling tabs for view navigation together with a grid list, use vertical grid scrolling for list navigation. Grid List with Labels Use labels to display additional contextual information for your grid list items.
Style Use semi-transparent panels on top of the grid list items to display your labels. This allows you to control the contrast and ensures legibility of the labels while letting the content "shine through". 4) Scrolling Scrolling allows the user to navigate to content in the overflow using a swipe gesture. The scrolling speed is proportional to the speed of the gesture. Scroll Indicator Appears during scrolling to indicate what portion of the content is currently in view. Index Scrolling In addition to traditional scrolling, a long alphabetical list can also offer index scrolling: a way to quickly navigate to the items that begin with a particular letter. With index scrolling, a scroll indicator appears even when the user isn't scrolling. Touching or dragging it causes the current letter to pop up in a prominent way. 5) Spinners Spinners provide a quick way to select one value from a set. In the default state, a spinner shows its currently selected value. Touching the spinner displays a dropdown menu with all other available values, from which the user can select a new one.
Spinners in forms Spinners are useful for data picking in forms. They are compact and integrate nicely with other components. Use spinners in forms for both simple data input and in combination with other input fields. For example, a text field might let you edit an email address for a contact, while its associated spinner allows you to select whether it's a Home or Work address. Spinners in action bars Use spinners in action bars to switch views. For example, Gmail uses a spinner to permit switching between accounts or commonly used labels. Spinners are useful when changing the view is important to your app, but not necessarily a frequent occurrence. In cases where view switching is frequent, use tabs.
Spinners in the Holo Dark and Holo Light themes, in various states. 6) Buttons A button consists of text and/or an image that clearly communicates what action will occur when the user touches it. Android supports two different types of buttons: basic buttons and borderless buttons. Both can contain text labels and/or images. Basic Buttons Basic buttons are traditional buttons with borders and background. Android supports two styles for basic buttons: default and small. Default buttons have slightly larger font size and are optimized for display outside of form content. Small buttons are intended for display alongside other content. They have a smaller font and smaller minimum height. Use small buttons in forms where they need to align with other UI elements.
Default buttons in Holo Dark & Light. Small buttons in Holo Dark & Light. Borderless Buttons Borderless buttons resemble basic buttons except that they have no borders or background. You can use borderless buttons with both icons and text. Borderless buttons are visually more lightweight than basic buttons and integrate nicely with other content. 7) Text Fields Text fields allow the user to type text into your app. They can be either single line or multi-line. Touching a text field places the cursor and automatically displays the keyboard. In addition to typing, text fields allow for a variety of other activities, such as text selection (cut, copy, paste) and data lookup via auto-completion. Single line and multi line
Single-line fields automatically scroll their content to the left as the text input cursor reaches the right edge of the input field. Multi-line text fields automatically break to a new line for overflow text and scroll vertically when the cursor reaches the lower edge. Text field types Text fields can have different types, such as number, message, or email address. The type determines what kind of characters are allowed inside the field, and may prompt the virtual keyboard to optimize its layout for frequently used characters. Auto-complete text fields Use auto-complete text fields to present real-time completions or search results in popups, so users can enter information more accurately and efficiently. Text Selection Users can select any word in a text field with a long press. This action triggers a text selection mode that facilitates extending the selection or choosing an action to perform on the selected text. Selection mode includes:
1. Contextual action bar A contextual action bar (CAB) displays the actions available to perform on the selection: typically cut, copy, and paste, but apps can insert additional commands as needed. 2. Selection handles Selection handles can be dragged to select more or less text while remaining in selection mode. 8) Seek Bars and Sliders Interactive sliders make it possible to select a value from a continuous or discrete range of values by moving the slider thumb. The smallest value is to the left, the largest to the right. The interactive nature of the slider makes it a great choice for settings that reflect intensity levels, such as volume, brightness, or color saturation.
Example Interactive slider to set the ringer volume. The value can either be set through the hardware volume controls or interactively via a gesture. Seek bars in Holo Light & Dark 9) Progress and Activity When an operation of interest to the user is taking place over a relatively long period of time, provide visual feedback that it's still happening and in the process of being completed. Progress If you know the percentage of the operation that has been completed, use a determinate progress bar to give the user a sense of how much longer it will take.
The progress bar should always travel from 0% to 100% completion. Avoid setting the bar to a lower value than a previous value, or using the same progress bar to represent the progress of multiple events, since doing so makes the display meaningless. If you're not sure how long a particular operation will take, use an indeterminate progress indicator. Progress bar in Holo Dark and Holo Light. Activity If you don't know how much longer an operation will continue, use an indeterminate progress indicator. There are two styles available: a flat bar and a circle. Use the one that best fits the available space.
1. Activity bar (shown with the Holo Dark theme) An indeterminate activity bar is used at the start of an application download because the Play Store app hasn't been able to contact the server yet, and it's not possible to determine how long it will take for the download to begin. 1. Activity circle (shown with the Holo Light theme) An indeterminate activity circle is used in the Gmail application when a message is being loaded because it's not possible to determine how long it will take to download the email.
You should only use one activity indicator on screen per activity, and it should appropriately sized for the surrounding context. For example, the largest activity circle works well when displayed in a blank content area, but not in a smaller dialog box. 10) Switches Switches allow the user to select options. There are three kinds of switches: checkboxes, radio buttons, and on/off switches. Checkboxes Checkboxes allow the user to select multiple options from a set. Avoid using a single checkbox to turn an option off or on. Instead, use an on/off switch. Radio Buttons Radio buttons allow the user to select one option from a set. Use radio buttons for exclusive selection if you think that the user needs to see all available options side-by-side. Otherwise, consider a spinner, which uses less space.
On/off Switches On/off switches toggle the state of a single settings option. 11) Dialogs Dialogs prompt the user for decisions or additional information required by the app to continue a task. Such requests can range from simple Cancel/OK decisions to more complex layouts asking the user to adjust settings or enter text.
1. Optional title region The title introduces the content of your dialog. It can, for example, identify the name of a setting that the user is about to change, or request a decision. 2. Content area Dialog content varies widely. For settings dialogs, a dialog may contain UI elements such as sliders, text fields, checkboxes, or radio buttons that allow the user to change app or system settings. In other cases, such as alerts, the content may consist solely of text that provides further context for a user decision. 3. Action buttons Action buttons are typically Cancel and/or OK, with OK indicating the preferred or most likely action. However, if the options consist of specific actions such as Close or Wait rather than a confirmation or cancellation of the action described in the content, then all the buttons should be active verbs. As a rule, the dismissive action of a dialog is always on the left whereas the affirmative actions are on the right.
Samples of typical dialog use in Android. Alerts Alerts inform the user about a situation that requires their confirmation or acknowledgement before proceeding. They differ slightly in appearance based upon the severity and impact of the message conveyed. Alerts without title bars Most alerts don't need titles. Usually the decision doesn't have a severe impact and can be summed up succinctly in a sentence or two. The content area should either ask a question (such as
"Delete this conversation?") or make a clear statement whose relationship to the action buttons is obvious. Alerts with title bars Use alerts with title bars sparingly. They are appropriate only when a high-risk operation involving potential loss of data, connectivity, extra charges, and so on requires a clear question or statement (the title) and some additional explanation (in the content area). Keep the question or statement short: for example, "Erase USB storage?" Avoid apologies. A user should be able to skip the content completely and still have a clear idea of what choices are available based on the title and the text of the action buttons. Popups Popups are lightweight version of dialogs that require a single selection from the user. Popups don't have have explicit buttons that accept or cancel the operation. Instead, making a selection advances the workflow, and simply touching outside the popup dismisses it.
Toasts Toasts provide lightweight feedback about an operation in a small popup. For example, navigating away from an email before you send it triggers a "Draft saved" toast to let you know that you can continue editing later. Toasts automatically disappear after a timeout.
12) Pickers Pickers provide a simple way to select a single value from a set. In addition to touching the up/down arrow buttons, it's possible to set the desired value from the keyboard or via a swipe gesture. Space considerations Pickers can be used inline on a form, but their relatively large footprint is best suited for display in a dialog. For inline display, consider using more compact controls such as text fields or spinners. Date and time pickers Android provides these as ready-to-use dialogs. Each picker is a dialog with a set of controls for entering the parts of the date (month, day, year) or time (hour, minute, AM/PM). Using these in your app helps ensure that a user's specification of a data or time input is valid and formatted correctly. The format of a time and date picker adjusts automatically to the locale.

More Related Content

PDF
Android Design Guidelines
bySam Gaddis
 
PDF
Android Design Guidelines 1.1
byMutual Mobile
 
KEY
Android UI Design Tips
byLuis Abreu
 
PDF
Android UI Design Tips
byAndroid Developers
 
PDF
Android UI design Patter
byTeddy Koornia
 
PDF
The Best Windows Phone Apps 2013: A Designers Collection
byTheresa Neil
 
PPTX
Android design in action
byShyamala Prayaga
 
PDF
Android
bymmJRiest
 
Android Design Guidelines
bySam Gaddis
 
Android Design Guidelines 1.1
byMutual Mobile
 
Android UI Design Tips
byLuis Abreu
 
Android UI Design Tips
byAndroid Developers
 
Android UI design Patter
byTeddy Koornia
 
The Best Windows Phone Apps 2013: A Designers Collection
byTheresa Neil
 
Android design in action
byShyamala Prayaga
 
Android
bymmJRiest
 

What's hot

PPT
9 Step Guide to Create Ripple View Effect in Android
byNine Hertz
 
PDF
10 Design Trends 2013
byDMI
 
PDF
My Interview with Healthy code Magazine: Future of Android Design
byShyamala Prayaga
 
PPTX
Project presentation -chady abidi
bychadyabidi
 
PDF
HealthyCodeMay2014
byShyamala Prayaga
 
PPTX
Mobile apps idea to making money
byDavid Bozward
 
PDF
Session 9-10 - UI/UX design for iOS 7 application
byVu Tran Lam
 
PDF
iOS 7 UI Transition Guide
byEvgeny Belyaev
 
KEY
10 Design Commandments for Mobile App Developers
byJigyasa Makkar
 
PPTX
iOS Human Interface Guidelines (HCI)
byMohammad Khalil
 
DOCX
Introduction%20of%20android
byLekha Adhi
 
PPTX
Day1 what is android(print)
byDongchul Shin
 
PPTX
Android material design lecture #2
byVitali Pekelis
 
PDF
iOS 7 Transition guide
byJigar Maheshwari
 
PPTX
Presentation on Android application
byAtibur Rahman
 
PDF
Prototyping
byHeatherm Huang
 
PDF
Mobile UI Design Patterns 2014
byLewis Lin 🦊
 
PPTX
Making your ui look good on android
bythe100rabh
 
PDF
Tizen mobile design_guidelines
bySaima Ashiq
 
PDF
Adobe Max Modern iPhone App Design with Rick Messer
byRick Messer
 
9 Step Guide to Create Ripple View Effect in Android
byNine Hertz
 
10 Design Trends 2013
byDMI
 
My Interview with Healthy code Magazine: Future of Android Design
byShyamala Prayaga
 
Project presentation -chady abidi
bychadyabidi
 
HealthyCodeMay2014
byShyamala Prayaga
 
Mobile apps idea to making money
byDavid Bozward
 
Session 9-10 - UI/UX design for iOS 7 application
byVu Tran Lam
 
iOS 7 UI Transition Guide
byEvgeny Belyaev
 
10 Design Commandments for Mobile App Developers
byJigyasa Makkar
 
iOS Human Interface Guidelines (HCI)
byMohammad Khalil
 
Introduction%20of%20android
byLekha Adhi
 
Day1 what is android(print)
byDongchul Shin
 
Android material design lecture #2
byVitali Pekelis
 
iOS 7 Transition guide
byJigar Maheshwari
 
Presentation on Android application
byAtibur Rahman
 
Prototyping
byHeatherm Huang
 
Mobile UI Design Patterns 2014
byLewis Lin 🦊
 
Making your ui look good on android
bythe100rabh
 
Tizen mobile design_guidelines
bySaima Ashiq
 
Adobe Max Modern iPhone App Design with Rick Messer
byRick Messer
 

Similar to Android Design Guidelines 4.0

PPTX
Design for Android OS training (some technical tips)
byPavel_Pavelko
 
PDF
Android android-ui-design-patterns
byDandhee Widiadamarrama
 
PPTX
Mobile Apps Design Principles
byMohamad Sani
 
PDF
UI design for mobile apps
byIvano Malavolta
 
PDF
Android UX & Design
byJesse Weed
 
PDF
Android UX & Design
byAndy Fitzgerald
 
PPTX
Android user experience
byRaihan Himel
 
PPTX
Android Design
byShyamala Prayaga
 
PDF
Android UX-UI Design for Fun and Profit
byFernando Cejas
 
PDF
Android UX-UI Design for Fun and Profit
bypenanochizzo
 
PDF
Android UX-UI Design for fun and profit | Fernando Cejas | Tuenti
bySmash Tech
 
KEY
Best Mobile UI Practices - FITC Mobile 2010
byBoris Chan
 
PDF
UI Design
byIvano Malavolta
 
PPTX
Introduction to Android for Quality Engineers
byAhmed Faidy
 
PDF
Excellence in the Android User Experience
bymobilegui
 
PDF
Designing apps for Android
byLorica Claesson
 
PDF
UI design for mobile apps
byIvano Malavolta
 
PPTX
Guidelines for Android application design.pptx
bydebasish duarah
 
PPT
Android ui patterns
byMobile March
 
PPT
Android ui patterns
byvpulec
 
Design for Android OS training (some technical tips)
byPavel_Pavelko
 
Android android-ui-design-patterns
byDandhee Widiadamarrama
 
Mobile Apps Design Principles
byMohamad Sani
 
UI design for mobile apps
byIvano Malavolta
 
Android UX & Design
byJesse Weed
 
Android UX & Design
byAndy Fitzgerald
 
Android user experience
byRaihan Himel
 
Android Design
byShyamala Prayaga
 
Android UX-UI Design for Fun and Profit
byFernando Cejas
 
Android UX-UI Design for Fun and Profit
bypenanochizzo
 
Android UX-UI Design for fun and profit | Fernando Cejas | Tuenti
bySmash Tech
 
Best Mobile UI Practices - FITC Mobile 2010
byBoris Chan
 
UI Design
byIvano Malavolta
 
Introduction to Android for Quality Engineers
byAhmed Faidy
 
Excellence in the Android User Experience
bymobilegui
 
Designing apps for Android
byLorica Claesson
 
UI design for mobile apps
byIvano Malavolta
 
Guidelines for Android application design.pptx
bydebasish duarah
 
Android ui patterns
byMobile March
 
Android ui patterns
byvpulec
 

Recently uploaded

PPTX
ENGLISH DICTIONARY PORTFOLIO FOR EVENTS.
byRie ESPERTA
 
PPTX
2D Transformation (Translation, Rotation, Scaling) in Computer Graphics
byVanshikaBhardwaj32
 
PDF
Early Nozzle (Now Amp) Explainer, Presented at company offsite in Ireland
byJames Hall
 
PDF
TOC Unit 1 Finite State Machine and divisible by 3
bySanjivani college of Engineering
 
PDF
🥳 BUKTI KEMENANGAN HARI INI SELASA 03 FEBRUARI 2026 🥰
byGRAB
 
PPTX
702112964-DELHI-HAAT-A-case-study data ppt
byrakshiperween3
 
PDF
CASE STUDY about Shreyas wellness Center, Quiet healing center; Auroville
byaishwaryag2304
 
PPTX
Pathological Fractures Lecture.pptx ORTHOPAEDICS
bymc22367
 
PPTX
Urban Planning Practice in the Philippines.pptx
byCORONADOJULIABEATRIZ
 
PPTX
ZAIRON AND CARLYN PPT 111111111111111111
byandaliasajohnzairon
 
PPTX
Blueprint Symbols & Learning to Draw a Floor Plan
bybrhaley
 
PDF
urahkhata chikitsa Yojana complete......
byVdoorviKulkarni
 
PPTX
Chikitsa Yojana of Urahkshata Roga......
byVdoorviKulkarni
 
PPTX
TLE - FCS 7 - Introduction to Technical Drawing.pptx
byLANISOCRATES1
 
PDF
Architectural Professional portfolio designs.pdf
bybuildasnest
 
PDF
Should you buy verified PayPal or Stripe accounts_.pdf
bywiulk201973rt6mlnjq7
 
PPTX
Noora_Custom_Color_HIV_TB_Flowchart.pptx
byparag186340
 
PPTX
Mogul Interior Armoires: Maximalist Poetry in Wood
byMogul Interior
 
PPTX
etics.pptxghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh...
byibganraffy22
 
DOCX
Felix's Research project final copy.docx
bymaingijimmy002
 
ENGLISH DICTIONARY PORTFOLIO FOR EVENTS.
byRie ESPERTA
 
2D Transformation (Translation, Rotation, Scaling) in Computer Graphics
byVanshikaBhardwaj32
 
Early Nozzle (Now Amp) Explainer, Presented at company offsite in Ireland
byJames Hall
 
TOC Unit 1 Finite State Machine and divisible by 3
bySanjivani college of Engineering
 
🥳 BUKTI KEMENANGAN HARI INI SELASA 03 FEBRUARI 2026 🥰
byGRAB
 
702112964-DELHI-HAAT-A-case-study data ppt
byrakshiperween3
 
CASE STUDY about Shreyas wellness Center, Quiet healing center; Auroville
byaishwaryag2304
 
Pathological Fractures Lecture.pptx ORTHOPAEDICS
bymc22367
 
Urban Planning Practice in the Philippines.pptx
byCORONADOJULIABEATRIZ
 
ZAIRON AND CARLYN PPT 111111111111111111
byandaliasajohnzairon
 
Blueprint Symbols & Learning to Draw a Floor Plan
bybrhaley
 
urahkhata chikitsa Yojana complete......
byVdoorviKulkarni
 
Chikitsa Yojana of Urahkshata Roga......
byVdoorviKulkarni
 
TLE - FCS 7 - Introduction to Technical Drawing.pptx
byLANISOCRATES1
 
Architectural Professional portfolio designs.pdf
bybuildasnest
 
Should you buy verified PayPal or Stripe accounts_.pdf
bywiulk201973rt6mlnjq7
 
Noora_Custom_Color_HIV_TB_Flowchart.pptx
byparag186340
 
Mogul Interior Armoires: Maximalist Poetry in Wood
byMogul Interior
 
etics.pptxghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh...
byibganraffy22
 
Felix's Research project final copy.docx
bymaingijimmy002
 

Android Design Guidelines 4.0

  • 1.
  • 2.
    Table of Contents I.Getting Started 1) Creative Vision 2) Design Principles 3) UI Overview II. Style 1) Devices and Displays 2) Themes 3) Touch Feedback 4) Metrics and Grids 5) Typography 6) Color 7) Iconography 8) Writing Style III. Patterns 1) New in Android 4.0 2) Gestures 3) App Structure 4) Navigation 5) Action Bar 6) Multi-pane Layouts 7) Swipe Views 8) Selection 9) Notifications 10) Settings 11) Compatibility 12) Pure Android IV. Building Blocks 1) Tabs 2) Lists 3) Grid Lists 4) Scrolling 5) Spinners 6) Buttons 7) Text Fields 8) Seek Bars 9) Progress & Activity 10) Switches 11) Dialog 12) Pickers
  • 3.
    I. Getting Started 1)Creative Vision Ice Cream Sandwich (Android 4.0) marks a major milestone for Android design. We touched nearly every pixel of the system as we expanded the new design approaches introduced in Honeycomb tablets to all types of mobile devices. Starting with the most basic elements, we introduced a new font, Roboto, designed for high-resolution displays. Other big changes include framework-level action bars on phones and support for new phones without physical buttons. We focused the design work with three overarching goals for our core apps and the system at large. As you design apps to work with Android, consider these goals: Enchant me Beauty is more than skin deep. Android apps are sleek and aesthetically pleasing on multiple levels. Transitions are fast and clear; layout and typography are crisp and meaningful. App icons are works of art in their own right. Just like a well-made tool, your app should strive to combine beauty, simplicity and purpose to create a magical experience that is effortless and powerful. Simplify my life Android apps make life easier and are easy to understand. When people use your app for the first time, they should intuitively grasp the most important features. The design work doesn't stop at the
  • 4.
    first use, though.Android apps remove ongoing chores like file management and syncing. Simple tasks never require complex procedures, and complex tasks are tailored to the human hand and mind. People of all ages and cultures feel firmly in control, and are never overwhelmed by too many choices or irrelevant flash. Make me amazing It's not enough to make an app that is easy to use. Android apps empower people to try new things and to use apps in inventive new ways. Android lets people combine applications into new workflows through multitasking, notifications, and sharing across apps. At the same time, your app should feel personal, giving people access to superb technology with clarity and grace. 2) Design Principles These design principles were developed by and for the Android User Experience Team to keep users' best interests in mind. Consider them as you apply your own creativity and design thinking. Deviate with purpose. Enchant Me Delight me in surprising ways A beautiful surface, a carefully-placed animation, or a well-timed sound effect is a joy to experience. Subtle effects contribute to a feeling of effortlessness and a sense that a powerful force is at hand. Real objects are more fun than buttons and menus Allow people to directly touch and manipulate objects in your app. It reduces the cognitive effort needed to perform a task while making it more emotionally satisfying.
  • 5.
    Let me makeit mine People love to add personal touches because it helps them feel at home and in control. Provide sensible, beautiful defaults, but also consider fun, optional customizations that don't hinder primary tasks. Get to know me Learn peoples' preferences over time. Rather than asking them to make the same choices over and over, place previous choices within easy reach.
  • 6.
    Simplify My Life Keepit brief Use short phrases with simple words. People are likely to skip sentences if they're long. Pictures are faster than words Consider using pictures to explain ideas. They get people's attention and can be much more efficient than words.
  • 7.
    Decide for mebut let me have the final say Take your best guess and act rather than asking first. Too many choices and decisions make people unhappy. Just in case you get it wrong, allow for 'undo'. Only show what I need when I need it People get overwhelmed when they see too much at once. Break tasks and information into small, digestible chunks. Hide options that aren't essential at the moment, and teach people as they go.
  • 8.
    I should alwaysknow where I am Give people confidence that they know their way around. Make places in your app look distinct and use transitions to show relationships among screens. Provide feedback on tasks in progress. Never lose my stuff Save what people took time to create and let them access it from anywhere. Remember settings, personal touches, and creations across phones, tablets, and computers. It makes upgrading the easiest thing in the world. If it looks the same, it should act the same Help people discern functional differences by making them visually distinct rather than subtle. Avoid modes, which are places that look similar but act differently on the same input.
  • 9.
    Only interrupt meif it's important Like a good personal assistant, shield people from unimportant minutiae. People want to stay focused, and unless it's critical and time-sensitive, an interruption can be taxing and frustrating. Make Me Amazing Give me tricks that work everywhere People feel great when they figure things out for themselves. Make your app easier to learn by leveraging visual patterns and muscle memory from other Android apps. For example, the swipe gesture may be a good navigational shortcut.
  • 10.
    It's not myfault Be gentle in how you prompt people to make corrections. They want to feel smart when they use your app. If something goes wrong, give clear recovery instructions but spare them the technical details. If you can fix it behind the scenes, even better. Sprinkle encouragement Break complex tasks into smaller steps that can be easily accomplished. Give feedback on actions, even if it's just a subtle glow. Do the heavy lifting for me Make novices feel like experts by enabling them to do things they never thought they could. For example, shortcuts that combine multiple photo effects can make amateur photographs look amazing in only a few steps.
  • 11.
    Make important thingsfast Not all actions are equal. Decide what's most important in your app and make it easy to find and fast to use, like the shutter button in a camera, or the pause button in a music player. 3) UI Overview Android's system UI provides the framework on top of which you build your app. Important aspects include the Home screen experience, global device navigation, and notifications. Your app will play an important part in keeping the overall Android experience consistent and enjoyable to use. At the end of this chapter we introduce the main elements for achieving this goal in your app. Read on for a quick overview of the most important aspects of the Android user interface. Home, All Apps, and Recents
  • 12.
    Home screen Home isa customizable space that houses app shortcuts, folders and widgets. Navigate between different home screen panels by swiping left and right. The Favorites Tray at the bottom always keeps your most important shortcuts and folders in view regardless of which panel is currently showing. Access the entire collection of apps and widgets by touching the All Apps button at the center of the Favorites Tray.
  • 13.
    All apps screen TheAll Apps screen lets you browse the entire set of apps and widgets that are installed on your device. Users can drag an app or widget icon from the All Apps screen and place it in any empty location on any Home screen.
  • 14.
    Recents screen Recents providesan efficient way of switching between recently used applications. It provides a clear navigation path between multiple ongoing tasks. The Recents button at the right side of the navigation bar displays the apps that the user has interacted with most recently. They are organized in reverse chronological order with the most recently used app at the bottom. Switch to an app by touching it. Remove an item by swiping left or right.
  • 15.
    System Bars The systembars are screen areas dedicated to the display of notifications, communication of device status, and device navigation. Typically the system bars are displayed concurrently with your app. Apps that display immersive content, such as movies or images, can temporarily hide the system bars to allow the user to enjoy full screen content without distraction. 1. Status Bar Displays pending notifications on the left and status, such as time, battery level, or signal strength, on the right. Swipe down from the status bar to show notification details. 2. Navigation Bar New for phones in Android 4.0, the navigation bar is present only on devices that don't have the traditional hardware keys. It houses the device navigation controls Back, Home, and Recents, and also displays a menu for apps written for Android 2.3 or earlier. 3. Combined Bar
  • 16.
    On tablet formfactors the status and navigation bars are combined into a single bar at the bottom of the screen. Notifications Notifications are brief messages that users can access at any time from the status bar. They provide updates, reminders, or information that's important, but not critical enough to warrant interrupting the user. Open the notifications drawer by swiping down on the status bar. Touching a notification opens the associated app. More on Notifications
  • 17.
    Most notifications havea one-line title and a one-line message. The recommended layout for a notification includes two lines. If necessary, you can add a third line. Timestamps are optional. Swiping a notification right or left removes it from the notification drawer. Common App UI A typical Android app consists of action bars and the app content area. 1. Main Action Bar The command and control center for your app. The main action bar includes elements for navigating your app's hierarchy and views, and also surfaces the most important actions. More on the Action Bar 2. View Control Allows users to switch between the different views that your app provides. Views typically consist of different arrangements of your data or different functional aspects of your app. 3. Content Area The space where the content of your app is displayed. 4. Split Action Bar Split action bars provide a way to distribute actions across additional bars located below the main action bar or at the bottom of the screen. In this example, a split action bar moves important actions that won't fit in the main bar to the bottom.
  • 19.
    II. Style 1) Devicesand Displays Android powers millions of phones, tablets, and other devices in a wide variety of screen sizes and form factors. By taking advantage of Android's flexible layout system, you can create apps that gracefully scale from large tablets to smaller phones. Be flexible Stretch and compress your layouts to accommodate various heights and widths. Optimize layouts On larger devices, take advantage of extra screen real estate. Create compound views that combine multiple views to reveal more content and ease navigation.
  • 20.
    Assets for all Provideresources for different screen densities (DPI) to ensure that your app looks great on any device. Strategies So where do you begin when designing for multiple screens? One approach is to work in the base standard (medium size,MDPI) and scale it up or down for the other buckets. Another approach is to start with the device with the largest screen size, and then scale down and figure out the UI compromises you'll need to make on smaller screens. For more detailed information on this topic, please visit Supporting Multiple Screens. 2) Themes Gmail in Holo Light.
  • 21.
    Settings in HoloDark. Talk in Holo Light with dark action bar.
  • 22.
    3) Touch Feedback Usecolor and illumination to respond to touches, reinforce the resulting behaviors of gestures, and indicate what actions are enabled and disabled. Whenever a user touches an actionable area in your app, provide a visual response. This lets the user know which object was touched and that your app is "listening". States Most of Android's UI elements have touch-feedback built in, including states that indicate whether touching the element will have any effect.
  • 23.
    Communication When your objectsreact to more complex gestures, help users understand what the outcome of the operation will be. For example, in Recents, when you start swiping a thumbnail left or right, it starts to dim. This helps the user understand that swiping will cause the item to be removed.
  • 24.
    Boundaries When users tryto scroll past the upper or lower limit of a scrollable area, communicate the boundary with a visual cue. For example, if a user attempts to scroll past the first home screen panel, the screen content tilts to the right to indicate that further navigation in this direction is not possible. Many of Android's scrollable UI widgets (e.g. lists or grid lists) already have support for boundary feedback built in. If you are building custom, keep boundary feedback in mind and provide it from within your app. 4) Metrics and Grids Devices vary not only in physical size, but also in screen density (DPI). To simplify the way you design for multiple screens, think of each device as falling into a particular size bucket and density bucket. The size buckets are handset(smaller than 600dp) and tablet (larger than or equal 600dp). The density buckets are LDPI, MDPI, HDPI, and XHDPI. Optimize your application's UI by designing alternative layouts for some of the different size buckets, and provide alternative bitmap images for different density buckets.
  • 25.
    Space considerations Devices varyin the amount of density-independent pixels (dp) they can display. To see more, visit the Screen Sizes and Densities Device Dashboard. 48dp Rhythm Touchable UI components are generally laid out along 48dp units. Why 48dp? On average, 48dp translate to a physical size of about 9mm (with some variability). This is comfortably in the range of recommended target sizes (7-10 mm) for touchscreen objects and users will be able to reliably and accurately target them with their fingers. If you design your elements to be at least 48dp high and wide you can guarantee that:  your targets will never be smaller than the minimum recommended target size of 7mm regardless of what screen they are displayed on.  you strike a good compromise between overall information density on the one hand, and targetability of UI elements on the other.
  • 26.
    Mind the gaps Spacingbetween each UI element is 8dp. Examples
  • 27.
    5) Typography The Androiddesign language relies on traditional typographic tools such as scale, space, rhythm, and alignment with an underlying grid. Successful deployment of these tools is essential to help users quickly understand a screen of information. To support such use of typography, Ice Cream Sandwich introduced a new type family named Roboto, created specifically for the requirements of UI and high-resolution screens. The current TextView framework supports regular, bold, italic, and bold italic weights by default.
  • 28.
    Download Roboto Specimen Book Defaulttype colors The Android UI uses the following default color styles:textColorPrimary and textColorSecondary. For light themes use textColorPrimaryInverse andtextColorSecondaryInverse. The framework text color styles also support variants for touch feedback states when used inside UI elements. Typographic Scale Contrast in type sizes can go a long way to create ordered, understandable layouts. However, too many different sizes in the same UI can be messy. The Android framework uses the following limited set of type sizes:
  • 29.
    Users can selecta system-wide scaling factor for text in the Settings app. In order to support these accessibility features, type should be specified in scale-independent pixels (sp) wherever possible. Layouts supporting scalable types should be tested against these settings. 6) Color Use color primarily for emphasis. Choose colors that fit with your brand and provide good contrast between visual components. Note that red and green may be indistinguishable to color-blind users.           Palette Blue is the standard accent color in Android's color palette. Each color has a corresponding darker shade that can be used as a complement when needed. Download the swatches
  • 30.
    7) Iconography An iconis a graphic that takes up a small portion of screen real estate and provides a quick, intuitive representation of an action, a status, or an app. Launcher The launcher icon is the visual representation of your app on the Home or All Apps screen. Since the user can change the Home screen's wallpaper, make sure that your launcher icon is clearly visible on any type of background.
  • 31.
    Sizes & scale  Launcher icons on a mobile device must be 48x48 dp.  Launcher icons for display on Google Play must be512x512 pixels. Proportions  Full asset, 48x48 dp Style Use a distinct silhouette. Three-dimensional, front view, with a slight perspective as if viewed from above, so that users perceive some depth.
  • 32.
    Action Bar Action baricons are graphic buttons that represent the most important actions people can take within your app. Each one should employ a simple metaphor representing a single concept that most people can grasp at a glance. Pre-defined glyphs should be used for certain common actions such as "refresh" and "share." The download link below provides a package with icons that are scaled for various screen densities and are suitable for use with the Holo Light and Holo Dark themes. The package also includes unstyled
  • 33.
    icons that youcan modify to match your theme, in addition to Adobe® Illustrator® source files for further customization. Download the Action Bar Icon Pack Sizes & scale  Action bar icons for phones should be 32x32 dp. Focal area & proportions
  • 34.
    Full asset, 32x32 dp Optical square, 24x24 dp Style Pictographic, flat, not too detailed, with smooth curves or sharp shapes. If the graphic is thin, rotate it 45° left or right to fill the focal space. The thickness of the strokes and negative spaces should be a minimum of 2 dp. Colors Colors: #333333 Enabled: 60% opacity Disabled: 30% opacity Colors: #FFFFFF Enabled: 80% opacity Disabled: 30% opacity Small / Contextual Icons Within the body of your app, use small icons to surface actions and/or provide status for specific items. For example, in the Gmail app, each message has a star icon that marks the message as important.
  • 35.
    Sizes & scale  Small icons should be 16x16dp. Focal area & proportions  Full asset, 16x16 dp Optical square, 12x12 dp Style
  • 36.
    Neutral, flat, andsimple. Filled shapes are easier to see than thin strokes. Use a single visual metaphor so that a user can easily recognize and understand its purpose. Colors Use non-neutral colors sparingly and with purpose. For example, Gmail uses yellow in the star icon to indicate a bookmarked message. If an icon is actionable, choose a color that contrasts well with the background. Notification Icons If your app generates notifications, provide an icon that the system can display in the status bar whenever a new notification is available.
  • 37.
    Sizes & scale  Notification icons must be24x24 dp. Focal area & proportions  Full asset, 24x24 dp Optical square, 22x22 dp Style
  • 38.
    Keep the styleflat and simple, using the same single, visual metaphor as your launcher icon. Colors Notification icons must be entirely white. Also, the system may scale down and/or darken the icons. 8) Writing Style When choosing words for your app: 1. Keep it brief. Be concise, simple and precise. Start with a 30 character limit (including spaces), and don't use more unless absolutely necessary. 2. Keep it simple. Pretend you're speaking to someone who's smart and competent, but doesn't know technical jargon and may not speak English very well. Use short words, active verbs, and common nouns.
  • 39.
    3. Be friendly.Use contractions. Talk directly to the reader using second person ("you"). If your text doesn't read the way you'd say it in casual conversation, it's probably not the way you should write it. Don't be abrupt or annoying and make the user feel safe, happy and energized. 4. Put the most important thing first. The first two words (around 11 characters, including spaces) should include at least a taste of the most important information in the string. If they don't, start over. 5. Describe only what's necessary, and no more. Don't try to explain subtle differences. They will be lost on most users. 6. Avoid repetition. If a significant term gets repeated within a screen or block of text, find a way to use it just once. Examples 1. Keep it brief. From the setup wizard: Too formal Consult the documentation that came with your phone for further instructions. Better Read the instructions that came with your phone. 1. Keep it simple. From the Location settings screen: Confusing Use GPS satellites When locating, accurate to street level. Better GPS
  • 40.
    GPS Let apps usesatellites to pinpoint your location. 1. Be friendly. Dialog that appears when an application crashes: Confusing and annoying—"Sorry" just rubs salt in the wound. Sorry! Activity MyAppActivity (in application MyApp) is not responding. Force close Wait Report Shorter, more direct, no faux-apologetic title: MyApp isn't responding. Do you want to close it? Wait Report Close 1. Put the most important thing first. Top news last 77 other people +1'd this, including Larry Page. Top news first Larry Page and 77 others +1'd this. Task last
  • 41.
    Touch Next tocomplete setup using a Wi-Fi connection. Task first To finish setup using Wi-Fi, touch Next. 1. Describe only what's necessary, and no more. From a Setup Wizard screen Signing in... Your phone needs to communicate with Google servers to sign in to your account. This may take up to five minutes. From a Setup Wizard screen Signing in... Your phone is contacting Google. This can take up to 5 minutes.
  • 42.
    III. Patterns Design appsthat behave in a consistent, predictable fashion. New in Android 4.0 1) New in Android 4.0 Navigation bar Android 4.0 removes the need for traditional hardware keys on phones by replacing them with a virtual navigation bar that houses the Back, Home and Recents buttons. Read theCompatibility pattern to learn how the OS adapts to phones with hardware buttons and how pre- Android 3.0 apps that rely on menu keys are supported.
  • 43.
    Action bar The actionbar is the most important structural element of an Android app. It provides consistent navigation across the platform and allows your app to surface actions. Multi-pane layouts Creating apps that scale well across different form factors and screen sizes is important in the Android world. Multi-pane layouts allow you to combine different activities that show separately on smaller devices into richer compound views for tablets. Selection The long press gesture which was traditionally used to show contextual actions for objects is now used for data selection. When selecting data, contextual action bars allow you to surface actions.
  • 44.
    2) Gestures Gestures allowusers to interact with your app by manipulating the screen objects you provide. The following table shows the core gesture set that is supported in Android. Touch Triggers the default functionality for a given item.  Action Press, lift Long press Enters data selection mode. Allows you to select one or more items in a view and act upon the data using a contextual action bar. Avoid using long press for showing contextual menus.
  • 45.
     Action Press, wait, lift Swipe Scrolls overflowing content, or navigates between views in the same hierarchy.  Action Press, move, lift Drag Rearranges data within a view, or moves data into a container (e.g. folders on Home Screen).  Action Long press, move, lift
  • 46.
    Double touch Zooms intocontent. Also used as a secondary gesture for text selection.  Action Two touches in quick succession Pinch open Zooms into content.  Action 2-finger press, move outwards, lift
  • 47.
    Pinch close Zooms outof content.  Action 2-finger press, move inwards, lift 3) Application Structure Apps come in many varieties that address very different needs. For example:  Apps such as Calculator or Camera that are built around a single focused activity handled from a single screen  Apps such as Phone whose main purpose is to switch between different activities without deeper navigation  Apps such as Gmail or the Play Store that combine a broad set of data views with deep navigation Your app's structure depends largely on the content and tasks you want to surface for your users. General Structure A typical Android app consists of top level and detail/edit views. If the navigation hierarchy is deep and complex, category views connect top level and detail views.
  • 48.
    Top level views Thetop level of the app typically consists of the different views that your app supports. The views either show different representations of the same data or expose an altogether different functional facet of your app. Category views Category views allow you to drill deeper into your data. Detail/edit view The detail/edit view is where you consume or create data. Top Level
  • 49.
    The layout ofyour start screen requires special attention. This is the first screen people see after launching your app, so it should be an equally rewarding experience for new and frequent visitors alike. Ask yourself: "What are my typical users most likely going to want to do in my app?", and structure your start screen experience accordingly. Put content forward Many apps focus on the content display. Avoid navigation-only screens and instead let people get to the meat of your app right away by making content the centerpiece of your start screen. Choose layouts that are visually engaging and appropriate for the data type and screen size. The Play Store app's start screen primarily allows navigation into the stores for Apps, Music, Books, Movies and Games. It is also enriched with tailored recommendations and promotions that surface content of interest to the user. Search is readily available from the action bar. Set up action bars for navigation and actions All screens in your app should display action bars to provide consistent navigation and surface important actions. At the top level, special considerations apply to the action bar:  Use the action bar to display your app's icon or title.  If your top level consists of multiple views, or if switching between data from different user accounts is a significant use case, make sure that it's easy for the user to navigate between them by adding view controls to your action bar.  If your app allows people to create content, consider making the content accessible right from the top level.  If your content is searchable, include the Search action in the action bar so people can cut through the navigation hierarchy.
  • 50.
    Email is aboutproductivity, so an efficient, easy-to-skim list with higher data density works well. Navigation supports switching between accounts and recent labels. Icons for creating a new message or searching are prominent in the split action bar at the bottom. Create an identity for your app Creating an identity for your app goes beyond the action bar. Your app communicates its identity through its data, the way that data is arranged, and how people interact with it. Especially for media-rich applications, try to create unique layouts that showcase your data and go beyond the monotony of simple list views.
  • 51.
    The 3D carouselcelebrates cover art and establishes a unique identity for the Music app. Defaulting to the Recent view keeps the focus on music the user has been listening to lately. Categories Generally, the purpose of a deep, data-driven app is to navigate through organizational categories to the detail level, where data can be viewed and managed. Minimize perceived navigation effort by keeping your apps shallow. Even though the number of vertical navigation steps from the top level down to the detail views is typically dictated by the structure of your app's content, there are several ways you can cut down on the perception of onerous navigation. Use tabs to combine category selection and data display This can be successful if the categories are familiar or the number of categories is small. It has the advantage that a level of hierarchy is removed and data remains at the center of the user's attention. Navigating laterally between data-rich categories is more akin to a casual browsing experience than to an explicit navigation step. If the categories are familiar, predictable, or closely related, use scrolling tabs (where not all items are in view simultaneously). Keep the number of scrolling tabs at a manageable level to minimize navigational effort. Rule of thumb: no more than 5–7 tabs.
  • 52.
    The Play Storeapp uses tabs to simultaneously show category choice and content. To navigate between categories, users can swipe left/right on the content. If the categories in the tabs are not closely related, favor fixed tabs, so that all categories are in view at the same time.
  • 53.
    YouTube uses fixedtabs to switch between different, relatively unrelated functional areas. Allow cutting through hierarchies Take advantage of shortcuts that allow people to reach their goals quicker. To allow top-level invocation of actions for a data item from within list or grid views, display prominent actions directly on list view items using drop-downs or split list items. This lets people invoke actions on data without having to navigate all the way down the hierarchy.
  • 54.
    Music allows theuser to act upon a data item (song) from within the category view (album), thereby removing the need to navigate all the way down to the song's detail view. Acting upon multiple data items Even though category views mostly serve to guide people to content detail, keep in mind that there are often good reasons to act on collections of data as well. For example, if you allow people to delete an item in a detail view, you should also allow them to delete multiple items in the category view. Analyze which detail view actions are applicable to collections of items. Then use multi-select to allow application of those actions to multiple items in a category view. Details The detail view allows you to view and act on your data. The layout of the detail view depends on the data type being displayed, and therefore differs widely among apps. Layout
  • 55.
    Consider the activitiespeople will perform in the detail view and arrange the layout accordingly. For immersive content, make use of the lights-out mode to allow for distraction-free viewing of full- screen content.
  • 56.
    Google Books' detailview is all about replicating the experience of reading an actual book. The page-flip animation reinforces that notion. To create an immersive experience the app enters lights-out mode, which hides all system UI affordances. The purpose of the People app's detail view is to surface communication options. The list view allows for efficient scanning and quick access of phone numbers, email addresses and other information items. Split items are used to combine calling and messaging into one compact line item. Make navigation between detail views efficient If your users are likely to want to look at multiple items in sequence, allow them to navigate between items from within the detail view. Use swipe views or other techniques, such as filmstrips, to achieve this. Gmail using swipe views to navigate from detail view to detail view.
  • 57.
    In addition tosupporting swipe gestures to move left or right through images, Gallery provides a filmstrip control that lets people quickly jump to specific images. Checklist  Find ways to display useful content on your start screen.  Use action bars to provide consistent navigation.  Keep your hierarchies shallow by using horizontal navigation and shortcuts.  Use multi-select to allow the user to act on collections of data.  Allow for quick navigation between detail items with swipe views. 4) Navigation with Back and Up Consistent navigation is an essential component of the overall user experience. Few things frustrate users more than basic navigation that behaves in inconsistent and unexpected ways. Android 3.0 introduced significant changes to the global navigation behavior. Thoughtfully following the guidelines for Back and Up will make your app's navigation predictable and reliable for your users.
  • 58.
    Android 2.3 andearlier relied upon the system Back button for supporting navigation within an app. With the introduction of action bars in Android 3.0, a second navigation mechanism appeared: the Up button, consisting of the app icon and a left-point caret. Up vs. Back The Up button is used to navigate within an app based on the hierarchical relationships between screens. For instance, if screen A displays a list of items, and selecting an item leads to screen B (which presents that item in more detail), then screen B should offer an Up button that returns to screen A. If a screen is the topmost one in an app (that is, the app's home), it should not present an Up button. The system Back button is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy. When the previously viewed screen is also the hierarchical parent of the current screen, pressing the Back button has the same result as pressing an Up button—this is a common occurrence. However, unlike the Up button, which ensures the user remains within your app, the Back button can return the user to the Home screen, or even to a different app.
  • 59.
    The Back buttonalso supports a few behaviors not directly tied to screen-to-screen navigation:  Dismisses floating windows (dialogs, popups)  Dismisses contextual action bars, and removes the highlight from the selected items  Hides the onscreen keyboard (IME) Navigation Within Your App Navigating to screens with multiple entry points Sometimes a screen doesn't have a strict position within the app's hierarchy, and can be reached from multiple entry points—such as a settings screen that can be reached from any other screen in your app. In this case, the Up button should choose to return to the referring screen, behaving identically to Back. Changing view within a screen Changing view options for a screen does not change the behavior of Up or Back: the screen is still in the same place within the app's hierarchy, and no new navigation history is created. Examples of such view changes are:  Switching views using tabs and/or left-and-right swipes  Switching views using a dropdown (aka collapsed tabs)  Filtering a list  Sorting a list  Changing display characteristics (such as zooming) Navigating between sibling screens When your app supports navigation from a list of items to a detail view of one of those items, it's often desirable to support direction navigation from that item to another one which precedes or follows it in the list. For example, in Gmail, it's easy to swipe left or right from a conversation to view a newer or older one in the same Inbox. Just as when changing view within a screen, such navigation does not change the behavior of Up or Back.
  • 60.
    However, a notableexception to this occurs when browsing between related detail views not tied together by the referring list—for example, when browsing in the Play Store between apps from the same developer, or albums by the same artist. In these cases, following each link does create history, causing the Back button to step through each previously viewed screen. Up should continue to bypass these related screens and navigate to the most recently viewed container screen.
  • 61.
    You have theability to make the Up behavior even smarter based on your knowledge of detail view. Extending the Play Store example from above, imagine the user has navigated from the last Book
  • 62.
    viewed to thedetails for the Movie adaptation. In that case, Up can return to a container (Movies) which the user hasn't previously navigated through. Navigation into Your App via Home Screen Widgets and Notifications
  • 63.
    You can useHome screen widgets or notifications to help your users navigate directly to screens deep within your app's hierarchy. For example, Gmail's Inbox widget and new message notification can both bypass the Inbox screen, taking the user directly to a conversation view. For both of these cases, handle the Up button as follows:  If the destination screen is typically reached from one particular screen within your app, Up should navigate to that screen.  Otherwise, Up should navigate to the topmost ("Home") screen of your app. In the case of the Back button, you should make navigation more predictable by inserting into the task's back stack the complete upward navigation path to the app's topmost screen. This allows users who've forgotten how they entered your app to navigate to the app's topmost screen before exiting. As an example, Gmail's Home screen widget has a button for diving directly to its compose screen. Up or Back from the compose screen would take the user to the Inbox, and from there the Back button continues to Home. Indirect notifications When your app needs to present information about multiple events simultaneously, it can use a single notification that directs the user to an interstitial screen. This screen summarizes these events, and provides paths for the user to dive deeply into the app. Notifications of this style are called indirect notifications.
  • 64.
    Unlike standard (direct)notifications, pressing Back from an indirect notification's interstitial screen returns the user to the point the notification was triggered from—no additional screens are inserted into the back stack. Once the user proceeds into the app from its interstitial screen, Up and Back behave as for standard notifications, as described above: navigating within the app rather than returning to the interstitial. For example, suppose a user in Gmail receives an indirect notification from Calendar. Touching this notification opens the interstitial screen, which displays reminders for several different events. Touching Back from the interstitial returns the user to Gmail. Touching on a particular event takes the user away from the interstitial and into the full Calendar app to display details of the event. From the event details, Up and Back navigate to the top-level view of Calendar.
  • 65.
    Pop-up notifications Pop-up notificationsbypass the notification drawer, instead appearing directly in front of the user. They are rarely used, and should be reserved for occasions where a timely response is required and the interruption of the user's context is necessary. For example, Talk uses this style to alert the user of an invitation from a friend to join a video chat, as this invitation will automatically expire after a few seconds. In terms of navigation behavior, pop-up notifications closely follow the behavior of an indirect notification's interstitial screen. Back dismisses the pop-up notification. If the user navigates from the pop-up into the notifying app, Up and Back follow the rules for standard notifications, navigating within the app.
  • 66.
    Navigation Between Apps Oneof the fundamental strengths of the Android system is the ability for apps to activate each other, giving the user the ability to navigate directly from one app into another. For example, an app that needs to capture a photo can activate the Camera app, which will return the photo to the referring app. This is a tremendous benefit to both the developer, who can easily leverage code from other apps, and the user, who enjoys a consistent experience for commonly performed actions. To understand app-to-app navigation, it's important to understand the Android framework behavior discussed below. Activities, tasks, and intents In Android, an activity is an application component that defines a screen of information and all of the associated actions the user can perform. Your app is a collection of activities, consisting of both the activities you create and those you re-use from other apps. A task is the sequence of activities a user follows to accomplish a goal. A single task can make use of activities from just one app, or may draw on activities from a number of different apps. An intent is a mechanism for one app to signal it would like another app's assistance in performing an action. An app's activities can indicate which intents they can respond to. For common intents such as "Share", the user may have many apps installed that can fulfill that request. Example: navigating between apps to support sharing To understand how activities, tasks, and intents work together, consider how one app allows users to share content by using another app. For example, launching the Play Store app from Home begins new Task A (see figure below). After navigating through the Play Store and touching a promoted book to see its details, the user remains in the same task, extending it by adding activities. Triggering the Share action prompts the user with a dialog listing each of the activities (from different apps) which have registered to handle the Share intent.
  • 67.
    When the userelects to share via Gmail, Gmail's compose activity is added as a continuation of Task A—no new task is created. If Gmail had its own task running in the background, it would be unaffected. From the compose activity, sending the message or touching the Back button returns the user to the book details activity. Subsequent touches of Back continue to navigate back through the Play Store, ultimately arriving at Home.
  • 68.
    However, by touchingUp from the compose activity, the user indicates a desire to remain within Gmail. Gmail's conversation list activity appears, and a new Task B is created for it. New tasks are always rooted to Home, so touching Back from the conversation list returns there.
  • 69.
    Task A persistsin the background, and the user may return to it later (for example, via the Recents screen). If Gmail already had its own task running in the background, it would be replaced with Task B—the prior context is abandoned in favor of the user's new goal. When your app registers to handle intents with an activity deep within the app's hierarchy, refer to Navigation into Your App via Home Screen Widgets and Notifications for guidance on how to specify Up navigation.
  • 70.
    5) Action Bar Theaction bar is arguably the most important structural element of an Android app. It's a dedicated piece of real estate at the top of each screen that is generally persistent throughout the app. The main purpose of the action bar is to:  Make important actions (such as New or Search, etc) prominent and accessible in a predictable way.  Support consistent navigation and view switching within apps.  Reduce clutter by providing an action overflow for rarely used actions.  Provide a dedicated space for giving your app an identity. If you're new to writing Android apps, note that the action bar is one of the most important design elements you can implement. Following the guidelines described here will go a long way toward making your app's interface consistent with the core Android apps. General Organization The action bar is split into four different functional areas that apply to most apps. 1. App icon The app icon establishes your app's identity. It can be replaced with a different logo or branding if you wish. Important: If the app is currently not displaying the top-level screen, be sure to display the Up caret to the left of the app icon, so the user can navigate up the hierarchy. For more discussion of Up navigation, see the Navigation pattern.
  • 71.
    App icon withand without "up" affordance. 1. View control If your app displays data in different views, this segment of the action bar allows users to switch views. Examples of view-switching controls are drop-down menus or tab controls. If your app doesn't support different views, you can also use this space to display non- interactive content, such as an app title or longer branding information. 2. Action buttons Show the most important actions of your app in the actions section. Actions that don't fit in the action bar are moved automatically to the action overflow. 3. Action overflow Move less often used actions to the action overflow. Adapting to Rotation and Different Screen Sizes One of the most important UI issues to consider when creating an app is how to adjust to screen rotation on different screen sizes. You can adapt to such changes by using split action bars, which allow you to distribute action bar content across multiple bars located below the main action bar or at the bottom of the screen.
  • 72.
    Split action barshowing action buttons at the bottom of the screen in vertical orientation. Layout Considerations for Split Action Bars When splitting up content across multiple action bars, you generally have three possible locations for action bar content: 1. Main action bar 2. Top bar 3. Bottom bar If the user can navigate up the hierarchy from a given screen, the main action bar contains the up caret, at a minimum. To allow the user to quickly switch between the views your app provides, use tabs or a spinner in the top bar. To display actions and, if necessary, the action overflow, use the bottom bar.
  • 73.
    Contextual Action Bars Acontextual action bar (CAB) is a temporary action bar that overlays the app's action bar for the duration of a particular sub-task. CABs are most typically used for tasks that involve acting on selected data or text.
  • 74.
    Contextual action barshown in Browser and Gmail The selection CAB appears after a long press on a selectable data item triggers selection mode. From here the user can:  Select additional elements by touching them.  Trigger an action from the CAB that applies to all selected data items. The CAB then automatically dismisses itself.  Dismiss the CAB via the navigation bar's Back button or the CAB's checkmark button. This removes the CAB along with all selection highlights. Use CABs whenever you allow the user to select data via long press. You can control the action content of a CAB in order to insert the actions you would like the user to be able to perform. For more information, refer to the Selection pattern.
  • 75.
    Action Bar Elements Tabs Tabsdisplay app views concurrently and make it easy to explore and switch between them. Use tabs if you expect your users to switch views frequently. There are two types of tabs: fixed and scrollable. Scrollable tabs Scrollable tabs always take up the entire width of the bar, with the currently active view item in the center, and therefore need to live in a dedicated bar. Scrollable tabs can themselves be scrolled horizontally to bring more tabs into view. Use scrollable tabs if you have a large number of views or if you're unsure how many views will be displayed because your app inserts views dynamically (for example, open chats in a messaging app that the user can navigate between). Scrollable tabs should always allow the user to navigate between the views by swiping left or right on the content area as well as swiping the tabs themselves. Scrolling tabs in the Play Store app. Fixed tabs Fixed tabs are always visible on the screen, and can't be moved out of the way like scrollable tabs. Fixed tabs in the main action bar can move to the top bar when the screen orientation changes.
  • 76.
    Default fixed tabsshown in Holo Dark & Light. Spinners A spinner is a drop-down menu that allows users to switch between views of your app. Use spinners rather than tabs in the main action bar if:  You don't want to give up the vertical screen real estate for a dedicated tab bar.  You expect your app's users to switch views infrequently. Action bar spinner from Calendar application. Action buttons Action buttons on the action bar surface your app's most important activities. Think about which buttons will get used most often, and order them accordingly. Depending on available screen real estate, the system shows your most important actions as action buttons and moves the rest to the action overflow. The action bar and the action overflow should only present actions to the user that are available. If an action is unavailable in the current context, hide it. Do not show it as disabled. A sampling of action buttons used throughout the Gmail application. For guidance on prioritizing actions, use the FIT scheme. F — Frequent  Will people use this action at least 7 out of 10 times they visit the screen?  Will they typically use it several times in a row?  Would taking an extra step every time truly be burdensome?
  • 77.
    I — Important  Do you want everyone to discover this action because it's especially cool or a selling point?  Is it something that needs to be effortless in the rare cases it's needed? T — Typical  Is it typically presented as a first-class action in similar apps?  Given the context, would people be surprised if it were buried in the action overflow? If either F, I, or T apply, then it's appropriate for the action bar. Otherwise, it belongs in the action overflow. Pre-defined glyphs should be used for certain common actions such as "refresh" and "share." The download link below provides a package with icons that are scaled for various screen densities and are suitable for use with the Holo Light and Holo Dark themes. The package also includes unstyled icons that you can modify to match your theme, in addition to Adobe® Illustrator® source files for further customization. Download the Action Bar Icon Pack Action overflow The action overflow in the action bar provides access to your app's less frequently used actions. The overflow icon only appears on phones that have no menu hardware keys. Phones with menu keys display the action overflow when the user presses the key. Action overflow is pinned to the right side. How many actions will fit in the main action bar? Action bar capacity is controlled by the following rules:  Action buttons in the main action bar may not occupy more than 50% of the bar's width. Action buttons on bottom action bars can use the entire width.  The screen width in density-independent pixels (dp) determine the number of items that will fit in the main action bar: o smaller than 360 dp = 2 icons o 360-499 dp = 3 icons o 500-599 dp = 4 icons o 600 dp and larger = 5 icons
  • 78.
    In the abovetable "o" denotes an action bar item and "=" an overflow icon. Sharing data Whenever your app permits sharing of data, such as images or movie clips, use a share action provider in your action bar. The share action provider is designed to speed up sharing by displaying the most recently used sharing service next to a spinner button that contains other sharing options.
  • 79.
    The Gallery app'sshare action provider with extended spinner for additional sharing options. Action Bar Checklist When planning your split action bars, ask yourself questions like these: How important is view navigation to the task? If view navigation is very important to your app, use tabs (for fastest view-switching) or spinners. Which of the app's actions need to be consistently available directly from the action bar, and which can be moved to the action overflow?
  • 80.
    Use the FITscheme to decide if actions are displayed at the top-level or can be moved to the action overflow. If the number of top-level actions exceeds the capacity of the main action bar, display them separately in a bottom action bar. What else is important enough to warrant continuous display? Sometimes it is important to display contextual information for your app that's always visible. Examples are the number of unread messages in a messaging inbox view or the Now Playing information in a music player. Carefully plan which important information you would like to display and structure your action bars accordingly. 6) Multi-pane Layouts When writing an app for Android, keep in mind that Android devices come in many different screen sizes and types. Make sure that your app consistently provides a balanced and aesthetically pleasing layout by adjusting its content to varying screen sizes and orientations. Panels are a great way for your app to achieve this. They allow you to combine multiple views into one compound view when a lot of horizontal screen real estate is available and by splitting them up when less space is available. Combining Multiple Views Into One On smaller devices your content is typically divided into a master grid or list view and a detail view. Touching an item in the master view opens a different screen showing that item's detail information.
  • 81.
    Because tablets havemore screen real estate than phones, you can use panels to combine the related list and detail views into a single compound view. This uses the additional space more efficiently and makes navigating the app easier.
  • 82.
    In general, usethe pane on the right to present more information about the item you selected in the left pane. Make sure to keep the item in the left pane selected in order to establish the relationship between the panels. Compound Views and Orientation Changes Screens should have the same functionality regardless of orientation. If you use a compound view in one orientation, don't split it up when the user rotates the screen. There are several techniques you can use to adjust the layout after orientation change while keeping functional parity intact.
  • 83.
    Stretch/compress Adjust the columnwidth of your left pane to achieve a balanced layout in both orientations. Stack Rearrange the panels on your screen to match the orientation.
  • 84.
    Expand/collapse When the devicerotates, collapse the left pane view to only show the most important information. Provide an expand control that allows the user to bring the left pane content back to its original width and vice versa.
  • 85.
    Show/hide After rotating thedevice, show the right pane in fullscreen view. Use the Up icon in the action bar to show the left panel and allow navigation to a different email. Hide the left panel by touching the content in the detail panel.
  • 86.
    Checklist  Plan in advance on how your app scales to different screen sizes and screen orientations.  Identify the most appropriate method for the panels in your compound views to reorganize themselves when screen orientation changes.  Look for opportunities to consolidate your views into multi-panel compound views.  Make sure that your screens provide functional parity after the screen orientation changes. 7) Swipe Views Efficient navigation is one of the cornerstones of a well-designed app. While apps are generally built in a hierarchical fashion, there are instances where horizontal navigation can flatten vertical hierarchies and make access to related data items faster and more enjoyable. Swipe views allow the user to efficiently move from item to item using a simple gesture and thereby make browsing and consuming data a more fluent experience. Swiping Between Detail Views An app's data is often organized in a master/detail relationship: The user can view a list of related data items, such as images, chats, or emails, and then pick one of the items to see the detail contents in a separate screen.
  • 87.
    Master (left) anddetail (right) views. On a phone, since the master and detail are on separate screens, this typically requires the user to jump back and forth between the list and the detail view, aka "pogo-sticking". In cases where users will want to view multiple detail items in succession, avoid pogo-sticking by using the swipe gesture to navigate to the next/previous detail view.
  • 88.
    Navigating between consecutiveEmail messages using the swipe gesture. Swiping Between Tabs People app with swipe gesture navigation between top-level screens. If your app uses action bar tabs, use swipe to navigate between the different views. Checklist  Use swipe to quickly navigate between detail views or tabs.  Transition between the views as the user performs the swipe gesture. Do not wait for the gesture to complete and then transition between views.  If you used buttons in the past for previous/next navigation, replace them with the swipe gesture.  Consider adding contextual information in your detail view that informs the user about the relative list position of the currently visible item.
  • 89.
    9) Selection Android 3.0introduced the long press gesture—that is, a touch that's held in the same position for a moment—as the global gesture to select data. This affects the way you should handle multi-select and contextual actions in your apps. What has changed? In previous versions of Android, the long press gesture was universally used to display contextual actions for a given data item in a contextual menu. This pattern changed with Android 3.0. The long press gesture is now used to select data, combining contextual actions and selection management functions for selected data into a new element called the contextual action bar (CAB). Traditional use of the long press gesture to show contextual menus. Using the contextual action bar (CAB) The selection CAB is a temporary action bar that overlays your app's current action bar while data is selected. It appears after the user long presses on a selectable data item.
  • 90.
    From here theuser can:  Select additional data items by touching them.  Trigger an action from the CAB that applies to all highlighted data items. The CAB then automatically dismisses itself.  Dismiss the CAB via the navigation bar's Back button or the CAB's checkmark button. This removes the CAB along with all selection highlights. Selecting CAB actions You can decide which actions and elements appear in the CAB. Use the guidelines in the Action Bar patternto decide which items to surface at the top level and which to move to the action overflow. Dynamically adjust CAB actions In most cases you need to adjust the actions in the CAB dynamically as the user adds more items to the selection. Actions that apply to a single selected data item don't necessarily apply to multiple selected data items of the same kind.
  • 91.
    Adjusting actions inthe CAB as additional items are selected. Checklist  Whenever your app supports the selection of multiple data items, make use of the contextual action bar (CAB).  Reserve the long press gesture for selection exclusively. Don't use it to display traditional contextual menus.  If you don't support multi-selection within a list, long press should do nothing.  Plan the actions you want to display inside of a CAB in the same way you would plan the actions inside your app's action bar. 10) Notifications The notification system allows your app to keep the user informed about important events, such as new messages in a chat app or a calendar event. To create an app that feels streamlined, pleasant, and respectful, it is important to design your notifications carefully. Notifications embody your app's voice, and contribute to your app's personality. Unwanted or unimportant notifications can annoy the user, so use them judiciously. When to display a notification
  • 92.
    To create anapplication that people love, it's important to recognize that the user's attention and focus is a resource that must be protected. To use an analogy that might resonate with software developers, the user is not a method that can be invoked to return a value. The user's focus is a resource more akin to a thread, and creating a notification momentarily blocks the user thread as they process and then dismiss the interruptive notification. Android's notification system has been designed to quickly inform users of events while they focus on a task, but it is nonetheless still important to be conscientious when deciding to create a notification. While well behaved apps generally only speak when spoken to, there are some limited cases where an app actually should interrupt the user with an unprompted notification. Notifications should be used primarily for time sensitive events, and especially if these synchronous events involve other people. For instance, an incoming chat is a real time and synchronous form of communication: there is another user actively waiting on you to respond. Calendar events are another good example of when to use a notification and grab the user's attention, because the event is imminent, and calendar events often involve other people. When not to display a notification There are however many other cases where notifications should not be used:  Don't notify the user of information that is not directed specifically at them, or information that is not truly time sensitive. For instance the asynchronous and undirected updates flowing through a social network do not warrant a real time interruption.  Don't create a notification if the relevant new information is currently on screen. Instead, use the UI of the application itself to notify the user of new information directly in context. For instance, a chat application should not create system notifications while the user is actively chatting with another user.  Don't interrupt the user for low level technical operations, like saving or syncing information, or updating an application, if it is possible for the system to simply take care of itself without involving the user.
  • 93.
    Don't interrupt the user to inform them of an error if it is possible for the application to quickly recover from the error on its own without the user taking any action.  Don't use notifications for services that the user cannot manually start or stop.  Don't create superfluous notifications just to get your brand in front of users. Such notifications will only frustrate and likely alienate your audience. The best way to provide the user with a small amount of updated information and to keep them engaged with your application is to develop a widget that they can choose to place on their home screen. Design Guidelines
  • 94.
    Make it personal Fornotifications of items sent by another user (such as a message or status update), include that person's image. Remember to include the app icon as a secondary icon in the notification, so that the user can still identify which app posted it. Navigate to the right place When the user touches a notification, be open your app to the place where the user can consume and act upon the data referenced in the notification. In most cases this will be the detail view of a single data item (e.g. a message), but it might also be a summary view if the notification is stacked (see Stacked notifications below) and references multiple items. If in any of those cases the user is taken to a hierarchy level below your app's top-level, insert navigation into your app's back stack to allow them to navigate to your app's top level using the system back key. For more information, see the chapter on System-to-app navigation in the Navigation design pattern. Timestamps for time sensitive events By default, standard Android notifications include a timestamp in the upper right corner. Consider whether the timestamp is valuable in the context of your notification. If the timestamp is not valuable, consider if the event is important enough to warrant grabbing the user's attention with a notification. If the notification is important enough, decide if you would like to opt out of displaying the timestamp. Include a timestamp if the user likely needs to know how long ago the notification occurred. Good candidates for timestamps include communication notifications (email, messaging, chat, voicemail) where the user may need the timestamp information to understand the context of a message or to tailor a response. Stack your notifications If your app creates a notification while another of the same type is still pending, avoid creating an altogether new notification object. Instead, stack the notification.
  • 95.
    A stacked notificationbuilds a summary description and allows the user to understand how many notifications of a particular kind are pending. Don't: Do: If you keep the summary and detail information on different screens, a stacked notification may need to open to a different place in the app than a single notification. For example, a single email notification should always open to the content of the email, whereas a stacked email notification opens to the Inbox view. Clean up after yourself Just like calendar events, some notifications alert the user to an event that happens at a particular point in time. After that moment has passed, the notification is likely not important to the user anymore, and you should consider removing it automatically. The same is true for active chat conversations or voicemail messages the user has listened to, users should not have to manually dismiss notifications independently from taking action on them. Provide a peek into your notification
  • 96.
    You can providea short preview of your notification's content by providing optional ticker text. The ticker text is shown for a short amount of time when the notification enters the system and then hides automatically. Make notifications optional Users should always be in control of notifications. Allow the user to silence the notifications from your app by adding a notification settings item to your application settings. Use distinct icons By glancing at the notification area, the user should be able to discern what notification types are currently pending. Do:  Look at the notification icons the Android apps already provide and create notification icons for your app that are sufficiently distinct in appearance. Don't:  Use color to distinguish your app from others. Notification icons should generally be monochrome. Interacting With Notifications
  • 97.
    Notifications are indicatedby icons in the notification area and can be accessed by opening the notification drawer. Inside the drawer, notifications are chronologically sorted with the latest one on top. Touching a notification opens the associated app to detailed content matching the notification. Swiping left or right on a notification removes it from the drawer. On tablets, the notification area is integrated with the system bar at the bottom of the screen. The notification drawer is opened by touching anywhere inside the notification area. Ongoing notifications Ongoing notifications keep users informed about an ongoing process in the background. For example, music players announce the currently playing track in the notification system and continue to do so until the user stops the playback. They can also be used to show the user feedback for longer tasks like downloading a file, or encoding a video. Ongoing notifications cannot be manually removed from the notification drawer. Dialogs and toasts are for feedback not notification Your app should not create a dialog or toast if it is not currently on screen. Dialogs and Toasts should only be displayed as the immediate response to the user taking an action inside of your app. For instance, dialogs can be used to confirm that the user understands the severity of an action, and toasts can echo back that an action has been successfully taken.
  • 98.
    10) Settings Settings isa place in your app where users indicate their preferences for how your app should behave. This benefits users because:  You don't need to interrupt them with the same questions over and over when certain situations arise. The settings predetermine what will always happen in those situations (see design principle: Decide for me but let me have the final say).  You help them feel at home and in control (see design principle: Let me make it mine). Flow and Structure Provide access to Settings in the action overflow Settings is given low prominence in the UI because it's not frequently needed. Even if there's room in the action bar, never make Settings an action button. Always keep it in the action overflow and label it "Settings". Place it below all other items except "Help".
  • 99.
    Avoid the temptationto make everything a setting Because Settings is a few navigational steps away, no matter how many items you have, they'll never clutter up the core part of your UI. This may seem like good news, but it also poses a challenge. Settings can be a tempting place to keep a lot of stuff—like a hall closet where things get stashed when you tidy up before company comes over. It's not a place where you spend lots of time, so it's easy to rationalize and ignore its cluttered condition. But when users visit Settings—however infrequently—they'll have the same expectations for the experience as they do everywhere else in your app. More settings means more choices to make, and too many are overwhelming. So don't punt on the difficult product decisions and debates that can bring on the urge to "just make it a setting". For each control you're considering adding to Settings, make sure it meets the bar:
  • 100.
    If you stillhave lots of settings, group related settings together The number of items an average human can hold in short-term memory is 7±2. If you present a list of 10 or more settings (even after applying the criteria above), users will have more difficulty scanning, comprehending, and processing them. You can remedy this by dividing some or all of the settings into groups, effectively turning one long list into multiple shorter lists. A group of related settings can be presented in one of two ways: 1. Under a section divider 2. In a separate subscreen You can use one or both these grouping techniques to organize your app's settings. For example, in the main screen of the Android Settings app, each item in the list navigates to a subscreen of related settings. In addition, the items themselves are grouped under section dividers. Grouping settings is not an exact science, but here's some advice for how to approach it, based on the total number of settings in your app. 7 or fewer Don't group them at all. It won't benefit users and will seem like overkill.
  • 101.
    8 to 10 Trygrouping related settings under 1 or 2 section dividers. If you have any "singletons" (settings that don't relate to any other settings and can't be grouped under your section dividers), treat them as follows:  If they include some of your most important settings, list them at the top without a section divider.  Otherwise, list them at the bottom with a section divider called "OTHER", in order of importance. 11 to 15 Same advice as above, but try 2 to 4 section dividers. Also, try the following to reduce the list:  If 2 or more of the settings are mainly for power users, move them out of your main Settings screen and into an "Advanced" subscreen. Place an item in the action overflow called "Advanced" to navigate to it.  Look for "doubles": two settings that relate to one another, but not to any other settings. Try to combine them into one setting, using the design patterns described later in this section. For example, you might be able to redesign two related checkbox settings into one multiple choice setting. 16 or more If you have any instances of 4 or more related settings, group them under a subscreen. Then use the advice suggested above for the reduced list size. Design Patterns Checkbox Use this pattern for a setting that is either selected or not selected.
  • 102.
    Multiple choice Use thispattern for a setting that needs to present a discrete set of options, from which the user can choose only one.
  • 103.
    Slider Use this patternfor a setting where the range of values are not discrete and fall along a continuum. Date/time Use this pattern for a setting that needs to collect a date and/or time from the user.
  • 104.
    Subscreen navigation Use thispattern for navigating to a subscreen or sequence of subscreens that guide the user through a more complex setup process.  If navigating to a single subscreen, use the same title in both the subscreen and the label navigating to it.  If navigating to a sequence of subscreens (as in this example), use a title that describes the first step in the sequence. List subscreen Use this pattern for a setting or category of settings that contains a list of equivalent items. The label provides the name of the item, and secondary text may be used for status. (In this example, status is reinforced with an icon to the right of the label.) Any actions associated with the list appear in the action bar rather than the list itself.
  • 105.
    Master on/off switch Usethis pattern for a category of settings that need a mechanism for turning on or off as a whole. An on/off switch is placed as the first item in the action bar of a subscreen. When the switch is turned off, the items in the list disappear, replaced by text that describes why the list is empty. If any actions require the switch to be on, they become disabled.
  • 106.
    You can alsoecho the master on/off switch in the menu item that leads to the subscreen. However, you should only do this in cases where users rarely need to access the subscreen once it's initially set up and more often just want to toggle the switch. Individual on/off switch Use this pattern for an individual setting that requires a more elaborate description than can be provided in checkbox form. The on/off switch only appears in the subscreen so that users aren't able to toggle it without also being exposed to the descriptive text. Secondary text appears below the setting label to reflect the current selection. In this example, Android Beam is on by default. Since users might not know what this setting does, we made the status more descriptive than just "On".
  • 107.
    Dependency Use this patternfor a setting that changes availability based on the value of another setting. The disabled setting appears below its dependency, without any indentation. If the setting includes a status line, it says "Unavailable", and if the reason isn't obvious, a brief explanation is included in the status. If a given setting is a dependency to 3 or more settings, consider using a subscreen with a master on/off switch so that your main settings screen isn't cluttered by lots of disabled items.
  • 108.
    Defaults Take great carein choosing default values for each of your settings. Because settings determine app behavior, your choices will contribute to users' first impressions of your app. Even though users can change settings, they'll expect the initial states to be sensible. The following questions (when applicable) may help inform your decisions:  Which choice would most users be likely to choose on their own if there were no default?  Which choice is the most neutral or middle-of-the-road?  Which choice is the least risky, controversial, or over-the-top?  Which choice uses the least amount of battery or mobile data?  Which choice best supports the design principle Never lose my stuff?  Which choice best supports the design principle Only interrupt me if it's important? Writing Guidelines Label clearly and concisely
  • 109.
    Writing a goodlabel for a setting can be challenging because space is very limited. You only get one line, and it's incredibly short on the smallest of devices. Follow these guidelines to make your labels brief, meaningful, and scannable:  Write each label in sentence case (i.e. only the first word and proper nouns are capitalized).  Don't start a label with an instructional verb like "Set", "Change", "Edit", "Modify", "Manage", "Use", "Select", or "Choose". Users already understand that they can do these things to settings.  Likewise, don't end a label with a word like "setting" or "settings". It's already implied.  If the setting is part of a grouping, don't repeat the word(s) used in the section divider or subscreen title.  Avoid starting a label with a negative word like "Don't" or "Never". For example, "Don't allow" could be rephrased to "Block".  Steer clear of technical jargon as much as possible, unless it's a term widely understood by your target users. Use common verbs and nouns to convey the setting's purpose rather than its underlying technology.  Don't refer to the user. For example, for a setting allowing the user to turn notifications on or off, label it "Notifications" instead of "Notify me". Once you've decided on labels for your settings, be sure to preview them on an LDPI handset in portrait to make sure they'll fit everywhere. Secondary text below is for status, not description… Before Ice Cream Sandwich, we often displayed secondary text below a label to further describe it or provide instructions. Starting in Ice Cream Sandwich, we're using secondary text for status. Before Screen timeout Adjust the delay before the screen automatically turns off After Sleep After 10 minutes of activity Status in secondary text has the following benefits:
  • 110.
    Users can see at a glance what the current value of a setting is without having to navigate any further.  It applies the design principle Keep it brief, which users greatly appreciate. …unless it's a checkbox setting There's one important exception to the using secondary text for status: checkbox settings. Here, use secondary text for description, not status. Status below a checkbox is unnecessary because the checkbox already indicates it. The reason why it's appropriate to have a description below a checkbox setting is because—unlike other controls—it doesn't display a dialog or navigate to another screen where additional information can be provided. That said, if a checkbox setting's label is clear enough on its own, there's no need to also provide a description. Only include one if necessary. Follow these guidelines to write checkbox setting descriptions:  Keep it to one sentence and don't use ending punctuation.  Convey what happens when the setting is checked, phrased in the form of a command. Example: "Allow data exchange", not "Allows data exchange".  Avoid repetition by choosing words that don't already appear in the label.  Don't refer to the user unless it's necessary for understanding the setting.  If you must refer to the user, do so in the second person ("you") rather than the first person ("I"). Android speaks to users, not on behalf of them. Writing examples The following are examples of changes we made to labels and secondary text in the Settings app in Ice Cream Sandwich. Before Use tactile feedback After Vibrate on touch In this checkbox setting, we eliminated the throwaway word "Use" and rephrased the label to be more direct and understandable. Before Screen timeout
  • 111.
    Screen timeout Adjustthe delay before the screen automatically turns off After Sleep After 10 minutes of activity In this multiple choice setting, we changed the label to a friendlier term and also replaced the description with status. We put some descriptive words around the selected value, "10 minutes", because on its own, the meaning could be misinterpreted as "sleep for 10 minutes". Before Change screen lock Change or disable pattern, PIN, or password security After Screen lock Pattern This setting navigates to a a sequence of subscreens that allow users to choose a type of screen lock and then set it up. We eliminated the throwaway word "Change" in the label, and replaced the description with the current type of screen lock set up by the user. If the user hasn't set up a screen lock, the secondary text says "None". Before
  • 112.
    NFC Use Near Field Communication to read and exchange tags After NFC Allow data exchange when the phone touches another device In this checkbox setting—although it's technical jargon—we kept the "NFC" label because: (1) we couldn't find a clear, concise alternative, and (2) user familiarity with the acronym is expected to increase dramatically in the next couple of years. We did, however, rewrite the description. It's far less technical than before and does a better job of conveying how and why you'd use NFC. We didn't include what the acronym stands for because it doesn't mean anything to most users and would have taken up a lot of space. Checklist  Make sure each item in Settings meets the criteria for belonging there.  If you have more than 7 items, explore ways to group related settings.  Use design patterns wherever applicable so users don't face a learning curve.  Choose defaults that are safe, neutral, and fit the majority of users.  Give each setting a clear, concise label and use secondary text appropriately. 11) Backwards Compatibility Significant changes in Android 3.0 included:
  • 113.
    Deprecation of navigation hardware keys (Back, Menu, Search, Home) in favor of handling navigation via virtual controls (Back, Home, Recents).  Robust pattern for the use of menus in action bars. Android 4.0 brings these changes for tablets to the phone platform. Adapting Android 4.0 to Older Hardware and Apps Phones with virtual navigation controls Android apps written for Android 3.0 and later display actions in the action bar. Actions that don't fit in the action bar or aren't important enough to be displayed at the top level appear in the action overflow. Users access the action overflow by touching it in the action bar. Phones with physical navigation keys Android phones with traditional navigation hardware keys don't display the virtual navigation bar at the bottom of the screen. Instead, the action overflow is available from the menu hardware key. The resulting actions popup has the same style as in the previous example, but is displayed at the bottom of the screen.
  • 114.
    Legacy apps onphones with virtual navigation controls When you run an app that was built for Android 2.3 or earlier on a phone with virtual navigation controls, an action overflow control appears at the right side of the virtual navigation bar. You can touch the control to display the app's actions in the traditional Android menu styling.
  • 115.
    12) Pure Android Mostdevelopers want to distribute their apps on multiple platforms. As you plan your app for Android, keep in mind that different platforms play by different rules and conventions. Design decisions that make perfect sense on one platform will look and feel misplaced in the context of a different platform. While a "design once, ship anywhere" approach might save you time up-front, you run the very real risk of creating inconsistent apps that alienate users. Consider the following guidelines to avoid the most common traps and pitfalls. Don't mimic UI elements from other platforms Platforms typically provide a carefully designed set of UI elements that are themed in a very distinctive fashion. For example, some platforms advocate rounded corners for their buttons, others use gradients in their title bars. In some cases, elements may have the same purpose, but are designed to work a bit differently. As you build your app for Android, don't carry over themed UI elements from other platforms and don't mimic their specific behaviors. Review the Building Blockssection in this styleguide to learn about Android's most important UI elements and the way they look in the system default themes. Also examine Android's platform apps to get a sense of how elements are applied in the context of an app. If you want to customize the theme of UI elements, customize carefully according to your specific branding - and not according to the conventions of a different platform. Sampling of UI elements from Android, iOS and Windows Phone 7. Don't carry over platform-specific icons
  • 116.
    Platforms typically providesets of icons for common functionality, such as sharing, creating a new document or deleting. As you are migrating your app to Android, please swap out platform-specific icons with their Android counterparts. You can find a wide variety of icons for use in your app on the Downloads page. Sampling of icons from Android, iOS and Windows Phone 7. Don't use bottom tab bars Other platforms use the bottom tab bar to switch between the app's views. Per platform convention, Android's tabs for view control are shown in action bars at the top of the screen instead. In addition, Android apps may use a bottom bar to display actions on a split action bar. You should follow this guideline to create a consistent experience with other apps on the Android platform and to avoid confusion between actions and view switching on Android. For more information on how to properly use action bars for view control, see Action Bars.
  • 117.
    Android dialer withtabs in an action bar vs. bottom tabs in iOS. Don't hardcode links to other apps In some cases you might want your app to take advantage of another app's feature set. For example, you may want to share the content that your app created via a social network or messaging app, or view the content of a weblink in a browser. Don't use hard-coded, explicit links to particular apps to achieve this. Instead, use Android's intent API to launch an activity chooser which lists all applications that are set up to handle the particular request. This lets the user complete the task with their preferred app. For sharing in particular, consider using theShare Action Provider in your action bar to provide faster access to the user's most recently used sharing target.
  • 118.
    Link to otherapps with the activity chooser or use the Share Action Provider in the action bar. Don't use labeled back buttons on action bars Other platforms use an explicit back button with label to allow the user to navigate up the application's hierarchy. Instead, Android uses the main action bar's app icon for hierarchical navigation and the navigation bar's back button for temporal navigation. For more information, please review theNavigation pattern. Follow this guideline to provide a consistent navigation experience across the platform.
  • 119.
    Android action barwith up caret vs. iOS labeled "Back" button. Don't use right-pointing carets on line items A common pattern on other platforms is the display of right-pointing carets on line items that allow the user to drill deeper into additional content. Android does not use such indicators on drill-down line items. Avoid them to stay consistent with the platform and in order to not have the user guess as to what the meaning of those carets may be.
  • 120.
    Android settings withoutright-pointing carets in line items vs. iOS settings. Device Independence Remember that your app will run on a wide variety of different screen sizes. Create visual assets for different screen sizes and densities and make use of concepts such as multi-pane layouts to appropriately scale your UI on different device form factors. For more information, read Devices and Displays as well as Multi-pane Layouts in this design guide.
  • 121.
    IV. Building Blocks Yourinventory of ready-to-use elements for creating outstanding apps. Tabs 1) Tabs Tabs in the action bar make it easy to explore and switch between different views or functional aspects of your app, or to browse categorized data sets.
  • 122.
    Scrollable Tabs Scrolling tabcontrols can contain a larger number of items than a standard tab control. To navigate to the next/previous view, swipe left or right. Scrolling tabs in the Play Store app. Fixed Tabs Fixed tabs display all items concurrently. To navigate to a different view, touch the tab. Tabs in Holo Dark & Light. Tabs in the YouTube app. Stacked Tabs If view navigation is essential to your app, you can break out tabs into a separate action bar. This permits fast view switching even on narrower screens.
  • 123.
    2) Lists Lists presentmultiple line items in a vertical arrangement. They can be used for data selection as well as drilldown navigation.
  • 124.
    1. Section Divider Use section dividers to organize the content of your list into groups and facilitate scanning. 2. Line Items List items can accommodate a wide range of data types in different arrangements, including simple single-line items, multi-line items, and custom items with icons, checkboxes, and action buttons. 3) Grid Lists
  • 125.
    Grid lists arean alternative to standard list views. They are best suited for showing data sets that represent themselves through images. In contrast to simple lists, grid lists may scroll either vertically or horizontally. Generic Grids The items in a grid list are arranged in two dimensions, one of which is fixed when scrolling content. The scrolling direction dictates the ordering of the items within the grid list. Since the scrolling direction is not deterministic, make it easy for the user to determine the orientation by cutting off grid items to communicate where the overflow is located. Avoid creating grid lists that scroll in two dimensions. Vertical scrolling Vertically scrolling grid list items are sorted in traditional western reading direction: left-to-right and top-down. When displaying the list, cut off the items in the bottom row to communicate that
  • 126.
    the user canscroll the list down to show additional items. Be sure to retain this scheme when the user rotates the screen. Horizontal scrolling Horizontally scrolling lists fix the vertical axis of the item grid. Compared to vertically scrolling lists, the sorting changes slightly to a top-down and left-to-right arrangement. Employ the same technique of cutting off the items in the rightmost column to indicate the scrolling direction. Don't use scrolling tabs as a means to switch views in conjunction with horizontally scrolling grid lists, because the horizontal gesture for view and content navigation will conflict. If you show scrolling tabs for view navigation together with a grid list, use vertical grid scrolling for list navigation. Grid List with Labels Use labels to display additional contextual information for your grid list items.
  • 127.
    Style Use semi-transparent panelson top of the grid list items to display your labels. This allows you to control the contrast and ensures legibility of the labels while letting the content "shine through". 4) Scrolling Scrolling allows the user to navigate to content in the overflow using a swipe gesture. The scrolling speed is proportional to the speed of the gesture. Scroll Indicator Appears during scrolling to indicate what portion of the content is currently in view. Index Scrolling In addition to traditional scrolling, a long alphabetical list can also offer index scrolling: a way to quickly navigate to the items that begin with a particular letter. With index scrolling, a scroll indicator appears even when the user isn't scrolling. Touching or dragging it causes the current letter to pop up in a prominent way. 5) Spinners Spinners provide a quick way to select one value from a set. In the default state, a spinner shows its currently selected value. Touching the spinner displays a dropdown menu with all other available values, from which the user can select a new one.
  • 128.
    Spinners in forms Spinnersare useful for data picking in forms. They are compact and integrate nicely with other components. Use spinners in forms for both simple data input and in combination with other input fields. For example, a text field might let you edit an email address for a contact, while its associated spinner allows you to select whether it's a Home or Work address. Spinners in action bars Use spinners in action bars to switch views. For example, Gmail uses a spinner to permit switching between accounts or commonly used labels. Spinners are useful when changing the view is important to your app, but not necessarily a frequent occurrence. In cases where view switching is frequent, use tabs.
  • 129.
    Spinners in theHolo Dark and Holo Light themes, in various states. 6) Buttons A button consists of text and/or an image that clearly communicates what action will occur when the user touches it. Android supports two different types of buttons: basic buttons and borderless buttons. Both can contain text labels and/or images. Basic Buttons Basic buttons are traditional buttons with borders and background. Android supports two styles for basic buttons: default and small. Default buttons have slightly larger font size and are optimized for display outside of form content. Small buttons are intended for display alongside other content. They have a smaller font and smaller minimum height. Use small buttons in forms where they need to align with other UI elements.
  • 130.
    Default buttons inHolo Dark & Light. Small buttons in Holo Dark & Light. Borderless Buttons Borderless buttons resemble basic buttons except that they have no borders or background. You can use borderless buttons with both icons and text. Borderless buttons are visually more lightweight than basic buttons and integrate nicely with other content. 7) Text Fields Text fields allow the user to type text into your app. They can be either single line or multi-line. Touching a text field places the cursor and automatically displays the keyboard. In addition to typing, text fields allow for a variety of other activities, such as text selection (cut, copy, paste) and data lookup via auto-completion. Single line and multi line
  • 131.
    Single-line fields automaticallyscroll their content to the left as the text input cursor reaches the right edge of the input field. Multi-line text fields automatically break to a new line for overflow text and scroll vertically when the cursor reaches the lower edge. Text field types Text fields can have different types, such as number, message, or email address. The type determines what kind of characters are allowed inside the field, and may prompt the virtual keyboard to optimize its layout for frequently used characters. Auto-complete text fields Use auto-complete text fields to present real-time completions or search results in popups, so users can enter information more accurately and efficiently. Text Selection Users can select any word in a text field with a long press. This action triggers a text selection mode that facilitates extending the selection or choosing an action to perform on the selected text. Selection mode includes:
  • 132.
    1. Contextual actionbar A contextual action bar (CAB) displays the actions available to perform on the selection: typically cut, copy, and paste, but apps can insert additional commands as needed. 2. Selection handles Selection handles can be dragged to select more or less text while remaining in selection mode. 8) Seek Bars and Sliders Interactive sliders make it possible to select a value from a continuous or discrete range of values by moving the slider thumb. The smallest value is to the left, the largest to the right. The interactive nature of the slider makes it a great choice for settings that reflect intensity levels, such as volume, brightness, or color saturation.
  • 133.
    Example Interactive slider toset the ringer volume. The value can either be set through the hardware volume controls or interactively via a gesture. Seek bars in Holo Light & Dark 9) Progress and Activity When an operation of interest to the user is taking place over a relatively long period of time, provide visual feedback that it's still happening and in the process of being completed. Progress If you know the percentage of the operation that has been completed, use a determinate progress bar to give the user a sense of how much longer it will take.
  • 134.
    The progress barshould always travel from 0% to 100% completion. Avoid setting the bar to a lower value than a previous value, or using the same progress bar to represent the progress of multiple events, since doing so makes the display meaningless. If you're not sure how long a particular operation will take, use an indeterminate progress indicator. Progress bar in Holo Dark and Holo Light. Activity If you don't know how much longer an operation will continue, use an indeterminate progress indicator. There are two styles available: a flat bar and a circle. Use the one that best fits the available space.
  • 135.
    1. Activity bar(shown with the Holo Dark theme) An indeterminate activity bar is used at the start of an application download because the Play Store app hasn't been able to contact the server yet, and it's not possible to determine how long it will take for the download to begin. 1. Activity circle (shown with the Holo Light theme) An indeterminate activity circle is used in the Gmail application when a message is being loaded because it's not possible to determine how long it will take to download the email.
  • 136.
    You should onlyuse one activity indicator on screen per activity, and it should appropriately sized for the surrounding context. For example, the largest activity circle works well when displayed in a blank content area, but not in a smaller dialog box. 10) Switches Switches allow the user to select options. There are three kinds of switches: checkboxes, radio buttons, and on/off switches. Checkboxes Checkboxes allow the user to select multiple options from a set. Avoid using a single checkbox to turn an option off or on. Instead, use an on/off switch. Radio Buttons Radio buttons allow the user to select one option from a set. Use radio buttons for exclusive selection if you think that the user needs to see all available options side-by-side. Otherwise, consider a spinner, which uses less space.
  • 137.
    On/off Switches On/off switchestoggle the state of a single settings option. 11) Dialogs Dialogs prompt the user for decisions or additional information required by the app to continue a task. Such requests can range from simple Cancel/OK decisions to more complex layouts asking the user to adjust settings or enter text.
  • 138.
    1. Optional titleregion The title introduces the content of your dialog. It can, for example, identify the name of a setting that the user is about to change, or request a decision. 2. Content area Dialog content varies widely. For settings dialogs, a dialog may contain UI elements such as sliders, text fields, checkboxes, or radio buttons that allow the user to change app or system settings. In other cases, such as alerts, the content may consist solely of text that provides further context for a user decision. 3. Action buttons Action buttons are typically Cancel and/or OK, with OK indicating the preferred or most likely action. However, if the options consist of specific actions such as Close or Wait rather than a confirmation or cancellation of the action described in the content, then all the buttons should be active verbs. As a rule, the dismissive action of a dialog is always on the left whereas the affirmative actions are on the right.
  • 139.
    Samples of typicaldialog use in Android. Alerts Alerts inform the user about a situation that requires their confirmation or acknowledgement before proceeding. They differ slightly in appearance based upon the severity and impact of the message conveyed. Alerts without title bars Most alerts don't need titles. Usually the decision doesn't have a severe impact and can be summed up succinctly in a sentence or two. The content area should either ask a question (such as
  • 140.
    "Delete this conversation?")or make a clear statement whose relationship to the action buttons is obvious. Alerts with title bars Use alerts with title bars sparingly. They are appropriate only when a high-risk operation involving potential loss of data, connectivity, extra charges, and so on requires a clear question or statement (the title) and some additional explanation (in the content area). Keep the question or statement short: for example, "Erase USB storage?" Avoid apologies. A user should be able to skip the content completely and still have a clear idea of what choices are available based on the title and the text of the action buttons. Popups Popups are lightweight version of dialogs that require a single selection from the user. Popups don't have have explicit buttons that accept or cancel the operation. Instead, making a selection advances the workflow, and simply touching outside the popup dismisses it.
  • 141.
    Toasts Toasts provide lightweightfeedback about an operation in a small popup. For example, navigating away from an email before you send it triggers a "Draft saved" toast to let you know that you can continue editing later. Toasts automatically disappear after a timeout.
  • 142.
    12) Pickers Pickers providea simple way to select a single value from a set. In addition to touching the up/down arrow buttons, it's possible to set the desired value from the keyboard or via a swipe gesture. Space considerations Pickers can be used inline on a form, but their relatively large footprint is best suited for display in a dialog. For inline display, consider using more compact controls such as text fields or spinners. Date and time pickers Android provides these as ready-to-use dialogs. Each picker is a dialog with a set of controls for entering the parts of the date (month, day, year) or time (hour, minute, AM/PM). Using these in your app helps ensure that a user's specification of a data or time input is valid and formatted correctly. The format of a time and date picker adjusts automatically to the locale.