Filed Under: Front-End Design
The hottest hot-button issue in responsive design is how to design navigation menus. That’s what the Hamburger Icon Flame Wars of 2014-15 are about: how do you put a large navigation menu into a tiny, phone-size window?
Whatever you’re doing, you’re doing it wrong. That’s the consensus answer, at least. Instead of dumping my opinion into the hamburger-icon flame wars, I’m going to offer some practical advice on how you can create responsive navigation menus that are a little less wrong.
This is one of the foundations of mobile-first design: if you don’t need something on your small-screen view, you probably don’t need it on your large-screen view. Slimming down your navigation will give you more room to work with on your small-screen view, and it will likely make your navigation more, well, navigable on all screen sizes.
Don’t just go deleting things, though. You probably don’t have a navigation full of unnecessary links, and people still need to navigate your site. Instead, look for things that could be moved elsewhere. Do you have an “Employment” tab in your main nav, but no open positions? Move it to your footer. Do users only access your President’s Cabinet page after visiting the President’s page? Take the President’s Cabinet link out of the main nav and put it somewhere visible on the President’s page.
It’s best to minimize in moderation. I use images in the navigation at cptc.edu, and they’re not necessary — but they get results. So I keep them.
Site navigations tend to fall somewhere between “This is just a fallback for people who’re looking for something weird” and “You’re not getting anywhere on this site without using the navigation.” This is fine. Cptc.edu falls closer to the fallback end of the spectrum — if someone’s not looking for something specific, I prefer to steer them toward the items on our homepage, e.g. enrolling, visiting, checking out or programs, reading our stories, and so on.
On the other hand, on our online catalog, the navigation is the whole point: without the navigation, you’d just be reading the welcome message. Thus the navigation takes up most of the viewport on small screens.
If your navigation is toward the fallback end of the spectrum, hiding it behind a menu button of some sort might be advisable. But if it’s crucial to what users need to do on your site, it’s best to let it take up more space and not hide it behind anything.
This is just basic UI, but it’s easy to forget when you’re designing navigation: if something’s important, make it look important. I love how Seattle Central College highlights the big-ticket links in their nav with icons — it’s nice looking, and it drives traffic where they want it to go.
Sometimes with navigation we can end up in information-architecture mode and try to give everything equal weight, but even something as simple as putting your most visited link at the top of the list can make things way easier on mobile users who have to scroll to see the whole nav.
In this option, you basically have two separate menus in your HTML: your small-screen menu and your large-screen menu. You hide the large-screen menu for small screens, and vice versa for large screens. Easy enough, right? They can have totally separate CSS, they can include different items, and so on.
The only real issue with this approach is a maintenance one: whenever you changes something — add a menu item, correct a misspelling — you have to change it in two places, which gives you more chances of making a mistake. If you’re using a CMS, this isn’t that big of a deal. In WordPress, for example, you’ll probably just be using PHP to spit out your menu in two different places, so when you add or change a link it will automatically update in both places.
The other issue with this approach is that it introduces a bit of bloat to your file. I.e., you have two sets of HTML when you (possibly) could’ve just had one, and your page is thus slightly heavier than it should be. HTML usually isn’t the heaviest item on your page, so even if you’re duplicating your entire nav you’re probably only talking around 5kb — unless it includes images — so this isn’t the biggest issue, but it’s something to be aware of on your journey to Total Speed Optimization.
This is what most people default to for simple navigation. If you’re only dealing with a few navigation links — like the site you’re looking at right now — you can change basic CSS properties like floats, padding, display, and position and totally rearrange the menu. Want it in the upper-right corner for large screens but in a bar beneath the logo on small screens? You’ll either have to just adjust the width and float at your breakpoints or — if you’re a cool flexbox person — just change the flex properties.
When you get to a more complicated navigation, though, this gets way tougher. What if you have dropdown menus? What if you have subcategories within your dropdown menus? What if you want a totally different logo for your large-screen view? Can little old CSS handle all that? Is it even worth it?
If I led you to believe this was going to be one of those “whatever works best for you is the right answer/you’ll probably end up doing a mix of all three of these” blog posts then you were mistaken. Because I have a STRONG TAKE: Option 3 is the best. Use CSS to rearrange your navigation, even if it’s a hugely complicated navigation. And if it’s so complicated that you can’t fathom how to solve the problem with CSS, storm into your boss’/the client’s office and let them know that their unwieldy navigation is a disservice to users and makes it nearly impossible to properly separate content and display as God himself intended. (Don’t do that — if your boss/the client wants incredibly complicated navigation and you absolutely can’t do it using CSS, just use Options 1 or 2 and do it the best you can. That’s your job, probably.)
If you don’t follow my advice, you are probably a bad person.