diff options
Diffstat (limited to 'docs/html/design/patterns')
| -rw-r--r-- | docs/html/design/patterns/actionbar.jd | 354 | ||||
| -rw-r--r-- | docs/html/design/patterns/app-structure.jd | 254 | ||||
| -rw-r--r-- | docs/html/design/patterns/compatibility.jd | 61 | ||||
| -rw-r--r-- | docs/html/design/patterns/gestures.jd | 115 | ||||
| -rw-r--r-- | docs/html/design/patterns/index.jd | 29 | ||||
| -rw-r--r-- | docs/html/design/patterns/multi-pane-layouts.jd | 110 | ||||
| -rw-r--r-- | docs/html/design/patterns/navigation.jd | 204 | ||||
| -rw-r--r-- | docs/html/design/patterns/new-4-0.jd | 71 | ||||
| -rw-r--r-- | docs/html/design/patterns/notifications.jd | 236 | ||||
| -rw-r--r-- | docs/html/design/patterns/pure-android.jd | 164 | ||||
| -rw-r--r-- | docs/html/design/patterns/selection.jd | 100 | ||||
| -rw-r--r-- | docs/html/design/patterns/settings.jd | 689 | ||||
| -rw-r--r-- | docs/html/design/patterns/swipe-views.jd | 74 |
13 files changed, 2461 insertions, 0 deletions
diff --git a/docs/html/design/patterns/actionbar.jd b/docs/html/design/patterns/actionbar.jd new file mode 100644 index 0000000..2226fec --- /dev/null +++ b/docs/html/design/patterns/actionbar.jd @@ -0,0 +1,354 @@ +page.title=Action Bar +@jd:body + +<img src="{@docRoot}design/media/action_bar_pattern_overview.png"> + +<p>The <em>action bar</em> is arguably the most important structural element of an Android app. It's a +dedicated piece of real estate at the top of each screen that is generally persistent throughout the +app.</p> +<p><strong>The main purpose of the action bar is to</strong>:</p> +<ul> +<li>Make important actions (such as <em>New</em> or <em>Search</em>, etc) prominent and accessible in a predictable + way.</li> +<li>Support consistent navigation and view switching within apps.</li> +<li>Reduce clutter by providing an action overflow for rarely used actions.</li> +<li>Provide a dedicated space for giving your app an identity.</li> +</ul> +<p>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.</p> +<h2 id="organization">General Organization</h2> + +<p>The action bar is split into four different functional areas that apply to most apps.</p> +<img src="{@docRoot}design/media/action_bar_basics.png"> + +<div class="layout-content-row"> + <div class="layout-content-col span-7 with-callouts"> + + <ol> + <li class="value-1"><h4>App icon</h4> + <p> + +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 <a href="{@docRoot}design/patterns/navigation.html">Navigation</a> pattern. + +<div class="figure"> + <img src="{@docRoot}design/media/action_bar_pattern_up_app_icon.png"> + <div class="figure-caption"> + App icon with and without "up" affordance. + </div> +</div> + + </p> + </li> + </ol> + + </div> + <div class="layout-content-col span-6 with-callouts"> + + <ol> + <li class="value-2"><h4>View control</h4> + <p> + +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. + + </p> + <p> + +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. + + </p> + </li> + <li class="value-3"><h4>Action buttons</h4> + <p> + +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. + + </p> + </li> + <li class="value-4"><h4>Action overflow</h4> + <p> + +Move less often used actions to the action overflow. + + </p> + </li> + </ol> + </div> +</div> + +<h2 id="adapting-rotation">Adapting to Rotation and Different Screen Sizes</h2> + +<p>One of the most important UI issues to consider when creating an app is how to adjust to screen +rotation on different screen sizes.</p> +<p>You can adapt to such changes by using <em>split action bars</em>, which allow you to distribute action bar +content across multiple bars located below the main action bar or at the bottom of the screen.</p> + +<img src="{@docRoot}design/media/action_bar_pattern_rotation.png"> +<div class="figure-caption"> + Split action bar showing action buttons at the bottom of the screen in vertical orientation. +</div> + +<h2 id="considerations-split-action-bars">Layout Considerations for Split Action Bars</h2> + +<div class="layout-content-row"> + <div class="layout-content-col span-8 with-callouts"> + +<p>When splitting up content across multiple action bars, you generally have three possible locations +for action bar content:</p> +<ol> +<li><strong>Main action bar</strong></li> +<li><strong>Top bar</strong></li> +<li><strong>Bottom bar</strong></li> +</ol> +<p>If the user can navigate up the hierarchy from a given screen, the main action bar contains the up +caret, at a minimum.</p> +<p>To allow the user to quickly switch between the views your app provides, use tabs or a spinner in +the top bar.</p> +<p>To display actions and, if necessary, the action overflow, use the bottom bar.</p> + + </div> + <div class="layout-content-col span-3"> + + <img src="{@docRoot}design/media/action_bar_pattern_considerations.png"> + + </div> +</div> + +<h2 id="contextual">Contextual Action Bars</h2> + +<p>A <em>contextual action bar (CAB)</em> 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.</p> + +<img src="{@docRoot}design/media/action_bar_cab.png"> +<div class="figure-caption"> + Contextual action bar shown in Browser and Gmail +</div> + +<p>The selection CAB appears after a long press on a selectable data item triggers selection mode.</p> +<p><strong>From here the user can</strong>:</p> +<ul> +<li>Select additional elements by touching them.</li> +<li>Trigger an action from the CAB that applies to all selected data items. The CAB then + automatically dismisses itself.</li> +<li>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.</li> +</ul> +<p>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.</p> +<p>For more information, refer to the "Selection" pattern.</p> +<h2 id="elements">Action Bar Elements</h2> + +<h4>Tabs</h4> +<p><em>Tabs</em> display app views concurrently and make it easy to explore and switch between them. Use tabs +if you expect your users to switch views frequently.</p> + +<img src="{@docRoot}design/media/tabs_youtube.png"> + +<p>There are two types of tabs: fixed and scrollable.</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>Scrollable tabs</h4> +<p><em>Scrollable tabs</em> always take up the entire width of the bar, with the currently active view item in +the center, and therefore need to live in a dedicated bar. Scrollable tabs can themselves be +scrolled horizontally to bring more tabs into view.</p> +<p>Use scrollable tabs if you have a large number of views or if you're unsure how many views will be +displayed because your app inserts views dynamically (for example, open chats in a messaging app +that the user can navigate between). Scrollable tabs should always allow the user to navigate +between the views by swiping left or right on the content area as well as swiping the tabs +themselves.</p> + + </div> + <div class="layout-content-col span-7"> + + <video width="400" class="with-shadow play-on-hover" autoplay> + <source src="{@docRoot}design/media/tabs_scrolly.mp4" type="video/mp4"> + <source src="{@docRoot}design/media/tabs_scrolly.webm" type="video/webm"> + <source src="{@docRoot}design/media/tabs_scrolly.ogv" type="video/ogg"> + </video> + <div class="figure-caption"> + Scrolling tabs in the Play Store app. + <div class="video-instructions"> </div> + </div> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>Fixed tabs</h4> +<p><em>Fixed tabs</em> are always visible on the screen, and can't be moved out of the way like scrollable +tabs. Fixed tabs in the main action bar can move to the top bar when the screen orientation changes.</p> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/action_bar_pattern_default_tabs.png"> + <div class="figure-caption"> + Default fixed tabs shown in Holo Dark & Light. + </div> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>Spinners</h4> +<p>A <em>spinner</em> is a drop-down menu that allows users to switch between views of your app. </p> +<p><strong>Use spinners rather than tabs in the main action bar if</strong>:</p> +<ul> +<li>You don't want to give up the vertical screen real estate for a dedicated tab bar.</li> +<li>You expect your app's users to switch views infrequently.</li> +</ul> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/action_bar_pattern_spinner.png"> + <div class="figure-caption"> + Action bar spinner from Calendar application. + </div> + + </div> +</div> + +<h4>Action buttons</h4> +<p><em>Action buttons</em> on the action bar surface your app's most important activities. Think about which +buttons will get used most often, and order them accordingly. Depending on available screen real +estate, the system shows your most important actions as action buttons and moves the rest to the +action overflow. The action bar and the action overflow should only present actions to the user that +are available. If an action is unavailable in the current context, hide it. Do not show it as +disabled.</p> + +<img src="{@docRoot}design/media/action_bar_pattern_action_icons.png"> +<div class="figure-caption"> + A sampling of action buttons used throughout the Gmail application. +</div> + +<p>For guidance on prioritizing actions, use the FIT scheme.</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + +<p><strong>F — Frequent</strong></p> +<ul> +<li>Will people use this action at least 7 out of 10 times they visit the screen?</li> +<li>Will they typically use it several times in a row?</li> +<li>Would taking an extra step every time truly be burdensome?</li> +</ul> + + </div> + <div class="layout-content-col span-4"> + +<p><strong>I — Important</strong></p> +<ul> +<li>Do you want everyone to discover this action because it's especially cool or a selling point?</li> +<li>Is it something that needs to be effortless in the rare cases it's needed?</li> +</ul> + + </div> + <div class="layout-content-col span-4"> + +<p><strong>T — Typical</strong></p> +<ul> +<li>Is it typically presented as a first-class action in similar apps?</li> +<li>Given the context, would people be surprised if it were buried in the action overflow?</li> +</ul> + + </div> +</div> + +<p>If either F, I, or T apply, then it's appropriate for the action bar. Otherwise, it belongs in the +action overflow.</p> + +<p> + +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. + +</p> +<p> + +<a href="https://dl-ssl.google.com/android/design/Android_Design_Icons_20120229.zip">Download the Action Bar Icon Pack</a> + +</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>Action overflow</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/action_bar_pattern_overflow.png"> + <div class="figure-caption"> + Action overflow is pinned to the right side. + </div> + + </div> +</div> + +<p>How many actions will fit in the main action bar? Action bar capacity is controlled by the following +rules:</p> +<ul> +<li>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.</li> +<li>The screen width in density-independent pixels + (<acronym title="Density-independent pixels. One dp is one pixel on a 160 dpi screen.">dp</acronym>) + determine the number of items that will fit in the main action bar:<ul> +<li>smaller than 360 dp = 2 icons</li> +<li>360-499 dp = 3 icons</li> +<li>500-599 dp = 4 icons</li> +<li>600 dp and larger = 5 icons</li> +</ul> +</li> +</ul> + +<img src="{@docRoot}design/media/action_bar_pattern_table.png"> +<div class="figure-caption"> + In the above table "o" denotes an action bar item and "=" an overflow icon. +</div> + +<h4>Sharing data</h4> +<p>Whenever your app permits sharing of data, such as images or movie clips, use a <em>share action +provider</em> 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.</p> + +<img src="{@docRoot}design/media/action_bar_pattern_share_pack.png"> +<div class="figure-caption"> + The Gallery app's share action provider with extended spinner for additional sharing options. +</div> + +<h2 id="checklist">Action Bar Checklist</h2> + +<p>When planning your split action bars, ask yourself questions like these:</p> +<h4>How important is view navigation to the task?</h4> +<p>If view navigation is very important to your app, use tabs (for fastest view-switching) or spinners.</p> +<h4>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?</h4> +<p>Use the <acronym title="Frequent, Important or Typical">FIT</acronym> 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.</p> +<h4>What else is important enough to warrant continuous display?</h4> +<p>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.</p> diff --git a/docs/html/design/patterns/app-structure.jd b/docs/html/design/patterns/app-structure.jd new file mode 100644 index 0000000..e2398ed --- /dev/null +++ b/docs/html/design/patterns/app-structure.jd @@ -0,0 +1,254 @@ +page.title=Application Structure +@jd:body + +<p>Apps come in many varieties that address very different needs. For example:</p> +<ul> +<li>Apps such as Calculator or Camera that are built around a single focused activity handled from a + single screen</li> +<li>Apps such as Phone whose main purpose is to switch between different activities without deeper + navigation</li> +<li>Apps such as Gmail or the Play Store that combine a broad set of data views with deep navigation</li> +</ul> +<p>Your app's structure depends largely on the content and tasks you want to surface for your users.</p> +<h2 id="general-structure">General Structure</h2> + +<p>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.</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-9"> + + <img src="{@docRoot}design/media/app_structure_overview.png"> + + </div> + <div class="layout-content-col span-4"> + +<h4>Top level views</h4> +<p>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.</p> +<div class="vspace size-3"> </div> + +<h4>Category views</h4> +<p>Category views allow you to drill deeper into your data.</p> +<div class="vspace size-11"> </div> + +<h4>Detail/edit view</h4> +<p>The detail/edit view is where you consume or create data.</p> + + </div> +</div> + +<h2 id="top-level">Top Level</h2> + +<p>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.</p> +<p>Ask yourself: "What are my typical users most likely going to want to do in my app?", and structure +your start screen experience accordingly.</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Put content forward</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/app_structure_market.png"> + <div class="figure-caption"> + 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. + </div> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Set up action bars for navigation and actions</h4> +<p>All screens in your app should display action bars to provide consistent navigation and surface +important actions.</p> +<p>At the top level, special considerations apply to the action bar:</p> +<ul> +<li>Use the action bar to display your app's icon or title.</li> +<li>If your top level consists of multiple views, or if switching between data from different user + accounts is a significant use case, make sure that it's easy for the user to navigate between them + by adding view controls to your action bar.</li> +<li>If your app allows people to create content, consider making the content accessible right from the + top level.</li> +<li>If your content is searchable, include the Search action in the action bar so people can cut + through the navigation hierarchy.</li> +</ul> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/app_structure_gmail.png"> + <div class="figure-caption"> + 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. + </div> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Create an identity for your app</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/app_structure_music_lndscp.png"> + <div class="figure-caption"> + 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. + </div> + + </div> +</div> + +<h2 id="categories">Categories</h2> + +<p>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.</p> +<p>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.</p> +<h4>Use tabs to combine category selection and data display</h4> +<p>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.</p> + +<div class="vspace size-1"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-8"> + +<p>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.</p> + + <img src="{@docRoot}design/media/app_structure_scrolltabs.png"> + <div class="figure-caption"> + 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. + </div> + + </div> + <div class="layout-content-col span-5"> + +<p>If the categories in the tabs are not closely related, favor fixed tabs, so that all categories are +in view at the same time.</p> + + <img src="{@docRoot}design/media/app_structure_fixedtabs.png"> + <div class="figure-caption"> + YouTube uses fixed tabs to switch between different, relatively unrelated functional areas. + </div> + + + </div> +</div> + +<h4>Allow cutting through hierarchies</h4> +<p>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.</p> + +<img src="{@docRoot}design/media/app_structure_shortcut_on_item.png"> +<div class="figure-caption"> + 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. +</div> + +<h4>Acting upon multiple data items</h4> +<p>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.</p> +<p>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.</p> +<h2 id="details">Details</h2> + +<p>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.</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + +<h4>Layout</h4> +<p>Consider the activities people will perform in the detail view and arrange the layout accordingly. +For immersive content, make use of the lights-out mode to allow for distraction-free viewing of +full-screen content.</p> + + <img src="{@docRoot}design/media/app_structure_people_detail.png"> + + </div> + <div class="layout-content-col span-9"> + + <img src="{@docRoot}design/media/app_structure_book_detail_page_flip.png"> + <div class="figure-caption"> + Google Books' detail view is all about replicating the experience of reading an actual book. + The page-flip animation reinforces that notion. To create an immersive experience the app + enters lights-out mode, which hides all system UI affordances. + </div> + + <div class="figure-caption"> + 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. + </div> + </div> +</div> + +<h4>Make navigation between detail views efficient</h4> +<p>If your users are likely to want to look at multiple items in sequence, allow them to navigate +between items from within the detail view. Use swipe views or other techniques, such as filmstrips, +to achieve this.</p> + +<img src="{@docRoot}design/media/app_structure_gmail_swipe.png"> +<div class="figure-caption"> + Gmail using swipe views to navigate from detail view to detail view. +</div> + +<img src="{@docRoot}design/media/app_structure_gallery_filmstrip.png"> +<div class="figure-caption"> + In addition to supporting swipe gestures to move left or right through images, Gallery provides a + filmstrip control that lets people quickly jump to specific images. +</div> + +<h2 id="checklist">Checklist</h2> + +<ul> +<li> +<p>Find ways to display useful content on your start screen.</p> +</li> +<li> +<p>Use action bars to provide consistent navigation.</p> +</li> +<li> +<p>Keep your hierarchies shallow by using horizontal navigation and shortcuts.</p> +</li> +<li> +<p>Use multi-select to allow the user to act on collections of data.</p> +</li> +<li> +<p>Allow for quick navigation between detail items with swipe views.</p> +</li> +</ul> diff --git a/docs/html/design/patterns/compatibility.jd b/docs/html/design/patterns/compatibility.jd new file mode 100644 index 0000000..84ae337 --- /dev/null +++ b/docs/html/design/patterns/compatibility.jd @@ -0,0 +1,61 @@ +page.title=Backwards Compatibility +@jd:body + +<p>Significant changes in Android 3.0 included:</p> +<ul> +<li>Deprecation of navigation hardware keys (Back, Menu, Search, Home) in favor of handling navigation + via virtual controls (Back, Home, Recents).</li> +<li>Robust pattern for the use of menus in action bars.</li> +</ul> +<p>Android 4.0 brings these changes for tablets to the phone platform.</p> + +<h2 id="older-hardware">Adapting Android 4.0 to Older Hardware and Apps</h2> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>Phones with virtual navigation controls</h4> +<p>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.</p> +<p>Users access the action overflow by touching it in the action bar.</p> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/compatibility_virtual_nav.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>Phones with physical navigation keys</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/compatibility_physical_buttons.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>Legacy apps on phones with virtual navigation controls</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/compatibility_legacy_apps.png"> + + </div> +</div> diff --git a/docs/html/design/patterns/gestures.jd b/docs/html/design/patterns/gestures.jd new file mode 100644 index 0000000..9868df2 --- /dev/null +++ b/docs/html/design/patterns/gestures.jd @@ -0,0 +1,115 @@ +page.title=Gestures +@jd:body + +<p>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.</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + + <img src="{@docRoot}design/media/gesture_touch.png"> + +<h4>Touch</h4> +<p>Triggers the default functionality for a given item.</p> + +<ul> + <li class="no-bullet with-icon action"> + <h4>Action</h4> + <p>Press, lift</p></li> +</ul> + + </div> + <div class="layout-content-col span-4"> + + <img src="{@docRoot}design/media/gesture_longtouch.png"> + +<h4>Long press</h4> +<p>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.</p> + +<ul> + <li class="no-bullet with-icon action"> + <h4>Action</h4> + <p>Press, wait, lift</p></li> +</ul> + + </div> + <div class="layout-content-col span-4"> + + <img src="{@docRoot}design/media/gesture_swipe.png"> + +<h4>Swipe</h4> +<p>Scrolls overflowing content, or navigates between views in the same hierarchy.</p> + +<ul> + <li class="no-bullet with-icon action"> + <h4>Action</h4> + <p>Press, move, lift</p></li> +</ul> + + </div> +</div> + + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + + <img src="{@docRoot}design/media/gesture_drag.png"> + +<h4>Drag</h4> +<p>Rearranges data within a view, or moves data into a container (e.g. folders on Home Screen).</p> + +<ul> + <li class="no-bullet with-icon action"> + <h4>Action</h4> + <p>Long press, move, lift</p></li> +</ul> + + </div> + <div class="layout-content-col span-4"> + + <img src="{@docRoot}design/media/gesture_doubletouch.png"> + +<h4>Double touch</h4> +<p>Zooms into content. Also used as a secondary gesture for text selection.</p> + +<ul> + <li class="no-bullet with-icon action"> + <h4>Action</h4> + <p>Two touches in quick succession</p></li> +</ul> + + </div> + <div class="layout-content-col span-4"> + + <img src="{@docRoot}design/media/gesture_pinchopen.png"> + +<h4>Pinch open</h4> +<p>Zooms into content.</p> + +<ul> + <li class="no-bullet with-icon action"> + <h4>Action</h4> + <p>2-finger press, move outwards, lift</p></li> +</ul> + + </div> +</div> + + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + + <img src="{@docRoot}design/media/gesture_pinchclose.png"> + +<h4>Pinch close</h4> +<p>Zooms out of content.</p> + +<ul> + <li class="no-bullet with-icon action"> + <h4>Action</h4> + <p>2-finger press, move inwards, lift</p></li> +</ul> + + </div> +</div> diff --git a/docs/html/design/patterns/index.jd b/docs/html/design/patterns/index.jd new file mode 100644 index 0000000..732e4db --- /dev/null +++ b/docs/html/design/patterns/index.jd @@ -0,0 +1,29 @@ +page.title=Patterns +header.justLinks=1 +footer.hide=1 +@jd:body + +<style> +#landing-graphic-container { + position: relative; +} + +#text-overlay { + position: absolute; + left: 10px; + top: 492px; + width: 200px; +} +</style> + +<div id="landing-graphic-container"> + <div id="text-overlay"> + Design apps that behave in a consistent, predictable fashion. + <br><br> + <a href="{@docRoot}design/patterns/new-4-0.html" class="landing-page-link">New in Android 4.0</a> + </div> + + <a href="{@docRoot}design/patterns/new-4-0.html"> + <img src="{@docRoot}design/media/patterns_landing.png"> + </a> +</div> diff --git a/docs/html/design/patterns/multi-pane-layouts.jd b/docs/html/design/patterns/multi-pane-layouts.jd new file mode 100644 index 0000000..0e63e32 --- /dev/null +++ b/docs/html/design/patterns/multi-pane-layouts.jd @@ -0,0 +1,110 @@ +page.title=Multi-pane Layouts +@jd:body + +<p>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.</p> +<p><em>Panels</em> 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.</p> +<h2 id="combining-views">Combining Multiple Views Into One</h2> + +<p>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.</p> + +<img src="{@docRoot}design/media/multipane_views.png"> + +<p>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. </p> + +<img src="{@docRoot}design/media/multipane_view_tablet.png"> + +<p>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.</p> +<h2 id="orientation">Compound Views and Orientation Changes</h2> + +<p>Screens should have the same functionality regardless of orientation. If you use a compound view in +one orientation, don't split it up when the user rotates the screen. There are several techniques +you can use to adjust the layout after orientation change while keeping functional parity intact.</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/multipane_stretch.png"> + + </div> + <div class="layout-content-col span-5"> + +<h4>Stretch/compress</h4> +<p>Adjust the column width of your left pane to achieve a balanced layout in both orientations.</p> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/multipane_stack.png"> + + </div> + <div class="layout-content-col span-5"> + +<h4>Stack</h4> +<p>Rearrange the panels on your screen to match the orientation.</p> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/multipane_expand.png"> + + </div> + <div class="layout-content-col span-5"> + +<h4>Expand/collapse</h4> +<p>When the device rotates, collapse the left pane view to only show the most important information. +Provide an <em>expand</em> control that allows the user to bring the left pane content back to its original +width and vice versa.</p> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/multipane_show.png"> + + </div> + <div class="layout-content-col span-5"> + +<h4>Show/hide</h4> +<p>After rotating the device, show the right pane in fullscreen view. Use the Up icon in the action bar +to show the left panel and allow navigation to a different email. Hide the left panel by touching +the content in the detail panel.</p> + + </div> +</div> + +<h2 id="checklist">Checklist</h2> + +<ul> +<li> +<p>Plan in advance on how your app scales to different screen sizes and screen orientations.</p> +</li> +<li> +<p>Identify the most appropriate method for the panels in your compound views to reorganize + themselves when screen orientation changes.</p> +</li> +<li> +<p>Look for opportunities to consolidate your views into multi-panel compound views.</p> +</li> +<li> +<p>Make sure that your screens provide functional parity after the screen orientation + changes.</p> +</li> +</ul> diff --git a/docs/html/design/patterns/navigation.jd b/docs/html/design/patterns/navigation.jd new file mode 100644 index 0000000..7e288ae --- /dev/null +++ b/docs/html/design/patterns/navigation.jd @@ -0,0 +1,204 @@ +page.title=Navigation with Back and Up +@jd:body + +<p>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.</p> +<p>Android 2.3 and earlier relied upon the system <em>Back</em> button for supporting navigation within an +app. With the introduction of action bars in Android 3.0, a second navigation mechanism appeared: +the <em>Up</em> button, consisting of the app icon and a left-point caret.</p> + +<img src="{@docRoot}design/media/navigation_with_back_and_up.png"> + +<h2 id="up-vs-back">Up vs. Back</h2> + +<p>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.</p> +<p>If a screen is the topmost one in an app (that is, the app's home), it should not present an Up +button.</p> + +<p>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.</p> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_up_vs_back_gmail.png"> + +<p>The Back button also supports a few behaviors not directly tied to screen-to-screen navigation: +</p> +<ul> +<li>Dismisses floating windows (dialogs, popups)</li> +<li>Dismisses contextual action bars, and removes the highlight from the selected items</li> +<li>Hides the onscreen keyboard (IME)</li> +</ul> +<h2 id="within-app">Navigation Within Your App</h2> + +<h4>Navigating to screens with multiple entry points</h4> +<p>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.</p> +<h4>Changing view within a screen</h4> +<p>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.</p> +<p>Examples of such view changes are:</p> +<ul> +<li>Switching views using tabs and/or left-and-right swipes</li> +<li>Switching views using a dropdown (aka collapsed tabs)</li> +<li>Filtering a list</li> +<li>Sorting a list</li> +<li>Changing display characteristics (such as zooming)</li> +</ul> +<h4>Navigating between sibling screens</h4> +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_between_siblings_gmail.png"> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_between_siblings_market1.png"> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_between_siblings_market2.png"> + +<h2 id="into-your-app">Navigation into Your App via Home Screen Widgets and Notifications</h2> + +<p>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.</p> + +<p>For both of these cases, handle the Up button as follows:</p> + +<ul> +<li><em>If the destination screen is typically reached from one particular screen within your +app</em>, Up should navigate to that screen.</li> +<li><em>Otherwise</em>, Up should navigate to the topmost ("Home") screen of your app.</li> +</ul> + +<p>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.</p> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_from_outside_back.png"> + +<h4>Indirect notifications</h4> + +<p>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 <em>indirect notifications</em>.</p> + +<p>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.</p> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_indirect_notification.png"> + +<h4>Pop-up notifications</h4> + +<p><em>Pop-up notifications</em> bypass the notification drawer, instead appearing directly in +front of the user. They are rarely used, and <strong>should be reserved for occasions where a timely +response is required and the interruption of the user's context is necessary</strong>. 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.</p> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_popup_notification.png"> + +<h2 id="between-apps">Navigation Between Apps</h2> + +<p>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.</p> + +<p>To understand app-to-app navigation, it's important to understand the Android framework behavior +discussed below.</p> + +<h4>Activities, tasks, and intents</h4> + +<p>In Android, an <strong>activity</strong> 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.</p> + +<p>A <strong>task</strong> 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.</p> + +<p>An <strong>intent</strong> 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.</p> + +<h4>Example: navigating between apps to support sharing</h4> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_between_apps_inward.png"> + +<p>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.</p> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_between_apps_back.png"> + +<p>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.</p> + +<img src="{@docRoot}design/media/navigation_between_apps_up.png"> + +<p>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.</p> + +<p>When your app registers to handle intents with an activity deep within the app's hierarchy, +refer to <a href="#into-your-app">Navigation into Your App via Home Screen Widgets and +Notifications</a> for guidance on how to specify Up navigation.</p> diff --git a/docs/html/design/patterns/new-4-0.jd b/docs/html/design/patterns/new-4-0.jd new file mode 100644 index 0000000..91ebba7 --- /dev/null +++ b/docs/html/design/patterns/new-4-0.jd @@ -0,0 +1,71 @@ +page.title=New in Android 4.0 +@jd:body + +<div class="layout-content-row"> + <div class="layout-content-col span-7"> + +<h4>Navigation bar</h4> +<p>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 +<a href="{@docRoot}design/patterns/compatibility.html">Compatibility</a> 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.</p> + + </div> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/whats_new_nav_bar.png"> + + </div> +</div> + +<div class="vspace size-2"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-7"> + +<h4>Action bar</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/whats_new_action_bar.png"> + + </div> +</div> + +<div class="vspace size-2"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-7"> + +<h4>Multi-pane layouts</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/whats_new_multipanel.png"> + + </div> +</div> + +<div class="vspace size-2"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-7"> + +<h4>Selection</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/whats_new_multiselect.png"> + + </div> +</div> diff --git a/docs/html/design/patterns/notifications.jd b/docs/html/design/patterns/notifications.jd new file mode 100644 index 0000000..ad88a01 --- /dev/null +++ b/docs/html/design/patterns/notifications.jd @@ -0,0 +1,236 @@ +page.title=Notifications +@jd:body + +<p>The notification system allows your app to keep the user informed about important events, such as +new messages in a chat app or a calendar event.</p> +<p>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.</p> +<h4>When to display a notification</h4> +<p>To create an application that people love, it's important to recognize that the user's attention and +focus is a resource that must be protected. To use an analogy that might resonate with software +developers, the user is not a method that can be invoked to return a value. The user's focus is a +resource more akin to a thread, and creating a notification momentarily blocks the user thread as +they process and then dismiss the interruptive notification.</p> +<p>Android's notification system has been designed to quickly inform users of events while they focus +on a task, but it is nonetheless still important to be conscientious when deciding to create a +notification.</p> +<p>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.</p> +<p>Notifications should be used primarily for <strong>time sensitive events</strong>, and especially if these +synchronous events <strong>involve other people</strong>. 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.</p> + +<img src="{@docRoot}design/media/notifications_pattern_real_time_people.png"> + +<div class="vspace size-2"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-7"> + +<h4>When not to display a notification</h4> +<p>There are however many other cases where notifications should not be used:</p> +<ul> +<li> +<p>Don't notify the user of information that is not directed specifically at them, or information +that is not truly time sensitive. For instance the asynchronous and undirected updates flowing +through a social network do not warrant a real time interruption.</p> +</li> +<li> +<p>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.</p> +</li> +<li> +<p>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.</p> +</li> +<li> +<p>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.</p> +</li> +<li> +<p>Don't use notifications for services that the user cannot manually start or stop.</p> +</li> +<li> +<p>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.</p> +</li> +</ul> + + </div> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/notifications_pattern_social_fail.png"> + + </div> +</div> + +<h2 id="design-guidelines">Design Guidelines</h2> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/notifications_pattern_anatomy.png"> + + </div> + <div class="layout-content-col span-6"> + +<h4>Make it personal</h4> +<p>For notifications of items sent by another user (such as a message or status update), include that +person's image.</p> +<p>Remember to include the app icon as a secondary icon in the notification, so that the user can +still identify which app posted it.</p> + + </div> +</div> + +<h4>Navigate to the right place</h4> +<p>When the user touches a notification, be open your app to the place where the user can consume and +act upon the data referenced in the notification. In most cases this will be the detail view of a +single data item (e.g. a message), but it might also be a summary view if the notification is +stacked (see <em>Stacked notifications</em> 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 <em>System-to-app navigation</em> in the +<a href="{@docRoot}design/patterns/navigation.html">Navigation</a> design pattern.</p> +<h4>Timestamps for time sensitive events</h4> +<p>By default, standard Android notifications include a timestamp in the upper right corner. Consider +whether the timestamp is valuable in the context of your notification. If the timestamp is not +valuable, consider if the event is important enough to warrant grabbing the user's attention with a +notification. If the notification is important enough, decide if you would like to opt out of +displaying the timestamp.</p> +<p>Include a timestamp if the user likely needs to know how long ago the notification occurred. Good +candidates for timestamps include communication notifications (email, messaging, chat, voicemail) +where the user may need the timestamp information to understand the context of a message or to +tailor a response.</p> +<h4>Stack your notifications</h4> +<p>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.</p> +<p>A stacked notification builds a summary description and allows the user to understand how many +notifications of a particular kind are pending.</p> +<p><strong>Don't</strong>:</p> + +<img src="{@docRoot}design/media/notifications_pattern_additional_fail.png"> + +<p><strong>Do</strong>:</p> + +<img src="{@docRoot}design/media/notifications_pattern_additional_win.png"> + +<p>If you keep the summary and detail information on different screens, a stacked notification may need +to open to a different place in the app than a single notification.</p> +<p>For example, a single email notification should always open to the content of the email, whereas a +stacked email notification opens to the Inbox view.</p> +<h4>Clean up after yourself</h4> +<p>Just like calendar events, some notifications alert the user to an event that happens at a +particular point in time. After that moment has passed, the notification is likely not important to +the user anymore, and you should consider removing it automatically. The same is true for active +chat conversations or voicemail messages the user has listened to, users should not have to manually +dismiss notifications independently from taking action on them.</p> + +<div class="vspace size-1"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-7"> + +<h4>Provide a peek into your notification</h4> +<p>You can provide a short preview of your notification's content by providing optional ticker text. +The ticker text is shown for a short amount of time when the notification enters the system and then +hides automatically.</p> + + </div> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/notifications_pattern_phone_ticker.png"> + + </div> +</div> + +<h4>Make notifications optional</h4> +<p>Users should always be in control of notifications. Allow the user to silence the notifications from +your app by adding a notification settings item to your application settings.</p> +<h4>Use distinct icons</h4> +<p>By glancing at the notification area, the user should be able to discern what notification types are +currently pending.</p> +<p><strong>Do</strong>:</p> +<ul> +<li>Look at the notification icons the Android apps already provide and create notification icons for + your app that are sufficiently distinct in appearance.</li> +</ul> +<p><strong>Don't</strong>:</p> +<ul> +<li>Use color to distinguish your app from others. Notification icons should generally be monochrome.</li> +</ul> + +<h2 id="interacting-with-notifications">Interacting With Notifications</h2> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/notifications_pattern_phone_icons.png"> + + </div> + <div class="layout-content-col span-6"> + +<p>Notifications are indicated by icons in the notification area and can be accessed by opening the +notification drawer.</p> +<p>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.</p> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<p>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.</p> + + </div> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/notifications_pattern_tablet.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + + <img src="{@docRoot}design/media/notifications_pattern_ongoing_music.png"> + + </div> + <div class="layout-content-col span-6"> + +<h4>Ongoing notifications</h4> +<p>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.</p> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-12"> + +<h4>Dialogs and toasts are for feedback not notification</h4> +<p>Your app should not create a dialog or toast if it is not currently on screen. Dialogs and Toasts +should only be displayed as the immediate response to the user taking an action inside of your app. +For instance, dialogs can be used to confirm that the user understands the severity of an action, +and toasts can echo back that an action has been successfully taken.</p> + + </div> +</div> + +<div class="vspace size-1"> </div> + +<img src="{@docRoot}design/media/notifications_pattern_dialog_toast.png"> diff --git a/docs/html/design/patterns/pure-android.jd b/docs/html/design/patterns/pure-android.jd new file mode 100644 index 0000000..77813c0 --- /dev/null +++ b/docs/html/design/patterns/pure-android.jd @@ -0,0 +1,164 @@ +page.title=Pure Android +@jd:body + +<p>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.</p> + +<div class="vspace size-1"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Don't mimic UI elements from other platforms</h4> +<p>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.</p> +<p>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 +<a href="{@docRoot}design/building-blocks/index.html">Building Blocks</a> +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.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/migrating_ui_elements.png"> + <div class="figure-caption"> + Sampling of UI elements from Android, iOS and Windows Phone 7. + </div> + + </div> +</div> + +<div class="vspace size-2"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Don't carry over platform-specific icons</h4> +<p>Platforms typically provide sets of icons for common functionality, such as sharing, creating a new +document or deleting.</p> +<p>As you are migrating your app to Android, please swap out platform-specific icons with their Android +counterparts.</p> +<p>You can find a wide variety of icons for use in your app on the +<a href="{@docRoot}design/downloads/index.html">Downloads</a> page.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/migrating_icons.png"> + <div class="figure-caption"> + Sampling of icons from Android, iOS and Windows Phone 7. + </div> + + </div> +</div> + +<div class="vspace size-2"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Don't use bottom tab bars</h4> +<p>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.</p> +<p>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.</p> +<p>For more information on how to properly use action bars for view control, see +<a href="{@docRoot}design/patterns/actionbar.html">Action Bars</a>.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/migrating_ios_dialers.png"> + <div class="figure-caption"> + Android dialer with tabs in an action bar vs. bottom tabs in iOS. + </div> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Don't hardcode links to other apps</h4> +<p>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 <em>Share +Action Provider</em> in your action bar to provide faster access to the user's most recently used +sharing target.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/migrating_intents.png"> + <div class="figure-caption"> + Link to other apps with the activity chooser or use the <em>Share Action Provider</em> in the + action bar. + </div> + + </div> +</div> + +<div class="vspace size-2"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Don't use labeled back buttons on action bars</h4> +<p>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 <a href="{@docRoot}design/patterns/navigation.html">Navigation</a> pattern.</p> +<p>Follow this guideline to provide a consistent navigation experience across the platform.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/migrating_ios_galleries.png"> + <div class="figure-caption"> + Android action bar with up caret vs. iOS labeled "Back" button. + </div> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + +<h4>Don't use right-pointing carets on line items</h4> +<p>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.</p> +<p>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.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/migrating_ios_settings.png"> + <div class="figure-caption"> + Android settings without right-pointing carets in line items vs. iOS settings. + </div> + + </div> +</div> + +<h2 id="device-independence">Device Independence</h2> + +<p>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.</p> +<p>For more information, read <a href="{@docRoot}design/style/devices-displays.html">Devices and Displays</a> as +well as <a href="{@docRoot}design/patterns/multi-pane-layouts.html">Multi-pane Layouts</a> in this design guide.</p> diff --git a/docs/html/design/patterns/selection.jd b/docs/html/design/patterns/selection.jd new file mode 100644 index 0000000..e3ee90e --- /dev/null +++ b/docs/html/design/patterns/selection.jd @@ -0,0 +1,100 @@ +page.title=Selection +@jd:body + +<p>Android 3.0 introduced the <em>long press</em> gesture—that is, a touch that's held in the same +position for a moment—as the global gesture to select data. This affects the way you should +handle multi-select and contextual actions in your apps.</p> + +<div class="vspace size-1"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>What has changed?</h4> +<p>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.</p> +<p>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).</p> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/selection_context_menu.png"> + <div class="figure-caption"> + Traditional use of the long press gesture to show contextual menus. + </div> + + </div> +</div> + +<h4>Using the contextual action bar (CAB)</h4> +<p>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.</p> + +<img src="{@docRoot}design/media/selection_cab_big.png"> + +<div class="vspace size-1"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<p>From here the user can:</p> +<ul> +<li>Select additional data items by touching them.</li> +<li>Trigger an action from the CAB that applies to all highlighted data items. The CAB then + automatically dismisses itself.</li> +<li>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.</li> +</ul> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/selection_cab_example.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-6"> + +<h4>Selecting CAB actions</h4> +<p>You can decide which actions and elements appear in the CAB. Use the guidelines in the <a href="actionbar.html">Action Bar +pattern</a> to decide which items to surface at the top level and which to move to the +action overflow.</p> +<h4>Dynamically adjust CAB actions</h4> +<p>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.</p> + + </div> + <div class="layout-content-col span-7"> + + <img src="{@docRoot}design/media/selection_adjusting_actions.png"> + <div class="figure-caption"> + Adjusting actions in the CAB as additional items are selected. + </div> + + </div> +</div> + +<h2 id="checklist">Checklist</h2> + +<ul> +<li> +<p>Whenever your app supports the selection of multiple data items, make use of the contextual action + bar (CAB).</p> +</li> +<li> +<p>Reserve the long press gesture for selection exclusively. Don't use it to display traditional + contextual menus.</p> +</li> +<li> +<p>If you don't support multi-selection within a list, long press should do nothing.</p> +</li> +<li> +<p>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.</p> +</li> +</ul> diff --git a/docs/html/design/patterns/settings.jd b/docs/html/design/patterns/settings.jd new file mode 100644 index 0000000..3b28b84 --- /dev/null +++ b/docs/html/design/patterns/settings.jd @@ -0,0 +1,689 @@ +page.title=Settings +@jd:body + +<p>Settings is a place in your app where users indicate their preferences for how your app should +behave. This benefits users because:</p> + +<ul> +<li>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: <a href="{@docRoot}design/get-started/principles.html#decide-for-me">Decide for me but +let me have the final say</a>).</li> +<li>You help them feel at home and in control (see design principle: +<a href="{@docRoot}design/get-started/principles.html#make-it-mine">Let me make it mine</a>).</li> +</ul> + +<h2 id="flow-structure">Flow and Structure</h2> + +<h4 id="settings-access">Provide access to Settings in the action overflow</h4> + +<p>Settings is given low prominence in the UI because it's not frequently needed. Even if there's +room in the <a href="{@docRoot}design/patterns/actionbar.html">action bar</a>, 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".</p> + +<img src="{@docRoot}design/media/settings_overflow.png"> + +<div class="vspace size-2"> </div> + +<h4 id="what-to-make-a-setting">Avoid the temptation to make everything a setting</h4> + +<p>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.</p> + +<p>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.</p> + +<p>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:</p> + +<img src="{@docRoot}design/media/settings_flowchart.png"> + +<div class="vspace size-3"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-5 with-callouts"> + +<h4 id="group-settings">If you still have lots of settings, group related settings together</h4> + +<p>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.</p> + +<p>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:</p> + +<ol> +<li><h4>Under a section divider</h4></li> +<li><h4>In a separate subscreen</h4></li> +</ol> + +<p>You can use one or both these grouping techniques to organize your app's settings.</p> + +<p>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.</p> + + </div> + <div class="layout-content-col span-8"> + + <img src="{@docRoot}design/media/settings_grouping.png"> + + </div> +</div> + +<p>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.</p> + +<div class="vspace size-1"> </div> + +<div class="layout-content-row"> + <div class="layout-content-col span-2"> + +<h4>7 or fewer</h4> + + </div> + <div class="layout-content-col span-11"> + +<p>Don't group them at all. It won't benefit users and will seem like overkill.</p> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-2"> + +<h4>8 to 10</h4> + + </div> + <div class="layout-content-col span-11"> + +<p>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:</p> + +<ul> +<li>If they include some of your most important settings, list them at the top without a section +divider.</li> +<li>Otherwise, list them at the bottom with a section divider called "OTHER", in order of +importance.</li> +</ul> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-2"> + +<h4>11 to 15</h4> + + </div> + <div class="layout-content-col span-11"> + +<p>Same advice as above, but try 2 to 4 section dividers.</p> + +<p>Also, try the following to reduce the list:</p> + +<ul> +<li>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.</li> +<li>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.</li> +</ul> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-2"> + +<h4>16 or more</h4> + + </div> + <div class="layout-content-col span-11"> + +<p>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.</p> + + </div> +</div> + + +<h2 id="patterns">Design Patterns</h2> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>Checkbox</h4> +<p>Use this pattern for a setting that is either selected or not selected.</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_checkbox.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>Multiple choice</h4> +<p>Use this pattern for a setting that needs to present a discrete set of options, from which the +user can choose only one.</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_multiple_choice.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>Slider</h4> +<p>Use this pattern for a setting where the range of values are not discrete and fall along a +continuum.</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_slider.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>Date/time</h4> +<p>Use this pattern for a setting that needs to collect a date and/or time from the user.</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_date_time.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>Subscreen navigation</h4> +<p>Use this pattern for navigating to a subscreen or sequence of subscreens that guide the user +through a more complex setup process.</p> +<ul> +<li>If navigating to a single subscreen, use the same title in both the subscreen and the label +navigating to it.</li> +<li>If navigating to a sequence of subscreens (as in this example), use a title that describes the +first step in the sequence.</li> +</ul> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_subscreen_navigation.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>List subscreen</h4> +<p>Use this pattern for a setting or category of settings that contains a list of equivalent items. +</p> +<p>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.</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_list_subscreen.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>Master on/off switch</h4> +<p>Use this pattern for a category of settings that need a mechanism for turning on or off as a +whole.</p> +<p>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.</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_master_on_off.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<div class="vspace size-2"> </div> + +<p>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.</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_master_on_off_2.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>Individual on/off switch</h4> +<p>Use this pattern for an individual setting that requires a more elaborate description than can +be provided in checkbox form.</p> +<p>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.</p> +<p>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".</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_individual_on_off.png"> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-3"> + +<h4>Dependency</h4> +<p>Use this pattern for a setting that changes availability based on the value of another setting. +</p> +<p>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.</p> +<p>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. +</p> + + </div> + <div class="layout-content-col span-10"> + +<img src="{@docRoot}design/media/settings_dependency.png"> + + </div> +</div> + +<h2 id="defaults">Defaults</h2> + +<p>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:</p> + +<ul> +<li>Which choice would most users be likely to choose on their own if there were no default?</li> +<li>Which choice is the most neutral or middle-of-the-road?</li> +<li>Which choice is the least risky, controversial, or over-the-top?</li> +<li>Which choice uses the least amount of battery or mobile data?</li> +<li>Which choice best supports the design principle +<a href="{@docRoot}design/get-started/principles.html#never-lose-my-stuff">Never lose my stuff</a>?</li> +<li>Which choice best supports the design principle +<a href="{@docRoot}design/get-started/principles.html#interrupt-only-if-important">Only interrupt +me if it's important</a>? +</li> +</ul> + +<h2 id="writing">Writing Guidelines</h2> + +<h4>Label clearly and concisely</h4> + +<p>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:</p> + +<ul> +<li>Write each label in sentence case (i.e. only the first word and proper nouns are capitalized). +</li> +<li>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.</li> +<li>Likewise, don't end a label with a word like "setting" or "settings". It's already implied. +</li> +<li>If the setting is part of a grouping, don't repeat the word(s) used in the section divider or +subscreen title.</li> +<li>Avoid starting a label with a negative word like "Don't" or "Never". For example, "Don't +allow" could be rephrased to "Block".</li> +<li>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.</li> +<li>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".</li> +</ul> + +<p>Once you've decided on labels for your settings, be sure to preview them on an +<a href="{@docRoot}design/style/metrics-grids.html">LDPI handset</a> in portrait to make sure +they'll fit everywhere.</p> + +<h4>Secondary text below is for status, not description…</h4> + +<p>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. +</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + + <div class="do-dont-label bad emulate-content-left-padding">Before</div> + + <table class="ui-table bad emulate-content-left-padding"> + <thead> + <tr> + <th class="label"> + Screen timeout + </th> + </tr> + </thead> + <tbody> + <tr> + <td class="secondary-text"> + Adjust the delay before the screen automatically turns off + </td> + </tr> + </tbody> + </table> + + </div> + <div class="layout-content-col span-4"> + + <div class="do-dont-label good">After</div> + + <table class="ui-table good"> + <thead> + <tr> + <th class="label"> + Sleep + </th> + </tr> + </thead> + <tbody> + <tr> + <td class="secondary-text"> + After 10 minutes of activity + </td> + </tr> + </tbody> + </table> + + </div> +</div> + +<p>Status in secondary text has the following benefits:</p> +<ul> +<li>Users can see at a glance what the current value of a setting is without having to navigate +any further.</li> +<li>It applies the design principle +<a href="{@docRoot}design/get-started/principles.html#keep-it-brief">Keep it brief</a>, which +users greatly appreciate.</li> +</ul> + +<h4>…unless it's a checkbox setting</h4> +<p>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.</p> + +<p>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.</p> + +<p>Follow these guidelines to write checkbox setting descriptions:</p> +<ul> +<li>Keep it to one sentence and don't use ending punctuation.</li> +<li>Convey what happens when the setting is checked, phrased in the form of a command. Example: +"Allow data exchange", not "Allows data exchange".</li> +<li>Avoid repetition by choosing words that don't already appear in the label.</li> +<li>Don't refer to the user unless it's necessary for understanding the setting.</li> +<li>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.</li> +</ul> + +<h4>Writing examples</h4> + +<p>The following are examples of changes we made to labels and secondary text in the Settings app +in Ice Cream Sandwich.</p> + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + + <div class="do-dont-label bad emulate-content-left-padding">Before</div> + + <table class="ui-table bad emulate-content-left-padding"> + <thead> + <tr> + <th class="label"> + Use tactile feedback + </th> + </tr> + </thead> + </table> + + </div> + <div class="layout-content-col span-4"> + + <div class="do-dont-label good">After</div> + + <table class="ui-table good"> + <thead> + <tr> + <th class="label"> + Vibrate on touch + </th> + </tr> + </thead> + </table> + + </div> + <div class="layout-content-col span-5"> + +<p>In this checkbox setting, we eliminated the throwaway word "Use" and rephrased the label to be +more direct and understandable.</p> + + </div> + +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + + <div class="do-dont-label bad emulate-content-left-padding">Before</div> + + <table class="ui-table bad emulate-content-left-padding"> + <thead> + <tr> + <th class="label"> + Screen timeout + </th> + </tr> + </thead> + <tbody> + <tr> + <td class="secondary-text"> + Adjust the delay before the screen automatically turns off + </td> + </tr> + </tbody> + </table> + + </div> + <div class="layout-content-col span-4"> + + <div class="do-dont-label good">After</div> + + <table class="ui-table good"> + <thead> + <tr> + <th class="label"> + Sleep + </th> + </tr> + </thead> + <tbody> + <tr> + <td class="secondary-text"> + After 10 minutes of activity + </td> + </tr> + </tbody> + </table> + + </div> + <div class="layout-content-col span-5"> + +<p>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".</p> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + + <div class="do-dont-label bad emulate-content-left-padding">Before</div> + + <table class="ui-table bad emulate-content-left-padding"> + <thead> + <tr> + <th class="label"> + Change screen lock + </th> + </tr> + </thead> + <tbody> + <tr> + <td class="secondary-text"> + Change or disable pattern, PIN, or password security + </td> + </tr> + </tbody> + </table> + + </div> + <div class="layout-content-col span-4"> + + <div class="do-dont-label good">After</div> + + <table class="ui-table good"> + <thead> + <tr> + <th class="label"> + Screen lock + </th> + </tr> + </thead> + <tbody> + <tr> + <td class="secondary-text"> + Pattern + </td> + </tr> + </tbody> + </table> + + </div> + <div class="layout-content-col span-5"> + +<p>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".</p> + + </div> +</div> + +<div class="layout-content-row"> + <div class="layout-content-col span-4"> + + <div class="do-dont-label bad emulate-content-left-padding">Before</div> + + <table class="ui-table bad emulate-content-left-padding"> + <thead> + <tr> + <th class="label"> + NFC + </th> + </tr> + </thead> + <tbody> + <tr> + <td class="secondary-text"> + Use Near Field Communication to read and exchange tags + </td> + </tr> + </tbody> + </table> + + </div> + <div class="layout-content-col span-4"> + + <div class="do-dont-label good">After</div> + + <table class="ui-table good"> + <thead> + <tr> + <th class="label"> + NFC + </th> + </tr> + </thead> + <tbody> + <tr> + <td class="secondary-text"> + Allow data exchange when the phone touches another device + </td> + </tr> + </tbody> + </table> + + </div> + <div class="layout-content-col span-5"> + +<p>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.</p> +<p>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.</p> + + </div> +</div> + +<h2 id="checklist">Checklist</h2> +<ul> +<li><p>Make sure each item in Settings meets the criteria for belonging there.</p></li> +<li><p>If you have more than 7 items, explore ways to group related settings.</p></li> +<li><p>Use design patterns wherever applicable so users don't face a learning curve.</p></li> +<li><p>Choose defaults that are safe, neutral, and fit the majority of users.</p></li> +<li><p>Give each setting a clear, concise label and use secondary text appropriately.</p></li> +</ul>
\ No newline at end of file diff --git a/docs/html/design/patterns/swipe-views.jd b/docs/html/design/patterns/swipe-views.jd new file mode 100644 index 0000000..95d65dd --- /dev/null +++ b/docs/html/design/patterns/swipe-views.jd @@ -0,0 +1,74 @@ +page.title=Swipe Views +@jd:body + +<p>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.</p> +<h2 id="detail-views">Swiping Between Detail Views</h2> + +<p>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.</p> + +<img src="{@docRoot}design/media/swipe_views.png"> +<div class="figure-caption"> + Master (left) and detail (right) views. +</div> + +<p>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".</p> +<p>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.</p> + +<img src="{@docRoot}design/media/swipe_views2.png"> +<div class="figure-caption"> + Navigating between consecutive Email messages using the swipe gesture. +</div> + +<h2 id="between-tabs">Swiping Between Tabs</h2> + +<div class="layout-content-row"> + <div class="layout-content-col span-5"> + + <div class="framed-galaxynexus-port-span-5"> + <video class="play-on-hover" autoplay> + <source src="{@docRoot}design/media/swipe_tabs.mp4" type="video/mp4"> + <source src="{@docRoot}design/media/swipe_tabs.webm" type="video/webm"> + <source src="{@docRoot}design/media/swipe_tabs.ogv" type="video/ogg"> + </video> + </div> + <div class="figure-caption"> + People app with swipe gesture navigation between top-level screens. + <div class="video-instructions"> </div> + </div> + + </div> + <div class="layout-content-col span-8"> + +<p>If your app uses action bar tabs, use swipe to navigate between the different views.</p> +<div class="vspace size-2"> </div> + +<h2 id="checklist">Checklist</h2> + +<ul> +<li> +<p>Use swipe to quickly navigate between detail views or tabs.</p> +</li> +<li> +<p>Transition between the views as the user performs the swipe gesture. Do not wait for the + gesture to complete and then transition between views.</p> +</li> +<li> +<p>If you used buttons in the past for previous/next navigation, replace them with + the swipe gesture.</p> +</li> +<li> +<p>Consider adding contextual information in your detail view that informs the user about the + relative list position of the currently visible item.</p> +</li> +</ul> + + </div> +</div> |