Lately, I’ve been getting a lot of work regarding broken navigations and making sites that weren’t originally responsive into responsive sites. Frequently, I see clients with sites that are already responsive, but have custom navigations that aren’t performing to expectations as the site has grown. Because I’m seeing so many responsive navigation issues of late, I wanted to throw out my general strategy for building, or re-building, navigations. I say “re-building” because, when adapting an existing custom theme, or building a child theme, that involves making a site responsive, I find that pulling out the existing navigation and simply re-building it is the most time-effective method.
Mobile When?
To begin with, a caveat: When I’m designing from scratch, I design desktop down, not mobile up. I know many colleagues that would call this heresy, but there you have it. It’s easier in my mind to organize what information is critical for the page this way. So, with that in mind, the organization of the desktop navigation comes first. Spinning off of this somewhat loosely, I’ll confess that I’m not a huge fan of drop-down navigations. I think that they’re confusing to the user, and should be used sparingly. That said, there’s frequently enough content and good enough reasons for the client to justify having them, so it’s critical to expect them when designing. Even when they’re not included in the original design, the client may add them later, and I don’t want them in a position where they have to call me to include something that should have been included to begin with.
JavaScript. It’s Awesome, But…
This comes down to a philosophical decision, I suppose, but my general rule is that, if I can do it with CSS, then I’m not going to use JavaScript. When I’m building a site from the ground up, I build drop-down navigations with CSS transitions. Because the overall styling of the navigation items is essentially the same, and it’s only the action of the drop-down that is different, this is actually quicker to develop in my experience. Also, most JavsScript drop-downs have CSS fallbacks anyway for the purposes of graceful degradation (such as the popular Super Fish jQuery plugin…believe or not, there’s no CSS fallback in Bootstrap), because having access to the pages of a site dependent on JavaScript being enabled client-side, which we can’t control as developers, is just a bad idea.
So, for an idea of what that looks like…starting with a basic navigation with drop-downs:
The styling is very simple:
Phone Breakpoints? That’s Easy…
Basic rule of thumb: the navigation becomes the full width of the screen, including all of the individual list items. I then add an indicator to the top level items that have sub-menu items. You can hard code these in and display them with media queries (although that’s not flexible code to hand off to the end user), but I recommend adding them dynamically, either server-side or on the front-end with JavaScript. That’s what I’m doing here, using Font Awesome classes to add directional arrows as content:
Now, I custom build a hamburger button (that takes 30 seconds in Photoshop), adding this above the main navigation, and display it with media queries only for phones. Now, Javascript does generally come into play for me. I bind a click event(which serves perfectly well on a touch for this particular application) to the hamburger button’s element, and slide the main navigation down and up on touch.
I’m not concerned about an overwhelming majority of smartphone users turning of JavaScript on their mobile browsers (the last statistic I read indicates that less that 2% do so), so graceful degradation stops being a concern for me, here. Similarly, I use JavaScript to bind click events to the indicators for sub-level menu items to slide those down and up. To make this look really clean, I recommend using icon fonts, and swapping the class on the indicator to change a downward-facing arrow for an upward-facing arrow on touch. So, using Font Awesome again:
Clean up the positioning of the navigation overall in regards to the header, and, voila…you have a mobile navigation.
Tablets. That’s the Tricky Part.
Why are tablets tricky? I suppose it depends on your point of view. I think that the desktop visual experience should be kept largely intact on a tablet. For that reason, I don’t like placing the hamburger navigation in tablets. This isn’t a hard and fast rule: I’ve done it, and I’ve certainly seen it work well, but this is just my initial approach. So, the trick becomes…how to handle the hover events that trigger the CSS down-down navigations on tablets? Again, because I’m generally not concerned about JavaScript being disabled on a tablet device, I handle this issue with JavaScript. The trick is to convert the hover event to a touch event while preventing the top level item link from clicking through, then following the link on a second touch. If that’s intimidating JavaScript for you to write, here’s a great starting point.
Every Project is Different
As I’ve said before, every project has it’s own DNA, so there’s no such thing as a one-size-fits-all solution. Still, this approach, or a variation of it, has served me well on many projects. I invariably run into edge cases involving re-sizing events on desktop browsers, so I recommend getting Modernizr involved early, because customizing each project is much quicker when you can easily test for touch. Let me know what you think.