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 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.<p>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 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.<p>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.<p>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.<p>What ever happened to just "Menu" with a caret?
I strongly disagree with this, and use the word MENU every chance I get. Because always bet on text: <a href="http://graydon2.dreamwidth.org/193447.html" rel="nofollow">http://graydon2.dreamwidth.org/193447.html</a><p>And also, I've seen A/B tests show that users prefer MENU text.
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.<p>The problem with the hamburger menu is that <i>nobody taps on it</i>. Novices and expert users alike, tap rates for the hamburger menus is universally dismal no matter which app you're looking at.<p>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.<p>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.<p>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.
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 like the given definition of usability, but I wouldn't score the hamburger menu as the author did.<p>memorable: yes.<p>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.<p>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.
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.
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.<p>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.<p>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.<p>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.<p>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.<p>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.
Complete disagree.<p>1. You have no idea what will be under it.<p>2. Most people don't explore.<p>3. Most won't memorize what they saw at any point.<p>4. It never has text underneath it, so you don't even know what it is.<p>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.<p>6. Pause buttons are even better when they have 'Pause' written underneath the symbol.
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.<p>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.
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 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'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!!!