I've never understood the hate for the "Hamburger button". It's here, it works fine and doesn't hurt anyone.
Some options just don't need to be in the face of the user 100% of the time. Why do I need a "setting/more" button at the bottom of the screen all the time?
I can understand, it's often overused. Some applications would be better by using "tabs", some would be better by just placing the most-used buttons somewhere in the screen when you can always watch them. But why not doing both? Put your most-used features in an easy and discoverable position, hide stuff that the normal user don't need often in the hamburger button (A good example for that is the Play Store, the slide menu has a link to settings, an about, and the user picker to switch user).
Also, the proposed solution is to have an auto-hiding tab bar. Please, please, think twice before implementing this. It's really annoying to have something popping up and disappearing when I'm interacting with your applications, and not with your menu.
The Hamburger button has the advantage of staying to his place until the user decide to interact with it. This kind of tab bar instead is almost random. The user has to scroll up/down to show/hide it, which one already do when interacting with the applications. Also every applications seems to do it slightly different, so pulling up half of the screen might be enough in one, but not enough to show it in a different one.
So, the hamburger button might be horrible, but the tab bar is worse, at least in my opinion. The user interact with it more just because it's getting more annoyed by it.
As an additional note, see the recent Google+ for Android redesign, which removed the hamburger button. Now it has two bar at the top of the screen which disappear/appear while scrolling, occupying almost 1/5 of the whole screen. Plus a "+" button hovering the content all the time. The general consensus (at least, the one I've heard) is that it's a terrible upgrade.
In regard to the Google+ for Android "redesign".. Roman Nurik confirmed, this morning, that the navigation drawer pattern isn't going anywhere anytime soon. [1]
Also, if any devs are thinking of including a bottom tab bar for their Android apps, please don't. [2]
The navigation drawer is ergonomically equivalent to the deprecated "dashboard," except for touching to the right of the drawer to dismiss it. It looks a bit better, but it works just as poorly, being a place where you can do nothing but go to some other place.
As for the warning against using a "bottom tab bar" that's an iPhone idiom that should not be carried to Android. BUT Android has a split Action Bar option that is an Android-kosher way of displaying commands along the bottom of handset-sized layouts, and automatically putting them in the top action bar on large tablet-sized layouts.
The screen shot next to the "bottom tab bar" discussion is a bit confusing. It does not actually show tabs in an action bar, as the caption indicates it should.
Who cares what performs better in user tests, right? User behavior is clearly imaginary, you should just do what Google tells you to in their design documentation, because it's 'consistent', regardless of whether it makes it harder to use your software or hurts your revenues so you can't pay salaries. Consistency is most important!
"It's here, it works fine and doesn't hurt anyone."
Do you have any stats that shows it works fine? Do you have any stats that shows it doesn't hurt users (not understanding navigation or not able to complete their task)?
Cause what I see is you basing your view on this pattern and generalizing a statement for all users.
Oh, that's sure better. I missed the "persistently" in the article, my mind automatically assumed that it was auto-hiding (must be the late hours).
Anyway, I still don't agree that it's always better than a sliding menu. Sometime it is (when you use it exactly as you would use tabs), sometime it isn't (when you use it to show options that nobody really cares about) and sometimes both can easily work together (when you have tabs and options). It's just bad advice to say "don't even think about it, just kill the hamburger button and switch to tabs already".
There is a reason is we still have menu on the desktops (even if the trend lately seems to kill them), which is because those "mostly useless" options aren't that useless 100% of the time, and it's always good to have them somewhere that doesn't occupy space.
It's funny to see these trends in UI, starting in the early 90s it seems they gained more and more toolbars and features and navigation elements while reducing content area, then in the middle of the last decade they started getting hidden more and more behind menus and layers of menus (it continues today) to increase content area, and now we're at a point where opposition to this movement is becoming more apparent.
For me, the biggest issue I see with the example hamburger buttons there is that they don't look like buttons --- they look more like an air vent/grille, a stylistic thing rather than "touch here to get more".
>For me, the biggest issue I see with the example hamburger buttons there is that they don't look like buttons --- they look more like an air vent/grille, a stylistic thing rather than "touch here to get more".
Agreed, but if the trend continues eventually it will become known as the menu. It took my way to long to figure out what the hamburger did across all the apps and devices. I really disklike it in firefox and chrome on desktop, it seem unwarranted, but I guess firefox's change is just conforming to what the designers see as a common icon set.
I see two issues with menu / option icons.
1. There is no universal icon. There is the 'up' arrow on some IOS and android apps, the '...' on android, and now the hamburger. The fact that the hamburger doesn't look like a button will become irrelevant once the general user associates it with a menu. I personally don't like it either, but all I really want is consistency.
2. Related to this consistency, the hamburger button doesn't always perform the expected function. Both of these are UX issues that cannot be easily standardised. It really is noticeable when it 'breaks' the flow of the application by changing the state of the main window instead of offering a menu. I can't recall which apps I use do this, but I remember being frustrated, much like the abuse of the back button on android (I think google play breaks this on the My Apps sections).
> For me, the biggest issue I see with the example hamburger buttons there is that they don't look like buttons --- they look more like an air vent/grille, a stylistic thing rather than "touch here to get more".
Why do you consider that an issue, if I may ask? The generic nature of the button is exactly why I think it's actually a good icon, as it universally seems to mean 'tap this for more, but without completely losing your current context (as opposed to a back button, for example).
Any less-generic icon would not always be appropriate, and thus make this functionality less predictable.
Not that I think it's a good UX pattern, by the way. I'm just saying that if you're going to use a 'more' button, this seems like a better solution than custom buttons where you're not sure what they'll do.
I don't think that the hamburger button was ever meant to look like a button. It's supposed to be a place that you can drag and move like a grip. The interaction where you can tap it and a menu will appear is just their for user convenience.
I apologize in advance for potentially thread-jacking, but this story reminds me of an issue on which I'd really like to get other HN readers advice:
I'm seeing more and more stories online including animated GIFs by default like this one does.
Even when they add value to the story, I find the constant motion distracting at best, and seizure-inducing at worst.
Does anyone have recommendations re: the best way to block animated GIFs from auto-playing in Chrome?
Quick initial searching turned up this Stack Exchange thread http://superuser.com/questions/23655/how-to-stop-animated-gi... but the user script listed no longer seems to be available, and there is a debate in the thread re the usability of the other extension options listed.
Check out this [0] post. I tried the first extension and it worked but doesn't pause by default (ESC key toggles gif animation). I didn't try the other two but this looks like what you are looking for.
QuickJava is a Firefox extension that lets you toggle Java, Javascript, Cookies, Image Animations, Flash, Silverlight, Images, Stylesheets and Proxy with individual buttons in your toolbar or addon bar.
Photosensitive epilepsy (seizures triggered by sudden changes in luminescence) doesn't affect too many people, but it's an awful condition and sooner or later one of your users will have it. The general rule here is "no more than 3 flashes per second." [1]
You probably don't have a good design reason to use strobe lights anyway. Slow those .gifs down, please.
The worst part about Firefox 29 was the hamburger button. I couldn't believe it when I saw it.
Aw fuck! Et tu, Firefox?
...was all I could think. As I explored further, my worst fears came true: they had destroyed Firefox's extremely versatile and fully customizable toolbar, and re-architected it as a woefully inadequate and fully customizable hamburger.
</first-world-problems>
P.S. The fact that a floating unicorn appears, when you elect to have an empty hamburger, is little consolation.
The toolbar is still fully customizable, they haven't taken that out.
I agree that the hamburger menu is garbage, though. I guess they felt pressured to move to one since so many other browsers (mobile & desktop) have one so users expect it?
From my experience, scrollable tab bars can be nice – but that is if the user actually knows that the bar can be scrolled.
For example, in VSCOcam (image editing app) I discovered that the tab bar can be swiped/scrolled after two months of using the app, by accident. After showing this to a few other people, I can say that most of them didn't know that either. The fact that the part of the tab that was displayed by default already seemed to have enough options/tools also played a role, I guess.
And in the Twitter, they have this thing that from the timeline you can swipe to "Discover", and it's only shown by a small set of "pagination" circles on top – there's no explicit mention of this, and the circles are kind of easy to miss.
I think you'd have an exceptionally difficult time getting users to enjoy a scrollable tab bar. I've already had enough trouble getting the iOS menu to pull up from the bottom of the screen; can't imagine having to deal with the same for a tab bar in an app.
Good call. Its all about a battle for space and I'm not so sure either solves it. I'm a fan of gesture-based navigation/menus, but the learning curve is pretty steep there.
The original post makes a good point that, paraphrased, it's about improving a flawed information architecture instead of trying to fix symptoms, like the hamburger menu. And though it's tempting to use esoteric, hard-to-use/understand gestures and interaction models, it's almost never the right way. It's that subtle difference between an interface that feels like it's been designed to 'feel smart', instead of something that's easy to use.
I wish developers would put words next to their icons more often. Too many glyphs feel cryptic to me until I just try them at random to see what they do. A big example is the copy icon on Android that pops up. The word "copy" could've fit well there, and as a "high-level" experienced computer user I didn't know that the two papers side by side meant "copy". I actually thought it was "paste" at first. The hamburger buttons with a "more" or something on them probably fared better.
Generally, the reasoning behind not using text on a button (or wherever) is related to internationalization and locales.
Nascent software projects usually don't have the manpower or the budget to translate their user interfaces into multiple languages early in the game.
When tasked with coding a button labeled with text, many developers will simply hard-code the label onto the button, unless explicitly instructed to code the label as a reference to a separate resource of constants containing appropriate label strings.
This can be murder to re-develop, after the fact, when tasked with developing foreign language versions of the same software. You'll find that a team of ten developers have implemented a hundred different button labels, ten different ways, and sprayed them in a thousand places across the whole code tree, leading to partial and inconsistent translations, that need to be tested and re-tested in painstaking and tedious incremental iterations, and then you still have to dive back in and fix bug reports after releasing the translated version because you missed a spot.
To side-step this pitfall, and anticipate the potential for internationalization, one tactic is to implement languageless icons that define the look and feel of the interface. The drawback, of course, being that all users are confused equally, regardless of their native tongue.
I hate the Hamburger Button, but every single iOS and Android app uses it, so it's not like it's undiscoverable. Consistency wins over absolute excellence, I think, and this is consistent. Unfortunately.
Android apps that use an action bar no longer use an option menu button, which, in earlier Android versions, looked like a "hamburger button."
They might still have an overflow pop-up for commands that don't fit in the action bar. That's shown as three stacked dots. That depends on screen geometry and how the app has configured the action bar. Apps can avoid having an overflow pop-up and use, for example, a split action bar instead.
The article's main complaint isn't about the hamburger button per se, but the fact that it often pops out what in Android parlance is called a "navigation drawer." That's what's bad. And Google is pushing that idea as a replacement for a "dashboard" screen which was even worse, and is now deprecated as an official design idiom. But, as the article points out, a navigation drawer is just as much a nowhere-land as a "dashboard." Avoid it.
The article advocates a tab bar as an alternative. On Android, you have the choice of Tab objects that would show different Fragment objects, or a split menu bar. But, better still would be to make navigation an organic part of selection within the app. This has the added advantage on Android of not requiring different tab bar behavior on multi-Fragment layouts.
Some Android apps might have a hamburger menu leading to a navigation drawer, but that is probably due to iOS port-itis, not a deliberate idiom using Android UI elements.
A great example of how people think they can do better than Apple's Human Interface Guidelines only to backtrack later. Stop trying to reinvent the wheel!
Ultimately the HIGs are only meaningful as a starting point for a design. You should user-test your UI and figure out whether any changes you come up with are actually an improvement over the baseline.
In that sense, the only meaningful arguments in the article are that when they A/B and user-tested hamburger menus versus the alternatives, the hamburger menus were worse. Experimental errors and implementation errors in their hamburger menu aside, they were correct to stick with the UI that tested better, even if it defied Android or Apple's HIGs in one way or another.
Apple compiles and publishes their HIG because they benefit from platform consistency and it helps with branding & learnability, but third party developers don't benefit just from following the guidelines. The guidelines are a tool you use to try and get a consistent, learnable UI, and then you deviate as necessary to build something your customers actually enjoy using.
Recently implemented snap.js on a site with the ability to drag the menu from the left as well as press the 'hamburger' button. On iOS I found that dragging from the edge of the screen leads to a hit and miss situation where the user may sometimes open the nav drawer but may also sometimes go 'back' to the previous page. How are people 'doing' navigation right now? I always liked the sliding navs on mobile sites, but where should I have the drag box. The bottom of the screen?
I would have it take up the bottom 80-90% of the page. For me, and most people I see using smartphones, you could get away with a drag box that takes up only the bottom 30% or so (the most comfortable place to perform such a gesture with one's thumb), but it makes sense to handle the edge cases. Also, if someone tries to trigger that gesture and miss, the default behavior is going to be "try it again, but starting closer to the edge and higher up".
In the case of having such a large drag box how should I be ensuring the user can still interact with the content of the page. E.g make sure the hitbox isnt over the top of links and that users can still highlight text etc?
I recommend using the excellent Hammer.js[0] library to pick up swipes (since that's the gesture you're looking for). I've put together a small proof-of-concept here[1]. Try it out on your phone.
Alternatively, if you wanted to have some slick dragging action (so that a user could swipe a little, and control the rate at which the menu drawer opens), you could put a smaller (maybe 10-20% width) dragbox along the left-hand-side of the screen, and keep your selectable content to the right of that.
The only problem I see is that we are getting closer each day to mainstream adoption and just when this is starting to happen it is getting yanked back by UX studies.
Facebook seems to have been a poor example. The only item pulled out from the hamburger pane is the search bar. Which, while nice and all, is not as dramatic of a change as the article seems to make it out to be.
Personally, I really love swiping from the edge of the screen to open the hamburger menu. It's one of my favorite recent UI trends on iOS, and it's never lead to any confusion for me.
I think a mix of a tab bar and a hamburger menu is a good solution. Put the most frequently used items on the tab bar and then have a hamburger menu for everything else.
Some options just don't need to be in the face of the user 100% of the time. Why do I need a "setting/more" button at the bottom of the screen all the time?
I can understand, it's often overused. Some applications would be better by using "tabs", some would be better by just placing the most-used buttons somewhere in the screen when you can always watch them. But why not doing both? Put your most-used features in an easy and discoverable position, hide stuff that the normal user don't need often in the hamburger button (A good example for that is the Play Store, the slide menu has a link to settings, an about, and the user picker to switch user).
Also, the proposed solution is to have an auto-hiding tab bar. Please, please, think twice before implementing this. It's really annoying to have something popping up and disappearing when I'm interacting with your applications, and not with your menu.
The Hamburger button has the advantage of staying to his place until the user decide to interact with it. This kind of tab bar instead is almost random. The user has to scroll up/down to show/hide it, which one already do when interacting with the applications. Also every applications seems to do it slightly different, so pulling up half of the screen might be enough in one, but not enough to show it in a different one.
So, the hamburger button might be horrible, but the tab bar is worse, at least in my opinion. The user interact with it more just because it's getting more annoyed by it.
As an additional note, see the recent Google+ for Android redesign, which removed the hamburger button. Now it has two bar at the top of the screen which disappear/appear while scrolling, occupying almost 1/5 of the whole screen. Plus a "+" button hovering the content all the time. The general consensus (at least, the one I've heard) is that it's a terrible upgrade.