Android: Diseñando una navegación efectiva

[Fuente: http://developer.android.com/training/design-navigation/index.html]

Una de las primeras cosas que hay que plantearse para diseñar y desarollar una aplicación Android es determinar lo que los usuarios pueden ver y hacer con la app. Una vez que sabemos el tipo de datos con el que los usuarios están interactuando en nuestra aoo, el siguiente paso es diseñar las interacciones que permitan a los usuarios navegar por ellos adelante y atrás a través de las distintas piezas de contenido dentro de la app.

En este post te mostramos como planificar a alto nivel una jerarquia de pantallas para tu app y entonces elegir las formas más apropiadas de navegación que permita a tus usuarios efectivamente e intuitivamente navegar por ellas.. Each lesson covers various stages in the interaction design process for navigation in Android applications, in roughly chronological order. After going through the lessons in this class, you should be able to apply the methodology and navigation paradigms outlined here to your own applications, providing a coherent navigation experience for your users.

Lessons


Planificando las pantallas y sus relaciones
Learn how to choose which screens your application should contain. Also learn how to choose which screens should be directly reachable from others. This lesson introduces a hypothetical news application to serve as an example for later lessons.
Planificando para múltiples pantallas táctiles
Learn how to group related screens together on larger-screen devices to optimize use of available screen space.
Proporcionando navegación lateral y descendente
Learn about techniques for allowing users to navigate deep into, as well as across, your content hierarchy. Also learn about pros and cons of, and best practices for, specific navigational UI elements for various situations.
Proporcionando navegación temporal y ancestral
Learn how to allow users to navigate upwards in the content hierarchy. Also learn about best practices for the Back button and temporal navigation, or navigation to previous screens that may not be hierarchically related.
Poniendolo todo junto: Wireframing una aplicación de ejemplo
Learn how to create screen wireframes (low-fidelity graphic mockups) representing the screens in a news application based on the desired information model. These wireframes utilize navigational elements discussed in previous lessons to demonstrate intuitive and efficient navigation.

Planning Screens and Their Relationships

THIS LESSON TEACHES YOU TO
  1. Create a Screen List
  2. Diagram Screen Relationships
  3. Go Beyond a Simplistic Design

La mayoría de las apps tienen un modelo de información inherente que puede ser expresado como un árbol de tipos de objetos. Es decir, podemos dibujar un diagrama de tipos de información distintas que representan los tipos de cosas con las que los usuarios interactuan dentro de nuestra app. Los ingenieros de software y los arquitectos de datos a menudo utilizan diagramas entidad-relación (ERDs) para describir el modelo de información de una aplicación.

Consideremos una aplicación de ejemplo que permite a los usuarios navegar por un conjunto de noticias (stories) y fotos categorizadas. un posible modelo ERD para tal app podría ser el siguiente:

Entity-relationship diagram for the example news application

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

Create a Screen List


Una vez que defines el modelo de información , puedes comenzar a definir los contextos necesarios para permitir a tus usuarios descubrir , visualizar y actuar sobre los datos de tu app de forma efectiva . En la práctica ,una forma de hacer esto es determinando de forma exhaustiva el conjunto completo de pantallas necesario que permita a tus usuarios navegar e interactuar con los datos. El conjunto de pantallas que exponemos por supuesto variará dependiendo del tipo de dispositivo: es importante considerar esto desde el principio en el proceso de diseño para asegurar que la app se adapte a todos los entornos.

En nuestra aplicación de ejemplo , queremos habilitar usuarios para ver , grabar y compartir noticias y fotos categorizadas. A continuación exponemos una lista exhaustiva de pantallas que cubren estos casos de uso:

  • 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


Ahora podemos definir las relaciones directas entre pantallas; una flecha desde una pantalla A a una pantalla B implica que la pantalla B debe ser alcanzable por alguna interacción del usuario desde la pantalla A. Una vez que defines tanto el conjunto de pantallas como sus relaciones, podemos expresar esto en términos de una screen map, la cual muestra todas nuestras pantallas y sus relaciones:

Exhaustive screen map for the example news application

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.

Ir hacia un diseño más simplista


En este punto es posible diseñar una aplicación completamente funcional desde este screen map exhaustivo. Un interfaz de usuario simple se puede componer de listas y botones para ir a las pantallas hijas.

  • Botones para ir a las distinas secciones (e.g., stories, photos, saved items)
  • Listas verticales que representen colecciones de elementos (e.g., story lists, photo lists, etc.)
  • Información de detalle e.g., story view, full-screen photo view, etc.)

Sin embargo , puedes utilizar técnicas de agrupación de pantallas y elementos de navegación más sofisticados para presentar contenido de una forma más intuitiva y que se adapte mejor al dispositivo. En el siguiente apartado , exploraremos estas técnicas , tales como proporcionar  multi-pane layouts para dispositivos tablets. Más adelante , profundizaremos en los patrones de navegación más comunes en dispositivos Android.

Planning for Multiple Touchscreen Sizes

THIS LESSON TEACHES YOU TO
  1. Group Screens with Multi-pane Layouts
  2. Design for Multiple Tablet Orientations
  3. Group Screens in the Screen Map

YOU SHOULD ALSO READ

El mapa de pantallas que hemos hecho en el apartado anterior no está atado a un dispositivo en particular, aunque puede verse bien y funcionar en un móvil o dispositivo de un tamaño similar. Pero las aplicaciones Android necesitan adaptarse a una amplia variedad de dispositivos, desde 3″ handsets to 10″ tablets to 42″ TVs.En este apartado exploraremos las razones y tácticas para agrupar juntas varias pantallas desde el screen 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.

Agrupar Screens con Layouts Multi-pane

Diseño de un Layout Multi-pane 

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

Las pantallas de 3 o 4 pulgadas se ajustan bien a la hora de mostrar un sólo panel vertical de contenido en cada momento , ya sea una lista de elementos , o información de detalle de un elemento , etc. Asi que en tales dispositivos , las screens se mapean one-to-one con la jerarquia de los niveles de información (categorias –> lista de objetos –> detalle del objeto)

Las pantallas más grandes , como las de las tablets y las TVs, por otra parte , tiene más espacio de pantalla disponible y son capaces de presentar varios paneles de contenido. En landscape, los paneles son generalmente posicionados de izquierda a derecha en orden creciente de detalle. Los usuarios están acostumbrados a varios paneles en pantallas grandes desde hace muchos años en aplicaciones de escritorio y en aplicaciones web.Muchas aplicaciones de escritorio y websites ofrecen un panel de navegación en el lateral izquierdo o utilizan un layout de dos paneles master/detail.

Además de tratar con las expectativas del usuario, es generalmente necesario proporcionar múltiples paneles de información en tablets para eliminar mucho espacio vacío o poder prevenir interacciones del usuario no deseadas: por ejemplo botones de 10 x 0.5-pulgadas.

La siguiente figura demuestra algunos de los problemas que pueden surgir cuando se muestra un diseño UI  en un layout más grande y cómo solucionar estos inconvenientes con multi-pane layouts:

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

Multi-pane layouts in landscape offer better a visual balance while offering more utility and legibilityFigure 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.

Diseño para múltiples orientaciones de Tablet

Aunque no hemos empezado a colocar elementos de nuestro interfaz de usuario en nuestras pantallas todavia ,es un buen momento para considerar cómo tus pantallas de mulyi-pane se adaptarán a las distintas orientaciones de los dispositivos. Multi-pane layouts en landscape funcionan bastante bien because of the large amount of available horizontal space. Sin embargo , en la orientación portrait , your horizontal space is more limited, so you may need to design a separate layout for this orientation.

A continuación hay unas cuantas estrategias para crear portrait tablet layouts.

  • Stretch Stretch strategy La estrategia más directa es estrechar la anchura de cada uno de los panes cuando se presente el contenido en la orientación portrait. Los panes pueden tener anchuras fijas o tomar determinados porcentajes del espacio disponible de pantalla
  • Expand/collapse Expand/collapse strategy Una variación de la estrategia de estrechar es colapsar los contenidos del panel izquierdo cuando se pone en portrait. Esto funciona bien con master/detail panes donde el panel izquierdo contiene una lista de elementps fácilmente colapsables. Un ejemplo podría ser una aplicación de chat en tiempo real. En landscape , la lista izquierda podría contener las fotos , los nombres y el estado de los contactos. En portrait, el espacio horizontal puede ser colapsado escondiendo nombres de los contactos y sólo mostrando las fotos y los iconos indicadores de estado. Opcionalmente también proporcionar un control para poder expandir/esconder los contenidos del panel izquierdo.
  • Show/Hide Show/Hide strategy En este escenario, el panel izquierdo está completamente escondido en modo portrait. sin embargo, para asegurar la paridad funcionar de tu pantalla en portrait y landscape , el panel izquierdo debe estar disponible a través de algún tipo de control (como un botón). Es generalmente apropiado utilizar el botón Up del Action Bar (pattern docs at Android Design) para mostrar el panel izqdo, como se discutió en later lesson.
  • Stack Stack strategy 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.

Agrupar Screen del 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:

Updated example news application screen map for tablets

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:
  1. Buttons and Simple Targets
  2. Lists, Grids, Carousels, and Stacks
  3. Tabs
  4. Horizontal Paging (Swipe Views)

YOU SHOULD ALSO READ

Una forma de proporcionar acceso a un amplio rango de pantallas de la aplicación es reorganizarlas en una navegación jerárquica. En este apartado discutiremos la descendant navigation, permitiendo a los usuarios descender descend ‘down’ en la jerarquía de pantallas a una pantalla hija, y lateral navigation, permitiendo a los usuarios acceder a pantallas hermanas.

Descendant and lateral navigationFigure 1. Descendant and lateral navigation.

There are two types of sibling screens: collection-related and section-related screensCollection-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.

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

Tanto la navegación descendente como la navegación lateral puede ser realizada utilizando listas , tabs , y otros patrones de interfaces.  User interface patterns, como los software design patterns, son comúnmente utilizados, common solutions to recurring interaction design problems. Exploraremos unos pocos lateral navigation patterns en los apartados siguientes.

Botones y Targets simples

Diseño de botones

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.

Example button-based navigation interface with relevant screen map excerpt. Also shows dashboard pattern discussed below.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.

Example list-, grid-, and carousel-based navigation interfaces with relevant screen map excerptFigure 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.

Example phone and tablet tab-based navigation interfaces with relevant screen map excerptFigure 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 (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.

Example horizontal paging navigation interface with relevant screen map excerptFigure 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.

Example paging companion UI elementsFigure 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:
  1. Support Temporal Navigation: Back
  2. Provide Ancestral Navigation: Up and Home

YOU SHOULD ALSO READ

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


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.

The Back button behavior after entering the Email app from the People (or Contacts) appFigure 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 handles tasks 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’s Back 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.

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 (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 Home button 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.

Example behavior for UP navigation after entering the Email app from the People appFigure 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_TASKintent 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.