The Hamburger Menu Doesn't Work
deep.design
deep.design
Why and How to Avoid Hamburger Menus[1]
Hamburgers & Basements[2]
An Update on the Hamburger Menu[3]
The Hamburger is Bad for You[4]
[1] https://lmjabreu.com/post/why-and-how-to-avoid-hamburger-men...
[2] http://jxnblk.tumblr.com/post/36218805036/hamburgers-basemen...
[3] http://jxnblk.tumblr.com/post/82486816704/an-update-on-the-h...
[4] http://mor10.com/hamburger-bad/
[5] http://gizmodo.com/who-designed-the-iconic-hamburger-icon-15...
[1] WWDC 2014 Session 211 Designing Intuitive User Experiences @ 32:00, available here: https://developer.apple.com/videos/wwdc/2014/
Addendum: It's a responsive design so you can see this even on a desktop browser just by shrinking the width of the window. The top menubar collapses into a hamburger.
Addendum 2: Illustrated transcript here: http://blog.manbolo.com/2014/06/30/apple-on-hamburger-menus
Jobs loudly proclaimed that people didn't read, yet within a year Apple was selling ebooks.
As an aside, not specifically in response to your comment: I find it fascinating that most clients I work with have an immediate dislike of duplication that doesn't seem to be based on any reasonable argument (at least from where I'm standing...).
For example, I've been in a number of situations where a client did not want a 'pricing' menu item and a 'check out plans/pricing' link somewhere on the page. The only argument they really had was that 'it would be confusing to the user'.
This argument doesn't make sense to me, as the average user will just kind of scroll around and if there's a logical point for them to check pricing, they would surely be appreciative rather than confused that there are multiple ways to get to the pricing page?
I can only conclude that it's one of those things where people think 'logically' and prefer some kind of clean hierarchy, rather than consider the end goal ('funnel the user to a particular page').
Or am I missing something important?
Deleted comment
In that session the Apple UX evangelist absolutely rips hamburger menus to shreds calling them "tedious" and "terrible" at "telling you where you are [and] where else you can go". Quite a surprise to see it show up on apple.com, then.
Deleted comment
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.
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.
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?)
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.
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)
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.
(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 :) )
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. (...)"
[Select] [DO!] [Context]
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...
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.
It's unintuitive and undiscoverable, but I wouldn't necessarily call it unhelpful...
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.
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.
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.
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.
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.
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)
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).
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.
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.
One approach is to build a hierarchy
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.
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.
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.
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.
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.
Hey, designer. I know screen real estate on mobile is extremely limited. I know it would be really nice to fill the whole screen with content and just have a little, square, "more" icon tucked in the corner. I know you've tried to establish the hamburger icon as the universal "more" icon.
Too bad. Users aren't catching on as quickly as you'd like. They don't notice, understand or utilize the icon. Even if they do notice and understand, an ambiguous "more" is dramatically less engaging than explicitly showing what they can get. A "more" icon is asking them to expend effort up front exploring your interface with no clear reward in sight. So, they don't bother. Like, a measurable 50+% drop in engagement don't bother.
So, stick to tab bars as much as you can. It seems like a waste of screen space. But, the results still seem worth the cost.
- Most users do understand the hamburger icon, so they notice and understand it, but they definitely don't utilize it.
- It's not really about engagement. Users generally don't go about thinking to themselves "boy that icon looks so engaging and just begs for a click!"
- It's all about workflows and hints built into these workflows.
At any moment on your website/app your users are trying to accomplish something. UI nudges and pulls them in the correct direction towards their destination. At every step the user is evaluating the screen to determine the thing most relevant to moving closer to their goal.
A hamburger button never - and I mean never - tells the user "click me and you'll be closer to your goal!". A hamburger button is utterly neutral in every single way, even to the trained user who knows what a hamburger button does.
- When evaluating the screen to determine what they should do next, almost everything feels more relevant than the hamburger button.
It's not that people don't want to click on the hamburger button, it's that in any particular circumstance some other UI element will feel more relevant (even if it isn't actually true).
It probably isn't helped by the superflat UIs that are the current fad that make it impossible to tell what elements are active or what they do.
It's the kind of thing that makes sense on phones because the screen space is so precious (although with modern phones this is becoming less and less true), but only because you're willing to trade off some usability for getting more content on the screen. For a desktop site or application where you are not space constrained it is just bad design.
(These changes aren't just because of the hamburger menu, obviously. Digital stuff moves pretty fast in general, and companies keep evolving.)
And this is the crucial misinterpretation. Progressive disclosure as defined and used by Xerox is about objects and related actions. And it's all about visible objects! [1]
(Mind the classic example of a square in a drawing application: Clicking the shape discloses editing functions and displays handles to size the object.)
And here is the real problem: The hamburger icon as used today has no other object but the global context. By exposing context to the global context, it's a mere apropos without an object the user might relate to.
When Norm Cox designed the original icon for the Xerox Star user interface, it was a visual anchor for a menu revealing contextual functions to the visible content of the document. (Like selecting rows, etc. [2]) This is notably something else than the global, quite abstract context of a site navigation, disclosing navigational functions to address off-screen content.
Today's hamburger icon is just a paradigmatic misunderstanding.
[1] "A subtle thing happens when everything is visible: the display becomes reality. The user model becomes identical with what is on the screen. Objects can be understood purely in terms of their visible characteristics. Actions can be understood in terms of their effects on the screen. (...) In Star, we have tried to make the objects and actions in the system visible." (Designing the Star User Interface; David Canfield Smith, Byte, Issue 4/1982)
[2] Compare: http://g.recordit.co/8Q5oAYCaVx.gif (Outtake from a ACM CHI 1990 conference video, https://vimeo.com/61556918. Mind that the window-less bar at the top represents the global system as opposed to the document window below and its menu button(s).)
The hamburger icon/menu introduces a metaphor of its own that is not consistent with progressive disclosure as used elsewhere in common interfaces (see above). It's more a "and here is the rest that you may be missing"-icon that isn't motivated by any consistent notion of the interface, but by concern for screen real estate. As a user, we may not assume the content of the menu, but by empirical knowledge and by considering functions that we are missing and that may be hidden somewhere.
The hamburger menu _is_ the application. It's content may be related to only by expectation and assumptions regarding the extent of the application's basic functionality. Arguably, in the light of this considerations, the icon is communicating rather sparsely what it is and what it does. (Actually, it exposes a global, unrelated view on the basic extent of the app.)
While its use may be arguable for an application (esp. mobile apps), it's highly problematic, when used in web sites and web applications. (The difference: While in the former case it's located rather in the window chrome, thus relating to the viewport as an object, it's part of the view in the latter – like a wormhole to the global context.)
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.
But it requires some deliberate thought, effort, and app-specific solutions to replace it with something better, and that planning makes you answer all sorts of hard questions you might've not ever had to answer about your website/product, like "how are my users actually using this?"
I'd wager that everyone agrees that their own site's hamburger menu is a sore spot, suboptimal.
But the next rung up is a taller order than these types of articles admit.
I think a good follow-up blog post would be "Design patterns for escaping the hamburger menu" that showcases a variety of real-world approaches.
The main menu would be absolutely fine on its own; I think the hamburger menu is present because it's present on Windows, which - of course - doesn't have a universal menu. Still, I'm not letting Google off the hook here. These flagrant abuses of usability are things that the average undergrad should be able to identify, yet one of the biggest companies in the world can't? Disappointing.
drumroll please....
alt-F, like it is the File menu.....
So, should we web developers start ripping out hamburger icons on our sites. NO. Avoid groupthink. Implement and test layouts that produce measurable results. Removing hamburger icons is no panacea. What are the users doing? What does the data say? If cargo cult thinking produced an over-reliance on a single navigation icon, we aren't going to solve anything by snapping back in the other direction.
Also, there's a difference between a hamburger icon and a drawer menu. On mobile devices a drawer menu is still a fantastic way to reveal additional navigation options without a page reload over a (potentially) slow network connection. Stuffing a navigation list into drawer menu is an easy solution. But it may produce poor results.
My first impression of these was therefore to try to grab them and pull, as if to slide the bars that they appear on. Unfortunately, even now, most implementations of "hamburger menus" do the worst possible thing when you try to slide them: nothing at all.
And then there's the weirdness of seeing them on the desktop where there is plenty of space. It's the same frustration I feel whenever I see a desktop app force content into a tiny, non-resizable box with scroll bars on a 1920x1200 screen! If I have the space, I really, really want to use it. Any design that refuses to expand to available space is simply wrong.
Nobody ever asked me - for obvious reasons, because I might be blind - but I'm partial to an icon where you have a + sign ("additional" items) on top a V ("directional clue"; could be pointed in other directions for a pull-up menu for example) to form some sort of arrow.
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).
These things don't appear in the vacuum - the Hamburger Menu originated from the Celtic Knot Menu, which was originally at the end of the Ribbon. The Ribbon itself confused the use cases of the Menu and the Toolbar, and was rightly criticized for that.
I am just learning Emacs and it's a little paradox that this aspie guy Richard Stallman is the one who got so many things around the UI right. We are unfortunately confusing "easy to learn" with "dumbed down so much there is nothing to learn".
Select text > Think for a few seconds about which one of these similar looking icons means "copy" > press buttons until I figure it out.
[1] http://www.droid-life.com/wp-content/uploads/2015/02/cut-cop...
I'm sure tons of people don't know about this - I remember it took me quite a while to realize that that's what the '...' represented in Windows/OSX menus - but at least with the dots people have had more than a decade of time to figure this out.
I remember back in the early years of the web (mid to late '90s) and one of the most important factors in designing websites was realizing that users don't scroll. They just didn't, and if your site design relied on that fact then you'd be screwed. But users learned to scroll, and now scrolling is perhaps the most important and most universal method of interacting with the web. In another 10 years will the hamburger menu become so well known and universally relied upon that not doing it will hurt your usability? Or are there fundamental reasons why it will never be good?
"Some people argue that “we just have to wait for users to learn the new navigation convention,” but hopefully you can see how the principle of information scent invalidates that argument. [...] The problem wasn’t that users were confused by the hamburger menu, but rather that there was never a compelling reason to click it in the first place."
The principle of information scent is explained in the previous section:
"Most people navigation based on what’s called “information scent.” When faced with a set of options, they’ll choose the option that gives the strongest indication that it’ll bring them closer to what they want, like an animal sniffing around for food. [...] You know what never looks anything even close to what the user actually wants? A small three-bar icon tucked in the corner of a website. It has no information scent. Even after the user has exhausted every other option, it still might not occur to them that the answers they seek are hiding behind those three bars. Users generally aren’t inclined to click it."
It's not really that users don't scroll, more that relevant informations should be on the top of webpages rather than in the middle or the bottom. It don't think anybody ever said that users don't scroll in 90's .
I think what we are supposed to understand is that this Firefox Hamburger Menu (FHM) is really a TOA: Toolbar Overflow Area. It's a repository of icons for doing arbitrary things.
Its Customize button at the bottom invokes exactly the same UI as View/Toolbars/Customize: a big view where you can move icons between an editable version of the FHM, the browser toolbar, and a repository of available tools (shown in the main pane as a large area).
So any item that can be on your toolbar can go into FHM, including bookmarks. Hence: TOA: toobar overflow area for items you don't use much.
It would be better if they initialized it empty, and if it somehow clearly communicated "Hey, I am a toolbar overflow area: put stuff here that would go on the toolbar that you don't need so much, when you don't have space on the toolbar."
A hamburger on its own is, like the article says, dead weight with no meaning. If its on a bar with a bunch of other nav options and you feel like the one you want is missing you often use it.
If I ever get around to it I'll hack up the bootstrap code and make it tab based (icon + text underneath) but that seems like a PITA with how bootstrap does its layouts in nav bars from my paltry experience.
There are two reasons why the signs on the highway are so prominent:
1. When you are driving a car, you are basically meat bags inside 1.5+ ton collapsible metal cages moving around at 30+ or even 100+ km/h. One wrong move and meat bags risk being injured or killed. That's why the signs need to be simple and prominent.
2. A highway network has one and only one purpose: to transport people and things around, so the number of things that you can do on a highway network is inherently rather limited, which is why you can make decisions fast: go faster, go slower, stop, yield, merge, change lanes, exit a ramp, enter a ramp, turn left, turn right. That's why the signs can be simple and prominent.
Neither condition applies to websites in general:
1. If you lose your way on a website, you generally won't injure or kill anybody.
2. Websites generally don't have one and only one purpose, the number of things that you can do on a website cannot be expected to be limited. You could argue that the website menu should have one and only one purpose - to bring visitors to various pages - but that's not always true either.
list of reasons people are doing dumb thing, mostly blaming the people
Can we be honest here for a second? The reason people are still using hamburger menus is because people have to make things work for phones. Phones with screens that are vastly smaller than the screens on even the smallest laptop, even for people who are hauling around the biggest phablets they can find. And people with phones want to visit the same websites they visit on their computers and there just... isn't... room. The hamburger menu gives you close to double the space to work with, from a UI point of view.
The alternatives presented are partial solutions. It may well be true that more people are reaching for the hamburger menu than truly need it. But the tab bar example from the article only scales up so far before it stops being a valid solution. And I don't know if there is a really good answer that doesn't involve rewriting the web from the ground up.
What's wrong with moderation? Day-to-day navigation elements shouldn't be in a hamburger menu (also, an extra 'click' for common tasks is bad), but there are plenty of non-everyday things that can go in there.
You're blaming designers , I'm blaming developers(and managers) who can't tell a good designer from a bad one and choose to work only with people that "gravitate to extremes in these fads"(ie a majority of startups) Even Google and Apple are not that dumb, they know flat design is stupid,they actually have the data to prove it, thus they kept some depth within their UIs and don't hesitate to use border shadows ,even on mobile, while trying to "refresh" their UI, because a few influential SF bloggers were bashing their "lack of minimalism".
Flat design makes absolutely no FN sense, from a UX stand point in an app on a computer. If I can't tell what I can interact with and what I can't, I'm not going to play a guess game, I'm going to move on and use something else. I'm a big proponent of skeuomorphism and I don't care how ugly it looks. It's all about usability. If it can help convey the purpose of a feature then it's a good thing.
What makes sense on a poster, a printed magazine or a book doesn't make sense for an app or a website.
Their design had what looks like a menubar which is the precise anti-pattern to a menu-button. Those items, and what is showing already as top page content, is guaranteed to catch everyone's attention first. Those menu-button items are not only hidden and require an extra click, by design they have been made less important. And since so many sites have de-cluttered themselves by simplification, users' first impression is that they got rid of everything for the better... except it wasn't what they did, so basically everything under that menu was unreachable.
Two things would have been better. First, they could have kept the menu icon but had it expanded on the top page so that people would see those items as top page content, and also make the intuitive connection that there was a button that's associated with them. When the reader goes deeper, the menu items could then safely be hidden, with the user intuitively fetching them via the button as needed. Second, they could have given the button a name, instead of use the icon. For example, Amazon's "shop by department" button is the equivalent of NBC's hamburger menu. But since they have a menubar, instead of having a menu-button on a menubar, they put a menu-item instead by giving it a name and an equal member of the top selection. This upholds the primary design pattern in use.
NBC's designers went for the hamburger without knowing how to use it or understanding what made it popular. You cannot mix competing philosophies and color is no substitute for broken intuitions. Even now that they settled for the menu-bar, they don't have an at-state, under "more" we see the same items in the menu in different order, and they use the pinned menu that doesn't go away even when you scroll -- a design already falsified by the frame paradigm of 1999.
Also this may not apply to apps, but on the web the hamburger is an indirect result of responsive design techniques where a navigation menu has to compress due to limiteds screen real estate in mobile.
But the funny thing is that as a designer I hate the hamburger because it does feel like a hack. Yet I can see the popularity is due to trying to have something work on both mobile and desktop.
In fact if you look at mobile only apps they tend to avoid the hamburger trap (example: Instagram) but if you look at any app with a desktop legacy (example: Facebook) you almost have to need it (unless you are willing to cut features or make a suite of apps).
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 :-)
I might also refer to it as the 'vent', since it seems to heat up after a few months of not restarting my browser.
That hard button was even better from a real estate point of view, and since it was consistent across all apps it seems like users ought to have grasped it.
The surprising and important thing here is that, even if the user knows the menu is there and that, if asked, it could help them, it doesn't appear salient and doesn't get clicked.
Deleted comment
The point I took away was that menus should have logical, semantic purposes, and common functions shouldn't be buried inside them.
http://deep.design/wp-content/uploads/2015/07/B82uUMQCcAE4Eo...
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.
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?
Yet another tool for "screw the user" UI design.
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.