Kill The Hamburger Button
techcrunch.com
techcrunch.com
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.
Also, if any devs are thinking of including a bottom tab bar for their Android apps, please don't. [2]
[1] https://i.imgur.com/gF7TpEU.jpg
[2] https://developer.android.com/design/patterns/pure-android.h...
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.
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.
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.
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).
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.
http://tctechcrunch2011.files.wordpress.com/2014/05/facebook...
Left: Facebook’s old hamburger button navigation. Right: The new tab bar style
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.
[0] http://chris.pirillo.com/how-to-disable-animated-gifs-in-chr...
You probably don't have a good design reason to use strobe lights anyway. Slow those .gifs down, please.
Aw fuck! Et tu, Firefox?
</first-world-problems>
Haha! I had no idea. I just tested this and had a good laugh. I also didn't know this three-line glyph was called the "hamburger menu."
Since I have never used the new Firefox hamburger menu, I think I'll leave it with the unicorn.
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?
Hamburger button or no hamburger button, this article is a pretty decent example of one that should be taken with a large grain of salt
Hyperbolic, thoughtless, and over-generalized advice, not based on any user stories/scenarios.
You really need to dig a little deeper before generalizing like this.
And while I'm not a big fan of hamburgers as well, proposing a scrollable tab bar as an alternative is.. a bit strange.
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.
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.
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.
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.
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.
I don't think your demo works by the way! Doesn't seem to include the hammer.js file!
http://ux.stackexchange.com/questions/55807/is-the-hamburger...
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.
Not sure if they do this to try and push against the use of it by hijacking the meaning but still adds to the confusion none the less.