diff options
Diffstat (limited to 'docs/html/design/patterns/navigation.jd')
| -rw-r--r-- | docs/html/design/patterns/navigation.jd | 116 |
1 files changed, 116 insertions, 0 deletions
diff --git a/docs/html/design/patterns/navigation.jd b/docs/html/design/patterns/navigation.jd new file mode 100644 index 0000000..d35cd82 --- /dev/null +++ b/docs/html/design/patterns/navigation.jd @@ -0,0 +1,116 @@ +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 application 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 (i.e. the home of the app), it should not present an Up +button.</p> +<p>The system Back key is used to navigate based on the history of screens the user has recently seen, +in reverse chronological order—in effect, the temporal relationships between screens.</p> +<p>When the previously viewed screen is also the hierarchical parent of the current screen, pressing +the Back key will have 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 key can +return the user to the Home screen, or even to a different application.</p> + +<img src="{@docRoot}design/media/navigation_up_vs_back_gmail.png"> + +<p>The Back key also supports a few behaviors not directly tied to screen-to-screen navigation:</p> +<ul> +<li>Back dismisses floating windows (dialogs, popups)</li> +<li>Back dismisses contextual action bars, and removes the highlight from the selected items</li> +<li>Back 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—e.g., a settings screen which can be navigated to from any 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 (e.g. 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 on Google Play 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 screen of related content which has been +viewed. 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. If we extend our Google Play sample 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 had not previously navigated through.</p> + +<img src="{@docRoot}design/media/navigation_between_siblings_market2.png"> + +<h2 id="from-outside">Navigation From Outside Your App</h2> + +<p>There are two categories of navigation from outside your app to screens deep within the app's +hierarchy:</p> +<ul> +<li>App-to-app navigation, such as via intent completion.</li> +<li>System-to-app navigation, such as via notifications and home screen widgets.</li> +</ul> +<p>Gmail provides examples of each of these. For app-to-app navigation, a "Share" intent goes directly +to the compose screen. For system-to-app navigation, both a new message notification and a home +screen widget can bypass the Inbox screen, taking the user directly to a conversation view.</p> +<h4>App-to-app navigation</h4> +<p>When navigating deep into your app's hierarchy directly from another app via an intent, Back will +return to the referring app.</p> +<p>The Up button is handled as follows: +- If the destination screen is typically reached from one particular screen within your app, Up + should navigate to that screen. +- Otherwise, Up should navigate to the topmost ("Home") screen of your app.</p> +<p>For example, after choosing to share a book being viewed on Google Play, the user navigates directly to +Gmail's compose screen. From there, Up returns to the Inbox (which happens to be both the +typical referrer to compose, as well as the topmost screen of the app), while Back returns to +Google Play.</p> + +<img src="{@docRoot}design/media/navigation_from_outside_up.png"> + +<h4>System-to-app navigation</h4> +<p>If your app was reached via the system mechanisms of notifications or home screen widgets, Up +behaves as described for app-to-app navigation, above.</p> +<p>For the Back key, you should make navigation more predictably by inserting into the task's back +stack the complete upward navigation path to the app's topmost screen. This way, a user who has +forgotten how they entered your app can safely navigate to the app's topmost screen before exiting +it.</p> +<p>For example, Gmail's Home screen widget has a button for diving directly to its compose screen. +After following that path, the Back key first returns to the Inbox, and from there continues to +Home.</p> + +<img src="{@docRoot}design/media/navigation_from_outside_back.png"> |