Select menus simply sweep navigation issues under the rug. They don’t help solve questions such as how to handle long lists or nested sub-navigation. I suspect they’re confusing to users too. In my mind there’s only one form element that should ever be used for navigation and that’s search.
And elaborates on giving up control of the design:
Then there’s the issue of design. While iOS’ select menus keep the user somewhat connected to the page behind, Android’s overlay device makes navigation a separate layer. Window Phone 7 takes navigation out of the site and into native Metro UI, completely disconnecting the page from its navigation. When you use select menus, you put navigation design in the hands of the operating system designers.
Put all this together and using select menus for small screen navigation isn’t just a bad option, it’s a lazy one. Let’s design something better.
Let’s design something better. I’ll drink to that.
On a side note: I fucking love the internet for making these conversations possible across three countries and two continents. I definitely have to write more.
I’ve been thinking a lot about navigation in responsive designs lately, so when Brad Frost wrote Responsive Navigation Patterns a few days ago I thought I’d write down some thoughts on a couple of the methods he talks about.
Ultimately, mobile navigation should be like a good friend: there when you need them, but cool enough to give you your space.
The Select Menu
My main argument against it is that it feels awkward. I don’t think form elements should be used for navigation. We don’t use it on the desktop, why use it on mobile? But maybe it’s mostly a personal preference, I realize it solves the problem by keeping the navigation first while saving screen real estate.
One disadvantage though, is that it takes a few gestures to use. On an iPhone you first need to select it (1), scroll to the item you’re looking for (2), select it (3) and then hitting Done (4). From what I remember the interaction is the same on Android and other mobile OS.
I agree that this is probably the most elegant solution. At least for sites with just a few navigation item it’s probably the best solution. But if you have subnav items it quickly becomes more problematic. The problem is that I haven’t found an intuitive place for subnav items. In most cases you don’t want to show them initially when you toggle (the entire nav expanded), you could add toggles for each subnav too, but then it’s not that elegant anymore.
Once you have clicked/touched a nav item and landed on the page it isn’t obvious that you need to toggle the navigation again to find it’s subnav. And adding the subnav before the content don’t work well either since height matters and placing the sub-nav in the footer separates the topnav from subnav.
The Footer Anchor
This is the method we’ve gone for in most projects and I think it works pretty well (take a look at unicef.se for example). Allowing the navigation to take more space lets you design clear, large and tap friendly navigation items. You can also add toggles to each subnav without making it too complex. It also follows content first, navigation second recommended in Mobile First.
“Danish architect Bjarke Ingels rockets through photo/video-mingled stories of his eco-flashy designs. His buildings not only look like nature — they act like nature: blocking the wind, collecting solar energy — and creating stunning views.”
“You might almost think that the whole scheme had been cooked up by a bunch of hyperintelligent but hopelessly socially naive people, and you would not be wrong. Asking computer nerds to design social software is a little bit like hiring a Mormon bartender.”
“That is, I believe in the potential of natural user interfaces (NUIs) to push us toward a new era of computing. NUI principles—such as make content the user interface; enable direct interactions with content not chrome; and reduce visuals that are not content—drive us toward a more direct way of interacting with digital information and media.”