Much has been written of late in regards to the embattled “hamburger” icon. It shows up all over the web and abounds in mobile apps, all the while Apple says it’s a bad idea after implementing half of one on their own site and then backtracking on their responsive design implementation altogether. It’s all quite confusing, and, honestly, I find it to be much ado about nothing.
Let me be that I am and seek not to alter me
Much Ado About Nothing, William Shakespeare
If you’re not familiar with what the “Hamburger Icon” is, it’s that three line icon that now appears in so many responsive and mobile applications. It’s so called because it looks like a hamburger. Except for the fact that it totally doesn’t.
A brief investigation into the history of the Hamburger icon can be found in the excellent article by Karla Urbina. Should you read it, you will learn from her exhaustive research that it dates back to – suprise, surprise – Xerox. Does anyone else besides me feel like Xerox got the short end of the technology stick?
In any event, the idea behind the icon is that it would function much like a road sign in it’s simplicity, and would “mimic the look of the resulting displayed menu list.” All the “ado” about the hamburger icon has nothing at all to do with the icon, but rather with the UX that it now represents.
The Off-Canvas menu pattern has become incredibly popular lately. It’s also sometimes called a “Left Flyout” or “Drawer” menu. This is that interaction where you touch the hamburger and your screen moves out of the way to reveal content underneath. You can see some really neat animation examples for Off-Canvas on the Codrops site.
This menu style has become to the “go-to” solution for both mobile and responsive applications because it clears up so much space for more items. I’ve used it quite a bit myself, writing about how to take side menus and turn them into drawers. You’ll find it baked into CSS libraries like Zurb’s Foundation (a fantastic CSS framework by the way) and written about extensively by authorities on UX and design, such as Smashing Magazine.
In the recently posted transcript from WWDC, Apple UX Evangelist Mike Stern slams the concept of Off-Canvas (although they call it a “Hamburger Menu”) for a few reasons…
While I appreciate and respect Apple’s opinion, I want to address some of the assumptions made about hamburger / off-canvas / drawer / left-flyout menus since I think that we might be a little misguided due to the fact that and it’s hard to find the signal in all the noise.
Maybe, but this is an apples to oranges comparison. TabStrips are, by definition, simple in both form and function. That makes them simple to use and easy to understand. A veritable nirvana of user experience. It also makes them woefully inadequate for handling all of the navigation required by any app of sufficient size.
The Hamburger menu was designed to pick up the slack left lying around by TabStrips. It’s job is much bigger and more comprehensive. Comparing the two and saying you should use one over the other is unfair at best.
I find this argument that the user doesn’t know where they can go because they can’t see the menu largely baseless. I get that it’s better if you could see all of your options all the time, but come on. Desktop applications have no problem with sticking items into huge menus. Microsoft tried to fix this with the Ribbon, which is better, but you still can’t see everything and I don’t gather it’s a problem for the millions of people who crank away in Excel all day every day. It’s simply not reasonable to assume that we can present the user with all possible choices all the time, and this is one area where a TabStrip really starts to break down.
Screen space on mobile devices is so precious. It’s precious like that last 10% of battery on your iPhone when the battery icon has that pathetic sliver of red in the bottom. The problem with a TabStrip is that it is taking up valuable screen real estate all the time. Don’t need it? Too bad; get to scrolling. Now most of this gets better as phones get bigger, but watches are coming and it’s only a matter of time before someone noteworthy decries the absurd size of phones and we start making them smaller again.
The long and short of it is that you are trading screen space for a more intuitive user interface.
This idea that back buttons and hamburgers conflict is legit, but there is a way to fix it: stop doing that. I don’t think a back button and a hamburger menu need to be showing at the same time. Either you can go back, or you can go to the menu, but you can’t do both. Google Inbox implements this pattern using a close button instead of a back button, but the navigation concept is the same.
This is one of the arguments that I do indeed agree with. Hamburger menus remove the user from their current activity completely so that they can be dropped into another. I think we rationalize this away in our minds because the other screen isn’t gone. It’s still there. It’s just moved off to the right.
To be fair – it’s barely there. It’s most been pushed off the screen and what remains of it is only enough to remind you that you can get back to it by touching the still visible slice. Notice how this looks in Rdio (which I love and use every day by the way). You might as well navigate to a different screen entirely.
However, I think that this can be mitigated. Look at how Google Inbox does it…
Notice the subtle difference. Inbox doesn’t slide the main content out of the way, they slide the menu over the top of it. This feels right. It feels right because the menu is the content that you may or may not want, and your current context is still there, anchoring you in the application.
At the end of the day, I think the primary issue with Hamburger Menu is that it leaves the user transient between activities and contexts, and this can be fixed by thinking a little different about the position and animation of the drawer.
Oh – and there’s one other major problem.
In my kitchen, there is a drawer that is literally called “The Junk Drawer”. This is the drawer where we put everything without a home. It currently has Pizza Hut Parmesan cheese blend, half a book of checks from a closed bank account, a broken thermometer, a left-hand garden glove and three packets of Taco Bell Fire sauce. And this is all of the stuff on the top that I can actually see.
Frequently, when I can’t find something, I’ll ask my wife where it is. And sometimes, her answer will be, “Did you check the junk drawer”?
This is the worst possible answer you can get.
Could it be in the junk drawer? Maybe. Is it actually in there? Probably. But the sheer amount of anxiety that I feel rummaging through that nonsense makes me want to just buy a new pair of garden gloves instead of braving the chaos of the “junk drawer”.
This is the other problem with hamburger menus. They are the junk drawer of applications. They leave entirely too much room for “activities”.
Developers and designers cannot resist the urge to take advantage of all that extra space. The more content that gets added, the more exaggerated the “lost context” effect becomes and the more acutely it’s felt until nobody even wants to open the thing for fear of what might jump out and smack them in the brain.
Other than what Google is doing by sliding the menu over the top, there are some additional options for menus with a large amount of items.
Several have written about how to expand the TabStrip to be a horizontally scrolling list of items. Instagram does this already and I think that it works quite well. I can see this as being a valid replacement for hamburger menus, especially on native or hybrid mobile apps.
Another core issue with the hamburger menu is that it doesn’t do what you think it’s going to do. You click on a button in a navbar and the side slides in and the button actually gets out of your way or is covered up. That’s not how buttons are supposed to work. That’s not what one would expect to happen. Instead, you would expect to get a menu – you know – like a toolbar.
Toolbar menus fly down from the button when you click on it. That’s what the original hamburger icon did on Xerox so why can we not just do that again?
This seems to me like a much more natural interaction. I click on the button, I get a menu dropping down from said button. My screen isn’t moved out of the way. My experience isn’t interrupted. However, I still have a ton of room for menu items.
I think the best option is to keep using drawers / hamburger menus / off-canvas but do so as good stewards of the content we put inside them. If we need UX components to keep us from going nuts with content, then we have a bigger problem.
In that transcript from WWDC, Mr. Stern mentions that there is not a Hamburger Menu ViewController in Xcode. That’s too bad. I propose that we do not need Apple’s strong-arm opinions on design and interaction to create compelling and functional application experiences. We spend a lot of time at Telerik trying to break down paradigms and figure out which ones we should provide in our toolkits. We do provide a hamburger menu in Kendo UI Mobile, called a Drawer. We believe that developers don’t need us to tell them what they should and shouldn’t do, but rather enable them to easily make and implement that choice themselves.
So remember, there are 4 steps to a successful Hamburger Menu…
Burger image in header thanks to theimpulsivebuy