Scalable Navigation Patterns in Responsive Web Design

by Michael Mesker

The subject of navigation in responsive Web design (RWD) is both exciting and challenging. Best practices are emerging for smaller, boutique-style sites, but for sites with larger anatomies, it’s still the Wild West, especially when it comes to migrating legacy information into a new design.

Here are some of the lessons we’ve learned working on a recent real-life, large-scale RWD project. Specifically, this post focuses on how we chose to deal with deep navigation in the landscape of a templated environment.

UM Departments Lede Image

Back in October of 2011, Palantir was hired by University of Michigan Medical School to design a system of responsive page templates for their departmental websites. The purpose of these templates were to help sell each department on the idea of migrating their content to Drupal. Historically, each department had been accustomed to a certain level of autonomy when it came to the visual design of their websites. As you may imagine, there was a distinct lack of "Michigan" brand consistency across the board. The challenge was figuring out an approach that was both templated and flexible.

The Palantir design team (consisting of Patrick Grady, Colleen Carroll, project manager April Peck, and myself) were excited to get our hands dirty with a large-scale RWD project. The intense focus on navigation came from the fact that each department did not have the same information architecture (IA). With all the Tweets, posts, and lectures about "Mobile First" and "Content First" buzzing around in our heads, this particular situation seemed far from one that would be ideal for the RWD approach.

We didn't really let that get us down, though. Ideals are nice, but these were real clients with real budgets and real problems. It’s our job to accommodate such scenarios. Apprehension turned into excitement at the thought of all of this. How could we build a successful, responsive navigation pattern for such a flexible IA?

How Many is Too Many?

After studying a dozen of the existing departmental sites that would eventually be ported over into the design system we were building, we began to look deeper, trying to find the outliers. Looking for examples of department sites that for whatever reasons were the edge-cases in terms of the quantity and depth of their navigation.

These edge-case examples helped to define the true needs of our flexible navigation solution:

  • Every item in the navigation structure would have an actual destination URL or landing page
  • The number of primary navigation items could not be limited
  • A single primary navigation item, could have upwards of 6 to 9 sub-navigation items
  • A single sub-navigation item could have 3 to 9(!) child items
  • A child item could have its own child items

In summary, our pattern needed to able to sustain up to four levels of navigation and be able to visually accommodate a wide range of child items.

Instead of thinking about the navigation pattern from a content perspective, we approached it from the next possible level. Simply seeing pieces as levels of primary, secondary, tertiary and child items. The pattern would have to make sense of these relationships, and present them to the user in meaningful ways across all viewports.

Can You Pass the Menu, Please?

Once we'd analyzed the edge cases, we began focusing on how this would all play out in the mobile and tablet viewports. After several bouts of sketching, we quickly vetted our initial concept with our co-worker, front-end Drupal developer Greg Leroux. While our approach made sense design-wise, we obviously wanted to make sure that it was sustainable from a Drupal perspective. He explained that by using Drupal's menu_block module, we would be able to visually reconfigure the menu system in user-friendly ways for each media query. This solution would also not place any extra burdens on the site administrator.

Overview of navigation pattern
Since this was a templated approach, the basic problem to solve was *where* a user would need primary navigation (blue), search (yellow), and sub-navigation (green). This approach was all about giving the user context in the tablet and mobile screens. There was also the issue of avoiding potential "swipe fatigue" in situations where a user may feel like abandoning the content they were currently viewing, and go elsewhere within the site. We addressed this by displaying the entire navigation menu in a sub-footer (orange). From a visual design perspective, this configuration kept the header height fairly slim, while maintaining the look and feel of the desktop site from viewport to viewport.

Browser Viewport
Since the number of primary navigation items was a known variable, our design could not logically sustain a horizontally oriented navigation area. Thus, the main navigation block was placed in the left rail. This vertical orientation was dead simple and scalable. Another known variable was the client's need for a navigation structure with an unlimited number of children. Since each navigation item had a destination, we chose to not reveal child items through flyouts or accordion menus. Child items were only revealed in the navigation block *after* arriving on the said item's landing page.

Primary and secondary navigation in the tablet and mobile viewports
For both the tablet and mobile viewports, the main navigation block becomes wrapped in a touch-friendly toggle menu labeled "Navigation", and placed next to the Search block. A user can open the menu and select an item from a scalable, vertical list of primary navigation. Unlike the main navigation block on the desktop version, this menu never displays child items. Child items are contextually served up and the end of the page's content, with a touch-friendly menu similar to the treatment of the toggle's navigation.

Swiping up or down to non contextual navigation
Should a user not be interested in browsing the contextual child items, they have the choice of either swiping up towards the top of the page to choose a new primary navigation item, or continue swiping down towards the global nav in the super footer, where again they can see every piece of navigation the site has to offer.

Learning on the Job

Navigation patterns for RWD is exciting territory that we as an industry are all still exploring. We were lucky to have a client who was willing to come and explore along with us. In our experience, higher education sites are never one-size fits all. The addition of a RWD approach seemed to amplify this. It’s the nature of the beast. Characteristically, different types of departments have very different needs. In the case of Michigan, these "very different needs" ultimately translated to designing a sustainable navigation system based on existing IA. By embracing this need at the very beginning of our process, we were able to steer the design system in the right direction.

Comments

Very useful article. Simple, clear, right to the point!
Not just theory, shows how to solve a real problem.
Thanks!

Looks great!

Has a department site made it to production yet? It would be great to see it in action.

I was just working on a small RWD site and have been thinking about different models for complex child navigation menus. Very interesting approach to put child navigation below the primary page content and limit top nag to parent items. Will have to see if that survives customer usability.

"Ideals are nice, but these were real clients with real budgets and real problems. It’s our job to accommodate such scenarios." Isn't that the truth! Great article!

My development company has begun recently working on some responsive websites. We ran into some of the same issues that you addressed in this article. I wish I would have read this before we started our projects as I think it would have helped us.

I also would be interested to see the final website if it is live.

This is a very interesting time for web design and development, advancements are happening so fast that it's getting difficult getting a grasp of things. Articles such as this makes it more manageable. A couple of years ago I wasn't even thinking about responsive designs and now not including it in the conceptual process may even cause you tons of headaches down the road and even to lose the project. Brilliant article!

Excellent article - thank you so much for sharing! Has this project deployed live? When I do a quick search for the top-level Medical School or many of the subdepartments (such as Internal Medicine as in your example), my mobile phone displays very different sites to the ones shown here. It would be great to see this work in action!

We're currently in the middle of a responsive redesign for a local government website with 8 top-level items, and up to 10-12 second level items (and then some...). We ended up going for something very similar for our tablet/mobile viewports, so it's nice to know we're on the right track.

Thanks, Michael! Our university is about to undergo a Drupal 6 > 7 migration, with multisites.

Navigation is something we are really wanting to get right, especially for our mobile devices. This article totally helps.

Hi, Michael! It’s nearly impossible to find knowledgeable people about this subject, but you sound like you know what you’re talking about! Thanks, you really have good information about designs.

I understand that hierarchical navigation would be the difficult part while trying to make the design responsive, but did you first look at any responsive CSS frameworks ? goodcause.in makes use of the skeleton CSS framework and while there are no hierarchical menus, it does scale beautifully with the minimum of the effort !

I am new to web designing. You have shared a very useful information about responsive web design. I have some problems with what you mentioned here as swipe fatigue. And is there anyway to avoid rescaling in responsive web design?