
Kill The Hamburger Button - thomasmeagher
http://techcrunch.com/2014/05/24/before-the-hamburger-button-kills-you/
======
Spittie
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.

~~~
kefs
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]

[1] [https://i.imgur.com/gF7TpEU.jpg](https://i.imgur.com/gF7TpEU.jpg)

[2] [https://developer.android.com/design/patterns/pure-
android.h...](https://developer.android.com/design/patterns/pure-android.html)

~~~
Zigurd
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.

------
userbinator
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".

~~~
neumann
>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).

------
erso
I agree with losing the hamburger buttons, but the Facebook example is
terrible:

[http://tctechcrunch2011.files.wordpress.com/2014/05/facebook...](http://tctechcrunch2011.files.wordpress.com/2014/05/facebook-
ios-7.png)

    
    
      Left: Facebook’s old hamburger button navigation. Right: The new tab bar style
    

Looks to me like they just moved the same set of buttons from the top to the
bottom, adding a "More" button.. which is a hamburger button!

------
tapp
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...](http://superuser.com/questions/23655/how-to-stop-animated-gifs-in-
google-chrome) 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.

~~~
gress
You've had a seizure induced by an animated gif? That is nasty.

~~~
etjossem
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.

[1] [http://www.w3.org/TR/UNDERSTANDING-
WCAG20/seizure.html](http://www.w3.org/TR/UNDERSTANDING-WCAG20/seizure.html)

~~~
Moto7451
The Military maintains MIL-STD-1472 which contains the duty cycle for flashing
text. Here's an interesting (and occasionally submitted) discussion on jzw's
blog: [http://www.jwz.org/blog/2013/08/a-light-has-gone-out-on-
the-...](http://www.jwz.org/blog/2013/08/a-light-has-gone-out-on-the-
web/#comment-132598)

------
qwerty_asdf
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.

~~~
bhauer
> _P.S. The fact that a floating unicorn appears, when you elect to have an
> empty hamburger, is little consolation._

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.

------
arnorhs
(Sorry about the cynical comment)

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.

~~~
grinich
Not if you write for TechCrunch, apparently.

~~~
thomasmeagher
The original article provides some more insight. TC basically took the good
parts. [http://lmjabreu.com/post/why-and-how-to-avoid-hamburger-
menu...](http://lmjabreu.com/post/why-and-how-to-avoid-hamburger-menus/)

------
derwildemomo
Actually, the original article the tc-story summarizes is at
[http://lmjabreu.com/post/why-and-how-to-avoid-hamburger-
menu...](http://lmjabreu.com/post/why-and-how-to-avoid-hamburger-menus/) .

And while I'm not a big fan of hamburgers as well, proposing a scrollable tab
bar as an alternative is.. a bit strange.

~~~
kunstmord
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.

~~~
ahsanup
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.

------
jimmaswell
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.

~~~
qwerty_asdf
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.

~~~
jimmaswell
I don't think lack of manpower applies to the Android OS so much. And even so,
even only having English next to the icon is better than nothing.

~~~
qwerty_asdf
Not so much, Android itself, as much as the apps developed _for_ Android by
third parties.

------
jrockway
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.

~~~
Zigurd
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.

------
rmrfrmrf
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!

~~~
kevingadd
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.

------
dovel
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?

~~~
notduncansmith
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".

~~~
dovel
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?

~~~
notduncansmith
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.

[0]
[http://eightmedia.github.io/hammer.js/](http://eightmedia.github.io/hammer.js/)

[1]
[http://codepen.io/notduncansmith/full/sthyJ/](http://codepen.io/notduncansmith/full/sthyJ/)

~~~
dovel
Thanks for the reply. Great! I will check out hammer.js, I haven't used it
before. Have you used snap.js / what do you think of it?

I don't think your demo works by the way! Doesn't seem to include the
hammer.js file!

------
BorisMelnik
Good UX discussion over at Stack Exchange about this a month or so ago.

[http://ux.stackexchange.com/questions/55807/is-the-
hamburger...](http://ux.stackexchange.com/questions/55807/is-the-hamburger-
icon-a-recognized-navigation-symbol)

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.

------
supercoder
One big problem on iOS is that Apple use the hamburger icon to suggest
'History'. iTunes and I think the podcast app at least use it in this context.

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.

------
kenbellows
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.

------
archagon
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.

------
LukeB_UK
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.

------
reitanqild
Can we kill a subset of the gear buttons, specifically the "mystery" ones, as
well? Especially in Mac apps and wannabe mac apps.

