Home | History | Annotate | Download | only in design-navigation
      1 page.title=Providing Descendant and Lateral Navigation
      2 parent.title=Designing Effective Navigation
      3 parent.link=index.html
      4 
      5 trainingnavtop=true
      6 previous.title=Planning for Multiple Touchscreen Sizes
      7 previous.link=multiple-sizes.html
      8 next.title=Providing Ancestral and Temporal Navigation
      9 next.link=ancestral-temporal.html
     10 
     11 @jd:body
     12 
     13 <div id="tb-wrapper">
     14 <div id="tb">
     15 
     16 <h2>This lesson teaches you about:</h2>
     17 <ol>
     18   <li><a href="#buttons">Buttons and Simple Targets</a></li>
     19   <li><a href="#lists">Lists, Grids, Carousels, and Stacks</a></li>
     20   <li><a href="#tabs">Tabs</a></li>
     21   <li><a href="#paging">Horizontal Paging (Swipe Views)</a></li>
     22 </ol>
     23 
     24 <h2>You should also read</h2>
     25 <ul>
     26   <li><a href="{@docRoot}design/building-blocks/buttons.html">Android Design: Buttons</a></li>
     27   <li><a href="{@docRoot}design/building-blocks/lists.html">Android Design: Lists</a></li>
     28   <li><a href="{@docRoot}design/building-blocks/grid-lists.html">Android Design: Grid Lists</a></li>
     29   <li><a href="{@docRoot}design/building-blocks/tabs.html">Android Design: Tabs</a></li>
     30   <li><a href="{@docRoot}design/patterns/swipe-views.html">Android Design: Swipe Views</a></li>
     31 </ul>
     32 
     33 </div>
     34 </div>
     35 
     36 
     37 <p>One way of providing access to the full range of an application's screens is to expose hierarchical navigation. In this lesson we discuss <em>descendant navigation</em>, allowing users to descend 'down' a screen hierarchy into a child screen, and <em>lateral navigation</em>, allowing users to access sibling screens.</p>
     38 
     39 
     40 <img src="{@docRoot}images/training/app-navigation-descendant-lateral-desc.png"
     41   alt="Descendant and lateral navigation" id="figure-desc">
     42 
     43 <p class="img-caption"><strong>Figure 1.</strong> Descendant and lateral navigation.</p>
     44 
     45 
     46 <p>There are two types of sibling screens: collection-related and section-related screens. <em>Collection-related</em> screens represent individual items in the collection represented by the parent. <em>Section-related</em> screens represent different sections of information about the parent. For example, one section may show textual information about an object while another may provide a map of the object's geographic location. The number of section-related screens for a given parent is generally small.</p>
     47 
     48 
     49 <img src="{@docRoot}images/training/app-navigation-descendant-lateral-children.png"
     50   alt="Collection-related children and section-related children" id="figure-children">
     51 
     52 <p class="img-caption"><strong>Figure 2.</strong> Collection-related children and section-related children.</p>
     53 
     54 
     55 <p>Descendant and lateral navigation can be provided using lists, tabs, and other user interface patterns. <em>User interface patterns</em>, much like software design patterns, are generalized, common solutions to recurring interaction design problems. We explore a few common lateral navigation patterns in the sections below.</p>
     56 
     57 
     58 <h2 id="buttons">Buttons and Simple Targets</h2>
     59 
     60 <div class="note design">
     61 <p><strong>Button Design</strong></p>
     62   <p>For design guidelines, read Android Design's <a
     63   href="{@docRoot}design/building-blocks/buttons.html">Buttons</a> guide.</p>
     64 </div>
     65 
     66 <p>For section-related screens, offering touchable and keyboard-focusable targets in the parent is generally the most straightforward and familiar kind of touch-based navigation interface. Examples of such targets include buttons, fixed-size list views, or text links, although the latter is not an ideal UI (user interface) element for touch-based navigation. Upon selecting one of these targets, the child screen is opened, replacing the current context (screen) entirely. Buttons and other simple targets are rarely used for representing items in a collection.</p>
     67 
     68 
     69 <img src="{@docRoot}images/training/app-navigation-descendant-lateral-buttons.png"
     70   alt="Example button-based navigation interface with relevant screen map excerpt. Also shows dashboard pattern discussed below." id="figure-buttons">
     71 
     72 <p class="img-caption"><strong>Figure 3.</strong> Example button-based navigation interface with relevant screen map excerpt. Also shows dashboard pattern discussed below.</p>
     73 
     74 
     75 <p>A common, button-based pattern for accessing different top-level application sections, is the dashboard pattern. A <em>dashboard</em> is a grid of large, iconic buttons that constitutes the entirety, or most of, the parent screen. The grid generally has either 2 or 3 rows and columns, depending on the number of top-level sections in the app. This pattern is a great way to present all the sections of the app in a visually rich way. The large touch targets also make this UI very easy to use. Dashboards are best used when each section is equally important, as determined by product decisions or better yet, real-world usage. However, this pattern doesn't visually work well on larger screens, and requires users to take an extra step to jump directly into the app's content.</p>
     76 
     77 <p>More sophisticated user interfaces can make use of a variety of other user interaction patterns to improve content immediacy and presentation uniqueness, all the while remaining intuitive.</p>
     78 
     79 
     80 <h2 id="lists">Lists, Grids, Carousels, and Stacks</h2>
     81 
     82 <div class="note design">
     83 <p><strong>List and Grid List Design</strong></p>
     84   <p>For design guidelines, read Android Design's <a
     85   href="{@docRoot}design/building-blocks/lists.html">Lists</a> and <a
     86   href="{@docRoot}design/building-blocks/grid-lists.html">Grid Lists</a> guides.</p>
     87 </div>
     88 
     89 <p>For collection-related screens, and especially for textual information, vertically scrolling lists are often the most straightforward and familiar kind of interface. For more visual or media-rich content items such as photos or videos, vertically scrolling grids of items, horizontally scrolling lists (sometimes referred to as <em>carousels</em>), or stacks (sometimes referred to as <em>cards</em>) can be used instead. These UI elements are generally best used for presenting item collections or large sets of child screens (for example, a list of stories or a list of 10 or more news topics), rather than a small set of unrelated, sibling child screens.</p>
     90 
     91 
     92 <img src="{@docRoot}images/training/app-navigation-descendant-lateral-lists.png"
     93   alt="Example list-, grid-, and carousel-based navigation interfaces with relevant screen map excerpt" id="figure-lists">
     94 
     95 <p class="img-caption"><strong>Figure 4.</strong> Example list-, grid-, and carousel-based navigation interfaces with relevant screen map excerpt.</p>
     96 
     97 
     98 <p>There are several issues with this pattern. Deep, list-based navigation, known as <em>drill-down list navigation</em>, where lists lead to more lists which lead to even more lists, is often inefficient and cumbersome. The number of touches required to access a piece of content with this kind of navigation is generally very high, leading to a poor user experience&mdash;especially for users on-the-go.</p>
     99 
    100 <p>Using vertical lists can also lead to awkward user interactions and poor use of whitespace on larger screens, as list items generally span the entire width of the screen yet have a fixed height. One way to alleviate this is to provide additional information, such as text summaries, that fills the available horizontal space. Another way is to provide additional information in a separate horizontal pane adjacent to the list.</p>
    101 
    102 
    103 <h2 id="tabs">Tabs</h2>
    104 
    105 <div class="note design">
    106 <p><strong>Tab Design</strong></p>
    107   <p>For design guidelines, read Android Design's <a
    108   href="{@docRoot}design/building-blocks/tabs.html">Tabs</a> guide.</p>
    109 </div>
    110 
    111 <p>Using tabs is a very popular solution for lateral navigation. This pattern allows grouping of sibling screens, in that the tab content container in the parent screen can embed child screens that otherwise would be entirely separate contexts. Tabs are most appropriate for small sets (4 or fewer) of section-related screens.</p>
    112 
    113 
    114 <img src="{@docRoot}images/training/app-navigation-descendant-lateral-tabs.png"
    115   alt="Example phone and tablet tab-based navigation interfaces with relevant screen map excerpt" id="figure-tabs">
    116 
    117 <p class="img-caption"><strong>Figure 5.</strong> Example phone and tablet tab-based navigation interfaces with relevant screen map excerpt.</p>
    118 
    119 
    120 <p>Several best practices apply when using tabs. Tabs should be persistent across immediate related
    121 screens. Only the designated content region should change when selecting a tab, and tab indicators
    122 should remain available at all times. Additionally, tab switches should not be treated as history.
    123 For example, if a user switches from a tab <em>A</em> to another tab <em>B</em>, pressing the
    124 <em>Back</em> button (more on that in the <a href="ancestral-temporal.html">next lesson</a>) should
    125 not re-select tab <em>A</em>. Tabs are usually laid out horizontally, although other presentations
    126 of tab navigation such as using a drop-down list in the Action Bar (<a
    127 href="{@docRoot}design/patterns/actionbar.html">pattern docs</a> at Android Design) are sometimes
    128 appropriate. Lastly, and most importantly, <em>tabs should always run along the top of the
    129 screen</em>, and should not be aligned to the bottom of the screen.</p>
    130 
    131 <p>There are some obvious immediate benefits of tabs over simpler list- and button-based navigation:</p>
    132 
    133 <ul>
    134   <li>Since there is a single, initially-selected tab, users have immediate access to that tab's content from the parent screen.</li>
    135   <li>Users can navigate quickly between related screens, without needing to first revisit the parent. <p class="note"><strong>Note</strong>: when switching tabs, it is important to maintain this tab-switching immediacy; do not block access to tab indicators by showing modal dialogs while loading content.</p></li>
    136 </ul>
    137 
    138 <p>A common criticism is that space must be reserved for the tab indicators, detracting from the space available to tab contents. This consequence is usually acceptable, and the tradeoff commonly weighs in favor of using this pattern. You should also feel free to customize tab indicators, showing text and/or icons to make optimal use of vertical space. When adjusting indicator heights however, ensure that tab indicators are large enough for a human finger to touch without error.</p>
    139 
    140 
    141 <h2 id="paging">Horizontal Paging (Swipe Views)</h2>
    142 
    143 <div class="note design">
    144 <p><strong>Swipe Views Design</strong></p>
    145   <p>For design guidelines, read Android Design's <a
    146   href="{@docRoot}design/patterns/swipe-views.html">Swipe Views</a> pattern guides.</p>
    147 </div>
    148 
    149 <p>Another popular lateral navigation pattern is horizontal paging, also referred to as swipe views. This pattern applies best to collection-related sibling screens, such as a list of categories (world, business, technology, and health stories). Like tabs, this pattern also allows grouping screens in that the parent presents the contents of child screens embedded within its own layout.</p>
    150 
    151 
    152 <img src="{@docRoot}images/training/app-navigation-descendant-lateral-paging.png"
    153   alt="Example horizontal paging navigation interface with relevant screen map excerpt" id="figure-paging">
    154 
    155 <p class="img-caption"><strong>Figure 6.</strong> Example horizontal paging navigation interface with relevant screen map excerpt.</p>
    156 
    157 
    158 <p>In a horizontal paging UI, a single child screen (referred to as a <em>page</em> here) is presented one at a time. Users are able to navigate to sibling screens by touching and dragging the screen horizontally in the direction of the desired adjacent page. This gestural interaction is often complemented by another UI element indicating the current page and available pages, to aid discoverability and provide more context to the user. This practice is especially necessary when using this pattern for lateral navigation of section-related sibling screens. Examples of such elements include tick marks, scrolling labels, and tabs.</p>
    159 
    160 
    161 <img src="{@docRoot}images/training/app-navigation-descendant-lateral-paging-companion.png"
    162   alt="Example paging companion UI elements" id="figure-paging-companion">
    163 
    164 <p class="img-caption"><strong>Figure 7.</strong> Example paging companion UI elements.</p>
    165 
    166 
    167 <p>It's also best to avoid this pattern when child screens contain horizontal panning surfaces (such as maps), as these conflicting interactions may deter your screen's usability.</p>
    168 
    169 <p>Additionally, for sibling-related screens, horizontal paging is most appropriate where there is some similarity in content type and when the number of siblings is relatively small. In these cases, this pattern can be used along with tabs above the content region to maximize the interface's intuitiveness. For collection-related screens, horizontal paging is most intuitive when there is a natural ordered relationship between screens, for example if each page represents consecutive calendar days. For infinite collections (again, calendar days), especially those with content in both directions, this paging mechanism can work quite well.</p>
    170 
    171 <p>In the next lesson, we discuss mechanisms for allowing users to navigate up our information hierarchy and back, to previously visited screens.</p>