First off, two of their "studies" simply compared the hamburger icon to different types of icons, but the functionality remained the same (slide out). Only one looked at changing the navigation entirely.
Second, this is not so much a reflection of fly-out/slide-out navigations as it is a reflection of the fact that on mobile you just have less screen real estate period. Nowhere in that article is there a real reckoning with that fact.
I've yet to be convinced that fly-out/slide-out/hamburger navigations are worse than the alternative when you have lots of items to display. Either way you're not going to be displaying something, and whatever is not immediately visible will receive reduced engagement. If your home page/screen is full of navigation items, something else will be hidden instead.
Not to mention the article provides solution for cases that have many navigation items - something that is very common.
I kinda thought the same thing. Finding the perfect navigation can be a huge challenge for larger apps. Though I agree with the article that it's important to analyze and be critical of your app structure as much as possible.
As far as the article mentioning user engagement stats, it probably matters a lot what the point of the app is. If you're trying to get a social app off the ground and your users literally will not spend 15 seconds learning to use it - you have to put everything in their face. If you're making a vertical market app or something where the users need it to do actual work - they might appreciate a quick, single-click access to a large menu vs clicking through multiple levels of tabs.
The article's citation of the Twitter app is one I'd call a fine example of a UI that could benefit from a side drawer. Twitter has completely overloaded two of their four bottom tabs: First, the Timelines tab has several horizontally-navigated views that are spatially disorienting when positioned against the tab layout and feel conceptually muddy under the "Timelines" category. Second, the "Me" tab is also home to tangentially-related functionality such as searching for users and help, and has its own often confusing navigation that might be better expressed in a consistently laid-out side drawer.
A quick rule of thumb: if the title or the opening of the article for any technique do not contain some form of the phrase "when to use" or "under these circumstances" and instead contain absolutes like this title then you automatically know you are in for a slog to get any kind of general benefit from reading the article.
People these days seem incredibly quick to publish articles without considering how limited their perspective might be and thus the responsible way to present the information.
A quick rule of thumb: When a headline appears on the front page at HN, that headline alone is enough of a signal for 99% of HN users. It says, "a number of people are thinking about this. We need to talk about this." Forget what the article says, just read what the headline is shouting from its highly-upvoted position. If you don't like the article, fine. But "let's talk about hamburger menus and practically invisible navigation" is a worthwhile signal.
I actually submitted the article to initiate such a talk. The article failed to convince me completely, but it did make me think about the place of slide-in menus, since I consider hiding UI elements to be generally bad practice.
I've seen the doppleganger of this article a number of days ago and both drag out some form of nav bar as the alt. Really???
A nav bar, let alone a sliding nav bar, is tabs or an obese hamburger. We have been around this before. Tabbed desktop apps and tabbed web interfaces a la Amazon of the 90's. You know what this UI need? MORE TABS!
The great unbundling will continue as small screens and human eyes can only deal with so much info per inch.
I don't want to artificially engage with your A/B-optimized application. I want it to get the one or very few small things done that I need done. I don't want time sinks. I don't want to aimlessly dig through ambiguous icons looking for digital delight that you decided was unworthy of special treatment. If you are playing games with tricking humans into using your app, I question the value you are creating with your app.
There's a thing in my hand and it should be about the size of half a banana. If I want to see another half a banana, I'll put this one down and pick the other one up. I have one hand, two eyes, and a hankering for bananas! Show me pretty bananas!
3 other people may have. Let me simplify for you.
Hamburger hate is silly and a waste of time. The "better" alternatives have been done multiple times and keep getting ousted for their fundamental flaws. The value being espoused is "how to waste the user's time in your app." That's doubly wasteful. Stop creating artificial engagement and stop fighting the burger.
Doubly wasteful is making me click twice to get to what I want. and everyone, stop calling it a burger, that's a wave. This is like early-human mythology, it should be ingrained in there somewhere.
I've often thought that the HN submission form should support both the link and a short comment. If the submitter can frame the context of the submission, doesn't that help the discussion?
A very small minority of HN readers can propel something to the front-page with ease, with relatively few votes: Right now, two hours in, this has earned the arrows of a miserly 59 users. Undoubted thousands of others have browsed it and moved on, with by most measures is the opposite of the up arrow.
I'm not speaking to the specifics of this submission, but the "it's on the front page therefore it has merit" argument is not reasonable. Topics that are particularly contentious (and feelings about UI is one of them, particularly when people are motivated by disagreements with co-workers about UI direction) tend to make the front-page with ease.
Tomorrow - Why "hamburger" menus are the bestest. Also, TDD is the best, and so is NoSQL.
It is an accurate paraphrasing of what you did say. Do you disagree with that? The paraphrasing is necessary for discussion.
EDIT: I would love to see what an accurate paraphrasing is, then. I've re-read your post and what I stated is dead on with what you claimed, which is a common misunderstanding of the importance or common-agreement of a front-page appearance.
Nope, not accurate. Yes, I do disagree. No, the paraphrasing is not necessary for discussion (???). Not a biggie in the broader scheme of things though.
As a third party "we need to talk about this" and the topic "has merit" are equivalent statements. Granted you may have intended something else, but that's not how it comes across. Anyway, as you did not clarify what did you mean?
You forgot to mention that people these days are also incredibly petty. I don't see what's such a big deal about the title. Your quick rule of thumb is precisely the behavior you're pissed about.
Since when is it called a "hamburger menu"? I had no idea what it meant until actually reading the article. Names for generic things should be able to convey their own meaning. It smacks of trying too hard to be a person who coined a phrase.
My app has more than 4 views and one of the views needs to have as much of the screen available to it as possible, because a big chunk of the screen will be taken up by the keyboard. One menu button is better than trying to fit everything into 4 or 5 screens and having 5 buttons constantly taking up space at the bottom of the screen.
And I don't think that's "rare". It might be "rare" if your conception of apps is Facebook and SnapChat, but there there is a huge gap in the market for apps of real value that enable users to do real work in ways they can't do with a larger computer. Apps focused on helping users do work rather than selling ads to users will probably always grow in features over time. You can't get all of that to fit in 4 or 5 screens.
"Stacked" menus on the web have been called hamburger menus since at least the late 90's; I remember hearing the term in design meetings as far back as 1998.
A Google Image Search for "Web Hamburger Menu" also brings up images of the type of menu the author is describing[1].
Imho, Windows Phone actually has the best approach to menus. Useful icons are listed along the bottom without text labels. If you want more info you hit the "..." button and that introduces the text labels and additional menu items. A best-of-both-worlds approach that means there's one place to click when you don't know what to do, and it's already tied into vague unlabeled icons giving you the options.
My instinct told me what the article is claiming, but there just aren't any other compelling alternatives that will surface the content and serve as a solid navigation on many small screen devices.
We're still in infancy on small and touch screen devices and we don't have a ton of reliable data as things are still changing too fast.
It's something to keep in mind but does anything have any alternatives when you have more than 5 items?
All that tale makes me remember the mouse history of: Two buttons... No, one buttom! No 5 buttons that you can program! Nope, 4 buttons and 2 scroll weels!
We'll settle over something good enough for most cases, but it'll not be the sandwich alone, and I'm quite sure we'll stop using it at desktops on due time. Also, we'll probably need to rethink some APIs for getting a real option.
The way I'm currently doing it is to have two buttons: The Hamburger Icon and a context-sensitive button on the right.
This way my two most important pages get heavy traffic without removing the ability to access the other pages which get used less often.
Hamburger icons are great for large numbers of pages no one uses particularly often, but are necessary for the app to work (Settings, Profile, etc.) and as a fail safe to always be able to navigate to where you want. The way to access you main pages should be baked into them (links, buttons, action bars) on the page itself.
Sometimes you just have a shit-ton of navigation items, and it makes more sense to put them in the hamburger drawer, rather than drill-down into a tab bar further, which can take you out of your current context.
information architecture does tell us that people have to be much more engaged to navigate with more choices, and that 7 is about the top-end of what people will really process. 3 is your lowest engagement upper limit, people already need to be moderately engaged to process 5 choices, and they need to be really focused for 7. These principles apply to people focused on using a computer with a large screen in front of their face, and surely degrade on smaller devices with distractions around.
if you have a shit-ton of navigation items, get rid of some, because having fourteen is _not_ increasing engagement.
Sometimes, in the real world, clients want things a certain way and you are paid to make them that way. I would like less navigation options, but a big app has multiple things. That's just a fact of life sometimes - regardless of information architecture theory.
I like the approach to this article, and the demos it provided. I think there's a place for both, but I don't think that the "more" in the basement navigation is anywhere near as good as an actual menu. The problem is still that many people don't know that the hamburger icon is a menu icon, but with it's growing use I think that will change quickly.
Unrelated, but did anyone else think the title was related to food? That's the first thing that popped into my mind when I read "hamburger menu"
The hamburger menu experiments by James Foster are interesting, but the problem is that they assume the primary goal is navigation clicks. Rarely is a navigation click a bottom line business metric for a company. Almost always you want the user to convert into a customer for whatever you are selling. A more compelling experiment would be one that shows results for both a primary action of new visitor to customer as well as nav click conversions. The fact that fewer users click on the navigation is not necessarily a bad thing.
One of the key itches this article scratches is the issue of the hamburger menu that just appears in a design mock because it's how things are done nowadays. It's almost insulting to deal with people who care so little about the "bottom line business metrics" you mention that they throw things in there, like the hamburger, without justification in context.
It's not even a question of business metrics at that level. It's simply a question of thinking about how you want people to interact with your website, and a lot of designers (using the term as generically as possible--anybody who is planning a site, be they a graphic designer or developer) don't even get that far.
Agreed. There may be cases where a hamburger menu makes sense, like a news app where you can switch between sections. The article shows a solution with the search bar moved to a more prevalent position and other menu options dropped to the bottom - this makes sense if users reach destination pages in the app via search. It's good to think about but I think the article missed the point of starting with the objectives first (customer's needs) and working backwards to find which menu layout is best.
Low discoverability and less efficiency are not necessarily bad.
If I need to have specific functionality available but it's not something I use 90% of the time, then I gain nothing by making it more visible and efficient. If anything, interfaces may become more cluttered.
I thought this was going to be an article about actual hamburger menu's.
On that note, I would like to share a bit of information about the best burger I've ever had. I made an account just for this. If you are ever in the NYC area and you enjoy hamburgers, go to the Minetta Tavern in Manhattan. You will not be disappointed. I consider myself at least an intermediate burger-eater and Minetta carries the single best burger I have ever had. It is called the Black Label Burger. To me, it is a 9/10 where the next best burger I have had is a 7/10 and my average rating is a 4/10. Personally, I find cheeseburgers to be the best, but the standard Black Label Burger at Minetta has none. It is a testament to its greatness that I didn't add anything to the burger and it still is my favorite.
Look up the Black Label Burger. I can't get to the article while at work.
I don't get why these menus can't just appear as overlays.
I am not a fan of having to scroll to a menu it can be disorientating. Like on a web page: you read and move down the page, you want to glance the menu, you have to go back to the top (home button) and then try and find your place in the text again. Overlays, popup menus, would be better there also. In my mind a website should be able to register actions with the browser, and that would get tied in with the device/app navigation.
Why? Because the solution offered is if you really must have more than 5 navigation items, use a hamburger. Oh I forgot, the "scrollable" navbar is a second "solution". AWFUL. This article is as bad as I thought.
I think like most things in good UI design, the rule is:
"Make common user tasks as friction-less as possible."
Now, when a common user behavior is to use the main menu to switch between many different places in the app, then yes, hiding that menu from the user introduces an additional step. That creates additional friction. A permanent menu would be a good idea in that case.
But, if the most common use case involves a user mostly navigating from a main page (like a timeline or feed), then hiding the menu becomes less of a big deal. They will "organically" navigate through content from the timeline. Therefore allowing more space for the main element (the timeline) makes sense and increases the quality of the user experience.
As a plus, removing items from the screen helps make the action that you'd prefer the user to perform more obvious. That increase conversions in a context when you want the user to do certain things.
Lets focus on good UI/X design, which is often case dependent. No need to evangelize one particular approach and condemn another as being worthless (especially when you have weak reference studies).
Facebook is one that comes to mind when I read this since they started with the side hamburger style, but have switched to the standard tab bar on iOS in more recent versions. They show the current version in the article, but didn't mention the transition.
I'd be curious to hear from someone at Facebook if they're around today since I've heard they're pretty data-driven.
For content sites, it's probably fine. But for more functional sites, a lot of hamburger usage seems to be simply avoiding having to put some energy into your app's design.
Most of the apple apps put the buttons at the bottom and include a "more" if necessary.
My sense is the hamburger became more prevalent when it was used by default in Bootstrap, et al.
Trading off screen space for feature visibility cannot be good for content-heavy applications.
You can always trigger or "force" interaction on the user but you can't force content on a user after you lose screen space.
I'm sick of reading late criticisms about standard stuff that made its way into Android guidelines.
There was the Dashboard, then there was Navigation Drawer, now Google+ completely changed a few things altogether.
If you want to make all features so visible, then why not use Dashboards ?
In one screen, you list all critical features and in subsequent screens you have all the space for content. [Ignoring the fact that Dashboards make the app look old]
Or heck, we had real Menus before that, magically, heroically placed in lower part of the screen!
Not an ActionBar on top of the screen where you strain your thumb in mega screens.
But no... definitely no.
Everybody has to advertise something else.
It is a newer pattern so I would expect there is friction. The problem is if there is any serious amount of depth to your app you need to overflow the access to the other features somehow and this is, in my opinion, a good way to do it. I think that given enough time and it becomes a pretty common pattern the pain of discoverability that the article brings up will not be an issue. Most of the arguments brought up in the article are only valid in apps with focused small sets of functionality. I think the move Google did with the Google+ app is a good(bad) example, they got rid of the hamburger menu in favor of a combination of several menus (bottom menu with a expanded menu at the top). I find trying to find things in this new app painful. The hamburger menu excels as a landing point or a dashboard access to functionality.
Food for thought and further research: Now that fast food menus have become a popular but unhealthy user interface metaphor, people should consider picking pie menus, which are faster and tastier than hamburger menus.
+1000. Why limit the actionable area to unveil a menu to an icon at the top left part of the scree (hard to reach on big screens), while the whole screen could be actionable.
One problem with traditional menus and other UIs on any kind on touch screen is that you can't see through your hand, which covers up what you're pointing at, so user interfaces designed for a mouse driven cursor don't work well.
I'm developing 3D Augmented Reality pie menus for Pantomime, that you pop up by touching the edge of the screen (which is easy when you're holding the phone), which pop up in the center of the screen where you can see them, you control them by tilting, they stay in the same position in 3D "augmented reality" space, and they provide nifty continuous animated feedback!
That way the actionable area is the entire space around you -- a LOT larger than the screen!
With normal cursor driven pie menus on a big desktop screen, the further you move the mouse, the more angular precision and leverage control you gain over the selection. Pantomime 3D AR pie menus let you tilt to point out a lot further than the edge of a tiny phone screen!
By the way: we're looking for investors, and we just won first place in the Digital Media / Mobile category of the Launch Silicon Valley Startup Competition!
I agree that the article was not effective in introducing the topic and the problem space. I'm interested in mobile ui, but not familiar with all the new terminology, so this article was difficult to read. I scrolled down until I got to the conclusion, which was fortunately fairly clear, and then went back to understand the beginning.
It didn't help that the screen animations were too fast and lacked context. They also lacked user motions. Aren't there some standard ways of displaying tap and swipe events on a mobile screencast?
If you couldn't figure out what hamburger menus are after reading part of the article (presumes my including seeing the 3 images of such at the top) then you just weren't trying.
The interesting thing about it though is how fast it's being adopted. Right now it might have some poor performance in some instances but I think eventually it will be so prevalent that the hamburger icon will turn into a convention people understand.
They had to label the hamburger itself as "Menu" too -- I bet user testing revealed that people had no idea how to get to the rest of the site. Its pretty rare in websites, though, which could partially explain that.
Second, this is not so much a reflection of fly-out/slide-out navigations as it is a reflection of the fact that on mobile you just have less screen real estate period. Nowhere in that article is there a real reckoning with that fact.
I've yet to be convinced that fly-out/slide-out/hamburger navigations are worse than the alternative when you have lots of items to display. Either way you're not going to be displaying something, and whatever is not immediately visible will receive reduced engagement. If your home page/screen is full of navigation items, something else will be hidden instead.
Not to mention the article provides solution for cases that have many navigation items - something that is very common.