Different Navigation for Different Screen Sizes: Your Options, and a Recommendation

June 22, 2015

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.

Some General Principles for Designing Responsive Navs

1. Minimize

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.

2. Figure Out How Important Your Nav Actually Is, and Give It Space Accordingly

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.

3. Highlight Important Items

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.

Your Technical Options for Designing Mobile Navs

Option 1: Separate HTML for Different Screen Sizes

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.

Option 2: Use Javascript to Rearrange Markup

If you don’t want to duplicate your markup, you can use javascript to measure the screen size and then rearrange the markup accordingly. For example, if your large-screen navigation needs the search at the top of the screen, but your markup has the search bar after the main nav — because that’s where your search bar is for small screens, and your markup is mobile-first — you can drop in some javascript that detects the screen size, then, if it’s a large screen, appends the search bar to the top of the list.

This is not a terrible way to do things, if you know your way around javascript. If you’re a basic jQuery-level developer — which is totally fine! Don’t let the js nerds tell you differently — you will probably run into some issues with this:

First, you’re not going to want to run this sort of javascript after the document is ready — that means you’ll be rearranging the page in full view of the user, which is unsettling. But you also don’t want to just drop all your javascript — including the full jQuery library — at the head of the document, because that slows down your render time unnecessarily. You’ll probably want to write a short chunk of vanilla javascript that runs before the document renders, which will be a small file that won’t block rendering, but you’ll need to do it without jQuery.

Second, you’ll need to have a good way to include your CSS breakpoints in your javascript.

Third, you’ll have to deal with window resizing. Do you run your rearrange-the-menu.js javascript every time someone resizes the browser window? To do that, you’ll want to throttle or debounce so that the script doesn’t run constantly while the user resizes. Or you can just say, you know, anyone resizing their browser is probably a web developer looking for flaws in my design, so I hope the navigation gets all messed up when they do so.

Again, all of this is totally doable and inoffensive if you’re comfortable with vanilla javascript.

Option 3: Use CSS to Rearrange the Menu

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?

A Recommendation

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.)

I prefer Option 3 because even if the CSS itself gets complicated, everything else is simple. And how complicated can CSS alone really get? With Options 1 & 2, you’re still dealing with CSS — you’re either dealing with CSS and two sets of HTML markup or with CSS and javascript or (sometimes) CSS, two or more sets of HTML markup, javascript, and the server-side language that’s producing your HTML markup. No matter how complicated your CSS gets, dealing with CSS applied to a single instance of HTML markup is simpler than any of the other options. And it’s extremely likely that option 3 will be the fastest/lightest way to go.

If you don’t follow my advice, you are probably a bad person.