Planning Screens and Their Relationships

THIS LESSON TEACHES YOU TO

Create a Screen List
Diagram Screen Relationships
Go Beyond a Simplistic Design

Most apps have an inherent information model that can be expressed as a tree or graph of object types. In more obvious terms, you can draw a diagram of different kinds of information that represents the types of things users interact with in your app. Software engineers and data architects often use entity-relationship diagrams (ERDs) to describe an application's information model.

Let's consider an example application that allows users to browse through a set of categorized news stories and photos. One possible model for such an app is shown below in the form of an ERD.

Figure 1. Entity-relationship diagram for the example news application.

Create a Screen List

Once you define the information model, you can begin to define the contexts necessary to enable users to effectively discover, view, and act upon the data in your application. In practice, one way to do this is todetermine the exhaustive set of screens needed to allow users to navigate to and interact with the data. The set of screens we actually expose should generally vary depending on the target device; it's important to consider this early in the design process to ensure that the application can adapt to its environment.

In our example application, we want to enable users to view, save, and share categorized stories and photos. Below is an exhaustive list of screens that covers these use cases.

Home or "launchpad" screen for accessing stories and photos
List of categories
List of news stories for a given category
Story detail view (from which we can save and share)
List of photos, uncategorized
Photo detail view (from which we can save and share)
List of all saved items
List of saved photos
List of saved stories

Diagram Screen Relationships

Now we can define the directed relationships between screens; an arrow from one screen A to another screen Bimplies that screen B should be directly reachable via some user interaction in screen A. Once we define both the set of screens and the relationships between them, we can express these in concert as a screen map, which shows all of your screens and their relationships:

Figure 2. Exhaustive screen map for the example news application.

If we later wanted to allow users to submit news stories or upload photos, we could add additional screens to this diagram.

Go Beyond a Simplistic Design

At this point, it's possible to design a completely functional application from this exhaustive screen map. A simplistic user interface could consist of lists and buttons leading to child screens:

Buttons leading to different sections (e.g., stories, photos, saved items)
Vertical lists representing collections (e.g., story lists, photo lists, etc.)
Detail information (e.g., story view, full-screen photo view, etc.)

However, you can use screen grouping techniques and more sophisticated navigation elements to present content in a more intuitive and device-sensitive way. In the next lesson, we explore screen grouping techniques, such as providing multi-pane layouts for tablet devices. Later, we'll dive into the various navigation patterns common on Android.

Planning for Multiple Touchscreen Sizes

PREVIOUSNEXT

THIS LESSON TEACHES YOU TO

Group Screens with Multi-pane Layouts
Design for Multiple Tablet Orientations
Group Screens in the Screen Map

YOU SHOULD ALSO READ

Android Design: Multi-pane Layouts
Designing for Multiple Screens

The exhaustive screen map from the previous lesson isn't tied to a particular device form factor, although it can generally look and work okay on a handset or similar-size device. But Android applications need to adapt to a number of different types of devices, from 3" handsets to 10" tablets to 42" TVs. In this lesson we explore reasons and tactics for grouping together multiple screens from the exhaustive map.

Note: Designing applications for television sets also requires attention to other factors, including interaction methods (i.e., the lack of a touch screen), legibility of text at large reading distances, and more. Although this discussion is outside the scope of this class, you can find more information on designing for TVs in the Google TV documentation for design patterns.

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.

In addition to addressing these user expectations, it's usually necessary to provide multiple panes of information on tablets to avoid leaving too much whitespace or unwittingly introducing awkward interactions, for example 10 x 0.5-inch buttons.

The following figures demonstrate some of the problems that can arise when moving a UI (user interface) design into a larger layout and how to address these issues with multi-pane layouts:

Figure 1. Single pane layouts on large screens in landscape lead to awkward whitespace and exceedingly long line lengths.

Figure 2. Multi-pane layouts in landscape result in a better visual balance while offering more utility and legibility.

Implementation Note: After deciding on the screen size at which to draw the line between single-pane and multi-pane layouts, you can provide different layouts containing one or multiple panes for devices in varying screen size buckets (such as large/xlarge) or varying minimum screen widths (such as sw600dp).

Implementation Note: While a single screen is implemented as an Activity subclass, individual content panes can be implemented as Fragment subclasses. This maximizes code re-use across different form factors and across screens that share content.

Design for Multiple Tablet Orientations

Although we haven't begun arranging user interface elements on our screens yet, this is a good time to consider how your multi-pane screens will adapt to different device orientations. Multi-pane layouts in landscape work quite well because of the large amount of available horizontal space. However, in the portrait orientation, your horizontal space is more limited, so you may need to design a separate layout for this orientation.

Below are a few common strategies for creating portrait tablet layouts.

Stretch
The most straightforward strategy is to simply stretch each pane's width to best present the content in each pane in the portrait orientation. Panes could have fixed widths or take a certain percentage of the available screen width.
Expand/collapse
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
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
The last strategy is to vertically stack your normally horizontally-arranged panes in portrait. This strategy works well when your panes aren't simple text-based lists, or when there are multiple blocks of content running along the primary content pane. Be careful to avoid the awkward whitespace problem discussed above when using this strategy.

Group Screens in the Screen Map

Now that we are able to group individual screens together by providing multi-pane layouts on larger-screen devices, let's apply this technique to our exhaustive screen map from the previous lesson to get a better sense of our application's hierarchy on such devices:

Figure 3. Updated example news application screen map for tablets.

In the next lesson we discuss descendant and lateral navigation, and explore more ways of grouping screens to maximize the intuitiveness and speed of content access in the application's user interface.

Providing Descendant and Lateral Navigation

THIS LESSON TEACHES YOU ABOUT:

Buttons and Simple Targets
Lists, Grids, Carousels, and Stacks
Tabs
Horizontal Paging (Swipe Views)

YOU SHOULD ALSO READ

Android Design: Buttons
Android Design: Lists
Android Design: Grid Lists
Android Design: Tabs
Android Design: Swipe Views

One way of providing access to the full range of an application's screens is to expose hierarchical navigation. In this lesson we discuss descendant navigation, allowing users to descend 'down' a screen hierarchy into a child screen, and lateral navigation, allowing users to access sibling screens.

Figure 1. Descendant and lateral navigation.

There are two types of sibling screens: collection-related and section-related screens. Collection-related screens represent individual items in the collection represented by the parent.Section-related 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.

Figure 2. Collection-related children and section-related children.

Descendant and lateral navigation can be provided using lists, tabs, and other user interface patterns. User interface patterns, 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.

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.

Figure 3. Example button-based navigation interface with relevant screen map excerpt. Also shows dashboard pattern discussed below.

A common, button-based pattern for accessing different top-level application sections, is the dashboard pattern. A dashboard 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.

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.

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.

Figure 4. Example list-, grid-, and carousel-based navigation interfaces with relevant screen map excerpt.

There are several issues with this pattern. Deep, list-based navigation, known as drill-down list navigation, 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—especially for users on-the-go.

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.

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.

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 Ato 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:

Since there is a single, initially-selected tab, users have immediate access to that tab's content from the parent screen.
Users can navigate quickly between related screens, without needing to first revisit the parent.
Note: 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.

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 (Swipe Views)

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.

Figure 6. Example horizontal paging navigation interface with relevant screen map excerpt.

In a horizontal paging UI, a single child screen (referred to as a page 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.

Figure 7. Example paging companion UI elements.

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.

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.

In the next lesson, we discuss mechanisms for allowing users to navigate up our information hierarchy and back, to previously visited screens.

Providing Ancestral and Temporal Navigation

THIS LESSON TEACHES YOU TO:

Support Temporal Navigation: Back
Provide Ancestral Navigation: Up andHome

YOU SHOULD ALSO READ

Android Design: Navigation
Tasks and Back Stack

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 Navigationpattern guide.

Temporal navigation, or navigation between historical screens, is deeply rooted in the Android system. All Android users expect the Back button to take them to the previous screen, regardless of other state. The set of historical screens is always rooted at the user's Launcher application (the phone's "home" screen). That is, pressing Back enough times should land you back at the Launcher, after which the Back button will do nothing.

Figure 1. The Back button behavior after entering the Email app from the People (or Contacts) app.

Applications generally don't have to worry about managing the Back button themselves; the system handlestasks and the back stack, or the list of previous screens, automatically. The Back button by default simply traverses this list of screens, removing the current screen from the list upon being pressed.

There are, however, cases where you may want to override the behavior for Back. For example, if your screen contains an embedded web browser where users can interact with page elements to navigate between web pages, you may wish to trigger the embedded browser's default back behavior when users press the device'sBack button. Upon reaching the beginning of the browser's internal history, you should always defer to the system's default behavior for the Back button.

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.

Android 3.0 introduced the Up metaphor, which is presented in the Action Bar as a substitute for the Homebutton described above. Upon tapping Up, the user should be taken to the parent screen in the hierarchy. This navigation step is usually the previous screen (as described with the Back button discussion above), but this is not universally the case. Thus, developers must ensure that Up for each screen navigates to a single, predetermined parent screen.

Figure 2. Example behavior for up navigation after entering the Email app from the People app.

In some cases, it's appropriate for Up to perform an action rather than navigating to a parent screen. Take for example, the Gmail application for Android 3.0-based tablets. When viewing a mail conversation while holding the device in landscape, the conversation list, as well as the conversation details are presented side-by-side. This is a form of parent-child screen grouping, as discussed in a previous lesson. However, when viewing a mail conversation in the portrait orientation, only the conversation details are shown. The Up button is used to temporarily show the parent pane, which slides in from the left of the screen. Pressing the Up button again while the left pane is visible exits the context of the individual conversation, up to a full-screen list of conversations.

Implementation Note: As a best practice, when implementing either Home or Up, make sure to clear the back stack of any descendent screens. For Home, the only remaining screen on the back stack should be the home screen. For Up navigation, the current screen should be removed from the back stack, unless Back navigates across screen hierarchies. You can use the FLAG_ACTIVITY_CLEAR_TOP and FLAG_ACTIVITY_NEW_TASK intent flags together to achieve this.

In the last lesson, we apply the concepts discussed in all of the lessons so far to create interaction design wireframes for our example news application.

Putting it All Together: Wireframing the Example App

THIS LESSON TEACHES YOU TO:

Choose Patterns
Sketch and Wireframe
Create Digital Wireframes

Now that we have a solid understanding of navigation patterns and screen grouping techniques, it's time to apply them to our screens. Let's take another look at our exhaustive screen map for the example news application from the first lesson, below.

Figure 1. Exhaustive screen map for the example news application.

Our next step is to choose and apply navigation patterns discussed in the previous lessons to this screen map, maximizing navigation speed and minimizing the number of touches to access data, while keeping the interface intuitive and consistent with Android best practices. We also need to make different choices for our different target device form factors. For simplicity, let's focus on tablets and handsets.

Choose Patterns

First, our second-level screens (Story Category List, Photo List, and Saved Item List) can be grouped together using tabs. Note that we don't necessarily have to use horizontally arranged tabs; in some cases a drop-down list UI element can serve as a suitable replacement, especially on devices with narrow screens such as handsets. We can also group the Saved Photo List and Saved Story List screens together using tabs on handsets, or use multiple vertical content panes on tablets.

Finally, let's look at how we present news stories. The first option to simplify navigation across different story categories is to use horizontal paging, with a set of labels above the horizontal swiping surface, indicating the currently visible and adjacently accessible categories. On tablets in the landscape orientation, we can go a step further and present the horizontally-pageable Story List screen as a left pane, and the Story View screen as the primary content pane on the right.

Below are diagrams representing the new screen maps for handsets and tablets after applying these navigation patterns.

Figure 2. Final screen map for the example news application on handsets.

Figure 3. Final screen map for the example news application on tablets, in landscape.

At this point, it's a good idea to think of screen map variations, in case your chosen patterns don't apply well in practice (when you sketch the application's screen layouts). Below is an example screen map variation for tablets that presents story lists for different categories side-by-side, with story view screens remaining independent.

Figure 4. Example alternate screen map for tablets, in landscape.

Sketch and Wireframe

Wireframing is the step in the design process where you begin to lay out your screens. Get creative and begin imagining how to arrange UI elements to allow users to navigate your app. Keep in mind that at this point, pixel-perfect precision (creating high-fidelity mockups) is not important.

The easiest and fastest way to get started is to sketch out your screens by hand using paper and pencils. Once you begin sketching, you may uncover practicality issues in your original screen map or decisions on which patterns to use. In some cases, patterns may apply well to a given design problem in theory, but in practice they may break down and cause visual clutter or interactional issues (for example, if there are two rows of tabs on the screen). If that happens, explore other navigation patterns, or variations on chosen patterns, to arrive at a more optimal set of sketches.

After you're satisfied with initial sketches, it's a good idea to move on to digital wireframing using software such as Adobe® Illustrator, Adobe® Fireworks, OmniGraffle, or any other vector illustration tools. When choosing which tool to use, consider the following features:

Are interactive wireframes possible? Tools such as Adobe® Fireworks offer this functionality.
Is there screen 'master' functionality, allowing re-use of visual elements across different screens? For example, Action Bars should be visible on almost every screen in your application.
What's the learning curve? Professional vector illustration tools may have a steep learning curve, while tools designed for wireframing may offer a smaller set of features that are more relevant to the task.

Lastly, the XML Layout Editor that comes with the Android Development Tools (ADT) plugin for Eclipse can often be used for prototyping. However, you should be careful to focus more on the high-level layout and less on visual design details at this point.

Create Digital Wireframes

After sketching out layouts on paper and choosing a digital wireframing tool that works for you, you can create the digital wireframes that will serve as the starting point for your application's visual design. Below are example wireframes for our news application, corresponding one-to-one with our screen maps from earlier in this lesson.

Figure 5. Example news application wireframes, for handsets in portrait. (Download SVG)

Figure 6. Example news application wireframes, for tablets in landscape. Also includes an alternate layout for presenting story lists. (Download SVG)

(Download SVG for device wireframe art)

Next Steps

Now that you've designed effective and intuitive intra-app navigation for your application, you can begin to spend time refining the user interface for each individual screen. For example, you can choose to use richer widgets in place of simple text labels, images, and buttons when displaying interactive content. You can also begin defining the visual styling of your application, incorporating elements from your brand's visual language in the process.

Lastly, it may be time to begin implementing your designs and writing the code for the application using the Android SDK. To get started, take a look at the following resources:

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 (swipe views) using ViewPager

Implementing Effective Navigation

DEPENDENCIES AND PREREQUISITES

Android 2.2 or higher
Understanding of fragments and Android layouts
Android Support Library
Designing Effective Navigation

YOU SHOULD ALSO READ

Action Bar
Fragments
Designing for Multiple Screens

TRY IT OUT

Download the sample app

EffectiveNavigation.zip

This class demonstrates how to implement the key navigation design patterns detailed in the Designing Effective Navigationclass.

After reading the lessons in this class, you should have a strong understanding of how to implement navigation patterns with tabs, swipe views, and a navigation drawer. You should also understand how to provide proper Up and Back navigation.

Note: Several elements of this class require the Support Library APIs. If you have not used the Support Library before, follow the instructions in the Support Library Setup document.

Lessons

Creating Swipe Views with Tabs: Learn how to implement tabs in the action bar and provide horizontal paging (swipe views) to navigate between tabs.
Creating a Navigation Drawer: Learn how to build an interface with a hidden navigation drawer on the side of the screen that opens with a swipe or by pressing the action bar's app icon.
Providing Up Navigation: Learn how to implement Up navigation using the action bar's app icon.
Providing Proper Back Navigation: Learn how to correctly handle the Back button in special cases, including how to insert activities into the back stack when deep-linking the user from notifications or app widgets.
Implementing Descendant Navigation: Learn the finer points of navigating down into your application's information hierarch

HOT NEWS

Pages

Monday, 16 March 2015