docand 1 design methods

Portions of this Book are reproduced from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License. The derivitive website is devloper.android.com. The source url of the original document is included under each section title. Each Section is covered by the aforementioned License. Code Samples are included under the Apache 2.0 License. Each section has the approriate link, and associated license at the footer of the page.

The Creative Commons License & Apache License are available at the end of this book.

E&OE Errors and omissions excepted or excluded. All other sections of the document, that are not attributed to other source organisations are under Copyright © 2013 by Docand using the Creative Commons Attribution-NonCommercial 3.0 Unported License.

First Edition: October 2013

www.DocAnd.com

Introduction of 202 Content from developer.android.com/design/get-started/creative-vision.html through their Creative Commons Attribution 2.5 license

http://code.google.com/policies.html

http://code.google.com/policies.html

http://creativecommons.org/licenses/by/2.5/

http://en.wiktionary.org/wiki/error

http://en.wiktionary.org/wiki/and

http://en.wiktionary.org/wiki/omission

http://en.wiktionary.org/wiki/except

http://en.wiktionary.org/wiki/exclude

http://www.docand.com/

1.Introduction

This publication seriues has been created for the developers of Android™ applications. Personnally I like flip through a book, to know that I’ve covered everything in it. The website for the developers is fantstic and very comprehensive, I just wanted a publication that I could reference and read through from front to back, to know I had covered everything that I should know about. To this end, I created these documents to fullfil my own requirements, and I hope that it fullfils some of your requirements to get started, and to keep upto date with the latest information.

Android is a trademark of Google Inc.

Introduction of 202 Content from developer.android.com/design/get-started/creative-vision.html through their Creative Commons Attribution 2.5 license

2.Contents

1. INTRODUCTION ....................................... 3 2. CONTENTS ................................................. 4 3. CREATIVE VISION ................................... 9

Enchant me ...................................................................... 9 Simplify my life .............................................................. 9 Make me amazing......................................................... 9

4. DESIGN PRINCIPLES ............................ 10 ENCHANT ME ........................................................ 10

Delight me in surprising ways ............................ 10 Real objects are more fun than buttons and menus.............................................................................. 10 Let me make it mine................................................. 10 Get to know me .......................................................... 11

SIMPLIFY MY LIFE ............................................... 11 Keep it brief .................................................................. 11 Pictures are faster than words ........................... 12 Decide for me but let me have the final say .. 12 Only show what I need when I need it ............ 13 I should always know where I am ..................... 14 Never lose my stuff ................................................... 14 If it looks the same, it should act the same ... 14 Only interrupt me if it's important ................... 15

MAKE ME AMAZING ............................................ 15 Give me tricks that work everywhere ............. 15 It's not my fault .......................................................... 16 Sprinkle encouragement ....................................... 16 Do the heavy lifting for me ................................... 16 Make important things fast .................................. 17

5. UI OVERVIEW ........................................ 18 HOME, ALL APPS, AND RECENTS....................... 18

Home screen ................................................................ 18 All apps screen ............................................................ 19 Recents screen ............................................................ 20

SYSTEM BARS ....................................................... 20 • Status Bar ................................................................. 21 • Navigation Bar........................................................ 21 • Combined Bar ......................................................... 21

NOTIFICATIONS .................................................... 21 COMMON APP UI .................................................. 22

• Main Action Bar ..................................................... 23 • View Control............................................................ 23 • Content Area ........................................................... 24 • Split Action Bar ...................................................... 24

6. DEVICES AND DISPLAYS .................... 26 Be flexible ...................................................................... 26 Optimize layouts ........................................................ 26 Assets for all ................................................................. 26 Strategies ....................................................................... 26

7. THEMES ................................................... 28 8. TOUCH FEEDBACK............................... 31

States ............................................................................... 31 Communication .......................................................... 31

Boundaries ................................................................... 33 9. METRICS AND GRIDS ........................... 34

Space considerations ............................................... 34 48DP RHYTHM ..................................................... 34

Why 48dp?.................................................................... 34 Mind the gaps .............................................................. 35

EXAMPLES ............................................................. 35 10. TYPOGRAPHY ..................................... 36

Default type colors ................................................... 37 Typographic Scale ..................................................... 37

11. COLOR .................................................... 39 PALETTE ............................................................... 39

12. ICONOGRAPHY ................................... 40 LAUNCHER ............................................................ 40

Sizes & scale ................................................................. 41 Proportions .................................................................. 42 Style ................................................................................. 42

ACTION BAR ......................................................... 42 Sizes & scale ................................................................. 43 Focal area & proportions ....................................... 44 Style ................................................................................. 44 Colors .............................................................................. 44

SMALL / CONTEXTUAL ICONS ........................... 44 Sizes & scale ................................................................. 45 Focal area & proportions ....................................... 45 Style ................................................................................. 45 Colors .............................................................................. 46

NOTIFICATION ICONS .......................................... 46 Sizes & scale ................................................................. 47 Focal area & proportions ....................................... 47 Style ................................................................................. 47 Colors .............................................................................. 47

DESIGN TIPS ......................................................... 48 Use vector shapes where possible ........... 48 Start with large artboards ........................ 48 When scaling, redraw bitmap layers as needed ................................................................. 48 Use common naming conventions for icon assets .......................................................... 49 Set up a working space that organizes files by density ................................................. 49 Remove unnecessary metadata from final assets ......................................................... 50

13. WRITING STYLE ................................. 51 EXAMPLES ............................................................. 51

14. NEW IN ANDROID .............................. 54 JELLY BEAN - ANDROID 4.1 ............................... 54

Notifications ................................................................ 54 Resizable Application Widgets ........................... 54 Accessibility ................................................................. 55

ICE CREAM SANDWICH - ANDROID 4.0 ........... 55 Contents of 202

Content from developer.android.com/design/get-started/creative-vision.html through their Creative Commons Attribution 2.5 license

Navigation bar ............................................................ 55 Action bar ...................................................................... 56 Multi-pane layouts .................................................... 56 Selection ........................................................................ 56

15. GESTURES ............................................ 57 Touch............................................................................... 57 • Action ..................................................................... 57 Long press ..................................................................... 58 • Action ..................................................................... 58 Swipe ............................................................................... 59 • Action ..................................................................... 59 Drag .................................................................................. 59 • Action ..................................................................... 59 Double touch ............................................................... 60 • Action ..................................................................... 60 Pinch open .................................................................... 60 • Action ..................................................................... 61 Pinch close .................................................................... 61 • Action ..................................................................... 61

16. APPLICATION STRUCTURE ............ 62 GENERAL STRUCTURE ......................................... 62

Top level views ........................................................... 62 Category views ........................................................... 62 Detail/edit view ......................................................... 63

TOP LEVEL ............................................................ 63 Put content forward ................................................. 63 Create an identity for your app .......................... 63 Set up action bars for navigation and actions ............................................................................................ 64

TOP LEVEL SWITCHING WITH VIEW CONTROLS ................................................................................. 65

Fixed tabs ...................................................................... 65 Spinners ......................................................................... 65 Navigation drawers .................................................. 66 Don't mix and match ................................................ 67

CATEGORIES .......................................................... 67 Use tabs to combine category selection and data display .................................................................. 67 Allow cutting through hierarchies .................... 69 Acting upon multiple data items ........................ 70

DETAILS ................................................................. 70 Layout ............................................................................. 70 Lights-out mode ......................................................... 71 Make navigation between detail views efficient .......................................................................... 72

CHECKLIST ............................................................ 73 17. NAVIGATION WITH BACK AND UP 74

Developer Docs ............................................... 74 UP VS. BACK .......................................................... 74 NAVIGATION WITHIN YOUR APP ...................... 75

Navigating to screens with multiple entry points .............................................................................. 75 Changing view within a screen ........................... 75 Navigating between sibling screens ................. 75

NAVIGATION INTO YOUR APP VIA HOME SCREEN WIDGETS AND NOTIFICATIONS .......... 78

Indirect notifications ............................................... 79 Pop-up notifications................................................. 80

NAVIGATION BETWEEN APPS ............................ 81 Activities, tasks, and intents................................. 81 Example: navigating between apps to support sharing ............................................................................ 82

18. ACTION BAR ........................................ 85 Developer Docs ................................................ 85

GENERAL ORGANIZATION .................................. 85 • App icon .................................................................... 85 • View control ............................................................ 85 • Action buttons ........................................................ 86 • Action overflow ..................................................... 86

ADAPTING TO ROTATION AND DIFFERENT SCREEN SIZES ....................................................... 86 LAYOUT CONSIDERATIONS FOR SPLIT ACTION BARS ...................................................................... 86 ACTION BUTTONS................................................ 87

Action overflow .......................................................... 88 Sharing data ................................................................. 88

CONTEXTUAL ACTION BARS .............................. 89 ACTION BAR CHECKLIST .................................... 90

How important is view navigation to the task? ............................................................................................ 90 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?....................................................................... 90 What else is important enough to warrant continuous display? ................................................. 90

19. NAVIGATION DRAWER .................... 92 Developer Docs ................................................ 92

Displaying the navigation drawer ..................... 92 Dismissing the navigation drawer .................... 92

WHEN TO USE THE NAVIGATION DRAWER .... 93 More than 3 top-level views ................................ 93 Cross-navigation from lower levels ................. 93 Deep navigation branches .................................... 93

NAVIGATION HUBS .............................................. 94 CONTENT OF THE NAVIGATION DRAWER ....... 95

Titles, icons, and counters .................................... 96 Collapsible navigation items ................................ 97

NAVIGATION DRAWERS AND ACTION BARS ... 97 Actions ............................................................................ 98 Contextual action bars ............................................ 99

INTERACTION DETAILS....................................... 99 Introduce the user to the drawer at first use ............................................................................................ 99 Give the user a quick peek ..................................100 Highlights ....................................................................100

IMPACT OF DRAWER ON OVERALL APP NAVIGATION ....................................................... 100

System Back at the top level of the app ........100 System Back after cross navigation to lower hierarchy levels ........................................................101

STYLE................................................................... 101 NAVIGATION DRAWER CHECKLIST ................ 102

20. MULTI-PANE LAYOUTS ................. 103 Developer Docs ............................................. 103

COMBINING MULTIPLE VIEWS INTO ONE ..... 103 COMPOUND VIEWS AND ORIENTATION CHANGES ............................................................. 104

Stretch/compress ...................................................104 Stack ..............................................................................105 Expand/collapse ......................................................105 Show/hide ..................................................................106

CHECKLIST .......................................................... 106 21. SWIPE VIEWS ................................... 107

Contents of 202 Content from developer.android.com/design/get-started/creative-vision.html through their Creative Commons Attribution 2.5 license

Developer Docs ............................................. 107 SWIPING BETWEEN DETAIL VIEWS ............... 107 SWIPING BETWEEN TABS ................................ 108

22. SELECTION ........................................ 110 Developer Docs ............................................. 110

What has changed? ................................................ 110 Using the contextual action bar (CAB) ......... 110 Selecting CAB actions ........................................... 111 Dynamically adjust CAB actions ...................... 111

CHECKLIST ......................................................... 112 23. CONFIRMING & ACKNOWLEDGING 113

WHEN TO CONFIRM OR ACKNOWLEDGE USER ACTIONS.............................................................. 113 CONFIRMING ...................................................... 114

Example: Google Play Books ............................. 114 Example: Android Beam ..................................... 115

ACKNOWLEDGING ............................................. 116 Example: Abandoned Gmail draft saved ..... 116 Example: Gmail conversation deleted .......... 117

NO CONFIRMATION OR ACKNOWLEDGMENT 117 Example: +1'ing ....................................................... 117 Example: Removing an app from the Home Screen .......................................................................... 117

24. NOTIFICATIONS ............................... 119 Developer Docs ............................................. 119

New in Jelly Bean .................................................... 119 ANATOMY OF A NOTIFICATION ....................... 119

Base Layout ............................................................... 119 Expanded layouts ................................................... 120 Actions ......................................................................... 120

DESIGN GUIDELINES ......................................... 121 Make it personal ..................................................... 121 Navigate to the right place ................................. 121 Correctly set and manage notification priority ......................................................................................... 121 Stack your notifications ...................................... 122 Make notifications optional ............................... 122 Use distinct icons .................................................... 123 Pulse the notification LED appropriately ... 123

BUILDING NOTIFICATIONS THAT USERS CARE ABOUT ................................................................. 123

When to display a notification ......................... 123 When not to display a notification ................. 124

INTERACTING WITH NOTIFICATIONS ............ 125 Ongoing notifications ........................................... 126 Dialogs and toasts are for feedback not notification ................................................................ 126

25. WIDGETS ............................................ 127 Developer Docs ............................................. 127

WIDGET TYPES .................................................. 127 Information widgets ................................... 127 Collection widgets ....................................... 127 Control widgets............................................. 128 Hybrid widgets .............................................. 129

WIDGET LIMITATIONS ...................................... 129 Gestures ............................................................ 129 Elements........................................................... 130

DESIGN GUIDELINES ......................................... 130 Widget content ............................................. 130

Widget navigation ...................................... 130 Widget resizing ............................................ 131 Layout considerations .............................. 131 Widget configuration ................................ 132

CHECKLIST .......................................................... 132 26. SETTINGS ........................................... 133

Developer Docs ............................................. 133 FLOW AND STRUCTURE .................................... 133

Provide access to Settings in the action overflow .......................................................................133 Avoid the temptation to make everything a setting ...........................................................................133 If you still have lots of settings, group related settings together ......................................................134 • Under a section divider....................................134 • In a separate subscreen ...................................134 7 or fewer ....................................................................135 8 to 10 ...........................................................................135 11 to 15 ........................................................................135 16 or more ..................................................................135

DESIGN PATTERNS ............................................ 135 Checkbox .....................................................................136 Multiple choice .........................................................136 Slider .............................................................................137 Date/time ....................................................................137 Subscreen navigation ............................................138 List subscreen ...........................................................138 Master on/off switch .............................................139 Individual on/off switch ......................................140 Dependency ...............................................................141

DEFAULTS ........................................................... 141 WRITING GUIDELINES ...................................... 142

Label clearly and concisely .................................142 Secondary text below is for status, not description… ..............................................................142 …unless it's a checkbox setting ........................143 Writing examples ....................................................143

CHECKLIST .......................................................... 144 27. HELP .................................................... 145

DESIGNING HELP INTO YOUR APP .................. 145 Don't show unsolicited help, except in very limited cases ........................................ 145 Follow the standard design for navigating to help ....................................... 146 Assume that every call for help is urgent ............................................................................. 147

Don't ..............................................................................148 Better ............................................................................148 Even Better .................................................................148

PRINCIPLES FOR WRITING ON-SCREEN HELP CONTENT ............................................................ 149

Help is part of the UI ..............................................149 Make every pixel count ........................................149 Pictures are faster than words .........................149 Help me scan, not read .........................................149 Take me straight to the answer........................149

28. BACKWARDS COMPATIBILITY .. 150 Developer Docs ............................................. 150

ADAPTING ANDROID 4.0 TO OLDER HARDWARE AND APPS ............................................................ 150

Phones with virtual navigation controls ......150 Phones with physical navigation keys ..........150


Legacy apps on phones with virtual navigation controls ................................................ 151

29. ACCESSIBILITY ................................. 153 Developer Docs ............................................. 153

ANDROID'S ACCESSIBILITY TOOLS ................. 153 GUIDELINES ........................................................ 153

Make navigation intuitive .................................. 153 Use recommended touch target sizes .......... 153 Label visual UI elements meaningfully ........ 154 Provide alternatives to affordances that time out .................................................................................. 154 Use standard framework controls or enable TalkBack for custom controls .......................... 155 Try it out yourself .................................................. 155

CHECKLIST ......................................................... 155 30. PURE ANDROID ................................ 156

Don't mimic UI elements from other platforms ......................................................................................... 156 Don't carry over platform-specific icons .... 156 Don't use bottom tab bars .................................. 157 Don't hardcode links to other apps ............... 157 Don't use labeled back buttons on action bars ......................................................................................... 158 Don't use right-pointing carets on line items ......................................................................................... 159

DEVICE INDEPENDENCE ................................... 160 31. TABS .................................................... 162

Developer Docs ............................................. 162 SCROLLABLE TABS ............................................ 162 FIXED TABS ........................................................ 162 STACKED TABS .................................................. 162

32. LISTS .................................................... 164 Developer Docs ............................................. 164

• Section Divider .................................................... 164 • Line Items .............................................................. 164

33. GRID LISTS......................................... 165 Developer Docs ............................................. 165

GENERIC GRIDS ................................................. 165 Vertical scrolling ..................................................... 165 Horizontal scrolling ............................................... 166

GRID LIST WITH LABELS .................................. 166 Style .............................................................................. 166

34. SCROLLING ........................................ 167 SCROLL INDICATOR ........................................... 167 INDEX SCROLLING ............................................. 167

35. SPINNERS ........................................... 168 Developer Docs ............................................. 168

Spinners in forms ................................................... 168 Spinners in action bars ........................................ 169

36. BUTTONS ........................................... 170 Developer Docs ............................................. 170

BASIC BUTTONS ................................................ 170 BORDERLESS BUTTONS .................................... 170

37. TEXT FIELDS ..................................... 171 Developer Docs ............................................. 171

Single line and multi line .................................... 171 Text field types ........................................................ 171 Auto-complete text fields ................................... 171

TEXT SELECTION ............................................... 171 • Contextual action bar........................................172 • Selection handles ................................................172

38. SEEK BARS AND SLIDERS ............. 173 Example .......................................................................173

39. PROGRESS & ACTIVITY ................. 174 PROGRESS BARS ................................................. 174 ACTIVITY INDICATORS ...................................... 174

• Activity bar ............................................................175 • Activity circle ........................................................176

CUSTOM INDICATORS ........................................ 177 40. SWITCHES ......................................... 179

CHECKBOXES ...................................................... 179 Developer Docs ............................................. 179

RADIO BUTTONS ................................................ 179 Developer Docs ............................................. 179

ON/OFF SWITCHES ........................................... 180 Developer Docs ............................................. 180

41. DIALOGS............................................. 181 Developer Docs ............................................. 181

• Optional title region ..........................................181 • Content area ..........................................................181 • Action buttons ......................................................181

ALERTS ................................................................ 182 Alerts without title bars .......................................182 Alerts with title bars ..............................................182

POPUPS ................................................................ 183 TOASTS ................................................................ 183

Developer Docs ............................................. 183 42. PICKERS ............................................. 185

Developer Docs ............................................. 185 Space considerations .............................................185

DATE AND TIME PICKERS ................................. 185 43. DOWNLOADS .................................... 187

STENCILS AND SOURCES ................................... 187 ACTION BAR ICON PACK .................................. 187 STYLE................................................................... 188

Roboto ..........................................................................188 Color ..............................................................................188

44. VIDEOS ............................................... 190 Android Design for Success ..................... 190 Android Design for Engineers ............... 190 Navigation in Android .............................. 190 So You've Read the Design Guide; Now What?................................................................ 190 Playing with Patterns ............................... 190

45. CREATIVE COMMONS LICENSE .. 191 CREATIVE COMMONS ATTRIBUTION 3.0 UNPORTED .......................................................... 194

46. APACHE LICENSE, VERSION 2.0 . 199 47. INDEX .................................................. 202


Welcome to Android Design, your place for learning how to design exceptional Android apps. Creative Vision


http://developer.android.com/design/get-started/creative-vision.html


3.Creative Vision Content from developer.android.com/design/get-started/creative-vision.html through their Creative Commons Attribution 2.5 license

We focused the design of Android around three overarching goals, which apply to our core apps as well as 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.

Creative Vision of 202 Content from developer.android.com/design/get-started/creative-vision.html through their Creative Commons Attribution 2.5 license



4.Design Principles Content from developer.android.com/design/get-started/principles.html through their Creative Commons Attribution 2.5 license 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.

Design Principles of 202 Content from developer.android.com/design/get-started/principles.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/get-started/principles.html

http://developer.android.com/design/get-started/principles.html

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.


5.UI Overview Content from developer.android.com/design/get-started/ui-overview.html through their Creative Commons Attribution 2.5 license 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.

UI Overview of 202 Content from developer.android.com/design/get-started/ui-overview.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/get-started/ui-overview.html

http://developer.android.com/design/get-started/ui-overview.html

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.


• 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.

• 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.

• 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


http://developer.android.com/design/patterns/notifications.html


Notifications can be expanded to uncover more details and relevant actions. When collapsed, 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. 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.

• 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

• View Control UI Overview of 202

Content from developer.android.com/design/get-started/ui-overview.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/actionbar.html

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.

• Content Area

The space where the content of your app is displayed.

• 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.


Build visually compelling apps that look great on any device. Devices and Displays


http://developer.android.com/design/style/devices-displays.html


6.Devices and Displays Content from developer.android.com/design/style/devices-displays.html through their Creative Commons Attribution 2.5 license 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

Devices and Displays of 202 Content from developer.android.com/design/style/devices-displays.html through their Creative Commons Attribution 2.5 license



So where do you begin when designing for multiple screens? One approach is to work in the base standard (normal size and 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 details about designing layouts for larger screens, see the Multi-pane Layouts guide. Developer Guide For information about how to build flexible layouts for multiple screen sizes and densities, read Designing for Multiple Screens and Building a Dynamic UI with Fragments.

Devices and Displays of 202 Content from developer.android.com/design/style/devices-displays.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/multi-pane-layouts.html

7.Themes Content from developer.android.com/design/style/themes.html through their Creative Commons Attribution 2.5 license

Gmail in Holo Light.

Themes of 202 Content from developer.android.com/design/style/themes.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/style/themes.html

http://developer.android.com/design/style/themes.html

Settings in Holo Dark.


Talk in Holo Light with dark action bar. Themes are Android's mechanism for applying a consistent style to an app or activity. The style specifies the visual properties of the elements that make up your user interface, such as color, height, padding and font size. To promote greater cohesion between all apps on the platform, Android provides three system themes that you can choose from when building apps for Ice Cream Sandwich: • Holo Light • Holo Dark • Holo Light with dark action bars Applying these themes will go a long way in helping you to build apps that fit right into the general visual language of Android. Pick the system theme that best matches the needs and design aesthetics for your app. If your desire is to have a more distinct look for your app, using one of the system themes as a starting point for your customizations is a good idea. The system themes provide a solid foundation on top of which you can selectively implement your own visual stylings. Developer Guide For information about how to apply themes such as Holo Light and Dark, and how to build your own themes, see the Styles and Themes API guide.


8.Touch Feedback Content from developer.android.com/design/style/touch-feedback.html through their Creative Commons Attribution 2.5 license 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

Touch Feedback of 202 Content from developer.android.com/design/style/touch-feedback.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/style/touch-feedback.html

http://developer.android.com/design/style/touch-feedback.html

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.


9.Metrics and Grids Content from developer.android.com/design/style/metrics-grids.html through their Creative Commons Attribution 2.5 license 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, XHDPI, and XXHDPI. 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. Because it's important that you design and implement your layouts for multiple densities, the guidelines below and throught the documentation refer to layout dimensions with dp measurements instead of pixels.

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.

Metrics and Grids of 202 Content from developer.android.com/design/style/metrics-grids.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/style/metrics-grids.html


http://developer.android.com/resources/dashboard/screens.html

Mind the gaps

Spacing between each UI element is 8dp.

Examples

Metrics and Grids of 202 Content from developer.android.com/design/style/metrics-grids.html through their Creative Commons Attribution 2.5 license

10. Typography Content from developer.android.com/design/style/typography.html through their Creative Commons Attribution 2.5 license

Download Roboto 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 offers Roboto in thin, light, regular and bold weights, along with an italic style for each weight. The framework also offers the Roboto Condensed variant in regular and bold weights, along with an italic style for each weight.

Typography of 202 Content from developer.android.com/design/style/typography.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/style/typography.html


http://developer.android.com/downloads/design/roboto-1.100141.zip

http://www.google.com/fonts/specimen/Roboto

http://www.google.com/fonts/specimen/Roboto+Condensed

Specimen Book

Default type colors

The Android UI uses the following default color styles: textColorPrimary and textColorSecondary. For light themes use textColorPrimaryInverse and textColorSecondaryInverse. 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:


http://developer.android.com/downloads/design/Roboto_Specimen_Book_20111129.pdf

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.


11. Color Content from developer.android.com/design/style/color.html through their Creative Commons Attribution 2.5 license 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. • #33b5e5 • #aa66cc • #99cc00 • #ffbb33 • #ff4444 • #0099cc • #9933cc • #669900 • #ff8800 • #cc0000

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

Color of 202 Content from developer.android.com/design/style/color.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/style/color.html


12. Iconography Content from developer.android.com/design/style/iconography.html through their Creative Commons Attribution 2.5 license

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. When you design icons for your app, it's important to keep in mind that your app may be installed on a variety of devices that offer a range of pixel densities, as mentioned in Devices and Displays. But you can make your icons look great on all devices by providing each icon in multiple sizes. When your app runs, Android checks the characteristics of the device screen and loads the appropriate density-specific assets for your app. Because you will deliver each icon in multiple sizes to support different densities, the design guidelines below refer to the icon dimensions in dp units, which are based on the pixel dimensions of a medium-density (MDPI) screen.

So, to create an icon for different densities, you should follow the 2:3:4:6 scaling ratio between the four primary densities (medium, high, x-high, and xx-high, respectively). For example, consider that the size for a launcher icon is specified to be 48x48 dp. This means the baseline (MDPI) asset is 48x48 px, and the high density (HDPI) asset should be 1.5x the baseline at 72x72 px, and the x-high density (XHDPI) asset should be 2x the baseline at 96x96 px, and so on. Note: Android also supports low-density (LDPI) screens, but you normally don't need to create custom assets at this size because Android effectively down-scales your HDPI assets by 1/2 to match the expected size.

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.

Iconography of 202 Content from developer.android.com/design/style/iconography.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/style/iconography.html

http://developer.android.com/design/style/iconography.html

Sizes & scale


• Launcher icons on a mobile device must be 48x48 dp. • Launcher icons for display on Google Play must be 512x512 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. Iconography of 202

Content from developer.android.com/design/style/iconography.html through their Creative Commons Attribution 2.5 license

Download the Action Bar Icon Pack

Sizes & scale Iconography of 202

Content from developer.android.com/design/style/iconography.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/downloads/design/Android_Design_Icons_20130926.zip

• 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 16x16 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 be 24x24 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.


Design Tips Here are some tips you might find useful as you create icons or other drawable assets for your application. These tips assume you are using Adobe® Photoshop® or a similar raster and vector image-editing program.

Use vector shapes where possible

Many image-editing programs such as Adobe® Photoshop® allow you to use a combination of vector shapes and raster layers and effects. When possible, use vector shapes so that if the need arises, assets can be scaled up without loss of detail and edge crispness. Using vectors also makes it easy to align edges and corners to pixel boundaries at smaller resolutions.

Start with large artboards

Because you will need to create assets for different screen densities, it is best to start your icon designs on large artboards with dimensions that are multiples of the target icon sizes. For example, launcher icons are 48, 72, 96, or 144 pixels wide, depending on screen density (mdpi, hdpi, xhdpi, and xxhdpi, respectively). If you initially draw launcher icons on an 864x864 artboard, it will be easier and cleaner to adjust the icons when you scale the artboard down to the target sizes for final asset creation.

When scaling, redraw bitmap layers as needed


If you scaled an image up from a bitmap layer, rather than from a vector layer, those layers will need to be redrawn manually to appear crisp at higher densities. For example if a 60x60 circle was painted as a bitmap for mdpi it will need to be repainted as a 90x90 circle for hdpi.

Use common naming conventions for icon assets

Try to name files so that related assets will group together inside a directory when they are sorted alphabetically. In particular, it helps to use a common prefix for each icon type. For example:

Asset Type Prefix Example

Icons ic_ ic_star.png

Launcher icons ic_launcher ic_launcher_calendar.png

Menu icons and Action Bar icons ic_menu ic_menu_archive.png

Status bar icons ic_stat_notify ic_stat_notify_msg.png

Tab icons ic_tab ic_tab_recent.png

Dialog icons ic_dialog ic_dialog_info.png

Note that you are not required to use a shared prefix of any type—doing so is for your convenience only.

Set up a working space that organizes files by density

Supporting multiple screen densities means you must create multiple versions of the same icon. To help keep the multiple copies of files safe and easier to find, we recommend creating a directory structure in your working space that organizes asset files based on the target density. For example: art/... mdpi/... _pre_production/... working_file.psd finished_asset.png hdpi/... _pre_production/... working_file.psd finished_asset.png xhdpi/... _pre_production/... working_file.psd finished_asset.png

xxhdpi/... _pre_production/... working_file.psd finished_asset.png Because the structure in your working space is similar to that of the application, you can quickly determine which assets should be copied to each resources directory. Separating assets by density also helps you detect any variances in filenames across densities, which is important because corresponding assets for different densities must share the same filename. For comparison, here's the resources directory structure of a typical application:


res/... drawable-ldpi/... finished_asset.png drawable-mdpi/... finished_asset.png drawable-hdpi/... finished_asset.png drawable-xhdpi/... finished_asset.png

For more information about how to save resources in the application project, see Providing Resources.

Remove unnecessary metadata from final assets

Although the Android SDK tools will automatically compress PNGs when packaging application resources into the application binary, a good practice is to remove unnecessary headers and metadata from your PNG assets. Tools such as OptiPNG or Pngcrush can ensure that this metadata is removed and that your image asset file sizes are optimized.


http://optipng.sourceforge.net/

http://pmt.sourceforge.net/pngcrush/

13. Writing Style Content from developer.android.com/design/style/writing.html through their Creative Commons Attribution 2.5 license When choosing words for your app: • Keep it brief. Be concise, simple and precise. Start with a 30 character limit (including spaces), and don't use more unless absolutely necessary. • 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. • 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. • 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. • Describe only what's necessary, and no more. Don't try to explain subtle differences. They will be lost on most users. • Avoid repetition. If a significant term gets repeated within a screen or block of text, find a way to use it just once.

Examples • 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.

• Keep it simple. From the Location settings screen: Confusing

Use GPS satellites

When locating, accurate to street level.

Better

GPS

Let apps use satellites to pinpoint your location.

• Be friendly. Dialog that appears when an application crashes: Confusing and annoying—"Sorry" just rubs salt in the wound.

Writing Style of 202 Content from developer.android.com/design/style/writing.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/style/writing.html


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

• 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.

• 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.


Design apps that behave in a consistent, predictable fashion. New in Android


http://developer.android.com/design/patterns/new.html


14. New in Android Content from developer.android.com/design/patterns/new.html through their Creative Commons Attribution 2.5 license

Jelly Bean - Android 4.1 Notifications

Notifications have received some notable enhancements in Android 4.1: • Users can act on notifications immediately from the drawer • Notifications are more flexible in size and layout • A priority flag helps sort notifications by importance • Notifications can be collapsed and expanded The base notification layout has not changed, so app notifications designed for versions earlier than Jelly Bean still look and work the same. Check the updated Notifications page for more details.

Resizable Application Widgets

Widgets are an essential aspect of home screen customization, allowing "at-a-glance" views of an app's most important data and functionality right from the user's home screen. Android 4.1 introduces improved App Widgets that can automatically resize and load different content based upon a number of factors including: • Where the user drops them on the home screen • The size to which the user expands them • The amount of room available on the home screen You can supply separate landscape and portrait layouts for your widgets, which the system inflates as appropriate when the screen orientation changes. The Application Widgets has useful details about widget types, limitations, and design considerations.

New in Android of 202 Content from developer.android.com/design/patterns/new.html through their Creative Commons Attribution 2.5 license



Accessibility

One of Android's missions is to organize the world's information and make it universally accessible and useful. Our mission applies to all users-including people with disabilities such as visual impairment, color deficiency, hearing loss, and limited dexterity. The new Accessibility page provides details on how to design your app to be as accessible as possible by: • Making navigation intuitive • Using recommended touch target sizes • Labeling visual UI elements meaningfully • Providing alternatives to affordances that time out • Using standard framework controls or enable TalkBack for custom controls • Trying it out yourself You can supply separate landscape and portrait layouts for your widgets, which the system inflates as appropriate when the screen orientation changes. The [Application Widgets] (should be link) has useful details about widget types, limitations, and design considerations.

Ice Cream Sandwich - 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 the Compatibility 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.


15. Gestures Content from developer.android.com/design/patterns/gestures.html through their Creative Commons Attribution 2.5 license 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

Gestures of 202 Content from developer.android.com/design/patterns/gestures.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/gestures.html

http://developer.android.com/design/patterns/gestures.html

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 Gestures of 202

Content from developer.android.com/design/patterns/gestures.html through their Creative Commons Attribution 2.5 license

Zooms into content.

• Action

2-finger press, move outwards, lift

Pinch close

Zooms out of content.

• Action

2-finger press, move inwards, lift


16. Application Structure Content from developer.android.com/design/patterns/app-structure.html through their Creative Commons Attribution 2.5 license 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. Application Structure of 202

Content from developer.android.com/design/patterns/app-structure.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/app-structure.html


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.

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.

Application Structure of 202 Content from developer.android.com/design/patterns/app-structure.html through their Creative Commons Attribution 2.5 license

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.

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, 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.

Top Level Switching With View Controls The top level communicates your app’s capabilities by introducing the user to the major functional areas. In many cases the top level will consist of multiple views, and you need to make sure that the user can navigate between them efficiently. Android supports a number of view controls for this task. Use the control that best matches your app's navigation needs:

Fixed tabs

Fixed tabs display top-level views concurrently and make it easy to explore and switch between them. They are always visible on the screen, and can't be moved out of the way like scrollable tabs. Fixed tabs should always allow the user to navigate between the views by swiping left or right on the content area. Use tabs if: • You expect your app's users to switch views frequently. • You have a limited number of up to three top-level views. • You want the user to be highly aware of the alternate views.

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 a spinner in the main action bar if: • You don't want to give up the vertical screen real estate for a dedicated tab bar. • The user is switching between views of the same data set (for example: calendar events viewed by day,

week, or month) or data sets of the same type (such as content for two different accounts).


Action bar spinner from Calendar application.

Navigation drawers

A navigation drawer is a slide-out menu that allows users to switch between views of your app. It can hold a large number of items and is accessible from anywhere in your app. Navigation drawers show your app's top-level views, but can also provide navigation to lower-level screens. This makes them particularly suitable for complex apps. Use navigation drawers if: • You don't want to give up the vertical screen real estate for a dedicated tab bar. • You have a large number of top-level views. • You want to provide direct access to screens on lower levels. • You want to provide quick navigation to views which don't have direct relationships between each other. • You have particularly deep navigation branches.


Navigation drawer from the Shopper app.

Don't mix and match

After choosing the best top-level navigation for your app, don't mix and match patterns. For example, if you decide to use tabs for top-level switching, don't add a drawer, even if your navigation branches are deep. In this case, the navigation drawer would simply duplicate the information on the tabs, confusing your users.

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. For more discussion, see the Tabs design guide.

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. For more discussion, see the Selection design guide.

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.


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.

Lights-out mode

Immersive content like media and games is best experienced full screen without distractions. But that doesn't mean you can't also offer actions on the content like sharing, commenting, or searching. If the user hasn't interacted with any of the controls after a short period of time, automatically fade away the action bar and all system UI affordances so the user can lean back and enjoy the content. We call this lights-out mode. Later, if the user wants to take some action, they can touch anywhere on the screen to exit lights-out mode and bring back the controls.


Google Books' detail view replicates the immersive experience of reading an actual book through lights-out mode and a page-flip animation.

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 thumbnail view controls, 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 pages, Magazines provides a thumbnail view control that lets people quickly jump to specific pages. For more discussion, see the Swipe Views design guide.

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.


17. Navigation with Back and Up Content from developer.android.com/design/patterns/navigation.html through their Creative Commons Attribution 2.5 license

Developer Docs

Implementing Effective Navigation 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 with Back and Up of 202 Content from developer.android.com/design/patterns/navigation.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/navigation.html


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.


18. Action Bar Content from developer.android.com/design/patterns/actionbar.html through their Creative Commons Attribution 2.5 license

Developer Docs

Action Bar The action bar is a dedicated piece of real estate at the top of each screen that is generally persistent throughout the app. It provides several key functions: • Makes important actions prominent and accessible in a predictable way (such as New or Search). • Supports consistent navigation and view switching within apps. • Reduces clutter by providing an action overflow for rarely used actions. • Provides 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.

• 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.

• 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. For more information on view-switching, see the App Structure pattern. 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. Action Bar of 202

Content from developer.android.com/design/patterns/actionbar.html through their Creative Commons Attribution 2.5 license




• 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. Long-press on an icon to view the action's name.

• 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: • Main action bar • Top bar • 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.

Action Bar of 202 Content from developer.android.com/design/patterns/actionbar.html through their Creative Commons Attribution 2.5 license

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 should show only those actions that are available to the user. 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.

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 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 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.


19. Navigation Drawer Content from developer.android.com/design/patterns/navigation-drawer.html through their Creative Commons Attribution 2.5 license

Developer Docs

Creating a Navigation Drawer The navigation drawer is a panel that transitions in from the left edge of the screen and displays the app’s main navigation options.

Displaying the navigation drawer

The user can bring the navigation drawer onto the screen by swiping from the left edge of the screen or by touching the application icon on the action bar. As the navigation drawer expands, it overlays the content but not the action bar. When the drawer is fully extended, the action bar adjusts its content by replacing the current action bar title with the app name and removing all actions that are contextual to the view underneath the navigation drawer. The overflow menu with the standard action items for Settings and Help remains visible.

The user can open the drawer panel by touching the navigation drawer indicator. Because they are transient, navigation drawers make views less cluttered. You can also use them at deeper levels in the navigation hierarchy, allowing users to switch to your app's most important screens from anywhere in the app.

Open the drawer from anywhere in your app by swiping from the left edge of the screen.

Dismissing the navigation drawer

Navigation Drawer of 202 Content from developer.android.com/design/patterns/navigation-drawer.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/navigation-drawer.html

http://developer.android.com/design/patterns/navigation-drawer.html

When the navigation drawer is expanded, the user can dismiss it in one of four ways: • Touching the content outside the navigation drawer • Swiping to the left anywhere on the screen (including edge swipe from right) • Touching the app icon/title in the action bar • Pressing Back

When to Use the Navigation Drawer The navigation drawer is not a general replacement for top-level navigation via spinners or tabs. The structure of your app should guide your choice of which pattern to use for top-level switching. For more information on top-level switching mechanisms, see the Application Structure design pattern. Here are some examples of where navigation drawers work best:

More than 3 top-level views

Navigation drawers are great for displaying a large number of navigation targets concurrently. Use the navigation drawer if you have more than 3 unique top-level views. If not, use fixed tabs for top-level organization to ease discovery and interaction.

Cross-navigation from lower levels

If your app requires cross-navigating between lower-level screens, consider using the navigation drawer. Because it is accessible from anywhere in the app, the drawer enables efficient navigation from lower-level screens to other important places in your app.

The navigation drawer makes cross-navigation at lower levels possible.

Deep navigation branches



If you have particularly deep branches, navigating to the top-level of your app can become repetitive and cumbersome with Up and Back alone. Since navigation drawers are accessible from anywhere in the app, navigation up to the top level is faster and more efficient.

The navigation drawer allows for quick jumps to the top-level of your app, removing the need for repetitive Back or Up sequences.

Navigation Hubs The navigation drawer is a reflection of your app’s structure and displays its major navigation hubs. Think of navigation hubs as those places in your app that a user will want to visit frequently or use as a jumping-off point to other parts of the app. At a minimum, the navigation hubs are the top-level views, since they correspond to your app’s major functional areas. If your app’s structure is deep, you can add screens from lower levels that your users will likely visit often and make those navigation hubs as well.


The navigation drawer contains all of your app's navigation hubs. Include your top level screens as well as important lower-level screens. To facilitate access to the navigation drawer on navigation hubs, all screens that correspond to an entry in your navigation drawer should show the navigation drawer indicator next to the application icon in the action bar. Touching the app icon causes the navigation drawer to slide in from the left. All other lower-level screens show the traditional Up indicator next to the application icon. The drawer is still accessible with an edge-swipe, but is not featured in the action bar.

App icon with navigation drawer indicator.

Content of the Navigation Drawer


Keep the content of the navigation drawer focused on app navigation. Expose the navigation hubs of your app as list items inside the navigation drawer - one item per row.

Titles, icons, and counters

You can structure navigation targets by adding titles. The titles are not interactive, but just organize navigation targets into functional topics. If you have many navigation targets, use titles to orient the user within the drawer. Navigation targets can have optional leading icons as well as trailing counters. Use the counters to inform users about a changed state of data in the corresponding view.

Use titles and icons to organize your drawer.


Collapsible navigation items are split. Use the left side for navigation and the right to collapse and expand items.

Collapsible navigation items

If you have many views with some subordinate to others, consider collapsing them into one expandable item to conserve space. The parent in the navigation drawer then turns into a split item. The left side allows navigation to the parent item’s view, and the right side collapses or expands the list of child items. At launch, the initial state of the collapsible items is up to you. As a rule, all top-level view entries of the navigation drawer should be visible. If you have many collapsible items, consider collapsing all items to allow the user to see the top-level views in their entirety. When the user opens the drawer from a lower-level screen, expand the associated branch of the top-level view to give a stronger sense of place and highlight navigation opportunities close to the user’s current location in the app.

Navigation Drawers and Action Bars When the user expands the navigation drawer, the task focus switches to selecting an item from the drawer. Because the drawer does not overlay the action bar, users may not realize that the items in the action bar do not pertain to the navigation drawer. To reduce confusion, adjust the content of the action bar to the following, once the drawer is fully expanded:


• App icon • App name • Remove actions from the action bar that are contextual to the underlying view (such as Create new, Refresh).

You may retain actions with global scope, such as “Search”. • Overflow menu with expected navigation targets, such as Settings and Help.

Clean up the action bar when the drawer is fully expanded. Remove actions that are not needed and display your app's name in the title area.

Actions

Keep actions on the right side of the action bar and in the overflow Don’t place actions in the navigation drawer. Actions belong in the action bar, and the user expects to see them there. Keep in mind that not all applications use the navigation drawer pattern. It may be tempting to expose all your app’s capabilities in a single place, but keep the bigger picture in mind. Place your actions where all apps display them. This also applies to common navigation targets, such as access to Help or the app’s Settings. As per style guide convention Help and Settings are always located in the action overflow.


Keep Help and Settings in the overflow.

Contextual action bars

Sometimes the user will be in a state where a contextual action bar (CAB) appears instead of the app’s action bar. This typically happens when the user selects text or selects multiple items after a press-and-hold gesture. While the CAB is visible, you should still allow the user to open the navigation drawer using an edge swipe. However, replace the CAB with the standard action bar while the navigation drawer is open. When the user dismisses the drawer, re-display the CAB.

Hide contextual action bars while the drawer is visible. If the user navigates away from a view with selected content, deselect the content before before navigating to the new view.

Interaction Details Introduce the user to the drawer at first use

Upon first launch of your app, introduce the user to the navigation drawer by automatically opening it. This ensures that users know about the navigation drawer and prompts them to learn about the structure of your app by exploring its content. Continue showing the drawer upon subsequent launches until the user actively expands the navigation drawer manually. Once you know that the user understands how to open the drawer, launch the app with the navigation drawer closed.


At first use, show the navigation drawer automatically to help the user learn the functionality and structure of your app.

Give the user a quick peek

If the user touches the very left edge of the screen (within 20 dp from the left), have the drawer peek out as soon as the finger makes contact with the display. This promotes accidental discovery and provides richer feedback.

The navigation drawer peeks out when the user touches the very left edge of the screen.

Highlights

When you open the navigation drawer from a screen that is represented inside the drawer, highlight its entry in the drawer. Vice versa, if you open the drawer from a screen that is not listed in the drawer, none of the items of the drawer should be highlighted.

Impact of Drawer on Overall App Navigation The navigation drawer is an alternative to other top-level navigation patterns. To make apps with navigation drawers work consistently with apps that use a tab or spinner pattern, remember that all navigation requirements for system Back and Up apply. Pay special attention to the following situations:

System Back at the top level of the app

Touching System Back at the app’s top level never opens the navigation drawer. Instead, System Back behaves according to the navigation rules for the top level, such as navigating to the previous app within the task or navigating to the Home screen.


System Back does not show the drawer, but behaves according to the navigation rules for the top level.

System Back after cross navigation to lower hierarchy levels

If the user navigates to a lower hierarchy screen from the navigation drawer and the screen has a direct parent, then the Back stack is reset and Back points to the target screen’s parent. This Back behavior is the same as when a user navigates into an app from a notification.

Reset the Back stack if your lower-level navigation target has direct parents.

Style The width of the navigation drawer depends on the content you want to display, but should be between a minimum of 240 dp and a maximum of 320 dp. The height of the individual line items should not fall below 48 dp. See the layout guideline below for recommendations on padding and spacing.


Layout guidelines for the navigation drawer. Pick the drawer background to best match your app’s theme. See the following examples for a Holo light and a Holo dark themed drawer.

Navigation drawers in Holo light and Holo dark themed apps.

Navigation Drawer Checklist Even if you already support a similar navigation drawer, update your drawer to this pattern to make sure that: • The action bar remains in place and adjusts its content. • Your navigation drawer overlays the content. • Any view represented in the drawer has a navigation drawer indicator in its action bar that allows the drawer

to be opened by touching the app icon. • You take advantage of the new visual drawer transition. • Any view not represented in the drawer maintains the traditional Up indicator in its action bar. • You stay in sync with the general navigation patterns for Up and Back.


20. Multi-pane Layouts Content from developer.android.com/design/patterns/multi-pane-layouts.html through their Creative Commons Attribution 2.5 license

Developer Docs

Building a Dynamic UI with Fragments 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.

Multi-pane Layouts of 202 Content from developer.android.com/design/patterns/multi-pane-layouts.html through their Creative Commons Attribution 2.5 license



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 strive to have the same functionality regardless of orientation. If you use a compound view in one orientation, try not to 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.


Show/hide

If your screen cannot accommodate the compound view on rotation show the right pane in full screen view on rotation to portrait. Use the Up icon in action bar to show the parent screen.

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 try to provide functional parity after the screen orientation changes.


21. Swipe Views Content from developer.android.com/design/patterns/swipe-views.html through their Creative Commons Attribution 2.5 license

Developer Docs

Creating Swipe Views with Tabs 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.

Swipe Views of 202 Content from developer.android.com/design/patterns/swipe-views.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/swipe-views.html


http://developer.android.com/training/implementing-navigation/lateral.html




Navigating between consecutive Email messages using the swipe gesture. If a view contains content that exceeds the width of the screen such as a wide Email message, make sure the user's initial swipes will scroll horizontally within the view. Once the end of the content is reached, an additional swipe should navigate to the next view. In addition, support the use of edge swipes to immediately navigate between views when content scrolls horizontally.

Scrolling within a wide Email message using the swipe gesture before navigating to the next message.

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. Swipe Views of 202

Content from developer.android.com/design/patterns/swipe-views.html through their Creative Commons Attribution 2.5 license

• For more details on how to build swipe views, read the developer documentation on Implementing Lateral Navigation.

Swipe Views of 202 Content from developer.android.com/design/patterns/swipe-views.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/training/implementing-navigation/lateral.html%23horizontal-paging

http://developer.android.com/training/implementing-navigation/lateral.html%23horizontal-paging

22. Selection Content from developer.android.com/design/patterns/selection.html through their Creative Commons Attribution 2.5 license

Developer Docs

Menus: Creating Contextual Menus Android 3.0 changed the long press gesture—that is, a touch that's held in the same position for a moment—to be 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:

Selection of 202 Content from developer.android.com/design/patterns/selection.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/selection.html

http://developer.android.com/design/patterns/selection.html

• 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 pattern to 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. Developer Guide For information about how to create a contextual action bar, read Using the contextual action mode.

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.


http://developer.android.com/guide/topics/ui/menus.html%23CAB

23. Confirming & Acknowledging Content from developer.android.com/design/patterns/confirming-acknowledging.html through their Creative Commons Attribution 2.5 license In some situations, when a user invokes an action in your app, it's a good idea to confirm or acknowledge that action through text.

Confirming is asking the user to verify that they truly want to proceed with an action they just invoked. In some cases, the confirmation is presented along with a warning or critical information related to the action that they need to consider.

Acknowledging is displaying text to let the user know that the action they just invoked has been completed. This removes uncertainty about implicit operations that the system is taking. In some cases, the acknowledgment is presented along with an option to undo the action. Communicating to users in these ways can help alleviate uncertainty about things that have happened or will happen. Confirming or acknowledging can also prevent users from making mistakes they might regret.

When to Confirm or Acknowledge User Actions Not all actions warrant a confirmation or an acknowledgment. Use this flowchart to guide your design decisions.

Confirming & Acknowledging of 202 Content from developer.android.com/design/patterns/confirming-acknowledging.html through their Creative Commons Attribution 2.5

license

http://developer.android.com/design/patterns/confirming-acknowledging.html

http://developer.android.com/design/patterns/confirming-acknowledging.html

Confirming Example: Google Play Books


license

In this example, the user has requested to delete a book from their Google Play library. An alert appears to confirm this action because it's important to understand that the book will no longer be available from any device. When crafting a confirmation dialog, make the title meaningful by echoing the requested action.

Example: Android Beam


license

Confirmations don't necessarily have to be presented in an alert with two buttons. After initiating Android Beam, the user is prompted to touch the content to be shared (in this example, it's a photo). If they decide not to proceed, they simply move their phone away.

Acknowledging Example: Abandoned Gmail draft saved


license

In this example, if the user navigates back or up from the Gmail compose screen, something possibly unexpected happens: the current draft is automatically saved. An acknowledgment in the form of a toast makes that apparent. It fades after a few seconds. Undo isn't appropriate here because saving was initiated by the app, not the user. And it's quick and easy to resume composing the message by navigating to the list of drafts.

Example: Gmail conversation deleted

After the user deletes a conversation from the list in Gmail, an acknowledgment appears with an undo option. The acknowledgment remains until the user takes an unrelated action, such as scrolling the list.

No Confirmation or Acknowledgment Example: +1'ing

Confirmation is unnecessary. If the user +1'd by accident, it's not a big deal. They can just touch the button again to undo the action. Acknowledgment is unnecessary. The user will see the +1 button bounce and turn red. That's a very clear signal.

Example: Removing an app from the Home Screen


license

Confirmation is unnecessary. This is a deliberate action: the user must drag and drop an item onto a relatively large and isolated target. Therefore, accidents are highly unlikely. But if the user regrets the decision, it only takes a few seconds to bring it back again. Acknowledgment is unnecessary. The user will know the app is gone from the Home Screen because they made it disappear by dragging it away.


license

24. Notifications Content from developer.android.com/design/patterns/notifications.html through their Creative Commons Attribution 2.5 license

Developer Docs

Notifying the User The notification system allows your app to keep the user informed about events, such as new chat messages or a calendar event. Think of notifications as a news channel that alerts the user to important events as they happen or a log that chronicles events while the user is not paying attention.

New in Jelly Bean

In Jelly Bean, notifications received their most important structural and functional update since the beginning of Android. • Notifications can include actions that enable the user to immediately act on a notification from the

notification drawer. • Notifications are now more flexible in size and layout. They can be expanded to show additional information

details. • A priority flag was introduced that helps to sort notifications by importance rather than time only.

Anatomy of a notification Base Layout

At a minimum, all notifications consist of a base layout, including: • the sending application's notification icon or the sender's photo • a notification title and message • a timestamp • a secondary icon to identify the sending application when the senders image is shown for the main icon The information arrangement of the base layout has not changed in Jelly Bean, so app notifications designed for versions earlier than Jelly Bean still look and work the same.

Base layout of a notification

Notifications of 202 Content from developer.android.com/design/patterns/notifications.html through their Creative Commons Attribution 2.5 license



Expanded layouts

With Jelly Bean you have the option to provide more event detail. You can use this to show the first few lines of a message or show a larger image preview. This provides the user with additional context, and - in some cases - may allow the user to read a message in its entirety. The user can pinch-zoom or two-finger glide in order to toggle between base and expanded layouts. For single event notifications, Android provides two expanded layout templates (text and image) for you to re-use in your application.

Actions

Starting with Jelly Bean, Android supports optional actions that are displayed at the bottom of the notification. With actions, users can handle the most common tasks for a particular notification from within the notification shade without having to open the originating application. This speeds up interaction and, in conjunction with "swipe-to-dismiss", helps users to streamline their notification triaging experience. Be judicious with how many actions you include with a notification. The more actions you include, the more cognitive complexity you create. Limit yourself to the fewest number of actions possible by only including the most imminently important and meaningful ones. Good candidates for actions on notifications are actions that are: • essential, frequent and typical for the content type you're displaying • time-critical • not overlapping with neighboring actions Avoid actions that are: • ambiguous • duplicative of the default action of the notification (such as "Read" or "Open")


Calendar reminder notification with two actions You can specify a maximum of three actions, each consisting of an action icon and an action name. Adding actions to a simple base layout will make the notification expandable, even if the notification doesn't have an expanded layout. Since actions are only shown for expanded notifications and are otherwise hidden, you must make sure that any action a user can invoke from a notification is available from within the associated application as well.

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 the body of a notification (outside of the action buttons), 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 such as 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.

Correctly set and manage notification priority

Starting with Jelly Bean, Android now supports a priority flag for notifications. It allows you to influence where your notification will appear in comparison to other notifications and help to make sure that users always see their most important notifications first. You can choose from the following priority levels when posting a notification:

Priority Use

MAX Use for critical and urgent notifications that alert the user to a condition that is time-critical or needs to be resolved before they can continue with a particular task.

HIGH Use high priority notifications primarily for important communication, such as message or chat events with content that is particularly interesting for the user.

DEFAULT The default priority. Keep all notifications that don't fall into any of the other categories at this priority level.



LOW Use for notifications that you still want the user to be informed about, but that rate low in urgency.

MIN Contextual/background information (e.g. weather information, contextual location information). Minimum priority notifications will not show in the status bar. The user will only discover them when they expand the notification tray.

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:

You can provide more detail about the individual notifications that make up a stack by using the expanded digest layout. This allows users to gain a better sense of which notifications are pending and if they are interesting enough to be read in detail within the associated app.

Make notifications optional Notifications of 202

Content from developer.android.com/design/patterns/notifications.html through their Creative Commons Attribution 2.5 license

Users should always be in control of notifications. Allow the user to disable your apps notifications or change their alert properties, such as alert sound and whether to use vibration, 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 kinds of notifications 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. Do Use the proper notification icon style for small icons, and the Holo Dark action bar icon style for your action icons. Do Keep your icons visually simple and avoid excessive detail that is hard to discern. Don't Use color to distinguish your app from others.

Pulse the notification LED appropriately

Many Android devices contain a tiny lamp, called the notification LED, which is used to keep the user informed about events while the screen is off. Notifications with a priority level of MAX, HIGH, or DEFAULT should cause the LED to glow, while those with lower priority (LOW and MIN) should not. The user's control over notifications should extend to the LED. By default, the LED will glow with a white color. Your notifications shouldn't use a different color unless the user has explicitly customized it.

Building notifications that users care about 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. While Android's notification system has been designed to minimize the impact of notifications on the users attention, it is nonetheless still important to be aware of the fact that notifications are potentially interrupting the users task flow. As you plan your notifications, ask yourself if they are important enough to warrant an interruption. If you are unsure, allow the user to opt into a notification using your apps notification settings or adjust the notifications priority flag. 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: • Avoid notifying 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 generally do not warrant a real time interruption. For the users that do care about them, allow them to opt-in.

• 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 create notifications that have no true notification content and merely advertise your app. A notification should inform the user about a state and should not be used to merely launch an app.

• 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.


Interacting With Notifications

Notifications are indicated by icons in the notification area and can be accessed by opening the notification drawer. Notifications of 202

Content from developer.android.com/design/patterns/notifications.html through their Creative Commons Attribution 2.5 license

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 further guidance on the use of dialogs and toasts, refer to Confirming & Acknowledging.


25. Widgets Content from developer.android.com/design/patterns/widgets.html through their Creative Commons Attribution 2.5 license

Developer Docs

App Widgets Widgets are an essential aspect of home screen customization. You can imagine them as "at-a-glance" views of an app's most important data and functionality that is accessible right from the user's home screen. Users can move widgets across their home screen panels, and, if supported, resize them to tailor the amount of information within a widget to their preference.

Widget types As you begin planning your widget, think about what kind of widget you're trying to build. Widgets typically fall into one of the following categories:

Information widgets

Information widgets typically display a few crucial information elements that are important to a user and track how that information changes over time. Good examples for information widgets are weather widgets, clock widgets or sports score trackers. Touching information widgets typically launches the associated app and opens a detail view of the widget information.

Collection widgets

As the name implies, collection widgets specialize in displaying multitude elements of the same type, such as a collection of pictures from a gallery app, a collection of articles from a news app or a collection of emails/messages from a communication app. Collection widgets typically focus on two use cases: browsing the collection, and opening an element of the collection to its detail view for consumption. Collection widgets can scroll vertically.

Widgets of 202 Content from developer.android.com/design/patterns/widgets.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/widgets.html

http://developer.android.com/design/patterns/widgets.html

ListView widget

GridView widget

Control widgets

The main purpose of a control widget is to display often used functions that the user can trigger right from the home screen without having to open the app first. Think of them as remote controls for an app. A typical example of control widgets are music app widgets that allow the user to play, pause or skip music tracks from outside the actual music app. Widgets of 202

Content from developer.android.com/design/patterns/widgets.html through their Creative Commons Attribution 2.5 license

Interacting with control widgets may or may not progress to an associated detail view depending on if the control widget's function generated a data set, such as in the case of a search widget.

Hybrid widgets

While all widgets tend to gravitate towards one of the three types described above, many widgets in reality are hybrids that combine elements of different types. For the purpose of your widget planning, center your widget around one of the base types and add elements of other types if needed.

A music player widget is primarily a control widget, but also keeps the user informed about what track is currently playing. It essentially combines a control widget with elements of an information widget type.

Widget limitations While widgets could be understood as "mini apps", there are certain limitations that are important to understand before you start to embark on designing your widget:

Gestures

Because widgets live on the home screen, they have to co-exist with the navigation that is established there. This limits the gesture support that is available in a widget compared to a full-screen app. While apps for example may support a view pager that allows the user to navigate between screens laterally, that gesture is already taken on the home screen for the purpose of navigating between home panels. The only gestures available for widgets are: • Touch • Vertical swipe


Elements

Given the above interaction limitations, some of the UI building blocks that rely on restricted gestures are not available for widgets. For a complete list of supported building blocks and more information on layout restrictions, please refer to the "Creating App Widget Layouts" section in the App Widgets API Guide.

Design guidelines

Widget content

Widgets are a great mechanism to attract a user to your app by "advertising" new and interesting content that is available for consumption in your app. Just like the teasers on the front page of a newspaper, widgets should consolidate and concentrate an app's information and then provide a connection to richer detail within the app; or in other words: the widget is the information "snack" while the app is the "meal." As a bottom line, always make sure that your app shows more detail about an information item than what the widget already displays.

Widget navigation

Besides the pure information content, you should also consider to round out your widget's offering by providing navigation links to frequently used areas of your app. This lets users complete tasks quicker and extends the functional reach of the app to the home screen. Good candidates for navigation links to surface on widgets are: • Generative functions: These are the functions that allow the user to create new content for an app, such as

creating a new document or a new message. • Open application at top level: Tapping on an information element will usually navigate the user to a lower

level detail screen. Providing access to the top level of your application provides more navigation flexibility and can replace a dedicated app shortcut that users would otherwise use to navigate to the app from the home screen. Using your application icon as an affordance can also provide your widget with a clear identity in case the data you're displaying is ambiguous.


Widget resizing

With version 3.1, Android introduced resizable widgets to the platform. Resizing allows users to adjust the height and/or the width of a widget within the constraints of the home panel placement grid. You can decide if your widget is freely resizable or if it is constrained to horizontal or vertical size changes. You do not have to support resizing if your particular widget is inherently fixed-size. Allowing users to resize widgets has important benefits: • They can fine-tune how much information they want to see on each widget. • They can better influence the layout of widgets and shortcuts on their home panels.

A long press and subsequent release sets resizable widgets into resize mode. Users can use the drag handles or the widget corners to set the desired size. Planning a resize strategy for your widget depends on the type of widget you're creating. List or grid-based collection widgets are usually straightforward because resizing the widget will simply expand or contract the vertical scrolling area. Regardless of the of the widget's size, the user can still scroll all information elements into view. Information widgets on the other hand require a bit more hands-on planning, since they are not scrollable and all content has to fit within a given size. You will have to dynamically adjust your widget's content and layout to the size the user defined through the resize operation.

In this simple example the user can horizontally resize a weather widget in 4 steps and expose richer information about the weather at the current location as the widget grows. For each widget size determine how much of your app's information should surface. For smaller sizes concentrate on the essential and then add more contextual information as the widget grows horizontally and vertically.

Layout considerations

It will be tempting to layout your widgets according to the dimensions of the placement grid of a particular device that you own and develop with. This can be a useful initial approximation as you layout your widget, but keep the following in mind: • The number, size and spacing of cells can vary widely from device to device, and hence it is very important

that your widget is flexible and can accommodate more or less space than anticipated. • In fact, as the user resizes a widget, the system will respond with a dp size range in which your widget can

redraw itself. Planning your widget resizing strategy across "size buckets" rather than variable grid dimensions will give you the most reliable results.


Widget configuration

Sometimes widgets need to be setup before they can become useful. Think of an email widget for example, where you need to provide an account before the inbox can be displayed. Or a static photo widget where the user has to assign the picture that is to be displayed from the gallery. Android widgets display their configuration choices right after the widget is dropped onto a home panel. Keep the widget configuration light and don't present more than 2-3 configuration elements. Use dialog-style instead of full-screen activities to present configuration choices and retain the user's context of place, even if doing so requires use of multiple dialogs. Once setup, there typically is not a lot of reason to revisit the setup. Therefore Android widgets do not show a "Setup" or "Configuration" button.

After adding a Play widget to a home panel, the widget asks the user to specify the type of media the widget should display.

Checklist • Focus on small portions of glanceable information on your widget. Expand on the information in your app. • Choose the right widget type for your purpose. • For resizable widgets, plan how the content for your widget should adapt to different sizes. • Make your widget orientation and device independent by ensuring that the layout is capable of stretching and

contracting.


26. Settings Content from developer.android.com/design/patterns/settings.html through their Creative Commons Attribution 2.5 license

Developer Docs

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:

Settings of 202 Content from developer.android.com/design/patterns/settings.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/settings.html

http://developer.android.com/design/patterns/settings.html

http://developer.android.com/design/get-started/principles.html%23decide-for-me

http://developer.android.com/design/get-started/principles.html%23decide-for-me

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:

• Under a section divider

• 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 Settings of 202

Content from developer.android.com/design/patterns/settings.html through their Creative Commons Attribution 2.5 license

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 inactivity

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

Adjust the delay before the screen automatically turns off

After

Sleep

After 10 minutes of inactivity

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 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.


27. Help Content from developer.android.com/design/patterns/help.html through their Creative Commons Attribution 2.5 license We wish we could guarantee that if you follow every piece of advice on this website, everyone will be able to learn and use your app without a hitch. Sadly, that's not the case. Some of your users will run into questions or problems along the way. They'll be looking for answers within your app, and if they don't find them quickly, they may leave and never come back. This page covers design patterns for making help accessible in your app and tips for creating help content for users who are eager for assistance.

Designing Help into Your App

Don't show unsolicited help, except in very limited cases

Naturally, you want everyone to quickly learn the ropes, discover the cool features, and get the most out of your app. So you might be tempted to present a one-time introductory slideshow, video, or splash screen to all new users when they first open the app. Or you might be drawn to the idea of displaying helpful text bubbles or dialogs when users interact with certain features for the first time. In almost all cases, we advise against approaches like these because: • They're interruptions. People will be eager to start using your app, and anything you put in front of them

will feel like an obstacle or possibly an annoyance, despite your good intentions. And because they didn't ask for it, they probably won't pay close attention to it.

• They're usually not necessary. If you have usability concerns about an aspect of your app, don't just throw help at the problem. Try to solve it in the UI. Apply Android design patterns, styles, and building blocks, and you'll go a long way in reducing the need to educate your users.

The only reason for showing pure help content to new users unsolicited is: To teach high value functionality that's only available through a gesture. For example, we use help content to teach users how to place apps on their Home Screen. This functionality is: • High value

Without it, users wouldn't be able to customize the most frequently visited Android screen to meet their needs.

• Available only through a gesture Because there's no button or menu for it, users might not ever discover it on their own.

However, not all high value gesture-only functionality needs a tutorial. For example, don't teach users how to scroll content. They already know how because it's a fundamental, system-wide interaction.

Help of 202 Content from developer.android.com/design/patterns/help.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/help.html

http://developer.android.com/design/patterns/help.html

The first time each user visits the All Apps screen, a semi-transparent overlay appears to teach an important gesture. Bottom line: when it comes to offering help in your app, it's much better to let users come to you when they need it.

Follow the standard design for navigating to help

On every screen in your app, offer help in the action overflow. Always make it the very last item in the menu and label it "Help".


Even if your screen has no other action overflow items, "Help" should appear there and not be promoted to the action bar. We've established this standard design so that when users are desperate for help, they won't have to hunt to find it (see design principle: Give me tricks that work everywhere).

Assume that every call for help is urgent

In addition to help, you might want to expose other information, such as copyright info, credits, terms of service, and privacy policy. Let users access this information through the Help menu item, but optimize the flow for people with urgent questions about how to do something or why something is happening in your app. The smaller subset of users who are looking for legal fine print or the names of the people who created the app won't be as burdened by taking a few extra steps. The same is true for any communication options you might want to provide, such as contacting customer support or submitting feedback. Offer these options in a way that doesn't add an extra step before users see help. When you put the help content forward, you increase the likelihood that users will find the answers on their own, which in turn reduces your support costs. When someone chooses "Help":


Don't Present a dialog asking them to choose between help and other options.

Better Immediately launch a web browser with help content. Place other options in a footer.

Even Better Build a help screen in your app and offer other options in the action bar. For example, you could let users contact you with questions or feedback through an action button. The action overflow is the ideal place for non-help information that users rarely need.


This requires more development work than launching a web browser, but it's a nicer experience for users because they don't leave your app to get the help they need and doesn't require a network connection.

Principles for Writing On-Screen Help Content Help is part of the UI

On-screen help is an extension of your app's UI, not a description of it. All words on the screen from the core app to the help should follow our Writing Style principles so that the end-to-end experience feels seamless and cohesive.

Make every pixel count

It's not necessary to document every single detail about your app, especially things that are extremely apparent just by looking at the UI, or behaviors that are standard for the platform. Surface just the key additional information that the on-screen text doesn't have room to describe, in a way that makes it easy to map to the screen.

Pictures are faster than words

In describing key UI elements and providing step-by-step instructions, consider combining text with icons, partial screenshots with callouts, and other imagery. You'll need fewer words to explain things, and users will absorb the information more quickly.

Help me scan, not read

People don't read help from start to finish. They scan around, looking for a piece of information containing the answer they need. Make it less burdensome with friendly formatting and layout choices like bold headings, bulleted and numbered lists, tables, and white space between paragraphs. And if you have a large amount of content, divide it into multiple screens to cut down on scrolling.

Take me straight to the answer

What's better than a screen that's easy to scan? A screen that requires no scanning at all because the answer's right there. Consider having each screen in your app navigate to help that's relevant just to that screen. We call this contextual help, and it's the holy grail of user assistance. If you take this approach, be sure to also provide a way to get to the rest of the help content.



28. Backwards Compatibility Content from developer.android.com/design/patterns/compatibility.html through their Creative Commons Attribution 2.5 license

Developer Docs

Supporting Different Devices 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

Backwards Compatibility of 202 Content from developer.android.com/design/patterns/compatibility.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/compatibility.html

http://developer.android.com/design/patterns/compatibility.html

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.


29. Accessibility Content from developer.android.com/design/patterns/accessibility.html through their Creative Commons Attribution 2.5 license

Developer Docs

Implementing Accessibility One of Android's missions is to organize the world's information and make it universally accessible and useful. Accessibility is the measure of how successfully a product can be used by people with varying abilities. Our mission applies to all users-including people with disabilities such as visual impairment, color deficiency, hearing loss, and limited dexterity. Universal design is the practice of making products that are inherently accessible to all users, regardless of ability. The Android design patterns were created in accordance with universal design principles, and following them will help your app meet basic usability standards. Adhering to universal design and enabling Android's accessibility tools will make your app as accessible as possible. Robust support for accessibility will increase your app's user base. It may also be required for adoption by some organizations. Learn more about Google and accessibility.

Android's Accessibility Tools Android includes several features that support access for users with visual impairments; they don't require drastic visual changes to your app. • TalkBack is a pre-installed screen reader service provided by Google. It uses spoken feedback to describe

the results of actions such as launching an app, and events such as notifications. • Explore by Touch is a system feature that works with TalkBack, allowing you to touch your device's screen

and hear what's under your finger via spoken feedback. This feature is helpful to users with low vision. • Accessibility settings let you modify your device's display and sound options, such as increasing the text

size, changing the speed at which text is spoken, and more. Some users use hardware or software directional controllers (such as a D-pad, trackball, keyboard) to jump from selection to selection on a screen. They interact with the structure of your app in a linear fashion, similar to 4-way remote control navigation on a television.

Guidelines The Android design principle "I should always know where I am" is key for accessibility concerns. As a user navigates through an application, they need feedback and a mental model of where they are. All users benefit from a strong sense of information hierarchy and an architecture that makes sense. Most users benefit from visual and haptic feedback during their navigation (such as labels, colors, icons, touch feedback) Low vision users benefit from explicit verbal descriptions and large visuals with high contrast. As you design your app, think about the labels and notations needed to navigate your app by sound. When using Explore by Touch, the user enables an invisible but audible layer of structure in your application. Like any other aspect of app design, this structure can be simple, elegant, and robust. The following are Android's recommended guidelines to enable effective navigation for all users.

Make navigation intuitive

Design well-defined, clear task flows with minimal navigation steps, especially for major user tasks. Make sure those tasks are navigable via focus controls.

Use recommended touch target sizes

Accessibility of 202 Content from developer.android.com/design/patterns/accessibility.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/accessibility.html

http://developer.android.com/design/patterns/accessibility.html

https://www.google.com/%23hl=en&q=universal+design&fp=1

http://www.google.com/accessibility/

https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback

48 dp is the recommended touch target size for on screen elements. Read about Android Metrics and Grids to learn about implementation strategies to help most of your users. For certain users, it may be appropriate to use larger touch targets. An example of this is educational apps, where buttons larger than the minimum recommendations are appropriate for children with developing motor skills and people with manual dexterity challenges.

Label visual UI elements meaningfully

In your wireframes, label functional UI components that have no visible text. Those components might be buttons, icons, tabs with icons, and icons with state (like stars). Developers can use the contentDescription attribute to set the label.

• group • all contacts • favorites • search • action overflow button • when starred: remove from favorites when not starred: add to favorties • action overflow button • text message • video chat

Provide alternatives to affordances that time out

Your app may have icons or controls that disappear after a certain amount of time. For example, five seconds after starting a video, playback controls may fade from the screen. Due to the way that TalkBack works, those controls are not read out loud unless they are focused on. If they fade out from the screen quickly, your user may not even be aware that they are available. Therefore, make sure that you are not relying on timed out controls for high priority task flows. (This is a good universal design guideline too.) If the controls enable an important function, make sure that the user can turn on the controls again and/or their function is duplicated elsewhere. You can also change the behavior of your app when


accessibility services are turned on. Your developer may be able to make sure that timed-out controls won't disappear.

Use standard framework controls or enable TalkBack for custom controls

Standard Android framework controls work automatically with accessibility services and have ContentDescriptions built in by default. An oft-overlooked system control is font size. Users can turn on a system-wide large font size in Settings; using the default system font size in your application will enable the user's preferences in your app as well. To enable system font size in your app, mark text and their associated containers to be measured in scale pixels. Also, keep in mind that when users have large fonts enabled or speak a different language than you, their type might be larger than the space you've allotted for it. Read Devices and Displays and Supporting Multiple Screens for design strategies. If you use custom controls, Android has the developer tools in place to allow adherence to the above guidelines and provide meaningful descriptions about the UI. Provide adequate notation on your wireframes and direct your developer to the Custom Views documentation.

Try it out yourself

Turn on the TalkBack service in Settings > Accessibility and navigate your application using directional controls or eyes-free navigation.

Checklist • Make navigation intuitive • Use recommended touch target sizes • Label visual UI elements meaningfully • Provide alternatives to affordances that time out • Use standard framework controls or enable TalkBack for custom controls • Try it out yourself


http://developer.android.com/guide/practices/screens_support.html

http://developer.android.com/guide/practices/screens_support.html

30. Pure Android Content from developer.android.com/design/patterns/pure-android.html through their Creative Commons Attribution 2.5 license 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 Blocks section 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.

Pure Android of 202 Content from developer.android.com/design/patterns/pure-android.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/patterns/pure-android.html

http://developer.android.com/design/patterns/pure-android.html

http://developer.android.com/design/downloads/index.html

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 the Share 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 the Navigation 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.


Your inventory of ready-to-use elements for creating outstanding apps. Tabs


http://developer.android.com/design/building-blocks/tabs.html


31. Tabs Content from developer.android.com/design/building-blocks/tabs.html through their Creative Commons Attribution 2.5 license

Developer Docs

Creating Swipe Views with 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. For details on using gestures to move between tabs, see the Swipe Views pattern.

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, or swipe left or right. Fixed tabs are displayed with equal width, based on the width of the widest tab label. If there is insufficient room to display all tabs, the tab labels themselves will be scrollable. For this reason, fixed tabs are best suited for displaying 3 or fewer tabs.

Tabs in Holo Dark & Light.

Tabs in the Google Play Movies 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.

Tabs of 202 Content from developer.android.com/design/building-blocks/tabs.html through their Creative Commons Attribution 2.5 license








Tabs of 202 Content from developer.android.com/design/building-blocks/tabs.html through their Creative Commons Attribution 2.5 license

32. Lists Content from developer.android.com/design/building-blocks/lists.html through their Creative Commons Attribution 2.5 license

Developer Docs

List View Lists present multiple line items in a vertical arrangement. They can be used for data selection as well as drilldown navigation.

• Section Divider

Use section dividers to organize the content of your list into groups and facilitate scanning.

• 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.

Lists of 202 Content from developer.android.com/design/building-blocks/lists.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/lists.html

http://developer.android.com/design/building-blocks/lists.html

33. Grid Lists Content from developer.android.com/design/building-blocks/grid-lists.html through their Creative Commons Attribution 2.5 license

Developer Docs

Grid View 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.

Grid Lists of 202 Content from developer.android.com/design/building-blocks/grid-lists.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/grid-lists.html

http://developer.android.com/design/building-blocks/grid-lists.html

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".

Grid Lists of 202 Content from developer.android.com/design/building-blocks/grid-lists.html through their Creative Commons Attribution 2.5 license

34. Scrolling Content from developer.android.com/design/building-blocks/scrolling.html through their Creative Commons Attribution 2.5 license 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.

Scrolling of 202 Content from developer.android.com/design/building-blocks/scrolling.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/scrolling.html

http://developer.android.com/design/building-blocks/scrolling.html

35. Spinners Content from developer.android.com/design/building-blocks/spinners.html through their Creative Commons Attribution 2.5 license

Developer Docs

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 of 202 Content from developer.android.com/design/building-blocks/spinners.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/spinners.html

http://developer.android.com/design/building-blocks/spinners.html

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.

Spinners of 202 Content from developer.android.com/design/building-blocks/spinners.html through their Creative Commons Attribution 2.5 license

36. Buttons Content from developer.android.com/design/building-blocks/buttons.html through their Creative Commons Attribution 2.5 license

Developer Docs

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.

Buttons of 202 Content from developer.android.com/design/building-blocks/buttons.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/buttons.html

http://developer.android.com/design/building-blocks/buttons.html

37. Text Fields Content from developer.android.com/design/building-blocks/text-fields.html through their Creative Commons Attribution 2.5 license

Developer Docs

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:

Text Fields of 202 Content from developer.android.com/design/building-blocks/text-fields.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/text-fields.html

http://developer.android.com/design/building-blocks/text-fields.html

• 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.

• Selection handles

Selection handles can be dragged to select more or less text while remaining in selection mode.

Text Fields of 202 Content from developer.android.com/design/building-blocks/text-fields.html through their Creative Commons Attribution 2.5 license

38. Seek Bars and Sliders Content from developer.android.com/design/building-blocks/seek-bars.html through their Creative Commons Attribution 2.5 license 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

Seek Bars and Sliders of 202 Content from developer.android.com/design/building-blocks/seek-bars.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/seek-bars.html

http://developer.android.com/design/building-blocks/seek-bars.html

39. Progress & Activity Content from developer.android.com/design/building-blocks/progress.html through their Creative Commons Attribution 2.5 license Progress bars and activity indicators signal to users that something is happening that will take a moment.

Progress bars Progress bars are for situations where the percentage completed can be determined. They give users a quick sense of how much longer an operation will take.

A progress bar should always fill from 0% to 100% and never move backwards to a lower value. If multiple operations are happening in sequence, use the progress bar to represent the delay as a whole, so that when the bar reaches 100%, it doesn't return back to 0%.

Progress bar in Holo Dark and Holo Light.

Activity indicators Activity indicators are for operations of an indeterminate length. They ask users to wait a moment while something finishes up, without getting into specifics about what's happening behind the scenes. Two styles are available: a bar and a circle. Each is offered in a variety of sizes, in both Holo Light and Holo Dark themes. Choose the appropriate style and size 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. Each operation should only be represented by one activity indicator.

Progress & Activity of 202 Content from developer.android.com/design/building-blocks/progress.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/progress.html

http://developer.android.com/design/building-blocks/progress.html

• Activity bar

In this example, an activity bar (in Holo Dark) appears when a user first requests a download. There's an unknown period of time when the download has not yet started. As soon as the download starts, this activity bar transforms into a progress bar.


• Activity circle

In this example, an activity circle (in Holo Light) 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. When displaying an activity circle, do not include text to communicate what the app is doing. The moving circle alone provides sufficient feedback about the delay, and does so in an understated way that minimizes the impact. Don't

Do


Custom indicators The standard progress bar and activity indicators work well for most situations and should be used whenever possible to provide a consistent experience across Android. However, some situations may call for something more custom. Here's an example: In all of the Google Play apps (Music, Books, Movies, Magazines), we wanted the current download state of each item to be visible at all times at the top-level screen. These states are: • Not downloaded • Temporarily downloaded (automatically cached by the app) • Permanently downloaded on the device at the user's request We also needed to indicate progress from one download state to another, because downloading is not instantaneous. This presented a challenge, because the Google Play apps use a variety of different layouts, and some of them are highly space-constrained. We didn't want this information to clutter the top-level screens, or compete too much with the cover art. So we designed a custom indicator that could show all of the information in a tiny footprint, with the flexibility to appear on top of content if necessary.

The color indicates whether it's downloaded (blue) or not (gray). The appearance of the pin indicates whether the download is permanent (white, upright) or temporary (gray, diagonal). And when state is in the process of changing, progress is indicated by a moving pie chart.


Across Google Play apps with different layouts, the same custom indicator appears with each item. It communicates download state as well as progress, in a compact package that can be incorporated into any screen design. If you find that the standard indicators aren't meeting your needs (due to space constraints, state complexities), by all means design your own. Make it feel like part of the Android family by injecting some of the visual characteristics of the standard indicators. In this example, we carried over the circular shape, the same shade of blue, and the flat and simple style.


40. Switches Content from developer.android.com/design/building-blocks/switches.html through their Creative Commons Attribution 2.5 license Switches allow the user to select options. There are three kinds of switches: checkboxes, radio buttons, and on/off switches.

Checkboxes

Developer Docs

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

Developer Docs

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.

Switches of 202 Content from developer.android.com/design/building-blocks/switches.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/switches.html

http://developer.android.com/design/building-blocks/switches.html

On/off Switches

Developer Docs

Toggle Buttons On/off switches toggle the state of a single settings option.

Switches of 202 Content from developer.android.com/design/building-blocks/switches.html through their Creative Commons Attribution 2.5 license

41. Dialogs Content from developer.android.com/design/building-blocks/dialogs.html through their Creative Commons Attribution 2.5 license

Developer Docs

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.

• 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.

• 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.

• 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. Order actions following these rules: • The dismissive action of a dialog is always on the left. Dismissive actions return to the user to the previous

state. • The affirmative actions are on the right. Affirmative actions continue progress toward the user goal that

triggered the dialog.

Dialogs of 202 Content from developer.android.com/design/building-blocks/dialogs.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/dialogs.html

http://developer.android.com/design/building-blocks/dialogs.html

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. When crafting a confirmation dialog, make the title meaningful by echoing the requested action. Don't

Are you sure?

Don't

Warning!

Do

Erase USB storage?

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.

Developer Docs

Toasts


42. Pickers Content from developer.android.com/design/building-blocks/pickers.html through their Creative Commons Attribution 2.5 license

Developer Docs

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.

Pickers of 202 Content from developer.android.com/design/building-blocks/pickers.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/building-blocks/pickers.html

http://developer.android.com/design/building-blocks/pickers.html

Pickers of 202 Content from developer.android.com/design/building-blocks/pickers.html through their Creative Commons Attribution 2.5 license

43. Downloads Content from developer.android.com/design/downloads/index.html through their Creative Commons Attribution 2.5 license Want everything? We've bundled all the downloads available on Android Design, except for the Roboto font family, into a single ZIP file. You can also download individual files listed below. You may use these materials without restriction in your apps and to develop your apps. Download All

Stencils and Sources Drag and drop your way to beautifully designed Ice Cream Sandwich apps. The stencils feature the rich typography, colors, interactive controls, and icons found throughout Android 4.0, along with phone and tablet outlines to frame your creations. Source files for icons and controls are also available.

Adobe® Fireworks® PNG Stencil Adobe® Illustrator® Stencil Omni® OmniGraffle® Stencil Adobe® Photoshop® Sources

Action Bar Icon Pack Action bar icons are graphic buttons that represent the most important actions people can take within your app. More on Action Bar Iconography The download package includes icons that are scaled for various screen densities and 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, plus source files.

Downloads of 202 Content from developer.android.com/design/downloads/index.html through their Creative Commons Attribution 2.5 license



Action Bar Icon Pack

Style Roboto

Ice Cream Sandwich introduced a new type family named Roboto, created specifically for the requirements of UI and high-resolution screens. More on Roboto Roboto on Google Fonts Roboto Condensed on Google Fonts

Roboto Specimen Book

Color

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. More on Color




http://www.google.com/fonts/specimen/Roboto

http://www.google.com/fonts/specimen/Roboto+Condensed

http://developer.android.com/downloads/design/roboto-1.100141.zip

http://developer.android.com/downloads/design/Roboto_Specimen_Book_20111129.pdf


Color Swatches


44. Videos Content from developer.android.com/design/videos/index.html through their Creative Commons Attribution 2.5 license The Android Design Team was pleased to present five fantastic design-oriented sessions at Google I/O 2012. Visit these pages to view the videos and presentations from the conference.

Android Design for Success

You have a great idea for an Android app. You want it to stand out among hundreds of thousands. You want your users to love it and tell everyone they know. The Android User Experience team is here to help. We talk about the Android Design guide and other tricks of the trade for creating apps that delight users and help them accomplish their goals. No design background is required.

Android Design for Engineers

Design isn't black magic, it's a field that people can learn. In this talk two elite designers from Google give you an advanced crash course in interactive and visual design. Topics include mental models, natural mappings, metaphors, mode errors, visual hierarchies, typography and gestalt principles. Correctly applied, this knowledge can drastically improve the quality of your work.

Navigation in Android

An app is useless if people can't find their way around it. Android introduced big navigation-support changes in 3.0 and 4.0. The Action Bar offers a convenient control for Up navigation, the Back key's behavior became more consistent within tasks, and the Recent Tasks UI got an overhaul. In this talk, we discuss how and why we got where we are today, how to think about navigation when designing your app's user experience, and how to write apps that offer effortless navigation in multiple Android versions.

So You've Read the Design Guide; Now What?

The Android Design Guide describes how to design beautiful Android apps, but not how to build them. In this talk we give practical tips for how to apply fit & finish as you implement your design, we show you how to avoid some common pitfalls, we describe some useful patterns, and show how tools can help.

Playing with Patterns

Best-in-class application designers and developers talk about their experience in developing for Android, showing screenshots from their app, exploring the challenges they faced, and offering creative solutions congruent with the Android Design guide. Guests are invited to show examples of visual and interaction patterns in their application that manage to keep it simultaneously consistent and personal. Videos for the entire Design Track can also be found on the Android Developers Channel on YouTube.

Videos of 202 Content from developer.android.com/design/videos/index.html through their Creative Commons Attribution 2.5 license

http://developer.android.com/design/videos/index.html

http://developer.android.com/design/videos/index.html

https://developers.google.com/events/io/sessions/gooio2012/112/





http://www.youtube.com/playlist?list=PL54FA004D676C3EE9

45. Creative Commons License

Creative Commons

Attribution 2.5 CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE. License THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED. BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS. 1. Definitions

a. "Collective Work" means a work, such as a periodical issue, anthology or encyclopedia, in which the Work in its entirety in unmodified form, along with a number of other contributions, constituting separate and independent works in themselves, are assembled into a collective whole. A work that constitutes a Collective Work will not be considered a Derivative Work (as defined below) for the purposes of this License.

b. "Derivative Work" means a work based upon the Work or upon the Work and other pre-existing works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which the Work may be recast, transformed, or adapted, except that a work that constitutes a Collective Work will not be considered a Derivative Work for the purpose of this License. For the avoidance of doubt, where the Work is a musical composition or sound recording, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered a Derivative Work for the purpose of this License.

c. "Licensor" means the individual or entity that offers the Work under the terms of this License.

d. "Original Author" means the individual or entity who created the Work.

e. "Work" means the copyrightable work of authorship offered under the terms of this License.

f. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.

2. Fair Use Rights. Nothing in this license is intended to reduce, limit, or restrict any rights arising from fair use, first sale or other limitations on the exclusive rights of the copyright owner under copyright law or other applicable laws.

Creative Commons License of 202 Content from developer.android.com/design/videos/index.html through their Creative Commons Attribution 2.5 license

3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:

a. to reproduce the Work, to incorporate the Work into one or more Collective Works, and to reproduce the Work as incorporated in the Collective Works;

b. to create and reproduce Derivative Works;

c. to distribute copies or phonorecords of, display publicly, perform publicly, and perform publicly by means of a digital audio transmission the Work including as incorporated in Collective Works;

d. to distribute copies or phonorecords of, display publicly, perform publicly, and perform publicly by means of a digital audio transmission Derivative Works.

e. For the avoidance of doubt, where the work is a musical composition: i. Performance Royalties Under Blanket Licenses. Licensor waives the exclusive right to

collect, whether individually or via a performance rights society (e.g. ASCAP, BMI, SESAC), royalties for the public performance or public digital performance (e.g. webcast) of the Work.

ii. Mechanical Rights and Statutory Royalties. Licensor waives the exclusive right to collect, whether individually or via a music rights agency or designated agent (e.g. Harry Fox Agency), royalties for any phonorecord You create from the Work ("cover version") and distribute, subject to the compulsory license created by 17 USC Section 115 of the US Copyright Act (or the equivalent in other jurisdictions).

f. Webcasting Rights and Statutory Royalties. For the avoidance of doubt, where the Work is a sound recording, Licensor waives the exclusive right to collect, whether individually or via a performance-rights society (e.g. SoundExchange), royalties for the public digital performance (e.g. webcast) of the Work, subject to the compulsory license created by 17 USC Section 114 of the US Copyright Act (or the equivalent in other jurisdictions).

The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. All rights not expressly granted by Licensor are hereby reserved. 4. Restrictions.The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:

a. You may distribute, publicly display, publicly perform, or publicly digitally perform the Work only under the terms of this License, and You must include a copy of, or the Uniform Resource Identifier for, this License with every copy or phonorecord of the Work You distribute, publicly display, publicly perform, or publicly digitally perform. You may not offer or impose any terms on the Work that alter or restrict the terms of this License or the recipients' exercise of the rights granted hereunder. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties. You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. The above applies to the Work as incorporated in a Collective Work, but this does not require the Collective Work apart from the Work itself to be made subject to the terms of this License. If You create a Collective Work, upon notice from any Licensor You must, to the extent practicable, remove from the Collective Work any credit as required by clause 4(b), as requested. If You create a Derivative Work, upon notice from any Licensor You must, to the extent practicable, remove from the Derivative Work any credit as required by clause 4(b), as requested.

b. If you distribute, publicly display, publicly perform, or publicly digitally perform the Work or any Derivative Works or Collective Works, You must keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or (ii) if the Original Author and/or Licensor designate another party or parties (e.g. a sponsor institute, publishing entity, journal) for attribution in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; the title of the Work if supplied; to the extent reasonably practicable, the Uniform Resource Identifier, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and in the case of a Derivative Work, a credit


identifying the use of the Work in the Derivative Work (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). Such credit may be implemented in any reasonable manner; provided, however, that in the case of a Derivative Work or Collective Work, at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit.

5. Representations, Warranties and Disclaimer UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU. 6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 7. Termination

a. This License and the rights granted hereunder will terminate automatically upon any breach by You of the terms of this License. Individuals or entities who have received Derivative Works or Collective Works from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.

b. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.

8. Miscellaneous

a. Each time You distribute or publicly digitally perform the Work or a Collective Work, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.

b. Each time You distribute or publicly digitally perform a Derivative Work, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.

c. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.

d. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.

e. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.

Creative Commons is not a party to this License, and makes no warranty whatsoever in connection with the Work. Creative Commons will not be liable to You or any party on any legal theory for any damages whatsoever, including without limitation any general, special, incidental or consequential damages arising in Creative Commons License of 202

Content from developer.android.com/design/videos/index.html through their Creative Commons Attribution 2.5 license

connection to this license. Notwithstanding the foregoing two (2) sentences, if Creative Commons has expressly identified itself as the Licensor hereunder, it shall have all rights and obligations of Licensor. Except for the limited purpose of indicating to the public that the Work is licensed under the CCPL, neither party will use the trademark "Creative Commons" or any related trademark or logo of Creative Commons without the prior written consent of Creative Commons. Any permitted use will be in compliance with Creative Commons' then-current trademark usage guidelines, as may be published on its website or otherwise made available upon request from time to time. Creative Commons may be contacted at http://creativecommons.org/.

Creative Commons Attribution 3.0 Unported CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE LEGAL SERVICES. DISTRIBUTION OF THIS LICENSE DOES NOT CREATE AN ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES REGARDING THE INFORMATION PROVIDED, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM ITS USE. License

THE WORK (AS DEFINED BELOW) IS PROVIDED UNDER THE TERMS OF THIS CREATIVE COMMONS PUBLIC LICENSE ("CCPL" OR "LICENSE"). THE WORK IS PROTECTED BY COPYRIGHT AND/OR OTHER APPLICABLE LAW. ANY USE OF THE WORK OTHER THAN AS AUTHORIZED UNDER THIS LICENSE OR COPYRIGHT LAW IS PROHIBITED.

BY EXERCISING ANY RIGHTS TO THE WORK PROVIDED HERE, YOU ACCEPT AND AGREE TO BE BOUND BY THE TERMS OF THIS LICENSE. TO THE EXTENT THIS LICENSE MAY BE CONSIDERED TO BE A CONTRACT, THE LICENSOR GRANTS YOU THE RIGHTS CONTAINED HERE IN CONSIDERATION OF YOUR ACCEPTANCE OF SUCH TERMS AND CONDITIONS.

1. Definitions

a. "Adaptation" means a work based upon the Work, or upon the Work and other pre-existing works, such as a translation, adaptation, derivative work, arrangement of music or other alterations of a literary or artistic work, or phonogram or performance and includes cinematographic adaptations or any other form in which the Work may be recast, transformed, or adapted including in any form recognizably derived from the original, except that a work that constitutes a Collection will not be considered an Adaptation for the purpose of this License. For the avoidance of doubt, where the Work is a musical work, performance or phonogram, the synchronization of the Work in timed-relation with a moving image ("synching") will be considered an Adaptation for the purpose of this License.

b. "Collection" means a collection of literary or artistic works, such as encyclopedias and anthologies, or performances, phonograms or broadcasts, or other works or subject matter other than works listed in Section 1(f) below, which, by reason of the selection and arrangement of their contents, constitute intellectual creations, in which the Work is included in its entirety in unmodified form along with one or more other contributions, each constituting separate and independent works in themselves, which together are assembled into a collective whole. A work that constitutes a Collection will not be considered an Adaptation (as defined above) for the purposes of this License.

c. "Distribute" means to make available to the public the original and copies of the Creative Commons License of 202


http://creativecommons.org/

Work or Adaptation, as appropriate, through sale or other transfer of ownership.

d. "Licensor" means the individual, individuals, entity or entities that offer(s) the Work under the terms of this License.

e. "Original Author" means, in the case of a literary or artistic work, the individual, individuals, entity or entities who created the Work or if no individual or entity can be identified, the publisher; and in addition (i) in the case of a performance the actors, singers, musicians, dancers, and other persons who act, sing, deliver, declaim, play in, interpret or otherwise perform literary or artistic works or expressions of folklore; (ii) in the case of a phonogram the producer being the person or legal entity who first fixes the sounds of a performance or other sounds; and, (iii) in the case of broadcasts, the organization that transmits the broadcast.

f. "Work" means the literary and/or artistic work offered under the terms of this License including without limitation any production in the literary, scientific and artistic domain, whatever may be the mode or form of its expression including digital form, such as a book, pamphlet and other writing; a lecture, address, sermon or other work of the same nature; a dramatic or dramatico-musical work; a choreographic work or entertainment in dumb show; a musical composition with or without words; a cinematographic work to which are assimilated works expressed by a process analogous to cinematography; a work of drawing, painting, architecture, sculpture, engraving or lithography; a photographic work to which are assimilated works expressed by a process analogous to photography; a work of applied art; an illustration, map, plan, sketch or three-dimensional work relative to geography, topography, architecture or science; a performance; a broadcast; a phonogram; a compilation of data to the extent it is protected as a copyrightable work; or a work performed by a variety or circus performer to the extent it is not otherwise considered a literary or artistic work.

g. "You" means an individual or entity exercising rights under this License who has not previously violated the terms of this License with respect to the Work, or who has received express permission from the Licensor to exercise rights under this License despite a previous violation.

h. "Publicly Perform" means to perform public recitations of the Work and to communicate to the public those public recitations, by any means or process, including by wire or wireless means or public digital performances; to make available to the public Works in such a way that members of the public may access these Works from a place and at a place individually chosen by them; to perform the Work to the public by any means or process and the communication to the public of the performances of the Work, including by public digital performance; to broadcast and rebroadcast the Work by any means including signs, sounds or images.

i. "Reproduce" means to make copies of the Work by any means including without limitation by sound or visual recordings and the right of fixation and reproducing fixations of the Work, including storage of a protected performance or phonogram in digital form or other electronic medium.

2. Fair Dealing Rights. Nothing in this License is intended to reduce, limit, or restrict any uses free from copyright or rights arising from limitations or exceptions that are provided for in connection with the copyright protection under copyright law or other applicable laws.

3. License Grant. Subject to the terms and conditions of this License, Licensor hereby grants You a worldwide, royalty-free, non-exclusive, perpetual (for the duration of the applicable copyright) license to exercise the rights in the Work as stated below:

a. to Reproduce the Work, to incorporate the Work into one or more Collections, and to


Reproduce the Work as incorporated in the Collections;

b. to create and Reproduce Adaptations provided that any such Adaptation, including any translation in any medium, takes reasonable steps to clearly label, demarcate or otherwise identify that changes were made to the original Work. For example, a translation could be marked "The original work was translated from English to Spanish," or a modification could indicate "The original work has been modified.";

c. to Distribute and Publicly Perform the Work including as incorporated in Collections; and,

d. to Distribute and Publicly Perform Adaptations.

e. For the avoidance of doubt:

i. Non-waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme cannot be waived, the Licensor reserves the exclusive right to collect such royalties for any exercise by You of the rights granted under this License;

ii. Waivable Compulsory License Schemes. In those jurisdictions in which the right to collect royalties through any statutory or compulsory licensing scheme can be waived, the Licensor waives the exclusive right to collect such royalties for any exercise by You of the rights granted under this License; and,

iii. Voluntary License Schemes. The Licensor waives the right to collect royalties, whether individually or, in the event that the Licensor is a member of a collecting society that administers voluntary licensing schemes, via that society, from any exercise by You of the rights granted under this License.

The above rights may be exercised in all media and formats whether now known or hereafter devised. The above rights include the right to make such modifications as are technically necessary to exercise the rights in other media and formats. Subject to Section 8(f), all rights not expressly granted by Licensor are hereby reserved.

4. Restrictions. The license granted in Section 3 above is expressly made subject to and limited by the following restrictions:

a. You may Distribute or Publicly Perform the Work only under the terms of this License. You must include a copy of, or the Uniform Resource Identifier (URI) for, this License with every copy of the Work You Distribute or Publicly Perform. You may not offer or impose any terms on the Work that restrict the terms of this License or the ability of the recipient of the Work to exercise the rights granted to that recipient under the terms of the License. You may not sublicense the Work. You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. This Section 4(a) applies to the Work as incorporated in a Collection, but this does not require the Collection apart from the Work itself to be made subject to the terms of this License. If You create a Collection, upon notice from any Licensor You must, to the extent practicable, remove from the Collection any credit as required by Section 4(b), as requested. If You create an Adaptation, upon notice from any Licensor You must, to the extent practicable, remove from the Adaptation any credit as required by Section 4(b), as requested.

b. If You Distribute, or Publicly Perform the Work or any Adaptations or Collections, You must, unless a request has been made pursuant to Section 4(a), keep intact all copyright notices for the Work and provide, reasonable to the medium or means You


are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, and/or if the Original Author and/or Licensor designate another party or parties (e.g., a sponsor institute, publishing entity, journal) for attribution ("Attribution Parties") in Licensor's copyright notice, terms of service or by other reasonable means, the name of such party or parties; (ii) the title of the Work if supplied; (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work; and (iv) , consistent with Section 3(b), in the case of an Adaptation, a credit identifying the use of the Work in the Adaptation (e.g., "French translation of the Work by Original Author," or "Screenplay based on original Work by Original Author"). The credit required by this Section 4 (b) may be implemented in any reasonable manner; provided, however, that in the case of a Adaptation or Collection, at a minimum such credit will appear, if a credit for all contributing authors of the Adaptation or Collection appears, then as part of these credits and in a manner at least as prominent as the credits for the other contributing authors. For the avoidance of doubt, You may only use the credit required by this Section for the purpose of attribution in the manner set out above and, by exercising Your rights under this License, You may not implicitly or explicitly assert or imply any connection with, sponsorship or endorsement by the Original Author, Licensor and/or Attribution Parties, as appropriate, of You or Your use of the Work, without the separate, express prior written permission of the Original Author, Licensor and/or Attribution Parties.

c. Except as otherwise agreed in writing by the Licensor or as may be otherwise permitted by applicable law, if You Reproduce, Distribute or Publicly Perform the Work either by itself or as part of any Adaptations or Collections, You must not distort, mutilate, modify or take other derogatory action in relation to the Work which would be prejudicial to the Original Author's honor or reputation. Licensor agrees that in those jurisdictions (e.g. Japan), in which any exercise of the right granted in Section 3(b) of this License (the right to make Adaptations) would be deemed to be a distortion, mutilation, modification or other derogatory action prejudicial to the Original Author's honor and reputation, the Licensor will waive or not assert, as appropriate, this Section, to the fullest extent permitted by the applicable national law, to enable You to reasonably exercise Your right under Section 3(b) of this License (right to make Adaptations) but not otherwise.

5. Representations, Warranties and Disclaimer

UNLESS OTHERWISE MUTUALLY AGREED TO BY THE PARTIES IN WRITING, LICENSOR OFFERS THE WORK AS-IS AND MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND CONCERNING THE WORK, EXPRESS, IMPLIED, STATUTORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, OR THE ABSENCE OF LATENT OR OTHER DEFECTS, ACCURACY, OR THE PRESENCE OF ABSENCE OF ERRORS, WHETHER OR NOT DISCOVERABLE. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO SUCH EXCLUSION MAY NOT APPLY TO YOU.

6. Limitation on Liability. EXCEPT TO THE EXTENT REQUIRED BY APPLICABLE LAW, IN NO EVENT WILL LICENSOR BE LIABLE TO YOU ON ANY LEGAL THEORY FOR ANY SPECIAL, INCIDENTAL, CONSEQUENTIAL, PUNITIVE OR EXEMPLARY DAMAGES ARISING OUT OF THIS LICENSE OR THE USE OF THE WORK, EVEN IF LICENSOR HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

7. Termination

a. This License and the rights granted hereunder will terminate automatically upon any


breach by You of the terms of this License. Individuals or entities who have received Adaptations or Collections from You under this License, however, will not have their licenses terminated provided such individuals or entities remain in full compliance with those licenses. Sections 1, 2, 5, 6, 7, and 8 will survive any termination of this License.

b. Subject to the above terms and conditions, the license granted here is perpetual (for the duration of the applicable copyright in the Work). Notwithstanding the above, Licensor reserves the right to release the Work under different license terms or to stop distributing the Work at any time; provided, however that any such election will not serve to withdraw this License (or any other license that has been, or is required to be, granted under the terms of this License), and this License will continue in full force and effect unless terminated as stated above.

8. Miscellaneous

a. Each time You Distribute or Publicly Perform the Work or a Collection, the Licensor offers to the recipient a license to the Work on the same terms and conditions as the license granted to You under this License.

b. Each time You Distribute or Publicly Perform an Adaptation, Licensor offers to the recipient a license to the original Work on the same terms and conditions as the license granted to You under this License.

c. If any provision of this License is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this License, and without further action by the parties to this agreement, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.

d. No term or provision of this License shall be deemed waived and no breach consented to unless such waiver or consent shall be in writing and signed by the party to be charged with such waiver or consent.

e. This License constitutes the entire agreement between the parties with respect to the Work licensed here. There are no understandings, agreements or representations with respect to the Work not specified here. Licensor shall not be bound by any additional provisions that may appear in any communication from You. This License may not be modified without the mutual written agreement of the Licensor and You.

f. The rights granted under, and the subject matter referenced, in this License were drafted utilizing the terminology of the Berne Convention for the Protection of Literary and Artistic Works (as amended on September 28, 1979), the Rome Convention of 1961, the WIPO Copyright Treaty of 1996, the WIPO Performances and Phonograms Treaty of 1996 and the Universal Copyright Convention (as revised on July 24, 1971). These rights and subject matter take effect in the relevant jurisdiction in which the License terms are sought to be enforced according to the corresponding provisions of the implementation of those treaty provisions in the applicable national law. If the standard suite of rights granted under applicable copyright law includes additional rights not granted under this License, such additional rights are deemed to be included in the License; this License is not intended to restrict the license of any rights under applicable law.

Creative Commons Notice

Creative Commons is not a party to this License, and makes no warranty whatsoever in connection with the Work. Creative Commons will not be liable to You or any party on any legal theory for any damages whatsoever, including without limitation any general, special, incidental or consequential damages arising in connection to this license. Notwithstanding Creative Commons License of 202


the foregoing two (2) sentences, if Creative Commons has expressly identified itself as the Licensor hereunder, it shall have all rights and obligations of Licensor.

Except for the limited purpose of indicating to the public that the Work is licensed under the CCPL, Creative Commons does not authorize the use by either party of the trademark "Creative Commons" or any related trademark or logo of Creative Commons without the prior written consent of Creative Commons. Any permitted use will be in compliance with Creative Commons' then-current trademark usage guidelines, as may be published on its website or otherwise made available upon request from time to time. For the avoidance of doubt, this trademark restriction does not form part of this License.

Creative Commons may be contacted at http://creativecommons.org/.

46. Apache License, Version 2.0 Apache License V ersion 2.0, January 2004 http://www.apache.org/licenses/

TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

1. Definitions.

"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.

"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.

"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.

"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.

"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.

"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.

"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).

"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.

"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Apache License, Version 2.0 of 202


http://creativecommons.org/

http://www.apache.org/licenses/

Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."

"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.

2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:

f. You must give any other recipients of the Work or Derivative Works a copy of this License; and g. You must cause any modified files to carry prominent notices stating that You changed the files;

and h. You must retain, in the Source form of any Derivative Works that You distribute, all copyright,

patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and

i. If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. Y ou may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.

6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. Apache License, Version 2.0 of 202


7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.

8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.

9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.

END OF TERMS AND CONDITIONS

Apache License, Version 2.0 of 202 Content from developer.android.com/design/videos/index.html through their Creative Commons Attribution 2.5 license

47. INDEX 29. Accessibility ............................................ 154 18. Action bar ................................................... 86 46. Apache license, version 2.0 .............. 200 16. Application structure ............................. 63 28. Backwards compatibility ................... 151 36. Buttons ...................................................... 171 11. Color .............................................................. 39 23. Confirming & acknowledging .......... 114 2. Contents ........................................................... 4 45. Creative commons license ................ 192 3. Creative vision ............................................... 9 4. Design principles ........................................ 10 6. Devices and displays ................................. 26 41. Dialogs ....................................................... 182 43. Downloads ............................................... 188 15. Gestures ....................................................... 58 33. Grid lists ................................................... 166 27. Help ............................................................ 146 12. Iconography ............................................... 40 47. Index .......................................................... 203 1. Introduction .................................................... 3 32. Lists ............................................................ 165 9. Metrics and grids ........................................ 34 20. Multi-pane layouts ............................... 104 19. Navigation drawer .................................. 93 17. Navigation with back and up .............. 75

14. New in android ........................................ 55 24. Notifications ............................................ 120 42. Pickers ....................................................... 186 39. Progress & activity ............................... 175 30. Pure android ........................................... 157 34. Scrolling .................................................... 168 38. Seek bars and sliders ........................... 174 22. Selection ................................................... 111 26. Settings ...................................................... 134 35. Spinners .................................................... 169 21. Swipe views ............................................. 108 40. Switches .................................................... 180 31. Tabs ............................................................ 163 37. Text fields ................................................. 172 7. Themes ........................................................... 28 8. Touch feedback ........................................... 31 10. Typography ............................................... 36 5. Ui overview .................................................. 18 44. Videos ........................................................ 191 25. Widgets ..................................................... 128 13. Writing style ............................................. 51

INDEX of 202 Content from developer.android.com/design/videos/index.html through their Creative Commons Attribution 2.5 license

docand 1 design methods

Documents

attribution license

unported license

associated license

aforementioned license

creative vision

introduction page

source url

source organisations