I get the point trying to be made here, but the whole premise of "learning" has quite an oversight on the tangible differences between a hamburger menu and a pause button.
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.
I disagree about the pause button. It works equally well without context. This is anecdotal, but I have seen it successfully used in charades to mean "pause."
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.
People keep making this argument, but forgetting that context exists in the environment as well. In the context of charades, you're playing a game. It's something that's ongoing.
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.
I also disagree about the pause button. It doesn't mean pause because it's next to play (that could never work; you need a different method to identify play!). It means pause because it has the pause symbol on it:
| | pause
|> play
|>|> fast forward
<|<| rewind
|>|>| forward 1 track
|<|<| backward 1 track
Lay them out in whatever order you want; people will get it. The important context is that you want to control the playback of something, not the order the buttons appear in.
Look at any music app, and you'll see that the pause icon does in fact have meaning absent of a neighboring play button: music apps hide the play button when music is already playing, and it's still clear how to pause. Many video players on the web show pause controls even in the absence of next/prev buttons, let alone a play button.
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."
Play/Pause as an on/off toggle is still contextual within the music app. The play button is always going to be in the same place, and the pause button not much farther away. Music apps have also started displaying triangles over the album art.
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
But even ignoring the counterpoint to the idea that a UI element must be contextual within some category to be understandable, the idea that the hamburger menu isn't a standard OS abstraction is also just silly. Hamburger menus are for mobile devices, and in your points you're comparing them with navigation used on operating systems meant for desktops. On Android — the most-used mobile operating system in the world — the hamburger menu icon is part of the standard toolkit, is built directly into their SDK, and is called out explicitly in their specs for Material Design.
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.
The lack of a standard back button on iOS is more irritating to me. That is functionality that needs to be used more frequently and shouldn't be left as a discoverable experience on an app by app basis.
I have no idea why, but the ellipsis menu (three dots arranged horizontally) calls to me a lot more than the hamburger menu (three bars arranged vertically). The one means "there's extra stuff here" and the other means "oh yeah, that's why there are no more goddamned controls here, they're hidden behind that thing". It's a mystery...
I agree. “…” has an established meaning of “et cetera” that makes me inclined to tap it for “more”. For a while I wasn’t really aware that “≡” was something I could interact with.
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.
You might consider that a hamburger menu indicates an abstracted graphical menu form, whereas an ellipsis is culturally specific and limited in its meaning.
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.
All I would say is I am more interested in reaching the many Chinese (and other people) who have no understanding of an ellipses than those that do. Those that do are already digitally literate and can suss a hamburger menu out, those that don't are facing an artificial barrier imposed by our cultural expectations.
Universal glyphs versus culturally specific symbols, and glyphs should win every time imo.
I think the ... represents "some other text that's too small to read unless you peek close", which can probably appeal to any culture that has horizontal text.
More importantly, "..." has (at least; I don't know the exact timing here) a couple decades of history behind it as an indication of "more stuff is going to pop up when you click this item"-- it was used to indicate that a menu item was going to open a dialog prompting for more information at least as far back as Windows 3.1 on the Windows side and System 7 on the Mac side.
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.
Yeah, the ellipsis is clearer but has a hard time standing on its own. I had no idea this was making waves in the design community. And while I don't necessarily agree with the complaints, I recall that when I first started seeing hamburger menus I was somehow viscerally opposed.
You're right that there is more semantic value in ellipses vs the three bars - however I think the problem is that there's no standard. Blame it on operating systems for branding their start menus because it needs to be standardized first at an operating system level.
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.
I'd settle for a universal shortcut key that activates the hamburger menu, just like the F1 key is used for Help. Ohh no... someone killed F1 AND Help when I wasn't paying attention!!!
For the longest time there was no way to disable that stupid F1 shortcut in MTGO. This was a problem because you were pressing F2 ("pass priority") on a more or less constant basis. If you slipped... up popped the tremendously annoying help page in your web browser.
I have a hard time with Andy implying that criticism of the hamburger menu comes from "young designers" sniping on Twitter. In fact it comes from many, many prominent UX writers like NNG, Luke Wroblewski, etc. looking at real data.
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.
I think he meant that young designers overstate the problem by saying it was "worse the clippy". I'm sure these folks you mention aren't so overstated.
The iconography of the menu is one objection but I think the author is missing out on a subtler thing here. The other objection is that paths within your application should flow seamlessly enough to remove the need to have a place to dump all the "extras".
I hear this a lot, and I think it's wrong. Sometimes you just have too much information to fit on a phone screen, but which should still be available. For example, I see people argue for tabs, but if your app fundamentally has a lot of choices you're left with an overflow tab which if no better.
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"
No. Everyone knows the meaning of the pause button (and the others), because the word "pause" was written above or below the fucking symbol on VCRs, tape players, etc, for DECADES. So no, manufacturers didn't just beat consumers over the head with it to the point it became learned.
I can get on board with the idea that the hamburger is bad for developers because we want our users to use our app a specific way. If the button is in their face, they are more likely to click on it - makes sense.
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.
I really don't believe in the use of the hamburger menu. You can just as easily have the word "menu" in the same amount of space. For something as critical as a main menu, why introduce any possible confusion.
I guess I'm betraying my age here. In a previous incarnation of Windows, they actually put the word "start" on the OS menu for people who were less computer literate. They even got the rights to "Start Me Up" by the Rolling Stones for commercials. No joke.
I have, and still prefer text. More users figure it out. Sometimes the text will be long and you have to design around it, but I'm pretty sure MENU in Dutch is still MENU.
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.
I like how the Foundation tutorials have the hamburger button with the word "Menu" next to it. That's how I've implemented it on all my recent websites. It's not that much text and removed ambiguity.
The problem with the hamburger menu isn't that people don't know what it means - it's been around long enough that most users know what it means.
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.
> 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.
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.
Because the overwhelming observed pattern for users is that they want something, and they will tap on the thing on the screen that appears most likely to lead towards the goal.
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
What about the thousands of sites and apps that store the entire navigation menu behind a hamburger menu button? If no one clicks on it, that's kind of an issue, since people won't leave the site/app front page.
I find hamburger menus a bit like pie charts: they’re popular in some quarters, but they have some significant drawbacks and the vast majority of the time there is a better way to do the job.
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.
I like the given definition of usability, but I wouldn't score the hamburger menu as the author did.
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.
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.
54 comments
[ 3.5 ms ] story [ 115 ms ] threadA 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.
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.
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.
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.
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"
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.
https://youtu.be/5VPFKnBYOSI
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
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.
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.
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.