Organizing Mobile

Getting back

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.

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. Even Apple’s mobile web browser includes a prominent back control in the application toolbar. 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?”

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

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.

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

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.

Maintain clarity and focus

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.

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.