I think the point was not to use the hamburger as a "catch-all". It's easy to just chuck features in there without thinking about how the users will truly interact with them.
The point I took away was that menus should have logical, semantic purposes, and common functions shouldn't be buried inside them.
It shouldn't be the only thought you have. The pluses are that people are used to it; sometimes common usage is better than inventing something unusual. But design should involve thinking about what people are trying to do with your app rather than starting with some design idea.
Anecdotally, I don't use a ton of mobile social apps, and the first time I encountered this icon I thought it was some weird play on an equals sign. Never occurred to me it was a menu. Now my own dev team is using it and for some bizarre reason I cannot convince them to stop.
It is almost always preferable to have all of your options available to the user at all times. However, it's very important to make the distinction between apps and websites when talking about a hamburger menu.
A tab bar is great in an iOS app with a limited scope of functionality. That just doesn't work a sprawling news site covering dozens of topics. A small, product-focused website may even be able to get away with showing all of their navigation options at once. For many sites, however, it's unfortunate, but sometimes you just need a well-organized junk drawer inside a hamburger menu.
But there's almost always a better way to present it to the user. If I'm viewing a news site, I'm not going to think that the hamburger menu is where I go to find the Lifestyle section. If you absolutely must hide your sections behind a menu, there are practically infinite different menus that make more sense.
The hamburger menu only makes sense when it's the literal junk drawer of the app/site, when there's no possible way to categorize its contents with anything more than the completely generic 3 horizontal bars. But primary navigation elements are not junk and don't belong there.
This a a little hyperbolic. If you want surface a link to the Lifestyle section, then you also have to accept that links to about a dozen other sections need to be visible as well - on mobile, this would lead to about a third of the visible page (or more) being consumed by navigation links. Alternatively, you put the nav at the bottom of the page, but I would argue that doing so makes it less accessible/visible than it would be in a hamburger menu.
The real challenge is not when you're trying to put 3-4 links or nav-groups in a hamburger menu, but when your site structure is so flat/shallow that you have a dozen or more equally-viable nav/action options for users. Except for the NBC example in the article, the nav in the examples can be distilled into a narrower, deeper structure.
The article author doesn't appear to realize that on NBC news, the hamburger-equivalent "more" menu still appears at mobile widths. Sometimes it really is a decent solution.
You seem to have completely missed the entire point of my comment. In no way am I saying that a news site needs to have a link "Lifestyle" visible to the user at all times. In fact, you quoted directly from the most relevant point, the bit that says that there are practically infinite different ways to design a menu that avoids the problem of the hamburger.
As a trivial example, you could have a single menu labelled "Sections" with a disclosure arrow, and mousing over / tapping it would then reveal a list of all sections. It's functionally identical to the hamburger in actual usage, but because it's called "Sections" (and only contains sections, not arbitrary junk), it becomes an obvious thing for users to interact with if they're looking for the Lifestyle section.
> You seem to have completely missed the entire point of my comment
This is a little hyperbolic. You've basically recommended a labeled hamburger menu - 'Sections' instead of 'Menu' - and text labels definitely have a demonstrable advantage over icon-only buttons, but the OP isn't advocating for text labels instead of the hamburger icon (see NBC example that had a labeled hamburger menu originally), it's proposing that the menu items be surfaced into tabs, segmented controls, and lists. That's not viable on sites with a flat structure.
nytimes.com uses the hamburger icon with the 'Sections' label, as you suggest, but it's important to acknowledge that this is just a variation on the theme, not a complete rejection of the 'menu items hidden behind something else' principle, so we need to be precise about the problems that a hamburger menu can and can't solve.
It's not just about labelling, it's also about not putting everything into the same generic menu. And I completely agree with the original article that anything[1] that you can pull out of the menu entirely and turn into a top-level element, you should. But freshyill's comment was specifically about large sites, such as news sites, that have too many elements to put them all at the top level. And in the context of that, I'm saying that the hamburger menu is still the worst solution you can come up with. If you must hide things behind menus, group them in a way that makes sense, with a label that tells the user immediately what the menu will contain. If the user has to actually open the menu to find out what's in it, then you've already lost, because it means the user won't know to click on that menu when searching for a thing that happens to be in it. For a news site, if the user wants the Lifestyle section, they'll probably understand that clicking on a menu named "Sections" is likely to give them what they want (or perhaps clicking on a menu labelled "More" right next to a few of the most popular sections such as World News). What they won't figure out without guessing blindly is that a menu with an icon of 3 horizontal stripes is where they can find the sections list.
So basically, what I'm saying is that if you must use a menu, label it appropriately, and only put relevant items in that menu. If you have a bunch of things that aren't related to each other, they should be in different menus. A real hamburger menu is only appropriate for items that the vast majority of users are expected to never click on, and for which you're ok with making it hard to find for the rare user that actually does need it.
[1] Well, anything that you want users to actually click on.
This is a big part of the problem. Devs too lazy to use media querys to adapt the layout to the screen. We end up with poorly implemented "mobile" sites on our big, wide desktop screens. It's like the web took a step back to 1995 with pages hardcoded for 640px width. Looks good on my iPhone... time to deploy.
A hamburger menu that can be optionally converted to a persistent sidebar on screens with sufficient space would alleviate much of the usability problems.
Practically anywhere else. If I really wanted to find it, I'd probably eventually click that hamburger menu, but the only place that I'd be even less likely to look for it is the footer of the page.
In a mobile app it makes a lot more sense, because screen space is so limited and the hamburger button will occupy one of the prime navigation points in the app UI (typically the upper-left or upper-right navigation button slots), so there's obviously not very many possibilities to find something, but even there, if you can possibly avoid using it, you should. As the original article demonstrates, hiding your navigational elements, even on mobile apps, significantly reduces user engagement.
In a desktop website, I can't think of any reason why I would ever use a hamburger menu. Other, more specific menus, sure (e.g. "Sections" in a news site). But if I see the hamburger menu, besides thinking that it's really out of place when not in a mobile app, I also will instantly assume that it's the place to find things that I probably will never need. Basically, if it's something that you might put in the footer of your site, then hiding it in a hamburger is fine. If you think it's something that enough users will want such that the footer would be inappropriate, then don't put it behind a hamburger either.
I keep reading these articles about how awful hamburgers are but so far not a single one addresses menus that have more than 3-5 items. I manage sites that we have kicked around ideas for how to deal with the menu better, but the size of what is in that menu makes all the proposed ideas I've seen not feasible. So I'm right there with you that it is unfortunate, I wish these articles had more in way of solutions than just regurgitating what we've heard for a while, hamburgers suck.
Somewhere along the way I realized that design skill has as much to do with making convincing business cases for simplifying your business offering as it does with what design patterns we use. Approached this way, these types of articles help in the same way software design patterns do: perhaps refactoring the code will improve the smell, but its also possible we have an unnecessarily complex business problem ("50 more news categories than anyone will ever actually browse through", for example), and we need to make a case for simplifying the architecture.
This is an important point. You contribute most as a designer when you control or influence whatever is necessary to get to good design. In most cases, the largest levers of influence are not in which design patterns you use, but in the business decisions that make things simple or complex.
In retrospect, I should have clarified what I meant by recommending the 3- to 5-item menu in the article; I was assuming the need to consolidate the menu to that many items on mobile, even if it wasn't so consolidated on larger views. There many need to be a "junk drawer" as others here have mentioned, or maybe those secondary items rely on navigation in the content itself.
I think the best practice might be to pare down the navigation to the most important items, so at least those have visibility in a mobile context. However, these are still new design patterns being established, so nobody really has solid answers yet.
I'm gonna sound like an old fart now (mostly because I am) but back in the late 90s we used to have a discipline called Information Architecture that existed to handle exactly this case.
You see, Information Architecture has more to do with capital D Design, not fad, bandwagons and styles. Its about solving this exact problem. I really hope the concept of User Experience dies in a fire so we can go back to real Design.
(User Experience is in my opinion the most nebulous, snake-oil concept I've heard since SEO. Users don't want "an experience". They want to get in get what they want and to get out. The experience should be invisible)
You can redef UX to mean something bad, but it's obvious that it is supposed to be UI + how stuff works instead of just the graphical part. Also, X's are sexy. Even that big rocket company decided to just take Space and put an X on it.
SEO might have plenty of snake oil vendors, but it is, unfortunately, a very real and immensely lucrative thing. Search engines drive traffic, which drives money. Search engines are gameable. End of story.
OK, so what does IA have to say about this problem? From what I remember about it (my course didn't have it, but I read a bunch in the early 2000s), it was more concerned about the overall organization of the information over the pages, and not with the specifics of how a menu should be formatted.
By the way, it's not "an" experience, it's "the" experience, and nobody would agree more with you about it being invisible than the coiner of the term UX - after all, Don Norman's seminal work (The Design of Everyday Things) was all about designing stuff to be more intuitive and fast to use.
I'm not so sure UX can be dismissed that easily. IA deals with content hierarchies rather than things like "navigation efficiency" details or site registration journeys, or touch interaction behaviours and optimisation.
There's cross-over, but one "Designer" can't do it all, even if they have a good grasp of everything.
When the focus is on UX, decisions might be made about how people sign in or out. The UX expert might determine that a 2-step log out process is one step too many, but the research they gather might suggest it's nevertheless still acceptable enough to get away with. The designer makes whatever-step process look and function the best it can, without needing to scrutinise the research and testing around 2-step sign out processes.
Another example - consider the user experience of dismissing the banner that appears on some websites that have an app in iOS Safari. The little 'X' close link is tiny, way smaller than any touch button or link should be. Bad UX? Sure is. But the UX person must have data suggesting that having a stupidly small close button for that banner is worth it for the primary visual incentive to act on the promotional prompt without annoying too many people (annoys the hell out of me, but I'm not everyone).
Perhaps the term IxD (Interaction Design) would sit better with you than UX. IxD includes UX but also Info Architecture and has a lot more to do with structuring information before any 'design' takes place. In IxD you wouldn't normally touch on users or appearance (affordances for example is far off down the road at this point) before you sort out the "what is it?" and "what data?". It's very easy to start thinking about the users, too easy in fact, that many self-proclaimed 'UX-experts' focus on that and forget that 'content is still king' and it's presentation may actually attract users, so don't try to tailor shit to maggots when you can create a garden and attract bees.
> That just doesn't work a sprawling news site covering dozens of topics.
Then have a menu named "topics" (or whatever marketing says to call areas of news). Still makes more sense than a menu whose icon means nothing more than "this is a menu" (and doesn't reliably convey that to everyone).
"topics" is also how untested, new fangled things like book stores and libraries work. People are also far more likely to side scroll menus on mobile. I'm not saying it's great design, but the option is there. ITunes store, that example of perfect design /s, uses side scrolling a lot too but it only really (half) works and only with the apple mouse.
I really hate hamburger menus on desktop because as you say, it only says "this is a menu". On mobile: navigation, on desktop (FF & Chrome) it means options. And then on Chrome they have tried to shoe-horn everything into a stupidly small pop-up where half the options are just links to open more options. It's hardly a step up from a menu bar.
What if we made the tab bar show the last 4 recently used items, plus "other" to open a drawer to show everything else? But if one of the top 4 is selected, it doesn't move within the list, it stays where it is.
That's what I mean by not moving an item if it's already in the top 4. Do most people use all of the features of any given app? I can see things like news sites being able to get by with this, as I suspect the general use case with news sites is to only have a few sections one cares about.
Or maybe it's a Markov chain! Move an item in the list by a random proportion weighted by how frequently that item has been used in the past! Infrequently used items have a low probability of making it into the most-recently-used list, where they would supplant more frequently used items.
Or more direct: just always sort items by how frequently they've been use over time, but never allow the top 4 to be rearranged, even if one of the "lower" items gets used more.
Or more simple: just let the user choose which items they want to pin to the front view.
In all honesty, I thought the article was going to be really about restaurant (fast food or not) menus... And I know what hamburger menu is... But hamburger icon would've been more direct and up to the point (for me at least)!
It should be obvious to most designers that critical features of your product should not be buried or hidden.
I disagree with this article that hamburger menus should be burned to the ground. I think it's useful for tucking away secondary or tertiary functionality.
* Facebook still uses it for accessing your friends list. With smartphones growing in physical size, there is more vertical real-estate to bring the tabnav back.
* Despite it not working for NBC, it seems to be working well for New York Times – and not yellow. And I actually really like NYT's new page layout.
> As a last-ditch attempt to solve the problem, they made it yellow
Amazing! I could almost write a script for the meeting in which that solution was decided upon.
Rough sketch:
Idea is proposed by one individual at level N in the hierarchy. Some cursory justification is provided, based on theory from a design article they read, they think, or maybe it was a youtube video - doesn't matter: Yellow attracts attention! Green makes people want to proceed! Red makes people want to stop! It's so obvious.
Numerous objections are raised by individuals at level < N in the hierarchy, who have a fairly deep understanding of design and have thought a lot about the problem. The objections are considered briefly, and then summarily ignored.
Or in a less jaded view, they decided to try a very low cost fix before pulling the trigger on a very expensive site navigation redesign. Or, even better, this showed a partial improvement while they worked on the navigation redesign since "turn it yellow" takes 2 seconds and redesign the navigation takes much longer.
I like how this reads as jaded, was actually just an attempt at a bit of humour! Of course I agree with everything you said, that's probably what it actually was.
I've still not learned, probably never will, that tone rarely comes across in text :-)
Worse is the "invisible x" menu. The one for the options that help the user but decrease revenue, such as "mark this item as spam". Facebook uses this a lot. (Mouse over a Facebook ad. A greyed-out "x" appears at the right of the ad. Mouse over the "x", and the grey turns darker. Click on the "x", and a menu comes up demanding to know why you didn't like that ad.) So does Youtube. (Those silly pop-ups on Youtube, if moused over, display a tiny, tiny "x" in the upper right hand corner which will make them go away.)
Except these don't actually "remove ads." They are meant to further train the algorithm on relevancy while providing the minority of users who use it a button that lets them feel like they are doing something about the annoying ads.
My co-founder and I debated whether to use the hamburger menu for our iOS and Android apps (currently in beta -- https://recent.io/).
We decided to keep the hamburger menu on both platforms for launch. Our reasoning was that it's a common UI convention and our primary navigation options -- Home, Recommended, Hot News, Local News, and topics -- are visible in the extended app bar. An option to follow additional topics appears inline in the Home tab.
So the three functions that are only accessible through the hamburger menu are bookmarks, history, and settings, which seems like a reasonable compromise. You could use our app fully for a year, albeit with the default settings and no bookmarks/history, without ever seeing the hamburger menu.
Analytics shows that the hamburger menu is used frequently by our beta users, so I'm fairly confident that we made the right choice. On the other hand, the new YouTube Android app -- which had more in its hamburger menu than we do -- has moved in the opposite direction and eliminated it.
Thanks for the suggestion! I don't think either of us had thought of that.
Inside the app, Home is a starting point that lets you see your news highlights at a glance. It does seem like the concept could be broad enough, as you say, to support history and bookmarks...
The inspiration came from Firefox Mobile, which has a unified home screen that incorporates navigation, recent history, bookmarks, and tabs from other devices, all in the same home screen.
If Home is highlights of the day, then it seems natural to scroll down and see a heading for "Yesterday" with yesterday's highlights, rather than less relevant news from today (which could appear in the other views).
This is a really important point. While the article makes several strong conceptual points, the metrics won't necessarily stand the test of time. There's nothing particularly "natural" about design, so anything that becomes habitual and conventional is part of "good" design. If the hamburger lives on we won't think twice about it, like we no longer think about that stupid "gears" icon for "settings" and the very idea of a windowed UI.
I was inclined to dismiss this author's view on mobile design since they were saying "click" this and "click" that everywhere. On mobile, there is no clicking. Clicking is for when you have a mouse. On mobile there's tapping.
But. That being said, the article makes sense. Hamburger menus are where features go to die.
So if you want a feature used, I agree it should be brought forward in a different way.
I definitely struggle with that wording issue, since there are a variety of devices and interaction methods that make it difficult to write about without the language getting cumbersome. :) "Click" seems to be the most commonly-accepted term for initiating a request for the browser to load a URI based on a hyperlink, so I went with that as a general term.
hamburger menu should only contain notbso often needed actions. There can be additional buttons in the GUI. Simple as that.
also most android apps support swiping from the border which gives the user a quick access to actions not using any space. The author doesn't mention it?
I like the hamburger icon because (I think) almost everyone who would read my web sites (technical stuff) knows what it is.
I agree that if the hidden menu has very few options then it is a good idea to have everything visible but that is not feasible for more than a few navigation options.
Just use a tab bar where the right most tab is "more" and that brings up more navigation options. Can still have more than 5 nav links and avoids the hamburger menu, you can thank me later.
James Archer, author of the piece, is Chief Creative Officer of both Crowd Favorite, and Forty, both of which use -- surprise -- the hamburger menu in their mobile sites. Is this another case of "do what I say, not what I do"?
It's in the queue. :) The Crowd Favorite site is in the process of being redesigned, and there'll be changes to the Forty site coming shortly after that.
(These changes aren't just because of the hamburger menu, obviously. Digital stuff moves pretty fast in general, and companies keep evolving.)
Before hamburger menus became popular, weren't people complaining about the exact opposite problem? That is, if you break out the menu items into more prominent interface elements (e.g., tab bar items), then you're at risk of cluttering your visual design with less-common functions. As in all things design, I suppose a balance needs to be found, but I personally don't find anything wrong with a hamburger menu per se.
Almost everything has or needs something like a hamburger menu somewhere. Can it be abused? Yes. Does that make it inherently bad? I don't think so.
I agree that sometimes that works really well. Still, for some apps/websites there is really only one obvious and important function. In those cases, a tab bar would just be putting "the other junk" in a more important place than it should be.
There will always be a conflict in design between minimalism and functionality. The hamburger menu just happens to be prime territory upon which that battle is fought.
Out of curiosity I just opened up Facebook on my iPhone (mentioned in the article as a good example).
The tab bar has 5 items: News Feed, Requests, Messages, Notifications, and More. I'm in the News Feed 99% of the time. Requests and Notifications are pretty much redundant (since requests become notifications) and could easily be put somewhere else - maybe nav/title bar. Messages is completely useless - just shows me a button to install a different app that I don't care about (of course that's "better for metrics", but not better for users). And "More"... well that's a standard hamburger menu, and frankly the only thing that needs to be there in my opinion.
Maybe I'm an atypical user, but that experience seems to be the case in a lot of tabbed apps.
Yes, you are an atypical user. You also don't work for Facebook, so you don't have insight into all their priorities.
Facebook is a data-driven company. They've publicly discussed the process that resulted in the current tab bar design. In initial tests, they saw a drop in newsfeed views; they solved it by badging the newsfeed tab when new content arrives.
Requests get their own tab because adding friends to your network is probably a critical priority, and if you really want a user to do something, you give it a top-level navigation item.
No argument here about Facebook's priorities or being data-driven. I don't doubt any of what you're saying.
Still, as a user I don't care if data suggests that it's in Facebook's best interest to require a separate app for messages (and keeping around a tab that does absolutely nothing in the current app). I'm sure that is better for their business, at least in the short run. But from a user experience design perspective, I'll probably never see that as better design.
Littering your app with ads may be great for business, but I wouldn't consider ads in an app to be "great design" in general. I fully understand that design is meant to serve a purpose - usually the interests of a business, but I'd draw a line when it comes at the expense of frustrating your users (and no, I'm not atypical in my frustration with Facebook).
That philosophy is at the core of what's killing Facebook. My opinion, as always, so take it or leave it.
It's beyond me why they made the choice to move out Messages to a different app. Not only is it incredibly frustrating when I accidentally click the messages tab bar, and the entire FB app closes and another app opens, with no easy way to quickly go back (on iOS), but it also eliminated one of the very few reasons I ever needed to open FB app in the first place, to chat with people. Before, when I would open the FB app to chat with people, I would inevitably quickly look through the feed, and be exposed to one or two of their crappy ads. Now I can just open the FB Chat client and never bother with the main app. A win for me, perhaps. But a win for FB?
> I personally don't find anything wrong with a hamburger menu per se.
The trouble, which the article describes with some case studies on engagement before and after hamburger menu implementations, is that people who are not you are confused by it and don't understand it to be a menu.
fwiw, I've encountered this quite a bit when helping users switch from Internet Explorer to Firefox or Chrome -- both of which use the stupid hamburger menu -- an users hate it and "being able to find things" is probably the number one reported reason that they go back to Internet Explorer.
ed: for a more specific example, look at Firefox or Chrome, try really hard to imagine that you are a first time user of that web browser, but you've used IE before, and then figure out how to do one of the most common things that people want to do with a web browser: bookmark a page.
> fwiw, I've encountered this quite a bit when helping users switch from Internet Explorer to Firefox or Chrome -- both of which use the stupid hamburger menu -- an users hate it and "being able to find things" is probably the number one reported reason that they go back to Internet Explorer.
Even as a routine Firefox user, I never use the "hamburger menu." Instead, to reach functions not visible on my toolbar, I just press Alt to reveal the traditional drop-down menus and use those.
I still remember when I first heard someone call the three-line button a "hamburger." Variations had been around for some time, and I think people generally called it a "list" or "menu" button. I personally thought it looked like a thumb grip, so when it appeared on mobile as something you could grab and slide, for a while I called it a grip. The name "hamburger" has never resonated with me. So admittedly part of my disdain for the hamburger is simply the new name.
I am generally in favor of the article's argument, especially in large-display contexts such as desktop computing. As much as I can appreciate the visual minimalism of mobile designs, it can feel frustrating and constraining to navigate a mobile design in a large-display context.
It's also funny that on the desktop OS designed by Apple, that paragon of modern and superficially minimal design, the menu is always visible (in the menu bar, just for the focused application). Other desktops trying to be as "easy and beautiful" as OS X are doing more to hide the classic menu.
(not an apple fanboy, I promise, I've spent more time with linux overall)
Apple chose to always have an active menu at the top of the screen because of Fitts' law, which roughly says that bigger buttons can be clicked on more quickly than small ones (see wikipedia for a more precise mathematical description). Duh.
With the menu at the top, the user can slam the mouse pointer to the top edge, and simply focus on moving the pointer left of right. This is perceptually equivalent to having the screen divided into several tall stripes, one for each menu item. The menu items thus act like buttons with very large screen area.
On a small mobile device, this trick is used too: most of the UI buttons are on the edges of the display.
Compare this experience with trying to hit a tab or button on the top edge of your application's window (on a desktop computer). The top edge is rather narrow, and the targets sitting on that edge have small area. It takes much more effort to hit them, than if they were planted at the top of the screen.
From what I've read, Apple chose this design way back in the stone age era (early 1980s), after actually doing user testing!
>people who are not you are confused by it and don't understand it
This is the history of computers and users. So many technologies that seem completely intuitive now started out just like this. being confused by it and don't understand it is only a problem if stays that way like shortcut key combos. Hamburger menus are like "right click". it's not that bad and when people have seen it a few times it won't be some confusing.
The trouble is that so many software developers in particular use this argument to justify every single silly notion they come up with. "Users just hate change, they'll get used to it and then they'll love it" is not a good engine for UI design.
Which is why most right click menu options also can be found in another place. The right click menu is a shortcut much like hotkeys. Not essential, but convenient.
Yeah, me too. And its amusingly frustrating to watch. And we know why double-clicking is a thing, and why it's not consistent across widgets, but I wonder if we'd be better off if the mouse originated not with "left" and "right" buttons, but instead "do" and "select" buttons. The Do button would open the files and visit the hyperlinks, the Select button would add the object you're looking at to a stack of selections, or provide more information about the thing you're pointing at, or some other lower-cost action.
(I just changed the setting on my desktop to use single-click-to-open, and was immediately punished by it. Couldn't merely select files anymore without fear :) )
Shouldn't you also have a third button to list available actions, or would you throw that away? Overloading the select button would be just as confusing; I hope you don't want to do that.
You're right of course. At some point a trade off has to be made among usability, discover-ability, and simplicity. (Pick any two).
Adding another button reduces simplicity, but enhances the other two. Apple's one-button mouse—at the other extreme—makes things simple and discoverable, but often not as useable as I'd like. I still don't know how OSX's equivalent to Windows' [Alt] key access to menu items (does it exist?)
I do think using three buttons are good -- I'm not so happy with the classic "Xerox Parc/Smalltalk" layout -- I'd prefer to have a button on the thumb (like many logitech mice have) and a scroll-wheel in the middle that's not a button.
Which leaves us with a bit of a problem for touch screens. While it might be ok to demand users to learn one and two-finger touch -- three finger touch might be going a bit too far...
I used to use an MX Revolution mouse[1] that had what you describe. Multiple thumb buttons, that amazing flywheel scroll wheel, that other thumb wheel. I loved that mouse.
Unfortunately I love trackballs more than mice now, and am severely limited in my choices. The Trackman is nice, and has a couple of extra buttons, but it would be so nice to have something close to what I had with that Revolution mouse.
In response to your comment above, no I wasn't being ironic :). I'm sure I've seen similar schemes before that informed my "idea", though.
Middle button (usually) on a three button mouse: Activate a menu to invoke an action concerting the contents of a window; e.g. carrying out an editing operation on text withing the window. (...)"
Right button on a three button mouse: Activate the menu or invoke an action concering the manipulation of the window (view / Morph) itself; e.g. moving or closing a window.
Depends on the user group and the context you're designing for. Only so-called "novice users" struggle with right click. Intermediate to advanced users are well versed in it. The former user group is dwindling by the day.
Be very careful about conflating the two issues. Usability studies have shown that users struggle with inappropriately labelled hamburger menus. Usability studies have also shown that users of intermediate to advanced skill do not struggle with right click. One is an issue regarding appropriate labelling and visual affordance, and the other is one of system and hardware affordances.
Yet oddly we appear to be going down a route where UI is hidden a lot:
a. long-press on a touch-screen device to select text, show a menu etc.
b. buttons with hieroglyphics to indicate what to do (worse than the old floppy disk for save) - eg. iOS' share button is a box with an arrow going into it (which is confusing to me as I do not want to put my concept into a box - I want to share it OUTSIDE my box of a device).
c. Sliding from sides of the screen to show notification areas, control panels (iOS), or "split screen" apps (Samsung Note), or charms (Windows).
d. Using different gestures to do things like take screenshots on Samsung note devices (swipe your entire hand across the screen)
e. Hiding UI elements until something is done, eg. scrollbars on OSX by default until you scroll (which you would need the scrollbar to actually do...)
They are all very simple once you know them but it must be very difficult as a first-time user, particularly if you are an older first-time user where your ability to absorb information like a sponge is diminished.
Every couple of years interaction is reinvented it seems! This differs from the decades of computer use where the only massive changes were scrollwheels on mice.
1. the small screen version of big footer menus which conflict with infinite or long scroll on mobile.
2. The new "site map" menu, flash web sites loved where you dump the navigation of your pages hierarchically.
3. Another "design by committee" tool similar to carousel. As a designer you say "yes" to any navigation request and dump it under the carpet (hamburger)
Part of the engagement reduction has to do with simple confusion on what the heck it is but I think even when it's well-understood it's clunky and distracts from better UX design.
> The trouble, which the article describes with some case studies on engagement before and after hamburger menu implementations, is that people who are not you are confused by it and don't understand it to be a menu.
I confess I'd seen these for awhile before it dawned on me "you should totally click that!"
And today I learned what they're called.
As I saw the headline a few times at work, waiting to get home before I read it, I tried to imagine what a hamburger menu might be (and I never guessed it was what it is).
I imagined the menu at a hamburger store like McD's. And what most looks like that is the columns of small print links at the bottom of big kids' sites like Amazon. (And do those have a name?)
> ed: for a more specific example, look at Firefox or Chrome, try really hard to imagine that you are a first time user of that web browser, but you've used IE before, and then figure out how to do one of the most common things that people want to do with a web browser: bookmark a page.
You press Command+D, dauh. You know D for Bookmark :)
I find myself attributing this to the constantly hammered home message from Apple and MS about how easy computer use is.
Therefore when something is "not easy" (aka, breaks with people's rote learning), people having trouble will not admit it. As it will in their mind be the equivalent of admitting they are stupid.
Last I checked bookmarking a page is just clicking the star button to the right of the search bar. Though maybe Firefox on Windows has a different UI nowadays. You could also (still, thankfully) just enable the menu bar in Firefox.
Funny thing, I am so used to Ctrl-D that I have never used the star button. Until now, I didn't even know what it was for. Different strokes different folks I guess.
The title of the article is "The Hamburger Menu Doesn't Work" not "The Hamburger Menu Is Bad". Not only that, they present actual evidence about it not working for a number of apps and websites.
Before the hamburger menu, people were complaining about the MS Office style ribbon. Design fads are an endless cycle of "ops, just froze my thumb!" -> "wait, I'll just put your hand on fire to solve that" -> "ops, my hand is on fire!" -> "wait let me freeze your arm", and so on.
Just like the ribbon, there are plenty of things wrong with the hamburger. One of them is that people can not even find it on a large screen. Both can be used well (look at AutoCad 2010 for a good example of ribbon; there are plenty of good examples of the hamburger on phone apps), and both are widely abused. But I'll just disagree that almost everything needs it. Almost nothing on a desktop of tablet needs it, it's a phone thing.
It's a common pattern that is used everywhere. If we were to zero base think, then yeah, it's absolutely horrible. But since it is already established people look for it. Better to go with an established pattern than reinvent your own. That being said, the article advocates tab bars and I think that is fine if you have the screen real estate. Often times you don't though.
> As in all things design, I suppose a balance needs to be found, but I personally don't find anything wrong with a hamburger menu per se.
It's not about balance, cluttering or abuses, it's all about engagement. Ultimately design decisions must be data-driven. If using other nav patterns you increase user engagement (and consequently revenue for the company) the hamburger should be replaced. So, A/B test it, and you will learn which is the correct choice: hamburger, tabs, segmented control, etc
As a software engineer who spends way too much time on front of a computer, I think it took me over a year to notice that a hamburger menu was a consistent user interface feature on phone apps and elsewhere.
I also am the person you describe. Once I figured out that it was a menu, and not that the world switched to a super-minimal feature-stripped interface for mobile websites. I never felt I liked it. I can click on tiny "Click [here]" links in the middle of a bunch of text on my phone. I can certainly click on a normal menu too. Then, I started to notice it in css frameworks. So, even I started to use it.
But, they were just such a pain. Every time. Trying to manipulate their behaviour even slightly was an exercise and in the end I was never happy with the result. I'm in full agreement that this interface should go away. I was happy to read the article and discover I haven't gone mad.
One of the things that I felt Windows Phone 7 and 8/8.1 in their design language did well was encouraging designs that were better than the hamburger (pivots and sprawling "hubs" that encourage you to explore in two dimensions; app-bars with ellipses).
It's interesting to see Hamburger menus bleeding back into the design language with Windows 10. It seems a strange, sad concession to meeting Android/iOS designs and even Desktop designs (with their million year old menu bars) "half-way". That said, one of the interesting twists that Windows 10 designs thus far tend to put on the Hamburger menu is that secretly in many cases the Hamburger icon is just a replacement for the Windows Phone 8's App Bar ellipsis:
The items on the bar show just icons at tablet size or lower and the Hamburger simply reveals app labels and maybe (rarely) lesser used text-only options. (At larger than table sizes sometimes the bar defaults expanded rather than condensed.)
This roughly corresponds with the Facebook suggestions in the article here.
The interesting differences to a WP8 app bar are that the W10 hamburger "app bars" have mostly gone vertical and the hamburger is a toggle rather than the WP8 app bar ellipsis was a "slide".
It will be interesting to see how this design language continues to accrete/evolve as Windows 10 Mobile gets closer to launch.
As someone who has been using Windows Phone devices since WP7 was launched the hamburger button making an appearance makes me just shake my head in disgust. To an extent Microsoft has been making reasonable use of it, in Outlook it's particularly nice since I no longer need to expand the app bar to get to my folder list - but I fear the signaling it may be giving 3rd party designers, that they can get away with mystery meat navigation and ruin one of the better parts of the Windows Phone UX.
I'm right there with you. My hopes are that enough developers and designers are paying attention to why and what the hamburger menus are doing in Outlook and Xbox and some of the other Microsoft-built Windows 10 applications rather than just duplicating whatever they've been doing on iOS/Android. I've got a feeling that maybe Microsoft themselves hope that their smarter use of hamburgers might be contagious in the other direction (just as so much of Material UI copied some of the flatter styles of WP7/8) and iOS/Android developers might start using the Windows app bar-style of hamburgers. I'm worried, of course, that designers/developers won't be paying attention and will assume the consistency in iconography applies a consistency in functionality. That said, I also see Microsoft's point that the global consistency in iconography may be more important than consistent functionality in a world where users are using applications on multiple platforms (ie, so many people are using some admixture of Windows, Mac OS X, iOS, and Android these days).
The neat thing about UI is that even bad designs eventually become the best ones as people get used to them and recognize them. The hamburger menu appears on a bazillion sites and it's going to be familiar to most users soon if it isn't already.
In my apps I generally use the Hamburger menu to hide stuff that's required but not used very often. (Settings, legal agreements etc..) Since engagement is lower for these things anyway it allows you to have them there if needed without cluttering the main content that should be the focus.
191 comments
[ 4.3 ms ] story [ 210 ms ] threadThe point I took away was that menus should have logical, semantic purposes, and common functions shouldn't be buried inside them.
Please rebut those, instead of name-calling.
http://exisweb.net/menu-eats-hamburger and followup http://exisweb.net/mobile-menu-abtest
http://conversionxl.com/testing-hamburger-icon-revenue/
http://thenextweb.com/dd/2014/04/08/ux-designers-side-drawer...
http://www.adammcfarland.com/2013/10/24/responsive-mobile-ui...
Anecdotally, I don't use a ton of mobile social apps, and the first time I encountered this icon I thought it was some weird play on an equals sign. Never occurred to me it was a menu. Now my own dev team is using it and for some bizarre reason I cannot convince them to stop.
A tab bar is great in an iOS app with a limited scope of functionality. That just doesn't work a sprawling news site covering dozens of topics. A small, product-focused website may even be able to get away with showing all of their navigation options at once. For many sites, however, it's unfortunate, but sometimes you just need a well-organized junk drawer inside a hamburger menu.
The hamburger menu only makes sense when it's the literal junk drawer of the app/site, when there's no possible way to categorize its contents with anything more than the completely generic 3 horizontal bars. But primary navigation elements are not junk and don't belong there.
This a a little hyperbolic. If you want surface a link to the Lifestyle section, then you also have to accept that links to about a dozen other sections need to be visible as well - on mobile, this would lead to about a third of the visible page (or more) being consumed by navigation links. Alternatively, you put the nav at the bottom of the page, but I would argue that doing so makes it less accessible/visible than it would be in a hamburger menu.
The real challenge is not when you're trying to put 3-4 links or nav-groups in a hamburger menu, but when your site structure is so flat/shallow that you have a dozen or more equally-viable nav/action options for users. Except for the NBC example in the article, the nav in the examples can be distilled into a narrower, deeper structure.
The article author doesn't appear to realize that on NBC news, the hamburger-equivalent "more" menu still appears at mobile widths. Sometimes it really is a decent solution.
As a trivial example, you could have a single menu labelled "Sections" with a disclosure arrow, and mousing over / tapping it would then reveal a list of all sections. It's functionally identical to the hamburger in actual usage, but because it's called "Sections" (and only contains sections, not arbitrary junk), it becomes an obvious thing for users to interact with if they're looking for the Lifestyle section.
This is a little hyperbolic. You've basically recommended a labeled hamburger menu - 'Sections' instead of 'Menu' - and text labels definitely have a demonstrable advantage over icon-only buttons, but the OP isn't advocating for text labels instead of the hamburger icon (see NBC example that had a labeled hamburger menu originally), it's proposing that the menu items be surfaced into tabs, segmented controls, and lists. That's not viable on sites with a flat structure.
nytimes.com uses the hamburger icon with the 'Sections' label, as you suggest, but it's important to acknowledge that this is just a variation on the theme, not a complete rejection of the 'menu items hidden behind something else' principle, so we need to be precise about the problems that a hamburger menu can and can't solve.
So basically, what I'm saying is that if you must use a menu, label it appropriately, and only put relevant items in that menu. If you have a bunch of things that aren't related to each other, they should be in different menus. A real hamburger menu is only appropriate for items that the vast majority of users are expected to never click on, and for which you're ok with making it hard to find for the rare user that actually does need it.
[1] Well, anything that you want users to actually click on.
This is a big part of the problem. Devs too lazy to use media querys to adapt the layout to the screen. We end up with poorly implemented "mobile" sites on our big, wide desktop screens. It's like the web took a step back to 1995 with pages hardcoded for 640px width. Looks good on my iPhone... time to deploy.
A hamburger menu that can be optionally converted to a persistent sidebar on screens with sufficient space would alleviate much of the usability problems.
Well, if there is such a menu, where else would it be?
In a mobile app it makes a lot more sense, because screen space is so limited and the hamburger button will occupy one of the prime navigation points in the app UI (typically the upper-left or upper-right navigation button slots), so there's obviously not very many possibilities to find something, but even there, if you can possibly avoid using it, you should. As the original article demonstrates, hiding your navigational elements, even on mobile apps, significantly reduces user engagement.
In a desktop website, I can't think of any reason why I would ever use a hamburger menu. Other, more specific menus, sure (e.g. "Sections" in a news site). But if I see the hamburger menu, besides thinking that it's really out of place when not in a mobile app, I also will instantly assume that it's the place to find things that I probably will never need. Basically, if it's something that you might put in the footer of your site, then hiding it in a hamburger is fine. If you think it's something that enough users will want such that the footer would be inappropriate, then don't put it behind a hamburger either.
I think the best practice might be to pare down the navigation to the most important items, so at least those have visibility in a mobile context. However, these are still new design patterns being established, so nobody really has solid answers yet.
One approach is to build a hierarchy
You see, Information Architecture has more to do with capital D Design, not fad, bandwagons and styles. Its about solving this exact problem. I really hope the concept of User Experience dies in a fire so we can go back to real Design.
(User Experience is in my opinion the most nebulous, snake-oil concept I've heard since SEO. Users don't want "an experience". They want to get in get what they want and to get out. The experience should be invisible)
SEO might have plenty of snake oil vendors, but it is, unfortunately, a very real and immensely lucrative thing. Search engines drive traffic, which drives money. Search engines are gameable. End of story.
By the way, it's not "an" experience, it's "the" experience, and nobody would agree more with you about it being invisible than the coiner of the term UX - after all, Don Norman's seminal work (The Design of Everyday Things) was all about designing stuff to be more intuitive and fast to use.
There's cross-over, but one "Designer" can't do it all, even if they have a good grasp of everything.
When the focus is on UX, decisions might be made about how people sign in or out. The UX expert might determine that a 2-step log out process is one step too many, but the research they gather might suggest it's nevertheless still acceptable enough to get away with. The designer makes whatever-step process look and function the best it can, without needing to scrutinise the research and testing around 2-step sign out processes.
Another example - consider the user experience of dismissing the banner that appears on some websites that have an app in iOS Safari. The little 'X' close link is tiny, way smaller than any touch button or link should be. Bad UX? Sure is. But the UX person must have data suggesting that having a stupidly small close button for that banner is worth it for the primary visual incentive to act on the promotional prompt without annoying too many people (annoys the hell out of me, but I'm not everyone).
http://www.idg.se/
Then have a menu named "topics" (or whatever marketing says to call areas of news). Still makes more sense than a menu whose icon means nothing more than "this is a menu" (and doesn't reliably convey that to everyone).
I really hate hamburger menus on desktop because as you say, it only says "this is a menu". On mobile: navigation, on desktop (FF & Chrome) it means options. And then on Chrome they have tried to shoe-horn everything into a stupidly small pop-up where half the options are just links to open more options. It's hardly a step up from a menu bar.
Or maybe it's a Markov chain! Move an item in the list by a random proportion weighted by how frequently that item has been used in the past! Infrequently used items have a low probability of making it into the most-recently-used list, where they would supplant more frequently used items.
Or more direct: just always sort items by how frequently they've been use over time, but never allow the top 4 to be rearranged, even if one of the "lower" items gets used more.
Or more simple: just let the user choose which items they want to pin to the front view.
oh... i get it... you're dumb.
I disagree with this article that hamburger menus should be burned to the ground. I think it's useful for tucking away secondary or tertiary functionality.
* Facebook still uses it for accessing your friends list. With smartphones growing in physical size, there is more vertical real-estate to bring the tabnav back.
* Despite it not working for NBC, it seems to be working well for New York Times – and not yellow. And I actually really like NYT's new page layout.
* Google Maps uses it – also not yellow.
Amazing! I could almost write a script for the meeting in which that solution was decided upon.
Rough sketch:
Idea is proposed by one individual at level N in the hierarchy. Some cursory justification is provided, based on theory from a design article they read, they think, or maybe it was a youtube video - doesn't matter: Yellow attracts attention! Green makes people want to proceed! Red makes people want to stop! It's so obvious.
Numerous objections are raised by individuals at level < N in the hierarchy, who have a fairly deep understanding of design and have thought a lot about the problem. The objections are considered briefly, and then summarily ignored.
Meeting concluded.
I've still not learned, probably never will, that tone rarely comes across in text :-)
Yet another tool for "screw the user" UI design.
We decided to keep the hamburger menu on both platforms for launch. Our reasoning was that it's a common UI convention and our primary navigation options -- Home, Recommended, Hot News, Local News, and topics -- are visible in the extended app bar. An option to follow additional topics appears inline in the Home tab.
So the three functions that are only accessible through the hamburger menu are bookmarks, history, and settings, which seems like a reasonable compromise. You could use our app fully for a year, albeit with the default settings and no bookmarks/history, without ever seeing the hamburger menu.
Analytics shows that the hamburger menu is used frequently by our beta users, so I'm fairly confident that we made the right choice. On the other hand, the new YouTube Android app -- which had more in its hamburger menu than we do -- has moved in the opposite direction and eliminated it.
Inside the app, Home is a starting point that lets you see your news highlights at a glance. It does seem like the concept could be broad enough, as you say, to support history and bookmarks...
If Home is highlights of the day, then it seems natural to scroll down and see a heading for "Yesterday" with yesterday's highlights, rather than less relevant news from today (which could appear in the other views).
But. That being said, the article makes sense. Hamburger menus are where features go to die.
So if you want a feature used, I agree it should be brought forward in a different way.
also most android apps support swiping from the border which gives the user a quick access to actions not using any space. The author doesn't mention it?
I agree that if the hidden menu has very few options then it is a good idea to have everything visible but that is not feasible for more than a few navigation options.
(These changes aren't just because of the hamburger menu, obviously. Digital stuff moves pretty fast in general, and companies keep evolving.)
Almost everything has or needs something like a hamburger menu somewhere. Can it be abused? Yes. Does that make it inherently bad? I don't think so.
There will always be a conflict in design between minimalism and functionality. The hamburger menu just happens to be prime territory upon which that battle is fought.
The tab bar has 5 items: News Feed, Requests, Messages, Notifications, and More. I'm in the News Feed 99% of the time. Requests and Notifications are pretty much redundant (since requests become notifications) and could easily be put somewhere else - maybe nav/title bar. Messages is completely useless - just shows me a button to install a different app that I don't care about (of course that's "better for metrics", but not better for users). And "More"... well that's a standard hamburger menu, and frankly the only thing that needs to be there in my opinion.
Maybe I'm an atypical user, but that experience seems to be the case in a lot of tabbed apps.
Facebook is a data-driven company. They've publicly discussed the process that resulted in the current tab bar design. In initial tests, they saw a drop in newsfeed views; they solved it by badging the newsfeed tab when new content arrives.
Requests get their own tab because adding friends to your network is probably a critical priority, and if you really want a user to do something, you give it a top-level navigation item.
Still, as a user I don't care if data suggests that it's in Facebook's best interest to require a separate app for messages (and keeping around a tab that does absolutely nothing in the current app). I'm sure that is better for their business, at least in the short run. But from a user experience design perspective, I'll probably never see that as better design.
Littering your app with ads may be great for business, but I wouldn't consider ads in an app to be "great design" in general. I fully understand that design is meant to serve a purpose - usually the interests of a business, but I'd draw a line when it comes at the expense of frustrating your users (and no, I'm not atypical in my frustration with Facebook).
That philosophy is at the core of what's killing Facebook. My opinion, as always, so take it or leave it.
The trouble, which the article describes with some case studies on engagement before and after hamburger menu implementations, is that people who are not you are confused by it and don't understand it to be a menu.
fwiw, I've encountered this quite a bit when helping users switch from Internet Explorer to Firefox or Chrome -- both of which use the stupid hamburger menu -- an users hate it and "being able to find things" is probably the number one reported reason that they go back to Internet Explorer.
ed: for a more specific example, look at Firefox or Chrome, try really hard to imagine that you are a first time user of that web browser, but you've used IE before, and then figure out how to do one of the most common things that people want to do with a web browser: bookmark a page.
Even as a routine Firefox user, I never use the "hamburger menu." Instead, to reach functions not visible on my toolbar, I just press Alt to reveal the traditional drop-down menus and use those.
I still remember when I first heard someone call the three-line button a "hamburger." Variations had been around for some time, and I think people generally called it a "list" or "menu" button. I personally thought it looked like a thumb grip, so when it appeared on mobile as something you could grab and slide, for a while I called it a grip. The name "hamburger" has never resonated with me. So admittedly part of my disdain for the hamburger is simply the new name.
I am generally in favor of the article's argument, especially in large-display contexts such as desktop computing. As much as I can appreciate the visual minimalism of mobile designs, it can feel frustrating and constraining to navigate a mobile design in a large-display context.
(not an apple fanboy, I promise, I've spent more time with linux overall)
With the menu at the top, the user can slam the mouse pointer to the top edge, and simply focus on moving the pointer left of right. This is perceptually equivalent to having the screen divided into several tall stripes, one for each menu item. The menu items thus act like buttons with very large screen area.
On a small mobile device, this trick is used too: most of the UI buttons are on the edges of the display.
Compare this experience with trying to hit a tab or button on the top edge of your application's window (on a desktop computer). The top edge is rather narrow, and the targets sitting on that edge have small area. It takes much more effort to hit them, than if they were planted at the top of the screen.
From what I've read, Apple chose this design way back in the stone age era (early 1980s), after actually doing user testing!
New isn't always better.
This is the history of computers and users. So many technologies that seem completely intuitive now started out just like this. being confused by it and don't understand it is only a problem if stays that way like shortcut key combos. Hamburger menus are like "right click". it's not that bad and when people have seen it a few times it won't be some confusing.
It's unintuitive and undiscoverable, but I wouldn't necessarily call it unhelpful...
(I just changed the setting on my desktop to use single-click-to-open, and was immediately punished by it. Couldn't merely select files anymore without fear :) )
Adding another button reduces simplicity, but enhances the other two. Apple's one-button mouse—at the other extreme—makes things simple and discoverable, but often not as useable as I'd like. I still don't know how OSX's equivalent to Windows' [Alt] key access to menu items (does it exist?)
Which leaves us with a bit of a problem for touch screens. While it might be ok to demand users to learn one and two-finger touch -- three finger touch might be going a bit too far...
[ed: And for those that want to remap buttons, but avoid the bloated logitech software, in windows I recommend: http://www.highrez.co.uk/downloads/XMouseButtonControl.htm
In X it's of course much easier (or more difficult, depending on your point of view): https://wiki.debian.org/Keyboard/MultimediaKeys ]
Unfortunately I love trackballs more than mice now, and am severely limited in my choices. The Trackman is nice, and has a couple of extra buttons, but it would be so nice to have something close to what I had with that Revolution mouse.
In response to your comment above, no I wasn't being ironic :). I'm sure I've seen similar schemes before that informed my "idea", though.
[1] http://www.amazon.com/Logitech-Revolution-Cordless-Laser-Mou...
http://www.ethoberon.ethz.ch/mouse.html
Are you being ironic? I can't tell :-)
"Red button
The left button on a three button mouse: Used to select information (...)": http://wiki.squeak.org/squeak/1904
"Yellow button
Middle button (usually) on a three button mouse: Activate a menu to invoke an action concerting the contents of a window; e.g. carrying out an editing operation on text withing the window. (...)"
http://wiki.squeak.org/squeak/1905
"Blue button
Right button on a three button mouse: Activate the menu or invoke an action concering the manipulation of the window (view / Morph) itself; e.g. moving or closing a window.
The blue button is for meta actions. (...)"
http://wiki.squeak.org/squeak/1906
http://www.nngroup.com/articles/feature-richness-and-user-en...
This also falls under the "myth of the stupid user." http://infodesign.com.au/usabilityresources/articles/themyth...
Be very careful about conflating the two issues. Usability studies have shown that users struggle with inappropriately labelled hamburger menus. Usability studies have also shown that users of intermediate to advanced skill do not struggle with right click. One is an issue regarding appropriate labelling and visual affordance, and the other is one of system and hardware affordances.
a. long-press on a touch-screen device to select text, show a menu etc.
b. buttons with hieroglyphics to indicate what to do (worse than the old floppy disk for save) - eg. iOS' share button is a box with an arrow going into it (which is confusing to me as I do not want to put my concept into a box - I want to share it OUTSIDE my box of a device).
c. Sliding from sides of the screen to show notification areas, control panels (iOS), or "split screen" apps (Samsung Note), or charms (Windows).
d. Using different gestures to do things like take screenshots on Samsung note devices (swipe your entire hand across the screen)
e. Hiding UI elements until something is done, eg. scrollbars on OSX by default until you scroll (which you would need the scrollbar to actually do...)
They are all very simple once you know them but it must be very difficult as a first-time user, particularly if you are an older first-time user where your ability to absorb information like a sponge is diminished.
Every couple of years interaction is reinvented it seems! This differs from the decades of computer use where the only massive changes were scrollwheels on mice.
1. the small screen version of big footer menus which conflict with infinite or long scroll on mobile.
2. The new "site map" menu, flash web sites loved where you dump the navigation of your pages hierarchically.
3. Another "design by committee" tool similar to carousel. As a designer you say "yes" to any navigation request and dump it under the carpet (hamburger)
I confess I'd seen these for awhile before it dawned on me "you should totally click that!"
And today I learned what they're called.
As I saw the headline a few times at work, waiting to get home before I read it, I tried to imagine what a hamburger menu might be (and I never guessed it was what it is).
I imagined the menu at a hamburger store like McD's. And what most looks like that is the columns of small print links at the bottom of big kids' sites like Amazon. (And do those have a name?)
You press Command+D, dauh. You know D for Bookmark :)
Therefore when something is "not easy" (aka, breaks with people's rote learning), people having trouble will not admit it. As it will in their mind be the equivalent of admitting they are stupid.
Last I checked bookmarking a page is just clicking the star button to the right of the search bar. Though maybe Firefox on Windows has a different UI nowadays. You could also (still, thankfully) just enable the menu bar in Firefox.
Just like the ribbon, there are plenty of things wrong with the hamburger. One of them is that people can not even find it on a large screen. Both can be used well (look at AutoCad 2010 for a good example of ribbon; there are plenty of good examples of the hamburger on phone apps), and both are widely abused. But I'll just disagree that almost everything needs it. Almost nothing on a desktop of tablet needs it, it's a phone thing.
It's not about balance, cluttering or abuses, it's all about engagement. Ultimately design decisions must be data-driven. If using other nav patterns you increase user engagement (and consequently revenue for the company) the hamburger should be replaced. So, A/B test it, and you will learn which is the correct choice: hamburger, tabs, segmented control, etc
But, they were just such a pain. Every time. Trying to manipulate their behaviour even slightly was an exercise and in the end I was never happy with the result. I'm in full agreement that this interface should go away. I was happy to read the article and discover I haven't gone mad.
It's interesting to see Hamburger menus bleeding back into the design language with Windows 10. It seems a strange, sad concession to meeting Android/iOS designs and even Desktop designs (with their million year old menu bars) "half-way". That said, one of the interesting twists that Windows 10 designs thus far tend to put on the Hamburger menu is that secretly in many cases the Hamburger icon is just a replacement for the Windows Phone 8's App Bar ellipsis:
The items on the bar show just icons at tablet size or lower and the Hamburger simply reveals app labels and maybe (rarely) lesser used text-only options. (At larger than table sizes sometimes the bar defaults expanded rather than condensed.)
This roughly corresponds with the Facebook suggestions in the article here.
The interesting differences to a WP8 app bar are that the W10 hamburger "app bars" have mostly gone vertical and the hamburger is a toggle rather than the WP8 app bar ellipsis was a "slide".
It will be interesting to see how this design language continues to accrete/evolve as Windows 10 Mobile gets closer to launch.