The Fig Leaf Blog

The Case for Better Navigation when Developing Mobile Apps

How Current Design Patterns Fail Both Companies and Users

Smartphones have become nearly ubiquitous, and although more of us conduct business, seek out information, and shop on our phones than ever before, navigation for mobile websites is stuck in the dark ages. It’s been a hot topic in user experience for the last several years: how do you get people to the information they need on a 3.5” screen? The answers have been various: either you don’t (“if they really need it they’ll go to their desktop” or “they can search”), or you do it slowly, click after painfully loading click.

Many in the user experience community have argued that people don’t need the depth of information from a full website from their mobile devices, but it just isn’t true. What we don’t need is desktop-scale navigation and desktop-type interaction, because obviously, we’re not on a desktop. Our information needs are often the same, though; and because we’re on a mobile device, the need can be more targeted and critical. Most of us try to use our mobile devices to access specific information and conduct research, and we are overwhelmed by frustration. It takes time, effort, and persistence. Yet most major websites have this information tucked away, and it’s a ton easier to get it on your desktop.

It’s not all about connection speed, nor is it about the form factor alone. Most websites offer poor and limited navigation to mobile users. That people give up trying to extract information from the depths of websites is a failure of information architecture and, often more importantly, interaction design.

As interaction patterns for mobile navigation have been debated, a few patterns have emerged as dominant. It’s easy to find them, and even if you’re not a designer, you could probably list them – for the frustration they’ve caused, if nothing else. Most websites will give you a list of their top categories, either hidden under the hamburger-style “menu” icon at the top of the screen, or as a list at the top of the page or in the footer. A precious few will let you click to see the subtopics for each of the main categories. That’s usually where it ends (Figure 1, Figure 2, Figure 3).

Figure 1. With the mobile menu revealed, Lonely Planet offers visitors their top categories, preceded by Search and other tools. (The more helpful navigation is actually in the footer. If you click “Destinations” from here, the website cryptically takes you to “World”, as though you might not be here yet.)

Figure 2. The New School offers visitors five buttons to browse the site. Each of these buttons leads to long, scrolling pages; some of them have menus to help you filter through the information.

Figure 3. The Huffington Post offers only four main categories for navigation, and a link to a page with All Sections. Compare this with the main site, which offers eight different topics, each with subcategories of its own, and “All Sections” visible on the main page.

If you’re lucky, the page you’re clicking to gives you some more topics to click into; although it’s a cursed kind of luck, since each page you load takes some time (Figure 4). If you’re not, you’re stuck on a top-level landing page that shows you whatever an editor decided would be most important to you, and all of the rich detail available on a desktop screen is not available for you, dear mobile user. You have to search, and hope the search engine is good (and that you pick the right words to search on) – or just leave the site and try somewhere else.

That’s not a good thing. We want you to stay on our website. We have things to tell you or sell you, and we’ve worked hard to write them and publish them. We want you to hear what we have to say.

Figure 4. Macy’s lets you see subtopics for it’s major categories (like “Shop by Category”), but when you click a category, it loads a new page with more navigation. With the +/- symbols and the arrow icons, the page load is unexpected; and on a mobile device, these unexpected page loads are painful.

No librarian worth her salt would bar you from the catalogue and force you to stumble through the aisles, or hope she’d featured precisely the book you needed on the shelf of staff-selected features. Information architects are librarians: their job is to make the information on the site easy for you to find. They work hard on this for desktop sites, but all that work is lost on most mobile websites.

This is where interaction design has failed. As designers, we continue to rely on the outdated assumption that people don’t need the same information on mobile, even though mobile website use is increasingly dominant – sometimes it is the primary way that people get their information. It cripples a website audience to offer them only top topics and then the featured stories. A proper interaction design strategy for mobile navigation allows end users the same depth of navigation available to desktop users, but in a way that is easy for them to use, access, and understand.

There are currently two strong, but underutilized, strategies to offer deep navigation to end users. The leading contenders are push-and-pull menus, and nested accordions. Neither is perfect, but both are reasonable starting points to explore the problem.

Nested accordions allow the visitor to your site to click down into the categories for each section, seeing the options offered in each category and making a selection. As the visitor clicks, the topics in the selected category expand in place.

Figure 5. Samsung uses nested accordion navigation.

Push and pull menus work similarly, but instead of a topic expanding in place to show its menu, the menu for the selected topic replaces the old menu, either pushing it to the side or sliding over top of it. So if the user clicks “About” from the top group of topics, the top topics will push to the side slightly and reveal the menu of options for “About”. The pushing metaphor demonstrates the concept of drilling down in the site map, and lets the site visitor focus on the area of their interest.

Figure 6. NPR uses nested push and pull menu navigation.

Designed well, both strategies offer multiple levels of navigation that support an information- or product-rich website. When the navigation includes long lists or especially deep navigation, the push-and-pull method offers a cognitive advantage for the visitor, who sees only the options she’s interested in comparing, so that decision-making is easier. It also shows a visitor how deep she is in the site map, without requiring her to do a lot of scrolling and looking for subtle visual cues like shading groups and arrows, or plus and minus signs.

Both strategies also present a new interaction design problem: there is no way to click directly to any topic that has subtopics of its own (“children”), since when you click on a parent topic, it expands to show its children. However, on a desktop website, the visitor can usually click either the parent or the child topic; and sometimes the website is designed and written to show important information on parent pages. For example, in Samsung’s nested accordion navigation (Figure 5), the visitor cannot click to see all Tablets, even though Samsung has a page for this parent topic. So on websites with the deep navigation that we need, visitors miss the chance to see parent topic pages. If the visitor doesn’t know exactly what she’s looking for, this becomes a critical interaction issue. How can we offer users access to both the page itself and its child pages, in a mobile interface?

Brainstorming Solutions

One possible solution is to introduce a second gesture for mobile device menus, to let people get to top-level topic pages. On desktops, we pair hover and click to allow both shallow and deep navigation; so maybe on mobile devices, we could pair touch-and-hold with short-touch, or swipe with tap, to let users tell the menu whether they want it to open a topic or expand a menu to show subtopics? Over time this could become a solution, but it’s not a great option right now: most users don’t think to use these kinds of gestures when they are interacting with their phones unless they are trained to do this, and the conventions don’t exist at all for browsing websites. These kinds of advanced gestures don’t help us solve the problem.

As the Fig Leaf design team walked through these scenarios, we also considered whether there should be separate places to click within a navigation bar – possibly denoted with icons like + for “expand” and > for “open”. This results in teensy target spaces, though – hard for people with big fingers or with imperfect motor control; and it relies on users to distinguish between very subtle visual cues. Similarly, we considered whether users might click the topic name to open the page, and an icon next to the topic name to expand the menu. Still, this design requires user to pay attention to iconography, when the user’s main tasks in navigation are usually “make a choice” from a list, and “click the choice target” not its neighbors. ING uses a design like this, which illustrates the problem: it is far more compelling to click the topic you need, like “About Us”, than to click the plus sign to the far right. Unfortunately, this short circuits all of the advantages of providing a deep navigation menu.

Figure 7. ING uses nested accordion navigation with two distinct click behaviors: clicking the word portion of the label will take you to the parent page; clicking the plus sign on the right part of the label will expand the parent topic to show its children. While both parent and child pages are available to visitors in this model, it’s unlikely that most visitors will anticipate the difference between clicking on the left 290 pixels and the right 30 pixels in a single line.

Another option that Fig Leaf designers considered: when a topic menu is open, the topic itself could be listed a second time with its children, and users could click to the topic from here. Pottery Barn does something like this:

Figure 8. Pottery Barn includes an “All Bedding” link under its topic heading for Bedding > Shop By Category, but it does not include a similar “All Quilts” link under Quilts. Visitors have to decide on a solid or patterned quilt before shopping, or shop both categories separately.

It’s certainly easier to find the link to “all” here, but we found a few problems with this approach. First, it either requires the CMS to programmatically insert the parent topic a second time in each topic list (hidden from view for desktops), or it requires a person to do this manually, increasing the opportunity for error. In fact, the Pottery Barn example illustrates this problem: in the second image, “All Bedding” has been inserted under “By Category”; but in the third image, there is no similar “All Quilts” category. If you want to shop quilts at Macy’s by phone, you’d better have a preference for solid or pattern, or be willing to scour through both lists.

Second, if your site isn’t an e-commerce site, relisting your topic within its own subtopic list becomes a little trickier. With merchandise, you can reliably use “all” as a label; but it’s more complicated and less consistent if you are presenting information instead of merchandise. Imagine trying to extend this practice on a transit website or a university website, for example. You could have options for “all destinations” or “all majors”, but the same language would not apply to “rider guide” or “Provost’s office”. Other language solutions, like “See [Topic Name]”, end up looking clunky and confusing in this kind of navigation pattern.

With each mobile navigation solution Fig Leaf designers considered, we kept coming back to the same three issues:

The navigation has to behave consistently and predictably.

Users shouldn’t have to think about where to click, or what keywords, icons, or other visual design cues to look for. These solutions aren’t accessible to everyone, and they’re not easy for almost anyone to adapt to from site to site.

The solution has to be easy to implement for the people who maintain the website.

With this in mind, and many whiteboard sessions behind us, we finally settled on using two approaches for deep mobile navigation. The first model is a modification of nested accordion navigation, which works well for most sites with moderately deep architecture. The second model is our favorite, since it is more discoverable: it is a modification of push-and-pull navigation, which can support very deep information architecture models. Here are our recommendations:

Simple Accordion Menus

With the first click of an accordion title, expand the accordion.

With the second click of an accordion title, go to the landing page for that title.

Include supporting text or iconography for this behavior, if possible (e.g. if you use a + to denote an accordion, when it’s expanded, replace this with text like “go”, or better yet, “go to [topic]”.

To close an accordion title, the user would need to click another accordion title in the group.

Figure 9. Ashcroft.com uses modified accordion navigation. The first click on a topic expands the topic; the second click links directly to it. Topics which have children are denoted with a + sign.

Advantage: The user doesn’t have to find a second link to the top-level topic page, and doesn’t need to weed through complex iconography or distinguish between interaction spaces, to use the functionality.

Disadvantage: It takes two clicks to get to a topic, which makes the behavior less discoverable, since most people do not click the same link twice in a row expecting different behavior.

Although it is less discoverable than we would like, this model provides some support for access to top-level topics; and once the behavior is discovered, it is consistent and predictable throughout the site. However, as we develop sites using this navigation model, we do exercise some caution in the way we structure content relationships. Ideally, we want the key pages that users need to find at the endpoints of a navigation tree, so there is less risk that they will miss the page under a second click. Read the Ashcroft Case Study.

Push-and-Pull Menus (Our Favorite)

When the user clicks a topic, its subtopic menu slides over, as with a regular push-and-pull menu.

In the list of subtopics, the topic heading becomes clickable to the topic page.

A supporting text link is shown beneath the topic name, to reinforce that the heading is clickable.

Zurich does something like this in their responsive navigation, using the first two steps we recommend. (They completely push the underlying page away, so it’s less clear from the still images that the page has been pushed.) The blue text makes the headings reasonably understandable as links, but the support of a text link beneath the heading would help.

Figure 10. Zurich uses push-and-pull navigation, with support for clicking to parent topics. Mobile site visitors can click on the headers for “News” in the second image above, or “News releases” in the third image above, to see those pages.

We prefer this prototype below, which uses the same system, but shows the page that underlies the navigation (a single click anywhere in that area closes the navigation menu, so you don’t have to notice the back button). It also shows the supporting text link we’ve described, to call attention to the click to the topic ure 11. A prototype of our preferred model for mobile navigation: modified push-and-pull navigation, with supporting text links to the parent topics.

Advantage: Implemented well (with the supporting text links), this model is highly discoverable. It also does not require the same ongoing attention to the structure of information on the website as the nested navigation does.

Disadvantage: It still takes two clicks to a top-level topic, and the click target moves from the first click to the second. Some users may also be less comfortable with push-and-pull navigation, than with accordion navigation.

We prefer this approach to mobile navigation because it’s more discoverable and easier to maintain – and because it supports both shallow and deep site structures. In order to optimize discoverability, this approach requires extra visual design attention to make it clear that headings are clickable, and to incorporate the supporting text link beneath the menu heading (e.g. “Visit [Topic Name] >”, in the prototype illustration above).

Advantage: Implemented well (with the supporting text links), this model is highly discoverable. It also does not require the same ongoing attention to the structure of information on the website as the nested navigation does.

Disadvantage: It still takes two clicks to a top-level topic, and the click target moves from the first click to the second. Some users may also be less comfortable with push-and-pull navigation, than with accordion navigation.

We prefer this approach to mobile navigation because it’s more discoverable and easier to maintain – and because it supports both shallow and deep site structures. In order to optimize discoverability, this approach requires extra visual design attention to make it clear that headings are clickable, and to incorporate the supporting text link beneath the menu heading (e.g. “Visit [Topic Name] >”, in the prototype illustration above).