Master mobile navigation

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.

Evolution

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 first iPhone made it possible – nay, enjoyable – to tap and swipe your way across the web on a ‘small’ screen. In the coming months and years, users began to shift away from the focused, task-oriented traditionally ‘mobile’ browsing paradigm to a more traditionally ‘desktop’-ish one. And with the advent of CSS3 media queries in 2010, it became possible to craft adaptive layouts that tailored themselves to the screen on which they were displayed without relying on JavaScript-based trickery and alternate style sheets.

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.

Navigation strategies

I’m going to take you on a whirlwind tour of mobile navigation strategies. Each has its pros and cons but, more importantly, each has its own set of dependencies. Most, as you’d expect, rely on media queries. Some have source order requirements. And a few rely on JavaScript, the absence of which can make for an awkward interface.

Hide it

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:

/* Hide the nav by default */body > header nav {display: none;}/* >= 768px */@media only screen and (min-width: 768px) {/* Show the nav again */body > header nav {display: block;}}

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.

Trim it

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.

As part of an experiment, Michael Scharnagl crafted a navigation scheme wherein he classified the main navigation links into three distinct groups according to priority, progressively adding more items as more real estate became available. On smaller screens, he displays a ‘more’ link that enables users to toggle the additional navigation items into view without relying on JavaScript (akin to the JavaScript-less drop-down I will discuss shortly).

Shrink it

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.

/* <= 720px */@media (max-width: 720px) {/* Linearize the list & space out the items */.mainnav li {display: inline-block;line-height: 1em;margin: 0 .5em .5em 0;}/* Make the links large & tappable */.mainnav li a {border-radius: 1em;font-size: 1em;padding: .5em .75em;}}

Rearrange it

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.

/* >= 768px */@media screen and (min-width: 48em) {/* Hide the “skip to” */.go-nav {left: -1000em;}/* Move the nav up */#site-nav {position: absolute;top: -5em;width: 100%;z-index: 5;}}

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.

Jumping down the page to an anchor reference can be a little jarring. But with the help of some JavaScript, you can hijack a click on ‘skip to’ links to smoothly scroll the user up or down the page. Karl Swedberg’s Smooth Scroll plug-in for jQuery has served me reliably for this purpose.

Collapse it

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.

/* Hide the nav by default */#nav .nav_menu {display: block;height: 0;overflow: hidden;}/* Open it when JS addes the .open class */#nav.open .nav_menu {height: auto;}

Interestingly, without JavaScript, Starbucks leaves the nav open despite using a ‘skip to’ link as the tab. It could have accomplished the same UI treatment without JavaScript using the :target pseudo-class selector, as was done on Nichols College’s prospective student site. For more on Nichols College’s pure CSS technique, see here.

The Nichols College site, as well as being an excellent example of a JavaScript-less dropdown, shows the other option when it comes to this UI component: source order independence. Like Contents magazine, this site maintains all of its navigation at the bottom of the page and rearranges it as the layout adjusts. When the user is on a small screen device that supports :target, the primary navigation links move to the top and are hidden until the user clicks the ‘skip to’ link that triggers the reveal.

body:not(:target) #nav {/* these styles are only applied if :target and :notare understood (and the body is nottargeted, of course) */}

Convert it

Another popular mechanism for shrinking navigation on mobile devices is to convert it into a select element. The benefit of this approach is that it drastically reduces the space required for navigation, while maintaining a look and feel that is familiar to the user. It also places no limitation on the number or depth of navigation items. The downside is that using this scheme requires either a) converting a list-based nav to a select using JavaScript, or b) maintaining a hard-coded select in addition to a list for your navigation.

Five Simple Steps uses the latter approach for this technique. The style sheet manages which one is displayed based on media queries.

/* <= 767px */@media only screen and (max-width: 767px) {/* Hide the list */nav select {display: none;}/* Show the select */nav select {display: block;}}/* <= 767px */@media only screen and (min-width: 768px) {/* Show the list */nav select {display: block;}/* Hide the selectnav select {display: none;}}

If you decide to include a select in your markup rather than dynamically creating it with JavaScript, you will need to include a button to submit the form containing it (and have some server-side code to manage the redirection) – you can’t rely on JS to be available to trigger the page change.

If you don’t want that kind of hassle, you’re better off generating the select dynamically from a list in the markup using JavaScript. At least that way you know that JavaScript is available to handle the change event. TinyNav and Responsive Menu are two (of the many) JavaScript options out there for managing list-to-select conversion.

Reveal it

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.

#viewport,#page {position: relative;}.mSideArea {width: 260px;position: absolute;left: −260px;}

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.

.sideShowing #page {left: 260px;}.sideShowing .mSideArea {left: 0;}

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:

#page,.mSideArea {/* Insert prefixed versions here */transition: left .5s;}

As Facebook’s approach relies on toggling a class, it is JavaScript dependent. But there’s no reason you couldn’t use the :target pseudo-class (like the one employed by Nichols College) to accomplish a similar effect.

The decision is yours

There’s a host of interesting navigation options available to you when you are looking to adapt your designs to smaller screens. Each strategy has its own set of pros and cons, as well as dependencies in the form of source order, markup, CSS, and/or JavaScript support. Just keep in mind that there is no silver bullet; every project is different and every project’s needs are different. By taking a hard look at your content and your user goals, however, you should be able to identify the most suitable strategy.

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.