Master mobile navigation
The success of a site almost always hinges on its content. Content, as we are frequently reminded, is king. But if that’s the case, then navigation is the establishment that keeps him on the throne.
This article first appeared in issue 232 of .net magazine – the world’s best-selling magazine for web designers and developers.
Navigation does a lot more than move someone from location to location within a site; it shapes a user’s experience. Smart navigation can enhance a user’s understanding of your site’s content, services, and offerings, while obtuse language, unfamiliar acronyms and jargon can confuse and distract your users from their goals. While well-executed navigation reflects your brand and enhances its credibility, inappropriate navigation create dissonance and breeds mistrust. Simple, straightforward navigation can increase your sales by ensuring users easily find your goods and can make a purchase; confusing navigation can instead ramp up your customer service and support costs.
Sure, it’s not always sexy, but navigation is critical to the success or failure of your website. It doesn’t matter how good your content, product, or service is … if users can’t find it, they’ll move on.
When the mobile web first became a reality, the few companies that felt the need to venture into this uncharted territory – mostly airlines and financial institutions – did so by creating completely separate mobile websites, often with unique content and navigation. Frequently, these sites amounted to a ‘lite’ version of the parent website, with content and navigation focused on the tasks most likely to be needed ‘on the go’. The vast majority of these sites (especially the homepages) were entirely navigation: lists upon lists of links and simple forms for accomplishing what the business interests or UX teams deemed to be key tasks.
It was a decent strategy at the time. Not many mobile web browsers were powerful enough to handle CSS-based layouts and few supported more than the most basic elements of HTML in the form of WAP or XHTML MP. Browsing on these devices was painful, often accomplished by means of the phone’s number pad, a rocker button, or a scroll wheel. If you were lucky enough to have a Treo or a similar device, you could use your finger or a stylus to click the tiny links on your minuscule screen.
All of this is to say that navigating the web on a mobile device was not a enjoyable activity. Given the incapable browsers and the accompanying slow-as-molasses data connections, it was impossible to ‘hop’ onto the web to look something up. There was definitely no hopping. Just waiting and frustration.
Given the state of browsing on a mobile device, simple navigation and task-focused mobile sites were a breath of fresh air. Trying to browse (or simply load) a traditional desktop site was a nightmare. Consequently, if you used the web on a mobile, it was usually because you really needed access to information immediately and didn’t have a better device handy. And when you did so, you went right to the site, got the information you needed, and left. You rarely lingered and certainly never surfed around just for fun. Unless, of course, you were incredibly bored.
With the advent of the iPhone in 2007 our concept of what it meant to access the web from a mobile device changed dramatically. Out of nowhere, Apple came along and challenged the common wisdom by enabling browsing on mobile to be every bit as full-featured as it was on a desktop or laptop. Not only that, it was fun! (Fast? Well, not so much. At least not back in ’07.)
The balancing act
With the distinction between mobile and desktop dissolving, managing a breadth of web experiences from a single code base became an intriguing reality – and made it more difficult to justify stripping away content from small screen devices. After all, the ‘mobile’ context that was pretty much the norm on the old mobile web was no longer ensured. Study after study proved that people were surfing the web on their phones while plopped on the couch in front of the television. That’s about as far from ‘on the go’ as you can get.
The truth is, users are no longer satisfied with a ‘lite’ mobile experience, nor do they want to hunt for the ‘View Full Site’ link only to be greeted by a hard-to-use layout meant for a large monitor. They want to be able to do anything they could do on traditional desktop web platforms (and potentially more). It’s in our best interests to support a single, adaptive web experience: Opera recently found 59 per cent of its US user base is mobile-only. That number is higher in places such as Egypt, Brazil, and South Africa, and it’s growing worldwide.
If we assume users are just as likely to browse on a mobile device as they are on the desktop, we stop thinking about the small screen as needing ‘less’ and focus on making content, layouts and navigation appropriate to the real estate and capabilities available. And, at the same time, we should revisit our assumptions about desktop users: should wading through extra cruft in the pursuit of our content become a thing of web design’s past? We need to seek out that happy medium that balances the needs of desktop web users with those using mobile devices.
Our first strategy takes its cue from the old ‘mobile web’ camp and only enables users to accomplish ‘key’ tasks (as identified by the UX team, upper management or user testing of an existing mobile site). Users are offered little (or no) navigation and can only access a subset of a website’s features. In some cases, the decision to reduce or remove navigation is made to conserve real estate. Users who only experience such a website on a mobile device may never know they’re missing features, but users who visit it on multiple platforms (which is an increasing trend) are likely to become frustrated when they can’t see items they’re used to accessing.
Authentic Jobs is a good example of this strategy. The main navigation of the site is hidden by default and then displayed if the browser supports media queries and is at least 768px wide:
While this strategy may serve their users well, it is important to realise that mobile users are still being forced to download the HTML. True, it’s only a few navigation links in this instance – but when you begin to use display: none for more of your content (especially images) it can have a tremendous affect on the speed of the site, as well as how much of a user’s bandwidth your site consumes.
As I mentioned, this strategy can be frustrating for frequent users who want to complete a task (such as posting a job) from a small-screen device. Incidentally, most of the pages on Authentic Jobs do look and work well on mobile; you just can’t navigate between them.
If you are struggling to find a reasonable layout for a large navigation menu comprised of several tiers of navigation items, you might want to consider reducing the number of links to only the primary ones for mobile devices. This, of course, assumes that each of those navigation items has a corresponding landing page that provides access to those sub-pages (unfortunately, this is not always the case).
As with the previous example, this strategy would place a tax on your small screen users by forcing them to download more markup than they require. On the plus side, unlike the previous example, you are not likely to frustrate a cross-platform user because the primary navigation options will be consistent.
If you are considering this strategy, you should also ask yourself whether the sub-navigation is really necessary on any platform. After all, if you are comfortable getting rid of it on smaller screens, do you really need it on larger ones? It’s worth noting that this concept can be used in concert with most of the other navigation strategies.
If your site’s navigation is relatively succinct, it’s possible you’ll be able to get away with simply adjusting the layout and size of your navigation items. ‘Succinct’ is obviously a matter of opinion, so you should be cognisant of how much space your navigation occupies even when diminished. Unless they’re looking for inspiration, or writing a piece on mobile nav, users don’t generally come to your site with a view to checking out the navigation.
As with all of these strategies, maintaining a clickable size is key on touchscreens because fingers are much less precise than a mouse pointer. Be sure to provide ample targets (44px square at a minimum) and give your users a little breathing room between navigation items in order to reduce the possibility of mis-taps.
For a number of years now, web standards advocates, SEO consultants and accessibility experts have been arguing in favour of putting the content first in terms of source order. After all, if you’re using CSS, it’s a breeze to move your navigation to the top of the page.
The benefit of this approach is that it provides immediate access to the ‘meat’ of your page for your users and for search engine spiders alike. Incidentally, it’s also incredibly helpful for mobile users, because they don’t need to wade through all of the navigation options for your site before they can get to the content. Contents magazine uses this simple approach in concert with a ‘skip to navigation’ link at the top of the page to provide immediate access to the nav when a user wants it.
Source order independence can be very useful for increasing the usability and accessibility of your site. As long as you’re comfortable with absolute positioning, it’s not much of a challenge to implement either. Just be sure you also include a ‘back to top’ link at the end of your navigation list, in order that users can easily move back to the top of the page too.
One of the more popular mechanisms for managing larger navigation lists on mobile is the drop-down menu. This particular UI construct can be accomplished in a a few different ways, each of which has its own set of dependencies. To choose the right one, you must first determine whether or not the menu should push the page content down when it expands.
Starbucks is probably the most popular example of a drop-down menu that pushes the content down the page rather than sliding over it. In order to accomplish this, the navigation list must appear at the top of the document so that when it expands, it pushes all subsequent content down the page.
Five Simple Steps uses the latter approach for this technique. The style sheet manages which one is displayed based on media queries.
The final mobile navigation paradigm showing potential is the ‘slide to reveal’ nav treatment popularised by apps such as Path and Sparrow on iOS, and Facebook on the web.
On Facebook’s mobile site, the navigation is contained in a div classified as mSideArea and the main content is contained in a div identified as page. These two divs are contained within an outer div identified as viewport. This outer div is relatively positioned to create a positioning context for .mSideArea, which is absolutely positioned and given a width of 260px and a negative left offset of the same amount to move it out of view; #page is positioned relatively with no offsets.
The reveal is accomplished by adding a class of sideShowing to the body element. The addition of this class triggers #page to receive a left offset of 260px (shifting the page content to the right) and sets .mSideArea’s left offset back to 0, moving it into the 260px of empty space to the left of #page.
This is a pretty clever piese of code to be sure. And, should you want to make it a little slinkier, add a CSS3 transition:
The decision is yours
Author’s note: I’d like to say thanks to Brad Frost for creating and maintaining a living compendium of mobile navigation strategies. You can check it out here.
Discover 20 pro tips for mobile website design over at Creative Bloq.