diff options
Diffstat (limited to 'docs/html/design/patterns')
| -rw-r--r-- | docs/html/design/patterns/gestures.jd | 135 | ||||
| -rw-r--r-- | docs/html/design/patterns/index.jd | 30 | ||||
| -rw-r--r-- | docs/html/design/patterns/multi-pane-layouts.jd | 130 | ||||
| -rw-r--r-- | docs/html/design/patterns/navigation-drawer.jd | 346 | ||||
| -rw-r--r-- | docs/html/design/patterns/selection.jd | 123 | ||||
| -rw-r--r-- | docs/html/design/patterns/settings.jd | 708 |
6 files changed, 0 insertions, 1472 deletions
diff --git a/docs/html/design/patterns/gestures.jd b/docs/html/design/patterns/gestures.jd deleted file mode 100644 index b471ee3..0000000 --- a/docs/html/design/patterns/gestures.jd +++ /dev/null @@ -1,135 +0,0 @@ -page.title=Gestures -page.tags=gesture,input,touch -@jd:body - -<a class="notice-designers-material" - href="http://www.google.com/design/spec/patterns/gestures.html"> - <div> - <h3>Material Design</h3> - <p>Gestures<p> - </div> -</a> - -<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="vspace size-2"> </div> - -<div class="cols"> - - <div class="col-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="col-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="col-4"> - <img src="{@docRoot}design/media/gesture_swipe.png"> - <h4>Swipe or drag</h4> - <p>Scrolls overflowing content, or navigates between views in the same hierarchy. Swipes are - quick and affect the screen even after the finger is picked up. Drags are slower and more precise, - and the screen stops responding when the finger is picked up.</p> - <ul> - <li class="no-bullet with-icon action"> - <h4>Action</h4> - <p>Press, move, lift</p></li> - </ul> - </div> - -</div> - -<div class="vspace size-2"> </div> - -<div class="cols"> - - <div class="col-4"> - <img src="{@docRoot}design/media/gesture_drag.png"> - <h4>Long press 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="col-4"> - <img src="{@docRoot}design/media/gesture_doubletouch.png"> - <h4>Double touch </h4> - <p> Scales up a standard amount around the target with each repeated gesture until reaching - maximum scale. For nested views, scales up the smallest targetable view, or returns it to - its original scale. 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="col-4"> - <img src="{@docRoot}design/media/gesture_doubletouchdrag.png"> - <h4>Double touch drag</h4> - <p>Scales content by pushing away or pulling closer, centered around gesture.</p> - <ul> - <li class="no-bullet with-icon action"> - <h4>Action</h4> - <p>A single touch followed in quick succession by a drag up or down:</p> - <ul style="padding-left:1.5em;list-style-type:disc;"> - <li>Dragging up decreases content scale</li> - <li>Dragging down increases content scale</li> - <li>Reversing drag direction reverses scaling.</li> - </ul> - </li> - </ul> - </div> - -</div> - - -<div class="vspace size-2"> </div> - -<div class="cols"> - - <div class="col-4"> - <img src="{@docRoot}design/media/gesture_pinchopen.png" style="margin-left:-4px"> - <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 class="col-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 deleted file mode 100644 index e091a29..0000000 --- a/docs/html/design/patterns/index.jd +++ /dev/null @@ -1,30 +0,0 @@ -page.title=Patterns -header.justLinks=1 -footer.hide=1 -@jd:body - -<style> -#landing-graphic-container { - position: relative; -} - -#text-overlay { - position: absolute; - left: 0; - top: 492px; - width: 200px; -} -</style> - -<div id="landing-graphic-container"> - <div id="text-overlay"> - <span itemprop="description">Design apps that behave in a consistent, predictable - fashion.</span> - <br><br> - <a href="{@docRoot}design/patterns/new.html" class="landing-page-link">New in Android</a> - </div> - - <a href="{@docRoot}design/patterns/new.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 deleted file mode 100644 index c9d3d84..0000000 --- a/docs/html/design/patterns/multi-pane-layouts.jd +++ /dev/null @@ -1,130 +0,0 @@ -page.title=Multi-pane Layouts -page.tags="tablet","navigation","layout","fragment" -page.metaDescription=Design guide with examples of how to flatten navigation and provide improved layout across the range of Android devices. - -@jd:body - - -<a class="notice-designers-material" - href="http://www.google.com/design/spec/layout/structure.html#structure-ui-regions"> - <div> - <h3>Material Design</h3> - <p>UI Regions and Guidance<p> - </div> -</a> - -<a class="notice-developers" href="{@docRoot}training/basics/fragments/index.html"> - <div> - <h3>Developer Docs</h3> - <p>Building a Dynamic UI with Fragments</p> - </div> -</a> - -<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 strive to have the same functionality regardless of orientation. If you use a compound view in -one orientation, try not to split it up when the user rotates the screen. There are several techniques -you can use to adjust the layout after orientation change while keeping functional parity intact.</p> - -<div class="cols"> - <div class="col-8"> - - <img src="{@docRoot}design/media/multipane_stretch.png"> - - </div> - <div class="col-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="cols"> - <div class="col-8"> - - <img src="{@docRoot}design/media/multipane_stack.png"> - - </div> - <div class="col-5"> - -<h4>Stack</h4> -<p>Rearrange the panels on your screen to match the orientation.</p> - - </div> -</div> - -<div class="cols"> - <div class="col-8"> - - <img src="{@docRoot}design/media/multipane_expand.png"> - - </div> - <div class="col-5"> - -<h4>Expand/collapse</h4> -<p>When the device rotates, collapse the left pane view to only show the most important information.</p> - - </div> -</div> - -<div class="cols"> - <div class="col-8"> - - <img src="{@docRoot}design/media/multipane_show.png"> - - </div> - <div class="col-5"> - -<h4>Show/hide</h4> -<p>If your screen cannot accommodate the compound view on rotation show the right pane in full screen view on rotation to portrait. Use the Up icon in action bar to show the parent screen.</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 try to provide functional parity after the screen orientation - changes.</p> -</li> -</ul> diff --git a/docs/html/design/patterns/navigation-drawer.jd b/docs/html/design/patterns/navigation-drawer.jd deleted file mode 100644 index b359470..0000000 --- a/docs/html/design/patterns/navigation-drawer.jd +++ /dev/null @@ -1,346 +0,0 @@ -page.title=Navigation Drawer -page.tags=DrawerLayout,SlidingPaneLayout -@jd:body - - -<a class="notice-designers-material" - href="http://www.google.com/design/spec/layout/structure.html#structure-side-nav"> - <div> - <h3>Material Design</h3> - <p>Side Nav<p> - </div> -</a> - -<a class="notice-developers" href="{@docRoot}training/implementing-navigation/nav-drawer.html"> - <div> - <h3>Developer Docs</h3> - <p>Creating a Navigation Drawer</p> - </div> -</a> - - -<p>The navigation drawer is a panel that transitions in from the left edge of the screen and -displays the app’s main navigation options.</p> - - -<h4>Displaying the navigation drawer</h4> - -<p>The user can bring the navigation drawer onto the screen by swiping from the left edge of the -screen or by touching the application icon on the action bar.</p> - -<p>As the navigation drawer expands, it overlays the content but not the action bar. When the -drawer is fully extended, the action bar adjusts its content by replacing the current action -bar title with the app name and removing all actions that are contextual to the view underneath -the navigation drawer. The overflow menu with the standard action items for Settings and Help -remains visible.</p> - -<img src="{@docRoot}design/media/navigation_drawer_overview.png"> -<div class="figure-caption"> - The user can open the drawer panel by touching the navigation drawer indicator. -</div> - -<p>Because they are transient, navigation drawers make views less cluttered. You can also use -them at deeper levels in the navigation hierarchy, allowing users to switch to your app's most -important screens from anywhere in the app.</p> - -<img src="{@docRoot}design/media/navigation_drawer_open_from_lower.png"> -<div class="figure-caption"> - Open the drawer from anywhere in your app by swiping from the left edge of the screen. -</div> - - -<h4>Dismissing the navigation drawer</h4> - -<p> When the navigation drawer is expanded, the user can dismiss it in one of four ways: </p> -<ul> - <li>Touching the content outside the navigation drawer</li> - <li>Swiping to the left anywhere on the screen (including edge swipe from right)</li> - <li>Touching the app icon/title in the action bar</li> - <li>Pressing Back</li> -</ul> - - -<h2 id="WhenToUse"> When to Use the Navigation Drawer </h2> - -<p> The navigation drawer is not a general replacement for top-level navigation via spinners -or tabs. The structure of your app should guide your choice of which pattern to use for -top-level switching. For more information on top-level switching mechanisms, see the -<a href="{@docRoot}design/patterns/app-structure.html">Application Structure</a> design pattern.</p> -<p> Here are some examples of where navigation drawers work best:</p> - -<h4>More than 3 top-level views</h4> -<p> Navigation drawers are great for displaying a large number of navigation targets -concurrently. Use the navigation drawer if you have more than 3 unique top-level views. -If not, use fixed tabs for top-level organization to ease discovery and interaction.</p> - -<h4>Cross-navigation from lower levels</h4> -<p> If your app requires cross-navigating between lower-level screens, consider using the -navigation drawer. Because it is accessible from anywhere in the app, the drawer enables -efficient navigation from lower-level screens to other important places in your app.</p> - -<img src="{@docRoot}design/media/navigation_drawer_cross_nav.png"> -<div class="figure-caption"> - The navigation drawer makes cross-navigation at lower levels possible. -</div> - - -<h4>Deep navigation branches</h4> -<p> If you have particularly deep branches, navigating to the top-level of your app can become -repetitive and cumbersome with Up and Back alone. Since navigation drawers are accessible from -anywhere in the app, navigation up to the top level is faster and more efficient.</p> - -<img src="{@docRoot}design/media/navigation_drawer_quick_to_top.png"> -<div class="figure-caption"> - The navigation drawer allows for quick jumps to the top-level of your app, removing the need - for repetitive Back or Up sequences. -</div> - - -<h2 id="Hubs">Navigation Hubs</h2> - -<p>The navigation drawer is a reflection of your app’s structure and displays its major -navigation hubs. Think of navigation hubs as those places in your app that a user will want -to visit frequently or use as a jumping-off point to other parts of the app. -At a minimum, the navigation hubs are the top-level views, since they correspond to your app’s -major functional areas.</p> -<p> If your app’s structure is deep, you can add screens from lower levels that your users will -likely visit often and make those navigation hubs as well.</p> - -<img src="{@docRoot}design/media/navigation_drawer_navigation_hubs.png"> -<div class="figure-caption"> - The navigation drawer contains all of your app's navigation hubs. Include your top level - screens as well as important lower-level screens. -</div> - -<div class="cols"> - <div class="col-8"> - <p> To facilitate access to the navigation drawer on navigation hubs, all screens that - correspond to an entry in your navigation drawer should show the navigation drawer indicator - next to the application icon in the action bar. Touching the app icon causes the navigation - drawer to slide in from the left. </p> - <p> All other lower-level screens show the traditional Up indicator next to the application - icon. The drawer is still accessible with an edge-swipe, but is not featured in the action bar.</p> - </div> - <div class="col-5"> - <img src="{@docRoot}design/media/navigation_drawer_indicator_big.png"> - <div class="figure-caption"> - App icon with navigation drawer indicator. - </div> - </div> -</div> - - -<h2 id="Content">Content of the Navigation Drawer</h2> - -<p> Keep the content of the navigation drawer focused on app navigation. Expose the navigation -hubs of your app as list items inside the navigation drawer - one item per row. - -<div class="cols"> - <div class="col-8"> - <h4>Titles, icons, and counters</h4> - <p> You can structure navigation targets by adding titles. The titles are not interactive, - but just organize navigation targets into functional topics. If you have many navigation - targets, use titles to orient the user within the drawer.</p> - <p> Navigation targets can have optional leading icons as well as trailing counters. Use - the counters to inform users about a changed state of data in the corresponding view.</p> - </div> - <div class="col-5"> - <img src="{@docRoot}design/media/navigation_drawer_titles_icons.png"> - <div class="figure-caption"> - Use titles and icons to organize your drawer. - </div> - </div> -</div> - -<div class="cols"> - <div class="col-8"> - <img src="{@docRoot}design/media/navigation_drawer_collapse.png"> - <div class="figure-caption"> - Collapsible navigation items are split. Use the left side for navigation and the right - to collapse and expand items. - </div> - </div> - <div class="col-5"> - <h4>Collapsible navigation items</h4> - <p>If you have many views with some subordinate to others, consider collapsing them into one - expandable item to conserve space. - The parent in the navigation drawer then turns into a split item. The left side allows - navigation to the parent item’s view, and the right side collapses or expands the list of - child items. </p> - <p> At launch, the initial state of the collapsible items is up to you. As a rule, all - top-level view entries of the navigation drawer should be visible. If you have many collapsible - items, consider collapsing all items to allow the user to see the top-level views in their - entirety.</p> - <p> When the user opens the drawer from a lower-level screen, expand the associated branch - of the top-level view to give a stronger sense of place and highlight navigation opportunities - close to the user’s current - location in the app.</p> - </div> -</div> - - -<h2 id="ActionBar">Navigation Drawers and Action Bars</h2> - -<p> When the user expands the navigation drawer, the task focus switches to selecting an item -from the drawer. Because the drawer does not overlay the action bar, users may not realize that -the items in the action bar do not pertain to the navigation drawer. </p> -<p> To reduce confusion, adjust the content of the action bar to the following, once the drawer -is fully expanded:</p> -<ul> - <li>App icon</li> - <li>App name</li> - <li>Remove actions from the action bar that are contextual to the underlying view (such as - Create new, Refresh). You may retain actions with global scope, such as “Search”.</li> - <li>Overflow menu with expected navigation targets, such as Settings and Help.</li> -</ul> - -<img src="{@docRoot}design/media/navigation_drawer_open_overflow.png"> -<div class="figure-caption"> - Clean up the action bar when the drawer is fully expanded. Remove actions that are not needed - and display your app's name in the title area. -</div> - -<h4>Actions</h4> -<div class="cols"> - <div class="col-6"> - <img src="{@docRoot}design/media/navigation_drawer_nav_and_actions.png"> - <div class="figure-caption"> - Keep actions on the right side of the action bar and in the overflow - </div> - </div> - <div class="col-6"> - <p> Don’t place actions in the navigation drawer. Actions belong in the action bar, and the - user expects to see them there. Keep in mind that not all applications use the navigation - drawer pattern. It may be tempting to expose all your app’s capabilities in a single place, - but keep the bigger picture in mind. Place your actions where all apps display them.</p> - </div> -</div> -<div class="cols"> - <div class="col-6"> - <p> This also applies to common navigation targets, such as access to Help or the app’s - Settings. As per style guide convention Help and Settings are always located in the action - overflow.</p> - </div> - <div class="col-6"> - <img src="{@docRoot}design/media/navigation_drawer_settings_help.png"> - <div class="figure-caption"> - Keep Help and Settings in the overflow. - </div> - </div> -</div> - - -<h4>Contextual action bars</h4> -<p> Sometimes the user will be in a state where a contextual action bar (CAB) appears instead -of the app’s action bar. This typically happens when the user selects text or selects multiple -items after a press-and-hold gesture. While the CAB is visible, you should still allow the -user to open the navigation drawer using an edge swipe. However, replace the CAB with the -standard action bar while the navigation drawer is open. When the user dismisses the drawer, -re-display the CAB.</p> - -<img src="{@docRoot}design/media/navigation_drawer_CAB.png"> -<div class="figure-caption"> - Hide contextual action bars while the drawer is visible. -</div> - -<p>If the user navigates away from a view with selected content, deselect the content before -before navigating to the new view.</p> - - -<h2 id="Interaction">Interaction Details</h2> - -<h4>Introduce the user to the drawer at first use</h4> -<p> Upon first launch of your app, introduce the user to the navigation drawer by -automatically opening it. This ensures that users know about the navigation drawer and prompts -them to learn about the structure of your app by exploring its content. Continue showing the -drawer upon subsequent launches until the user actively expands the navigation drawer manually. -Once you know that the user understands how to open the drawer, launch the app with the -navigation drawer closed. </p> - -<img src="{@docRoot}design/media/navigation_drawer_first_run.png"> -<div class="figure-caption"> - At first use, show the navigation drawer automatically to help the user learn the - functionality and structure of your app. -</div> - -<h4>Give the user a quick peek</h4> -<p> If the user touches the very left edge of the screen (within 20 dp from the left), have the -drawer peek out as soon as the finger makes contact with the display. This promotes accidental -discovery and provides richer feedback. </p> - -<img src="{@docRoot}design/media/navigation_drawer_peek.png"> -<div class="figure-caption"> - The navigation drawer peeks out when the user touches the very left edge of the screen. -</div> - -<h4>Highlights</h4> -<p> When you open the navigation drawer from a screen that is represented inside the drawer, -highlight its entry in the drawer. Vice versa, if you open the drawer from a screen that is -not listed in the drawer, none of the items of the drawer should be highlighted.</p> - - -<h2 id="ImpactOnNav">Impact of Drawer on Overall App Navigation</h2> - -<p>The navigation drawer is an alternative to other top-level navigation patterns. To make apps -with navigation drawers work consistently with apps that use a tab or spinner pattern, remember -that all navigation requirements for system Back and Up apply.</p> -<p>Pay special attention to the following situations:</p> - -<h4>System Back at the top level of the app</h4> -<p>Touching System Back at the app’s top level never opens the navigation drawer. Instead, -System Back behaves according to the navigation rules for the top level, such as navigating -to the previous app within the task or navigating to the Home screen.</p> - -<img src="{@docRoot}design/media/navigation_drawer_top_out.png"> -<div class="figure-caption"> - System Back does not show the drawer, but behaves according to the navigation rules for - the top level. -</div> - -<h4>System Back after cross navigation to lower hierarchy levels</h4> -<p>If the user navigates to a lower hierarchy screen from the navigation drawer and the screen -has a direct parent, then the Back stack is reset and Back points to the target screen’s parent. -This Back behavior is the same as when a user navigates into an app from a notification.</p> - -<img src="{@docRoot}design/media/navigation_drawer_reset_backstack.png"> -<div class="figure-caption"> - Reset the Back stack if your lower-level navigation target has direct parents. -</div> - - -<h2 id="Style">Style</h2> - -<p>The width of the navigation drawer depends on the content you want to display, but should be -between a minimum of 240 dp and a maximum of 320 dp. The height of the individual line items -should not fall below 48 dp. See the layout guideline below for recommendations on padding and -spacing.</p> - -<img src="{@docRoot}design/media/navigation_drawer_layout.png"> -<div class="figure-caption"> - Layout guidelines for the navigation drawer. -</div> - - -<p>Pick the drawer background to best match your app’s theme. See the following examples -for a Holo light and a Holo dark themed drawer.</p> - -<img src="{@docRoot}design/media/navigation_drawer_holo_dark_light.png"> -<div class="figure-caption"> - Navigation drawers in Holo light and Holo dark themed apps. -</div> - - -<h2 id="Checklist">Navigation Drawer Checklist</h2> - -<p>Even if you already support a similar navigation drawer, update your drawer to this -pattern to make sure that:</p> -<ul> - <li>The action bar remains in place and adjusts its content.</li> - <li>Your navigation drawer overlays the content.</li> - <li>Any view represented in the drawer has a navigation drawer indicator in its action bar - that allows the drawer to be opened by touching the app icon.</li> - <li>You take advantage of the new visual drawer transition.</li> - <li>Any view not represented in the drawer maintains the traditional Up indicator in its action bar.</li> - <li>You stay in sync with the general navigation patterns for Up and Back.</li> -</ul> - diff --git a/docs/html/design/patterns/selection.jd b/docs/html/design/patterns/selection.jd deleted file mode 100644 index e00f726..0000000 --- a/docs/html/design/patterns/selection.jd +++ /dev/null @@ -1,123 +0,0 @@ -page.title=Selection -page.tags=actionmode,navigation,contextual -@jd:body - -<a class="notice-designers-material" - href="http://www.google.com/design/spec/patterns/selection.html"> - <div> - <h3>Material Design</h3> - <p>Selection<p> - </div> -</a> - -<a class="notice-developers" href="{@docRoot}guide/topics/ui/menus.html#context-menu"> - <div> - <h3>Developer Docs</h3> - <p>Menus: Creating Contextual Menus</p> - </div> -</a> - - -<p>Android 3.0 changed the <em>long press</em> gesture—that is, a touch that's held in the same position for a moment—to be the global gesture to select data.. This affects the way you should -handle multi-select and contextual actions in your apps.</p> - -<div class="vspace size-1"> </div> - -<div class="cols"> - <div class="col-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="col-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</h4> -<p itemprop="description">The contextual action bar (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="cols"> - <div class="col-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="col-7"> - - <img src="{@docRoot}design/media/selection_cab_example.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-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> - -<div class="note develop"> -<p><strong>Developer Guide</strong></p> - <p>For information about how to create a contextual action bar, read - <a href="{@docRoot}guide/topics/ui/menus.html#CAB">Using the contextual action mode</a>.</p> -</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 deleted file mode 100644 index 9ba837a..0000000 --- a/docs/html/design/patterns/settings.jd +++ /dev/null @@ -1,708 +0,0 @@ -page.title=Settings -page.tags=preferences,sharedpreferences -@jd:body - -<a class="notice-designers-material" - href="http://www.google.com/design/spec/patterns/settings.html"> - <div> - <h3>Material Design</h3> - <p>Settings<p> - </div> -</a> - -<a class="notice-developers" href="{@docRoot}guide/topics/ui/settings.html"> - <div> - <h3>Developer Docs</h3> - <p>Settings</p> - </div> -</a> - - -<p itemprop="description">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="cols"> - <div class="col-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="col-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="cols"> - <div class="col-2"> - -<h4>7 or fewer</h4> - - </div> - <div class="col-11"> - -<p>Don't group them at all. It won't benefit users and will seem like overkill.</p> - - </div> -</div> - -<div class="cols"> - <div class="col-2"> - -<h4>8 to 10</h4> - - </div> - <div class="col-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="cols"> - <div class="col-2"> - -<h4>11 to 15</h4> - - </div> - <div class="col-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="cols"> - <div class="col-2"> - -<h4>16 or more</h4> - - </div> - <div class="col-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="cols"> - <div class="col-3"> - -<h4>Checkbox</h4> -<p>Use this pattern for a setting that is either selected or not selected.</p> - - </div> - <div class="col-10"> - -<img src="{@docRoot}design/media/settings_checkbox.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-10"> - -<img src="{@docRoot}design/media/settings_multiple_choice.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-10"> - -<img src="{@docRoot}design/media/settings_slider.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-10"> - -<img src="{@docRoot}design/media/settings_date_time.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-10"> - -<img src="{@docRoot}design/media/settings_subscreen_navigation.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-10"> - -<img src="{@docRoot}design/media/settings_list_subscreen.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-10"> - -<img src="{@docRoot}design/media/settings_master_on_off.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-10"> - -<img src="{@docRoot}design/media/settings_master_on_off_2.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-10"> - -<img src="{@docRoot}design/media/settings_individual_on_off.png"> - - </div> -</div> - -<div class="cols"> - <div class="col-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="col-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="cols"> - <div class="col-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="col-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 inactivity - </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="cols"> - <div class="col-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="col-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="col-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="cols"> - <div class="col-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="col-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 inactivity - </td> - </tr> - </tbody> - </table> - - </div> - <div class="col-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="cols"> - <div class="col-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="col-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="col-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="cols"> - <div class="col-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="col-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="col-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> |