I still don't get all of the blind basement menu hate. It serves a useful task for providing secondary functions that don't need to be accessed all of the time. User engagement is a weak argument, since the core app offerings should always be front and center, regardless of the nav structure you choose.
This article is also very iOS-centric. Google, on the other hand, has doubled-down on the hamburger menu for core navigation in Android (and if they test 41 shades of blue, they probably tested secondary function accessibility). Facebook's Android app still uses a basement menu, with the hamburger icon in its traditional spot. Facebook for iOS uses the same pattern for hiding secondary navigation – they just moved the icon to the iOS-conventional navigation location.
Not happy with these articles
"We now have the data to back the fact that Sidebar Menus — sometimes called Hamburger Menus/Basements, are a bad design pattern."
This is based on test results on really small websites and apps. Please, don't generalise your statement when your assertion might only be valid for specific cases.
Understand the concern and thanks for reading. The linked article are just the public data I've found on the web. I've conducted user testing sessions demonstrating the same results. Cheers!
There might be some very rare occasions where this pattern actually makes sense, but the general rule is to avoid it altogether.
The solution is reviewing your information architecture.
Ugh. I feel like people who bash hamburger menus (on mobile, at least) haven't actually worked on a huge project and tried to practically solve the problem in a different way. A lot of times you can't break down the IA enough to fit in a tab bar. Or the space where a tab bar would make sense is reserved for another type of function. Or certain top-level sections are significantly less important. Or, conversely, all top-level sections are equally important so putting only 4 on a tab bar with a "more" button also doesn't make sense. Or using a table view interrupts the experience because the user has to choose a section before seeing any content, and still requires the same amount of taps to access other top-level sections.
I usually don't like hamburger menus on websites where there's significantly more real estate and possibilities for more creative approaches to navigation. But on mobile—and I've argued this before other times it's come up—I think it's a perfectly valid solution. It's used so often, in fact, that Android has a built-in hamburger menu that's found in their design guidelines. Obviously it's up to designers to choose the best pattern for the IA that they're working with, but if that IA has many (6+) top-level items which are either equally weighted, or one is significantly more important than all others, it can be very challenging to find a solution that's better than a hamburger menu. Avoiding a valid pattern based on anecdotal evidence is just silly.
I appreciate that this article attempted to suggest at least one alternative solution. Usually these pieces don't bother.
But on webpages, when you've got a lot of sections, I still haven't seen alternatives to the hamburger menu and wish there'd be more attention to solving problems.
They cite Time.com as doing it wrong, but what would they have them do? A scrollable Tool Bar? Would that really work?
That's usually how these pieces usually leave me: "what about sites that need it?". All these posts are chocked full of choice examples when not to use it, but no one talks about when it's appropriate.
On my site, I'd prefer the common user never bother with the menu. The entire site, our blog, our mobile presence, exists for a single business reason. If I've got the option to drive them to convert or drive them to explore, I'd rather drive to convert. Hide things that will distract from a conversion, even if those things are other pages, the blog, etc.
During our launch, I watched GA Live, and we consistently had more people in the "comparison view" (our business goal) than on the index page. That's a huuuuuge accomplishment that was only possible by downplaying the user's options to move around the site.
Weird and scary sounding, but it works for some. I know I'm at the extreme end of the spectrum, but I suspect that the other extreme end needs the hamburger menu too (when you've got more options than you could ever hope to present cleanly). Only those in the middle are suffering, the sites/apps that have 8 views and that want every user to see every view.
You're correct, I could've focused a bit more on the web side of things but as you noticed I work mostly with iOS.
Regarding the Time example on the web, they use the hamburger menu even on large desktop screens where space isn't as constrained. Their labeling of the icon a tutorial seems to suggest they might've encountered issues with their users.
I'll update the article with my suggestion in this case which is to simply present all options as a list in the page header.
If I ever have to add more sections to my website that's the pattern I'd use. As long as it's clearly identifiable as navigation, people do scroll past it into your content.
Let's not forget desktop's last attempt at complex menus, which was the mega-mega-dropdown. I feel like everyone gives the hamburger a hard time for not working, while simultaneously admitting how terrible the previous attempts were.
Glad someone is putting thought into it!
Thanks for reading and you're right, web pages demand a slightly different solution, I'll update the article with my proposed solution which is to simply list the navigation items in the site header.
The problem with Time is that they're using the hamburger menu even in the desktop where space isn't as restricted, and their labeling of the icon plus the tutorial seems to suggest they might've had issues with their users not engaging with it.
Thanks! And I agree: RE: desktop.
To be clear, your suggestion above is for mobile, too, though? Not just desktop?
A comprehensive writeup with loads of examples of problems and solutions.
Good sunday reading... thanks. My take away is still that criticism to this design pattern is related to it's misuse on news feed UI's which would be better served by tab bars and a more linear IA in general.
I think the article reinforced my view that for more "information rich" enterprise type apps which present more than five (5!) sections, the tab bar "more" feature isn't necessarily better than the hamburger slide-to-reveal. Our app's users were rarely selecting the "more" button, and were not using the "edit" feature to customize the tab bar at all.
Oddly, I think this discussion about avoiding hamburgers is more about being too quick to dismiss the value of tab bars as "short cuts" to key content.
How wrong are these articles nowadays. Hamburger menu is not useful on website with more than 5 sections and those sections doesn't have really deep subsections.
It's easy to talk.
Also, this person claims "data" and links 3 places where it was tested with negative results.
Nice! It's true, it makes life so much easier for us designers when we can just stuff everything away into the hamburger (I too am guilty... ehem.), but focussing on the iA early on can really help avoid using shortcuts.
tldr: stop hiding necessary shit.
This is a challenging article (in a good way), especially for me as a proponent of the sliding nav pattern.
However, I think we should keep things in perspective. Design is about intent overall and our decisions should communicate that. With that in mind, I like this quote from theNextWeb article that is linked:
My take-away from all of this is that if most of the user experience takes place in a single view, and it’s only things like user settings and options that need to be accessed in separate screens, then keeping the main UI nice and clean by burying those in a side menu is the way to go.