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.

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.

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.

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.

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.

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.