The author of that blog post concludes:
Apple could not be clearer: don’t use hamburgers menus on iOS.
And yet he transcribes the session speaker clearly stating:
I’m not going to say that there’s no place for these controls categorically. I think there are some apps that could maybe use one.
Of course the speaker goes on to say:
But I will say that their value is greatly over-stated, and they have huge usabiliy downsides too.
But that's not the same as explicitly, unambiguously declaring that designers and developers should not use hamburger menus on iOS. To state so is being dogmatic and even obtuse. To be clearer: the author is wrong.
The author's wrong in his transcription, but there's been so much inconclusive back and forth about this UI pattern that it takes a provocative, leading headline like this one to rise above the noise.
Also consider that the speaker, an Apple employee presenting in an official capacity, is probably speaking deliberately and very democratically. This isn't something that (yet) really belongs in the HIG one way or another, so strong suggestions like this one are all you're going to get.
He claims Apple couldn't be clearer, then goes on to state his personal opinion. My takeaway, anyway.
"I hate to break it to you, but no one cares." brilliant
He's right though. I like this point so much.
I like hamburger menus precisely because they let me ignore all the boring crap in your app.
So you get to put links to your terms of service, settings, and employee of the month page in your app, and I get to ignore them. Win-win!
I think this is the danger. Increasingly, these 'junk drawer' menus become a place for apps to stash all the stuff nobody cares about, and we learn that. When less savvy developers use it as an interface catchall and put important navigation in the drawer, everybody loses.
I think you're right so once again the answer on whether to use a hamburger icon for a menu is: "it depends".
We use it within our app because it makes the most sense and we have more functions than can easily fit onto a tab bar. We also have a suite of functions wrapped in a single app opposed to separate applications so having a larger menu of functions is the wiser choice. We also host a subscription-based service with tons of training for our customers so there's little need to expose them to other features of our application. We aren't competing for eyeballs or views or whatever so there are lots of reasons that it works for our organization where it might not work for others.
I believe it's a completely valid UI pattern with pros and cons just like any other - it'll work for some people and won't work for others. Designers really just need to understand the potential issues and be able to justify the rationale of their decision for or against. (Edited for clarity)
Came here to say this. As time goes on and mobile experiences get more complex we need patterns that allow us to manage that complexity. I don't know that the hamburger is the very best solution, but it works well for certain kinds of apps.
I think the hamburger hate demonstrates how focused designers are on the shiny apps, the super exciting cutting edge social local mobile new new. But there is a ton of growth happening in business apps and productivity apps and niche apps, and some of the most exciting design challenges, too.
You may not get on techchrunch with it, but you do have the opportunity to make so many people's lives easier and better.
Would this not also apply to web design? I found it a bit strange the new Apple.com used one.
I think it's because apps tend to be more single-purpose than websites and therefore there are more navigation items on the web. The pros/cons of hamburgers are the same, but on the web it can be more difficult to simplify the navigation down enough to fit without an element that shows/hides it.
Apps and websites have to be thought of differently in this context. On iOS, the bottom navigation behaves like tabs: instantaneously switching between functional modes or views.
Websites like apple.com have a different purpose. They're informational, and have a broader and deeper hierarchy which requires correspondingly hierarchical navigation. Furthermore, websites are generally loaded inside the chrome of your mobile browser which takes care of certain navigational elements such as the back/forward buttons.
It gets tricky if your app is very hierarchical, or if your website is very tool-like, but the navigation pattern should be dictated by the intended user behavior, not just the size of screen.
This feels more like a crutch to me, and that we are making excuses for the real issue: websites (as they are now) don't work well on mobile-sized screens.
I don't think it's safe to put "websites" under one category. Yes, it's true that many websites are simple and could benefit from clearer navigation. I'm not a proponent of the hamburger. However, there are also websites which are incredibly complex, and should be. A lot of information on a very small screen, that's always going to be tough.
That's why I quantified websites with "as they used to be". I guess my argument is, when we reach for the crutch (the hamburger menu, complicated dropdown menus, etc.) then we are avoiding a larger architecture issue.
Compare uk.gov and apple.com. You can't tell me that apple.com is more complicated. Uk.gov just did a much better job of designing/architecting for mobile devices. Apple.com stuck with the status quo. I think that's largely because of marketing, but that's just a guess.
Why are we still keeping a double standard for website and app navigation?
Because not only they're not the same thing, they're also not used in the same contexts.
One of the points he made was regarding back buttons and the menu icons. On the web, navigation is handled by the browser, in apps? Not so much.
The only thing worse than using hamburger menus is the constant debate about whether or not to use hamburger menus.
I'm joking, at least with the first half of that. I have no love or hate for the 'burger menu. I'll use it when it's the best option for a particular problem, and I won't use it when it isn't. That's how good design works. Not this continual circle-jerk of trying to pin down whether or not the hamburger menu should "die".
This is not (entirely) in defense of the hamburger.
The amount of *%#$s I give depends largely on the project. In other words: Know your audience.
On many projects, I am willing to take the "risk" that some users might not recognize this control. I am of the opinion that the number of people who don't recognize it will only go down as it gains ubiquity. Seems inevitable. We the design community are establishing a new convention, for better or worse.
We have a 12-year-old at home. Whenever I feel unsure about something I am working on, I hand her my phone. It's amazing to see how immediately kids understand even the most complex (and, sometimes, stupid and seemingly unusable) interfaces.
In my experience, my five year old can figure out interfaces more easily than most fifty year olds.
Your 12 year old is pretty much Steve Jobs.
Apple.com uses a hamburger menu on mobile...
Without being a complete jerk, he was basically saying in a more general/nice way that a lot of apps started using the burger, not as a result of creating a more streamlined user experience, but because it became trendy... really trendy.
Some apps absolutely need it... it makes sense... they may have a ton of categories to choose from or a huge list of contacts (note that FB killed it in SOME places, but the contacts list etc, remain... because it makes sense).
While I think the whole "do people know this is a menu" rants regarding burger icons are a bit over the top, I do agree that people were burying core navigational features for the wrong reasons.
If nothing else, I thought this observation was a good one:
Look, drawers of any kind have a nasty tendency to fill with junk.
The elegance of hiding lots of things behind a simple action can sometimes lead to, "well we don't know where x-thing belongs, so just stick it in the drawer with everything else". That's an easier path than being selective and maintaining focus, which makes you ask and deliberate, "do we really need x-thing?"
Poor content strategy is not an inherent problem with hamburger menus though, it's a problem with designers. If you're capable of "maintaining focus" and asking "do we really need x-thing?", at any point, why not do it while deciding whether or not to put the thing in the hamburger menu?
I agree 100%.
I think if it's a designer (human) problem, then we should be even more thoughtful of the the tools we choose to use. Some tools more easily enable our seemingly inherent tendency towards laziness, other tools discourage it. If you're capable, go for it, but be conscience of the weaknesses of the tools you use (to say nothing of the end-user experience).
I do believe hamburger menus are not the best form of representing Primary Navigation, although there are apps (not primary navigation) where it can be effective i.e. Slack for iOS.
I wrote an article on this exact topic
Surprising to see such over-generalisation and shallow analysis from this guy. Not to mention the hypocrisy....
When did the drawer pattern finally get removed from Apple's own apps on OS X? I seem to remember several apps having drawers for the first few iterations of OS X.
Perhaps Apple has some experience with drawers in apps and removed them on the desktop based on research? If it doesn't work on the desktop with all the 'extra' space, perhaps some of the same reasoning was applied for iOS.