From 3ba792c7f4646f6a33fdc2b6d9b8831ecf479e2c Mon Sep 17 00:00:00 2001 From: Roman Nurik Date: Thu, 26 Jan 2012 11:56:31 -0800 Subject: [PATCH] docs: Update designing-navigation training class to link to Android Design Change-Id: I1cdda032f31798f9a32b7bec583dcfaa6eafb8c2 --- .../design-navigation/ancestral-temporal.jd | 8 +++- .../design-navigation/descendant-lateral.jd | 42 +++++++++++++++++-- docs/html/training/design-navigation/index.jd | 2 +- .../design-navigation/multiple-sizes.jd | 11 ++++- .../training/design-navigation/wireframing.jd | 2 +- 5 files changed, 56 insertions(+), 9 deletions(-) diff --git a/docs/html/training/design-navigation/ancestral-temporal.jd b/docs/html/training/design-navigation/ancestral-temporal.jd index 02e43e150bd11..c0b1aef738e92 100644 --- a/docs/html/training/design-navigation/ancestral-temporal.jd +++ b/docs/html/training/design-navigation/ancestral-temporal.jd @@ -21,6 +21,7 @@ next.link=wireframing.html

You should also read

@@ -30,6 +31,11 @@ next.link=wireframing.html

Now that users can navigate deep into the application's screen hierarchy, we need to provide a method for navigating up the hierarchy, to parent and ancestor screens. Additionally, we should ensure that temporal navigation via the BACK button is respected to respect Android conventions.

+
+

Back/Up Navigation Design

+

For design guidelines, read Android Design's Navigation pattern guide.

+

Support Temporal Navigation: Back

@@ -49,7 +55,7 @@ next.link=wireframing.html

Provide Ancestral Navigation: Up and Home

-

Before Android 3.0, the most common form of ancestral navigation was the Home metaphor. This was generally implemented as a Home item accessible via the device's MENU button, or a Home button at the top-left of the screen, usually as a component of the Action Bar. Upon selecting Home, the user would be taken to the screen at the top of the screen hierarchy, generally known as the application's home screen.

+

Before Android 3.0, the most common form of ancestral navigation was the Home metaphor. This was generally implemented as a Home item accessible via the device's MENU button, or a Home button at the top-left of the screen, usually as a component of the Action Bar (pattern docs at Android Design). Upon selecting Home, the user would be taken to the screen at the top of the screen hierarchy, generally known as the application's home screen.

Providing direct access to the application's home screen can give the user a sense of comfort and security. Regardless of where they are in the application, if they get lost in the app, they can select Home to arrive back at the familiar home screen.

diff --git a/docs/html/training/design-navigation/descendant-lateral.jd b/docs/html/training/design-navigation/descendant-lateral.jd index ebfd913fe8485..0064bd495c2d5 100644 --- a/docs/html/training/design-navigation/descendant-lateral.jd +++ b/docs/html/training/design-navigation/descendant-lateral.jd @@ -18,9 +18,18 @@ next.link=ancestral-temporal.html
  • Buttons and Simple Targets
  • Lists, Grids, Carousels, and Stacks
  • Tabs
    • -
  • Horizontal Paging
    • +
  • Horizontal Paging (Swipe Views)
    • +

    You should also read

    + + @@ -48,6 +57,12 @@ next.link=ancestral-temporal.html

    Buttons and Simple Targets

    +
    +

    Button Design

    +

    For design guidelines, read Android Design's Buttons guide.

    +
    +

    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.

    @@ -64,6 +79,13 @@ next.link=ancestral-temporal.html

    Lists, Grids, Carousels, and Stacks

    +
    +

    List and Grid List Design

    +

    For design guidelines, read Android Design's Lists and Grid Lists guides.

    +
    +

    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 carousels), or stacks (sometimes referred to as cards) 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.

    @@ -80,6 +102,12 @@ next.link=ancestral-temporal.html

    Tabs

    +
    +

    Tab Design

    +

    For design guidelines, read Android Design's Tabs guide.

    +
    +

    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.

    @@ -89,7 +117,7 @@ next.link=ancestral-temporal.html

    Figure 5. Example phone and tablet tab-based navigation interfaces with relevant screen map excerpt.

    -

    Several best practices apply when using tabs. Tabs should be persistent across immediate related screens. Only the designated content region should change when selecting a tab, and tab indicators should remain available at all times. Additionally, tab switches should not be treated as history. For example, if a user switches from a tab A to another tab B, pressing the BACK button (more on that in the next lesson) should not re-select tab A. Tabs are usually laid out horizontally, although other presentations of tab navigation such as using a drop-down list in the Action Bar are sometimes appropriate. Lastly, and most importantly, tabs should always run along the top of the screen, and should not be aligned to the bottom of the screen.

    +

    Several best practices apply when using tabs. Tabs should be persistent across immediate related screens. Only the designated content region should change when selecting a tab, and tab indicators should remain available at all times. Additionally, tab switches should not be treated as history. For example, if a user switches from a tab A to another tab B, pressing the BACK button (more on that in the next lesson) should not re-select tab A. Tabs are usually laid out horizontally, although other presentations of tab navigation such as using a drop-down list in the Action Bar (pattern docs at Android Design) are sometimes appropriate. Lastly, and most importantly, tabs should always run along the top of the screen, and should not be aligned to the bottom of the screen.

    There are some obvious immediate benefits of tabs over simpler list- and button-based navigation:

    @@ -101,9 +129,15 @@ next.link=ancestral-temporal.html

    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.

    -

    Horizontal Paging

    +

    Horizontal Paging (Swipe Views)

    -

    Another popular lateral navigation pattern is horizontal paging. 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.

    +
    +

    Swipe Views Design

    +

    For design guidelines, read Android Design's Swipe Views pattern guides.

    +
    + +

    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.

    This class is not specific to any particular version of the Android platform. It is also primarily design-focused and does not require knowledge of the Android SDK. That said, you should have experience using an Android device for a better understanding of the context in which Android applications run.

    -

    You should also have basic familiarity with the Action Bar, used across most applications in devices running Android 3.0 and later.

    +

    You should also have basic familiarity with the Action Bar (pattern docs at Android Design), used across most applications in devices running Android 3.0 and later.

    diff --git a/docs/html/training/design-navigation/multiple-sizes.jd b/docs/html/training/design-navigation/multiple-sizes.jd index 7a8139f08910b..ebaec0f567a0d 100644 --- a/docs/html/training/design-navigation/multiple-sizes.jd +++ b/docs/html/training/design-navigation/multiple-sizes.jd @@ -22,6 +22,7 @@ next.link=descendant-lateral.html

    You should also read

    @@ -35,6 +36,12 @@ next.link=descendant-lateral.html

    Group Screens with Multi-pane Layouts

    +
    +

    Multi-pane Layout Design

    +

    For design guidelines, read Android Design's Multi-pane Layouts pattern guide.

    +
    +

    3 to 4-inch screens are generally only suitable for showing a single vertical pane of content at a time, be it a list of items, or detail information about an item, etc. Thus on such devices, screens generally map one-to-one with levels in the information hierarchy (categories → object list → object detail).

    Larger screens such as those found on tablets and TVs, on the other hand, generally have much more available screen space and are able to present multiple panes of content. In landscape, panes are usually ordered from left to right in increasing detail order. Users are especially accustomed to multiple panes on larger screens from years and years of desktop application and desktop web site use. Many desktop applications and websites offer a left-hand navigation pane or use a master/detail two-pane layout.

    @@ -76,12 +83,12 @@ next.link=descendant-lateral.html
  • Expand/collapse Expand/collapse strategy -

    A variation on the stretch strategy is to collapse the contents of the left pane when in portrait. This works quite well with master/detail panes where the left (master) pane contains easily collapsible list items. An example would be for a realtime chat application. In landscape, the left list could contain chat contact photos, names, and online statuses. In portrait, horizontal space could be collapsed by hiding contact names and only showing photos and online status indicator icons.

    • +

    A variation on the stretch strategy is to collapse the contents of the left pane when in portrait. This works quite well with master/detail panes where the left (master) pane contains easily collapsible list items. An example would be for a realtime chat application. In landscape, the left list could contain chat contact photos, names, and online statuses. In portrait, horizontal space could be collapsed by hiding contact names and only showing photos and online status indicator icons. Optionally also provide an expand control that allows the user to expand the left pane content to its larger width and vice versa.

  • Show/Hide Show/Hide strategy -

    In this scenario, the left pane is completely hidden in portrait mode. However, to ensure the functional parity of your screen in portrait and landscape, the left pane should be made available via an onscreen affordance (such as a button). It's usually appropriate to use the Up button in the Action Bar to show the left pane, as is discussed in a later lesson.

    • +

    In this scenario, the left pane is completely hidden in portrait mode. However, to ensure the functional parity of your screen in portrait and landscape, the left pane should be made available via an onscreen affordance (such as a button). It's usually appropriate to use the Up button in the Action Bar (pattern docs at Android Design) to show the left pane, as is discussed in a later lesson.

  • Stack Developer's Guide: User Interface: learn how to implement your user interface designs using the Android SDK.
  • Action Bar: implement tabs, up navigation, on-screen actions, etc.
  • Fragments: implement re-usable, multi-pane layouts -
  • Support Library: implement horizontal paging using ViewPager
    • +
  • Support Library: implement horizontal paging (swipe views) using ViewPager