In defence of the hamburger menu
andybudd.com
andybudd.com
I’m only 24, but didn’t get a smartphone until pretty recently. The thing that bothers me the most about mobile UIs is how implicit everything is—there are very few affordances to indicate what’s even interactible.
For example, I would never have tried to swipe down from the top of the screen on Android to view my notifications unless I had seen it done before, or I had done it by accident. To me, that’s abysmal design.
I tend to see people in the West (of which I am a native) who completely discount their cultural preconceptions when approaching accessible digital design.
It might be less culturally specific than you think. You wouldn't believe how often Chinese people send me 。。。 in chat.
Universal glyphs versus culturally specific symbols, and glyphs should win every time imo.
There are no universal glyphs; they're all culturally specific.
Why show me something meaningless because native Chinese speakers don't grok it? Show me (US male) what I get and show them what they get.
But, really, I don't care that much about what character we use as a menu button; I just wish we'd settle on one, for consistency's sake. And, when we do show a menu button, it shouldn't become a "kitchen sink" kind of menu (looking at you, Chrome)-- a menu button (without specific text or a more specific icon) should house global navigation and functionality, with more specific functionality placed in contextually appropriate locations within your app, where the user will actually find them.
Every iconic web element is modeled after the standard for operating systems. Think close buttons, minimize, input fields. While ellipses is better, it's not good enough because it's a terrible practice to put actions out of sight. There is no icon that semantically represents "a group of various actions that are related" because for that we need words.
But you know what? Andy Budd knows that. So let's just call it what it is: a lie. My respect for the man has been lowered.
A VCR pause button is always in the same place - next to the play button. We don't know a pause button because of it's shape or color, but rather it's context. You know where to find it because the controls for our music and video devices are familiar. If you take a pause button and put it in any other context, it loses it's meaning.
The hamburger menu doesn't have context. It's different from one site to another - from shape to placement. The icon has no grouping - no play button. It doesn't work there's no icon that can visually capture and condense the imagery of a menu without context.
What ever happened to just "Menu" with a caret?
Now, your comparison to the hamburger menu does make sense, and I agree. However, the context for the hamburger menu might be "button that's alone" and it just means "menu." I can see that catching on.
Now if we took out all the stop signs and replaced them with a pause symbol with yellow and black text (thus erasing the existing contextual clues we use for stop signs), we'd see how clearly context matters to symbol recognition.
| | pause
|> play
|>|> fast forward
<|<| rewind
|>|>| forward 1 track
|<|<| backward 1 track
The context required to parse || as "pause" is just being in a context where pausing is possible. But we've accepted even less context-specific iconography for controls and navigation than even the pause icon; for example, why does × mean "close" when it's in the upper-right corner of a screen? It's fairly arbitrary, but — well, it means close, and it's not confusing. I think the hamburger icon in the upper-left corner of the screen is starting to (or already does) assume the same ubiquity: "main menu."
Hamburger menu is an abstraction. Part of the blame here is on operating systems and their branded menu's (think Windows Start or OSX Apple menu). There's no standard to it, which is why native apps are a lot easier to navigate because they conform to what the user expects. That fragmentation grows when you divide by the user's browser, device, etc. It's just not standard and not contextual enough to be a standalone icon.
why does × mean "close" when it's in the upper-right corner of a screen
This, yes. The 'pause' button has a single, unambiguous meaning: 'pause the current action.' The hamburger menu means 'display in some fashion an unknown number of things of an indeterminate nature.' The hamburger menu is evidence of a lack of design rigor, the kitchen junk drawer of user experience design. It's sometimes necessary, but never ideal.
And also, I've seen A/B tests show that users prefer MENU text.
Try entering "undo" on Google Translate and see what it looks like in Dutch.
At work we're ramping up a build on a huge mobile app, and we have a menu (though more accurately, the master of a split for those familiar with iOS UIKit). We've been debating how to represent the navigation item that a user will tap. Of course, we all started discussing glyphs immediately and quickly found ourselves in the weeds.
Enough times on previous rodeos led me to ask if we could think of what text to put in the label. Team floated ideas, no one loved anything. Now, at 1:30 a.m. on Saturday night.
MENU!!!!
The problem with the hamburger menu is that nobody taps on it. Novices and expert users alike, tap rates for the hamburger menus is universally dismal no matter which app you're looking at.
Which is to say, no matter how well-trained and knowledgeable your userbase is, if you want something to be clicked, do not put it behind a hamburger menu.
We can talk nice about the menu all day and call it "plucky" all we want, but the facts on the grounds is that the hamburger menu almost never gets tapped, and anything that is accessed via the hamburger menu is destined for the graveyard of little to no usage.
We can call the hamburger menu an emergent experiment, but it's been, what, 3-4 years since its first appearance? At this point I think it's safe to call the experiment a failure.
Why is that a problem? Hamburger menus seem to be a place for stashing things you don't expect people to need in most uses of an application, but which need to be around for the occasional need. And that's a fairly well-established UI pattern, so it should have a low tap rate.
Not everything that needs to be accessible in the UI needs to be accessed frequently.
Roughly speaking, users will look at all possible touches on the screen and score them based on relevance, and tap the highest scoring element. The typical use of a mobile app is effective a pathfinding problem.
The problem is that because of the inherent meaninglessness of the hamburger button, the hamburger button always scores near zero. Which also means that users will actually tap on things that lead them away from what they want before they touch the hamburger button.
A common pattern you will see when a user is looking for a less-used function of the app is that they will make several mis-touches first, tapping on things that do not lead to their goal, before backing up and trying the hamburger button. Effectively hamburger buttons will send your users on wild goose chases through your app because it is a UI of last resort.
Even when users are looking for obscure/miscellaneous functions of your software, they will look practically everywhere else first before looking under the hamburger button.
There are better ways to point users towards less-used functions of the app that
memorable: yes.
efficient and produces low errors: not relative to its predecessor on non-mobile devices. We've gone from seeking and clicking one target to two.
learnable: it could be, but people aren't trying to teach us the same thing. On some websites it means "navigation", on others it means "everything from the header". It may or may not contain account settings, it may or may not let you sign out. On ally.com it actually contains all available actions, with site navigation inexplicably hidden in a different, cog-icon menu. The net result is that I never have confidence that clicking a hamburger icon will give me what I'm looking for.
For UIs on larger screens, I see no advantage at all in hiding menu items behind a hamburger. It just results in hunting around for a tiny thing to click and making it harder for the user to reach useful choices. However, even on smaller screens, I still try to present a set of related options so they are immediately accessible if possible.
One obvious way to do that is having few enough choices that they can all appear together in a compact menu, possibly bumping minor choices down to the page footer or some other secondary position. Achieving this might require careful consideration of the overall design and information architecture, and possibly deviating from the way the same material is presented on other devices in style and/or prioritisation.
Another possibility that can work well in some situations is to distribute commands or navigation options throughout the page/app instead of collecting them all together in a menu. Web pages can hyperlink directly from body text or images instead of having to collect all their navigation links together at the top or bottom of the page. Sometimes UIs can similarly attach commands to specific places where they make sense.
If there really are too many essential choices to display them tidily embedded within the overall UI on a small screen, my next preference is usually some form of dedicated full-screen navigation. This might make sense for something like an e-commerce web site with lots of different categories, for example, or a business app that provides access to many different reports. With this strategy, I would probably try to have that navigation be the starting point for the UI or at least be summoned via some very obvious and descriptively labelled button.
Between those three general strategies and the occasional more specialised alternative, I don’t think I’ve ever had a hamburger menu make it into production on any project — including those where our first thought was that we absolutely had to have loads of options available so a hamburger was “obviously” the way to go. So far, I’ve yet to see or run any substantial usability test where a hamburger was more effective.
1. You have no idea what will be under it.
2. Most people don't explore.
3. Most won't memorize what they saw at any point.
4. It never has text underneath it, so you don't even know what it is.
5. The icon represents many solutions for many tasks, but you only have one task at a time. A pause button is the opposite: it's pureness of direct manipulation means you can find what you're looking for when you need it.
6. Pause buttons are even better when they have 'Pause' written underneath the symbol.
I'm not convinced it's bad for users. I can't think if a single place where I would not prefer the extra screen real estate.
Worse, I see apps that try to scale down to what they think is the "essence" of their feature set, only to be left with something that makes me say "screw this, I'll just use their website/desktop app if I can't do everything I need on the phone app"