Open book with bookmark
Issue № 337 Illustration by

Organizing Mobile

A note from the editors: We are pleased to present an excerpt from Chapter 4 of Mobile First by Luke Wroblewski (A Book Apart, 2011).

When it comes to organizing the content and actions on mobile, solid information architecture principles like clear labeling, balanced breadth and depth, and appropriate mental models remain important. But the organization of mobile web experiences also needs to:

Article Continues Below
  • Align with how people use their mobile devices and why.
  • Emphasize content over navigation.
  • Provide relevant options for exploration and pivoting.
  • Maintain clarity and focus.
  • Align with mobile behaviors

In the previous part, we talked about the constraints and capabilities that make designing for mobile unique. Similarly, the desktop web also has a set of limitations and possibilities that make it distinct. So simply porting over what worked for you on the desktop to mobile often doesn’t make sense. Instead, you need to think about what mobile is uniquely good at and align it with the needs of your customers.

Looking at this intersection at a high level can illuminate how people are typically using their mobile devices and why. In his book Tapworthy, author Josh Clark focused on three critical mobile behaviors: micro-tasking, “I’m local,” and “I’m bored.” These align pretty well with Google’s breakdown of mobile users into three behavioral groups: urgent now, repetitive now, and bored now. Regardless of how you chose to label these behaviors, mobile usage generally consists of a couple of interaction types:

  • Lookup/Find (urgent info, local): I need an answer to something now—frequently related to my current location in the world.
  • Explore/Play (bored, local): I have some time to kill and just want a few idle time distractions.
  • Check In/Status (repeat/micro-tasking): Something important to me keeps changing or updating and I want to stay on top of it.
  • Edit/Create (urgent change/micro-tasking): I need to get something done now that can’t wait.

Because they directly align with why people pull out their mobile devices, these behaviors often determine how your mobile experience can be structured and organized to meet people’s needs. For example, the Flickr photo sharing mobile web experience has four primary actions. Recent activity and uploads from your contacts let people check-in on what’s new with their friends and photos; today’s interestingness and photos taken nearby give people a way to fill idle time by looking at great pictures (Fig 4.1).

Fig 4.1

Fig 4.1: Both Flickr and Basecamp’s mobile web experiences align with why people pull out their mobile devices.

Similarly, the Basecamp project management mobile web experience emphasizes the ability to check-in, edit, and create new messages, to-dos, and more. While people’s reasons for using Flickr and Basecamp are different, both sites have thought through how they’ll be used on mobile and adjusted their organization accordingly.

Aligning with mobile behaviors also naturally aligns your website with real-world needs. Since a mobile experience can be accessed anywhere and everywhere, you need to think through how it can be useful to people wherever they may be. That means lots of real-world use cases that ground your site’s organization in what people actually want to do.
I recently found a great example of this in action. On the Mobile in Higher Ed blog, Dave Olsen responded to an xkcd comic (Fig 4.2) with:

…as I was looking at the right side of the Venn diagram I thought, “That looks like a lot of the current and planned content for our mobile site.” […] removing unnecessary fluff and cruft to fit in the constraints of both the device real estate as well as network limitations, helps craft a better and more useful user experience.

I couldn’t have said it better myself.

Fig 4.2

Fig 4.2: A comic from xkcd parodying what people want on a university website versus what they find.

Content over navigation#section2

As a general rule, content takes precedence over navigation on mobile. Whether people are checking on frequently updated data like stocks, news, or scores; looking up local information; or finding their way to articles through search or communication tools—they want immediate answers to their needs and not your site map.

Too many mobile web experiences (like the Flickr and Basecamp examples we just looked at) start the conversation off with a list of navigation options instead of content. Time is often precious on mobile and downloads can cost money, so get people to what they came for as soon as you can.

The YouTube and ESPN mobile web experiences do just that. A simple header tells you whose site you are on and relegates navigation options to a single action. The rest of the page is filled with timely content to check-in on (ESPN) and popular time killers to explore (YouTube) (Fig 4.3).

Fig 4.3

Fig 4.3: ESPN and YouTube’s mobile web experiences put the focus on content instead of navigation.

Pivot and explore#section3

But wait—if content always takes precedence over navigation, how can I find my way around mobile web experiences? Don’t we need a way to navigate and discover what’s available? Of course, but allowing people to explore and pivot to relevant content doesn’t have to mean piles of navigation bars that bury content.

For example, it’s great that Facebook puts relevant content I can frequently check-in on front and center in their mobile web experience; but because of the three navigation bars at the top of their pages, I can only see one update on my screen. The Google Finance mobile web experience also has relevant, timely content—but it’s sandwiched below five navigation bars. That’s a lot of precious screen space spent on navigation options people might not need—space that could have been devoted to useful content instead (Fig 4.4).

Fig 4.4

Fig 4.4: Facebook and Google Finance fill precious space with lots of navigation options in their mobile web experience.

Facebook recently redesigned their mobile web experience and actually reduced the number of navigation options (Fig 4.5). If you don’t count the Top News and Most Recent filters on their news feed, they cut the number of navigation choices in half (from ten to five). That’s a pretty good start!

Fig 4.5

Fig 4.5: Facebook’s recent redesign cut down on the number of navigation options in their mobile web experience.

The examples from YouTube and ESPN (Fig 4.3) both emphasize content over navigation, but they handle the ability to pivot and explore the rest of their site through navigation differently. YouTube provides a shortcut to a full screen experience dedicated to getting around the site (Fig 4.6). This approach requires you to actively seek out navigation options and takes you out of context (to a separate page) when you do. You also need to know that the grid icon in YouTube’s header means “navigation menu, please.”

Fig 4.6

Fig 4.6: YouTube’s mobile web experience includes a full page of navigation options accessible from the header.

ESPN has a more clearly labeled “Menu” button in their header that reveals an extensive (and multi-leveled) navigation list directly below it (Fig 4.7). This approach allows you to stay on the current page when considering where to go next. No need to move to and load a separate page. ESPN also repeats their navigation options in a menu at the bottom of most pages.

Fig 4.7

Fig 4.7: ESPN’s mobile web experience includes navigation options in the header and at the bottom of every page.

Controls at the bottom of the screen are easier to interact with one-handed and present people with choices and ideas on what to do next when they get to the end of a screen. YouTube’s design lacks these pivots at the end of their pages; when you get to the bottom, there’s nowhere left to go (Fig 4.8).

Fig 4.8

Fig 4.8: The options at the end of a page on YouTube’s mobile web experience are basically a dead end. Sign out? Send feedback?

Though bottom menus are useful for further exploration, they probably shouldn’t just duplicate a menu that can be found elsewhere. Instead, a top-level menu button can simply link people to a navigation list on the bottom of a mobile webpage (after the content). We recently used this approach on the Bagcheck mobile web experience (Fig 4.9).

Fig 4.9

Fig 4.9: An anchor link in the Bagcheck header jumps you to the site’s navigation menu at the bottom of the page.

A simple anchor link in the site’s header jumps people to navigation options at the bottom of the page. Having this list present at the bottom of content pages allows people to pivot and explore other parts of the site. Especially when they come directly to a content page and may not be familiar with the rest of what the site offers.

The menu on the bottom of Bagcheck pages also has a “top” link to bring people back up to the start of a page if they want to return to the content they were just viewing.

This design uses a minimum amount of navigation elements (just a single link at the top), gives people an opportunity to pivot and explore when they get to the end of content, doesn’t duplicate the content of another menu, and (best of all) only requires a simple anchor link to work. That’s right: no fancy JavaScript, overlays, or separate navigation pages to maintain—just an anchor that links to the bottom of the page. That’s like HTML 0. (Which I’ve heard works in most browsers except Internet Explorer.)

Content pages on Bagcheck also have unique related navigation lists for deeper exploration (Fig 4.10). These navigation options allow people to immerse themselves in further information about a single topic if they choose. Or they can simply use the global navigation options below to pivot to a different area of the site.

Fig 4.10

Fig 4.10:  Contextual navigation menus on the Bagcheck mobile web experience allow people to explore related content.

Contextual navigation options are also useful for tasks. In the Gmail mobile web experience (Fig 4.11), a contextual menu of actions can be accessed from the top of the screen. Because these actions are directly related to the current email message being shown, putting them at the bottom of a web page wouldn’t be very efficient. Instead, they are always present at the top and thereby instantly accessible.

Fig 4.11

Fig 4.11: Contextual actions in the Gmail mobile web experience allow people to quickly act on their email.

Getting back#section4

It’s always interesting to see how design solutions migrate across digital borders. For example, many native iPhone applications have prominent “back” links in their navigation header (Fig 4.12). Apple’s mobile devices lack a physical back button and don’t display any system chrome actions for native apps.

Fig 4.12

Fig 4.12:  The “back” button is a common feature in native iPhone applications.

But the presence of a “back” button in the header has unnecessarily migrated to mobile web experiences. Many devices (Android, Blackberry, Windows Phone 7, etc.) have physical back buttons (Fig 4.13). Even Apple’s mobile web browser includes a prominent back control in the application toolbar (Fig 4.14). Adding another back button in your mobile web experience’s header only confuses things. Someone using the site must ask, “Do both of these back buttons do the same thing?”

Fig 4.13

Fig 4.13: Android devices feature a hardware back button on the device.

Fig 4.14

Fig 4.14: Apple’s mobile web browser has a permanent back button in the bottom toolbar.

So when designing mobile web experiences, you can leave “back” back in the native app. If you need to provide people with a quick way to go “up” a level in your site consider a label other than “back.”

Sticking to the bottom#section5

Speaking of native iPhone applications, many of them also use fixed position navigation bars at the bottom of the screen. These menus make key actions easier to access with our thumbs, but unlike mobile web experiences, native iOS applications don’t have web browser controls eating into their screen space. Yahoo! Mail’s mobile web experience illustrates the impact browser chrome can have on a mobile web page. The two browser menus and two fixed position menus in Yahoo! Mail’s mobile web experience leave little room for actually seeing what’s in your inbox (Fig 4.15).

Fig 4.15

Fig 4.15: Yahoo! Mail’s mobile web experience uses a navigation menu fixed to the bottom of the browser window.

But mobile web experiences don’t just have to contend with the chrome of one web browser on iOS: they have to contend with many web browsers. Devices with physical controls below their screen also present a challenge for menus fixed to the bottom of the screen (Fig 4.16). The close proximity of these controls and an application’s menu bar means errors are bound to happen as people miss menus and hit physical buttons.

Fig 4.16

Fig 4.16: Many devices have physical controls below the screen.

When developing a native mobile application you could adjust a menu’s position to account for physical buttons below the screen, but mobile web experiences need to work across platforms—physical buttons below the screen or not.
So while navigation menus fixed to the bottom of the screen might be a good idea in some native mobile applications, the variable presence of web browser menus and physical controls below the screen on mobile devices means they are often a poor idea in mobile web experiences. If you need a fixed menu, better to fix it to the top, as Twitter has done in their redesigned mobile mobile web experience (Fig 4.17).

Fig 4.17

Fig 4.17: Twitter’s latest mobile web experience uses a top navigation menu for key actions to account for the differences between mobile web devices.

Maintain clarity and focus#section6

As I mentioned in the first half of this book, when they are on their mobile devices, people are often just “one eyeball and one thumb.” They’re usually not comfortably seated in front of a desk and focused on your site. Instead, they are in the real world with many possible distractions around them. In these situations we only have people’s partial attention; they need clear, focused designs to get things done—not lots of navigation options getting in their way.

Yahoo! Mail’s compose email screen is a great example of removing extraneous actions and letting people focus on their primary task (in this case, writing an email) on their mobile device. This screen contains only a single navigation action: “cancel” (Fig 4.18). The rest of the interface is laser-focused on the task at hand.

Fig 4.18

Fig 4.18:  Contrast the amount of navigation options in Yahoo’s Compose Mail (left) and ESPN’s live game screens (right).

ESPN’s real-time updates of NBA games, on the other hand, are covered with so many navigation options that the display of what’s happening in the game is pushed off screen. The task at hand is seeing play-by-play action not jumping between menu options.

Minimizing the amount of navigation options on mobile screens helps to prevent errors as well. With fewer navigation choices, people are less likely to accidentally tap away to other tasks while trying to accomplish their current objective.

Organizing mobile#section7

When organizing your mobile web experience, think through how you can align mobile behaviors with your customer’s needs.

  • Mobile use cases like lookup/find, explore/play, check-in/status, and edit/create allow you to think through how your site will be used on mobile and adjust its structure appropriately.
  • Focusing on content first, navigation second gets people to the information and tasks they want quickly.
  • Relevant and well-placed navigation options allow people to dive deeper or pivot to explore other parts of your site.
  • Reducing the amount of navigation choices and chrome on key tasks maintains clarity and focus on what people need to accomplish—helpful when they are hurried or in less than ideal situations.
  • And when they do have some relaxing time on the couch with their mobile, people will still appreciate the simplicity of your design!

14 Reader Comments

  1. Contrary to the article, I prefer an on-screen “back” button in Android apps. The way I hold the phone when interacting with the screen is sometimes different than the way I need to hold the phone to click the hardware buttons. I can more easily tap the screen than shift around and press harder to click the button. For applications with a lot of forward and back navigation, it can make sense to keep more of the gestures on-screen.

  2. @astearns, in situations like that the gestures can be integrated in the app. But an explicit “back” button is different. it is a browser control. Why replicate it (often with different behavior)? We learned this lesson on the Web a long time ago. Site’s that tried to rebuild the browser’s back button moved away from it real fast.

    If you need navigation actions make them navigation actions: ideally labeled with their destination/function and secondarily with a non-“back” label like “up” a nav tree or “previous/next in a sequence.

  3. In an application I could see having a onscreen back button due to the fact that sometimes pressing the hardware back button actually closes out the program when you only meant to go back one screen.

    Website wise if you’re using an Android phone, Opera mini has an onscreen back and forward button.

  4. Simply changing the CSS of a normal, desktop focused web site to display the same content on a mobile is a Very Wrong Way of creating a mobile friendly site. You have demonstrated very clearly why we need to completely re-think the architecture for mobile presentation

    Good one

  5. Although the article doesn’t cover this I noticed that in your examples the redesign of facebook/twitter kept a small magnifying glass icon on the top while bagcheck’s search is integrated with the menu at the bottom. Should search be relegated to the bottom menu? Would the average user know to go to the bottom (or click on the arrow) to search for something?

    I could see the top menu design having both menu and search icons as well as the logo (a facebook & bagcheck combo).

    Fantastic article. I look forward to reading the book.

  6. Thanks for sharing this with the A List Apart readers Luke – some incredibly useful and usable information in here. Wondering how you feel about users who are exploring on information rich website being given a crumb trail for orientation purposes? It has its obvious benefits but is likely to add precious height to the header of every page.

  7. Mobiles are extremely used on web. Much more than a few years ago. In Brazil, its raising 500% per year according to google. We need to start focusing on that very quickly. Nice article!

  8. You wouldn’t believe how many “Back” button battles we’ve had in the past few months for our mobile sites. It’s like the early web days all over again.

  9. Having the menu button at the top take the user to a menu at the bottom of the page is a bad idea. If you argue that having a navigation page takes the user out of context is bad, then scrolling the user away from the context they’re in isn’t any better. It might even be worst. Autoscrolling is more jarring to me and there’s often no way to get back to the same context. I favor having a menu that is laid over the content. This way the user is able to take a peek at the menu and dismiss it without penalty. Peeking without penalty is a UX design pattern I’m seeing more of in both desktop and mobile apps.

  10. Hi Luke, I was about to buy the book, but I see that it’s quite old (from 2011?)
    Any updates planned for 2013?
    BTW, in German Amazon they only have the French version of the book!?

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA