[HN Gopher] The core problem with hamburger menus
___________________________________________________________________
The core problem with hamburger menus
Author : todsacerdoti
Score : 101 points
Date : 2023-05-05 18:18 UTC (4 hours ago)
(HTM) web link (bt.ht)
(TXT) w3m dump (bt.ht)
| psygn89 wrote:
| The only thing I would change is calling it "Menu" instead of
| "Sitemap" at the top. Saves more space and is understandable by
| all.
| amadeuspagel wrote:
| The most basic aspect of the hamburger menu, which the "sitemap
| footer" lacks, is that it toggles. You click on the hamburger
| icon to open the menu and then you click the same icon in the
| same place again to close it.
| throw-4e451c8 wrote:
| My 80+ mom still doesn't get hamburger menus in e.g. bank apps
| even though I've explained them a few times. They are obviously a
| discoverability fail.
|
| Meanwhile she's _surprisingly_ proficent at using Google and the
| mobile web non-logged in /preview version of Facebook to read
| gossip from the village she lives in, sometimes in very creative
| ways due to limitations FB put up for anonymous browsers. (She
| refuses to get a Facebook account.)
|
| No undiscoverable hamburger menus involved in the navigation
| sequence above. I think Google and FB get it.
| pcurve wrote:
| You know what gets me... is, when web sites only show hamburger
| menu in desktop viewport despite having plenty of space.
|
| I would try to enlarge the browser window to see if the full menu
| shows. Nope.
| ghstcode wrote:
| Why? They work just fine.
| cmdialog wrote:
| [dead]
| techn00 wrote:
| What do people think about a sticky footer on mobile? Easy to
| access & familiar
| mgaunard wrote:
| I wished I knew what a hamburger menu was.
| chiefalchemist wrote:
| Maybe. But not on my "Please God Make It Stop" list.
|
| - Stop using hovers when there's no indication I need to hover to
| see what I need.
|
| - Stop using hover that requires mousing over a limited sweet
| spot (else the nav closes)
|
| - Stop with your over zealous forms.
|
| - Stop with your forms that give ambiguous errors.
|
| - Stop with the loading spinners for pages that aren't that
| content heavy
|
| Etc.
|
| - Stop having required form inputs and not making that clear.
| yuters wrote:
| > It seems like most people _don 't actually like hamburger
| menus_.
|
| Is there a source for this? If there was a poll or something I'd
| be curious to see.
| cmdialog wrote:
| [dead]
| spinbutton wrote:
| How is having a button that jumps you to the bottom of the page
| different than a button that opens an offscreen menu? I'm not
| sure this argument scales particularly well.
| dinkleberg wrote:
| Using a footer as a replacement for a nav bar is ridiculous.
| Which requires more interaction? Clicking a button to see
| available actions or scrolling all the way to the bottom of the
| page (and making the bold assumption that you happen to know that
| the menu is at the bottom)?
|
| If you've got sufficient space at the top of your page to show
| your nav items, especially for larger window sizes, just show
| them instead of hiding them away behind a menu. But if you have
| limited space, like on mobile, a hamburger menu is a fine
| solution.
| cleansingfire wrote:
| Assuming the bottom is even accesible! I believe it's somewhere
| in the Amazon ios app where I see a promise of a useful footer
| that is always pushed off the page by infinitely scrolling
| things they're pushing at me instead.
| function_seven wrote:
| My favorite thing is when a website or app places a bunch of
| icons at the extreme bottom edge, and my tap there is
| confused by iOS as me interacting with the app switcher bar.
|
| That's always fun.
| throwaheyy wrote:
| This is very annoying. In Safari, clicking icons in that
| style of nav bar instead brings up the browser's
| back/forward buttons, and requires a 2nd click in a new
| location now that the nav bar has been offset by the height
| of the back/forward buttons.
| boosteri wrote:
| That's their mobile layout in general. In their view they
| must have improved UX immensely since no mobile person has
| needed help/support since introduction of infinite scrolling
| permo-w wrote:
| yesterday I tried to access customer service on my phone
| and I was unable to figure it out. the phone number told me
| to toss off and the chat link (even in desktop mode) just
| redirected me to the amazon app page in the App Store, an
| app I already have downloaded. I had to go on my laptop in
| the end
| vxNsr wrote:
| My wife chats with them so often, in the app I just have
| to go to hamburger menu > contact us > return to chat.
| joshspankit wrote:
| I literally showed that to someone the other day as an
| example of nonsense ways to build UIs.
| medstrom wrote:
| Protip: navigate to a different page, not a listing of
| products, then you may be able to scroll to the footer.
| Kwpolska wrote:
| Unless the app has an infintely scrolling list of
| recommended products or reviews or reviews of recommended
| products.
| misterprime wrote:
| You're misrepresenting the recommendation. You did not include
| the instructions "link directly to [the footer navigation
| options] from your header" or "Be sure to also include some
| form of "Top of the page" link for quick access back to the
| initial scroll view."
| bodge5000 wrote:
| Why put a link to the footer in the header which contains
| links to other pages when you can just put your links
| directly in the header?
|
| I know the reason why, because it makes the page cluttered,
| whereas having it at the footer does a better job of hiding
| it. But isn't that the exact problem that the hamburger menu
| was made to fix?
| misterprime wrote:
| That question is addressed in the article as well: "The
| biggest headache when coming across these menus on the web
| is the complete disregard for accessibility."
|
| And by "accessibility" I'm quite certain the author means
| "usability for people with impairments that don't allow
| them to use a mouse and keyboard or touch screen".
| Spivak wrote:
| > Which requires more interaction? Clicking a button to see
| available actions or scrolling all the way to the bottom of the
| page
|
| I mean honestly clicking the sitemap button on the OP is faster
| than than any SPA opening a menu.
|
| Your average site already has a bunch of links in the footer,
| if the argument is that footers are useless and should be
| eliminated then sure. But otherwise embracing their existing
| purpose is a good thing.
| bmelton wrote:
| To be fair, the only reason they exist in otherwise
| minimalist apps is because they need to be there for
| crawlability. A hamburger menu that isn't visible until
| someone clicks on it is an SEO problem that is (sadly) easily
| mitigated with a footer, which has bled into the problem of
| the big footer, wherein people hamfistedly use the footer to
| solve the entirety of their crosslinking strategies, which
| (at least for me, but maybe I'm the weirdo) makes it
| impossible to scroll to the bottom of the page to get to the
| meat of it without having to usually scroll almost all the
| way back up.
| tomkarho wrote:
| I see footers working as a usable nav bar only if the number of
| navigation elements is small enough and the footer is sticky
| (always visible and at the bottom).
| misterprime wrote:
| Interesting. I was thinking the header which contains a link
| to the footer could be sticky. That way, it wouldn't matter
| how large the footer became.
| tobr wrote:
| It's not ridiculous. Look at how it's done on the page itself:
| a link to the footer in the header. I'd argue that the word
| "sitemap" isn't a great choice for the link text, but the
| interaction itself works ok.
| waboremo wrote:
| If we're using this page as an example, they could have fit
| the entire navigation menu at the top of the page just fine.
| If it's pointless even at this small scale, what good is this
| going to do implementing on larger platforms like Amazon?
|
| I agree with the "stop resorting to hamburger menus so fast"
| take however.
| Kwpolska wrote:
| Exactly. The links fit very nicely at the top, and with
| just four CSS rules, I got this:
| https://i.imgur.com/7VH4UJ6.png
| permo-w wrote:
| Amazon already does this but without the link
| crimsontech wrote:
| I just assumed it would take me to a sitemap so I didn't
| click it.
| sametmax wrote:
| I assume they mean a sticly footer.
| eweise wrote:
| I agree. Part of what sucks about websites is that everyone is
| trying to things differently. When I see a hamburger menu, I
| know what it does. It would take me a long while to figure out
| your site's navigation sits at the bottom of the page.
| muxator wrote:
| This depends on when you started using the web. 15 years ago
| an (additional) navigation bar at the bottom was not
| surprising.
|
| Hamburgher menus, albeit fancy, where really confusing at the
| start. Personally I still think overusing them is design
| laziness.
| eweise wrote:
| Have to agree to disagree then. You're design laziness is
| my "grateful for consistency so I don't have to learn your
| navigation"
| [deleted]
| spacedcowboy wrote:
| Ah, so that's what a "hamburger menu" is.
|
| I think anyone doing "Down with X" ought to define X...
|
| And I think I like them, anyway :)
| HankB99 wrote:
| I came here looking for food. :-/
| bwb wrote:
| Ya I don't understand that comment, no users go down there when
| you actually test.
|
| It isn't a bad secondary navigation, but kinda odd to say.
| erickhill wrote:
| Agreed. Where I work, less than 10% of users even seen the
| footer regardless of the pages they visit.
| pseudosavant wrote:
| I wonder about using this _with_ a hamburger menu as a form of
| progressive enhancement?
|
| You would still use a hamburger menu that requires CSS and/or
| JS (it can be done in just CSS). You'd have that same content
| in the footer of the page. For the JS disabled people, you'd
| have a `<noscrip><a href="#footerburger"></noscript>` at the
| top of the page where the hamburger would be. So if a user
| clicks on it, it will jump to the footer that contains the
| exact same content as the hamburger.
| WWLink wrote:
| I agree. Start using Taco Menus!
| Nijikokun wrote:
| This doesn't work for infinity loading. Hamburger menus are often
| fine in practice and work like every application settings menu
| anyway.
| bogwog wrote:
| How about a hybrid:
|
| Hamburger menu-type icon in the header, but it's just a URI
| fragment that points to a tag in the footer. Clicking it will
| just jump the view to the footer, which can be designed to fill
| the entire viewport on mobile so it looks like what people have
| come to expect from a hamburger button. An ambiguous up/back
| arrow will jump the viewport back to the header. CSS can be used
| to make it look like it's fancier than it actually is, without
| resorting to javascript.
|
| Jumping back won't work great for sticky headers, but that's a
| feature since it means you'll be less likely to use those awful
| sticky headers.
| noelbautista91 wrote:
| One look at a the footer option (not disagreeing with it, btw)
| and I can already see product and design teams crapping on it.
|
| Product usually wants something to look familiar. "Can we make a
| website like _pulls up phone_, I want ours to look modern".
| kzrdude wrote:
| I use linux and hamburger menus in Gnome is one of the greatest
| tragedies. The global menu bar in macOS is a really nice thing,
| it's steady. It's a shame several linux DEs now have a top bar
| but none of them use it in this useful way.
| rickstanley wrote:
| KDE has a Global Menu plasmoid. Unfortunately it falls into the
| plasma's discoverability pit. Even if it did not fall into
| this, there are non-QT apps that don't export its menu to the
| DE, for instance: Firefox
| (https://bugzilla.mozilla.org/show_bug.cgi?id=1419151).
| droptablemain wrote:
| I'm not aware of any overwhelming disdain for hamburger menus
| among users. I'm all for accessibility improvements for sure, but
| at some point there has to be discussion about the trade-off of
| making something worse for 98% to accommodate 2%. That doesn't
| really make sense in general.
| karaterobot wrote:
| > The biggest headache when coming across these menus on the web
| is the complete disregard for accessibility.
|
| It's not clear to me how a hamburger menu is, by itself, an
| accessibility issue. It can be implemented in a way that makes it
| inaccessible, sure. But, if properly labeled, etc., what is the
| intrinsic difference between a hamburger menu and a dropdown
| menu?
|
| > So instead of just whining about hamburger menus, I will
| actually offer up a solid replacement: sitemap footers. Simply
| place all your website/application links into the bottom footer
| and link directly to them from your header.
|
| Ha ha, no. Now I understand that the author is approaching this
| from a narrow perspective: they're thinking about only navigation
| links, and only on fairly simple websites. A complex website, or
| a web app that uses hamburger menus to hide less commonly used
| actions, could not follow this strategy.
| SoftTalker wrote:
| Well in the beginning menus were always at the top of the page,
| or split between the top (horizontal) for main sections, and left
| margin menus for section-specific menus.
|
| Then we got various trees and drop-downs and expandable widgets,
| as browsers and technology became more capable of supporting
| them, eventually sort-of-standardizing on hiding it all behind
| the hamburger icon.
|
| Now we want menus in the footer? Maybe I'm too old but the bottom
| of the page is the last place I look for anything.
| etchalon wrote:
| While Hamburger menus are terrible, users have come to expect and
| look for them.
|
| Accessibility issues aren't unique to hamburger menus. Bad
| developers will implement all sorts of design patterns in in-
| accessible ways. There are ways to implement hamburger menus with
| good accessibility. We do it a lot.
| JohnFen wrote:
| I still don't understand why hamburger menus are a thing. They
| check just about every box for "bad UI design".
| ghusto wrote:
| Honest question: What problem did hamburger menus solve?
|
| I remember menus before. They were there, they were obvious, and
| they didn't need someone to explain them to me. The first time I
| was on a site with a hamburger menu, I'm not embarrassed to say
| that it to me _minutes_ to figure out what it was.
|
| I see how they're not as obvious, and would make that trade if
| they solved some serious worthwhile problem, but what was that?
| Brendinooo wrote:
| You need your menu design to work at every viewport width
| between 320 and 1900+. So if you want to have your top level
| items on the screen at all times:
|
| 1. You have to decide if your top-level menu will be dictated
| by the smallest width or not
|
| 2. If not 1, then you have to decide what will happen when a
| lot of menu ends up in a smaller space. Do you wrap it (and
| risk using up your "above the fold" space on menu items) or do
| something that requires scrolling/opening submenus?
|
| Also, whatever design you come up is almost inevitably messed
| up after handoff, when the client adds a word to a top-level
| item or adds five more top-level items.
|
| Hamburgers solve this by giving up a bit of usability and
| gaining a ton of screen real estate to work with as a result.
|
| As a designer-turned-developer, I've warmed to them over time,
| as has the Internet at large. If it helps, maybe consider them
| as a "the worst solution, except for every other solution" sort
| of thing. It's a pragmatic choice. And it's not like menus
| aren't a common paradigm of computing anyways.
| JohnFen wrote:
| IIRC, they came about because of smartphones having limited
| screen space which made normal menus problematic.
|
| In that view, I understand them even though they're terrible. I
| just wish they'd stay on smartphones and not appear elsewhere.
| INTPenis wrote:
| Watching my 80 year old dad use Google Photos web UI on his
| desktop computer I realize that hamburger menus, or three dot
| menus, were meant for small screens where realestate is at a
| premium. On large enough screens they should be words like
| "Options", or "Menu".
| chadlavi wrote:
| here's a better idea: stop having unilateral rules about menu
| layout. Different use cases require different layouts and
| interactions. You could maybe say "don't just default to
| hamburger menus."
| uzername wrote:
| Certainly an interesting take with the footer as the nav. It
| could work on information centric sites. It might seem strange
| working in a web app or a hybrid environment, where portions of
| the site lean towards app while others don't.
|
| Looking at the comments here, that's highly skewed towards
| desktop use, guessing at the HN audience here, skilled with
| computer usage and decent handlers of visually dense information,
| I think most common users aren't like that. Many are using
| smaller screens, many are on mobile the majority of their
| computing time. When they do have larger screens, their glaze
| over when there's too much to look at (I think because they're
| not used to it, and too busy to ever get used to it, but either
| way). All of that to say, the hamburgers aren't for us, they're
| for secondary flows for common users.
| pentagrama wrote:
| I think the main issue with hamburger menus is the lack of
| labeling them, the icon + the label "Menu" improves a lot. Don't
| see the op solution convincing, but I will suggest always add a
| sitemap to footers.
| carvking wrote:
| I don't like it when they have chicken and vegan options on menus
| either
| leshokunin wrote:
| Oh yeah, let's drop Google's design language that they enforce in
| every app, and instead use a bespoke system.
|
| That would be suboptimal in terms of ensuring users feel
| familiarity, even if this was a good design.
|
| The suggested alternative is one that requires scrolling down to
| the bottom of the page. Good luck scaling this.
|
| UX isn't just prettier solutions, sure. It's also not just
| finding solutions that are more elegant in a vacuum. People have
| an embedded expectation of the design language of things. You
| know what a glass of wine looks like, and what a glass of water
| looks like. If you start making up your own solutions, it needs
| to acknowledge those expectations. Otherwise it's not UX, but
| performance art.
| hulitu wrote:
| > Oh yeah, let's drop Google's design language that they
| enforce in every app, and instead use a bespoke system.
|
| The problem with "Google's design language" is that only Google
| speaks that language.
| legitster wrote:
| Eh. I've come around on them.
|
| In 2015 I might have agreed. But they clearly caught on. We now
| have enough data that shows users know how to use them, and in
| many cases prefer them. There's even one built into the Xbox
| controller for crying out loud.
|
| I won't begrudge the purists out there who find creative ways to
| avoid assimilating. But, uhhhh, I don't think this confusing
| footer link trick would actually win out in a UX test in 2023.
| JohnFen wrote:
| I know how to use them, but I still hate them. They're a
| symptom of a larger issue with modern web (and application) UI
| design: discovery seems to be no longer considered important.
| bsder wrote:
| Precisely, this article is part of a timeline. And has no
| "Next" or "Previous" links. Which are far more useful,
| especially if they were at the top of the article. You have
| to figure out that "Home" actually takes you to other
| articles--most definitely non-standard.
|
| In addition, whatever happened to the general UX advice
| "Users don't scroll"?
|
| Finally, on my monitor, it also has a gigantic amount of
| useless whitespace to the left and right no matter how wide
| you make it so the bottom links always manage to stay hidden.
|
| I'm no fan of hamburger menus, but there are far more
| fundamental UX mistakes being made here.
| ryantgtg wrote:
| This seems like normal "home" behavior. It goes to the home
| page.
|
| But yeah, where's the pagination!
| Pxtl wrote:
| Would you do away with all icons altogether? The hamburger
| icon is just as discoverable as any other.
| JohnFen wrote:
| It's not that the hamburger icon itself isn't discoverable.
| It's that the items under it aren't. There's no telling
| what is there until you click on it.
|
| As with all things, it's a tradeoff. Hamburger menus are
| always less than ideal, but I can see that the tradeoff of
| them is worthwhile on small screens. But if you aren't on a
| mobile device, there's no reason to use them. Use actual
| menus, or use icons that give some hint of the
| functionality behind them.
| kitsunesoba wrote:
| > It's not that the hamburger icon itself isn't
| discoverable. It's that the items under it aren't.
| There's no telling what is there until you click on it.
|
| Yep, hamburger menus are the junk drawers of software,
| with all sorts of things getting shoved into them without
| much thought. You might get some loose grouping but
| that's the extent of it.
|
| And to make it worse, if the number of items in a
| hamburger menu grows too long the menu becomes
| increasingly unusable, so many things just get left out
| and aren't accessible from the top level at all,
| remaining buried in some modal behind a button in some
| obscure, unsearchable part of the app.
|
| On the desktop it's one of the reasons I'm partial to
| macOS. Apps there have no reason to not use the global
| menubar, and so even most cross platform apps populate it
| with sensibly organized menus, making those apps more
| usable than they are on other platforms where only a
| hamburger menu is presented.
| jmartrican wrote:
| Its also a key on keyboards.
| https://en.wikipedia.org/wiki/Menu_key
| panzi wrote:
| Also on the Amazon Fire Stick remote: https://m.media-
| amazon.com/images/I/51Da2Z+FTFL.jpg
| codetrotter wrote:
| Tbh the keyboards at the time when the hamburger menu first
| showed up had symbols quite different from the symbol of the
| hamburger menu. And at the moment that symbol still looks
| different in the same way. Perhaps eventually keyboards will
| begin to use the hamburger menu symbol on the menu key.
| Probably a few do already. But I mean most keyboards.
|
| And also the hamburger menu symbol is not so much different
| from all of the other "mystery meatballs" (as Lynda Weinmann
| called them, many many years ago) that we all know and love.
| Today I expect that most people will be able to recognise and
| know how to use the hamburger menu.
| chrismorgan wrote:
| Given the context here, however, I should note that the Menu
| key is purely equivalent to right clicking on what's focused
| or selected or where the caret is in a text box, to open the
| context menu, which sounds fairly different from the Xbox
| controller's Menu button (though I've never used it). As for
| the context menu, web _pages_ should never touch it, and web
| _apps_ shouldn't often. I'm still sad about the death of
| <menu type="context"> which let you _add_ to the native
| context menu. Now your only options as a web app are to leave
| the native context menu alone, or completely replace it,
| neither of which are great options, a lot of the time.
| bombela wrote:
| back when you could actually use a GUI with a keyboard...
| those were the days.
| chrismorgan wrote:
| My computer use is heavily keyboard-driven. I don't find it
| common to encounter things that are _broken_. _Problems_ ,
| sure (e.g. airlines' date and airport selection dropdowns
| are pretty consistently poor, normally breaking basic
| usability stuff like "if I type MEL and then press Tab, I
| selected Melbourne, I didn't throw away what I typed"; and
| improper killing of focus indicators is still stupidly
| common), but seriously with no extra or special software
| installed for the purpose, having no mouse would only slow
| me down in some places, without ruining anything for me.
| eastbound wrote:
| Aren't we just rediscovering the pertinence of standardized
| actions?
|
| Windows 95 was the peak of usability (standardized menus, top
| bars, buttons, toolbars, bottom bar, keyboard shortcuts for
| everything), but it seems we've broken it down because... ?
| because it was boring? perfect uniformity made it look strict-
| minded? gray made people afraid of software?
|
| Or perhaps the power of machines meant that every large company
| could afford their own design?
|
| Anyway, yes the hamburger menu should become a standard, and
| the standard should be broken again because we don't want life
| to be boring.
| Ylmaz wrote:
| This must be a troll.
| actuator wrote:
| I have less of a problem with web UIs but when this sort of
| minimalistic design starts invading even washrooms, that's where
| I draw the line.
|
| There are no door handles for cubicle doors, you have to push
| them inside after seeing the separation lines. The first time I
| went to such a washroom, I was confused where should I enter
| from.
|
| The paper towels are hidden behind the mirrors, if someone pulls
| and the next one doesn't flow down, you really will have no way
| of knowing the paper towels were there.
|
| There are many other such things. I get that minimalistic design
| looks clean, but do you know what's better, accessibility.
| crazygringo wrote:
| I agree on them being confusing, but to be clear that's not
| copying a hamburger menu.
|
| That sounds like it's copying what are often called "handles",
| "grab handles" or "drag handles" in UX -- the close-together
| lines or dots in UX elements that indicate something can be
| dragged, a friction surface you can hold on to [1]. They mimic
| the grooves on a plastic cover for the battery compartment of a
| remote control, for example.
|
| But those are universally understood to indicate sliding, and
| should never be used for push/pull. That's literally what "door
| push plates" are for [2].
|
| [1] https://ux.stackexchange.com/a/25696
|
| [2] https://www.google.com/search?q=door+push+plate&tbm=isch
| kabdib wrote:
| There's a phrase for this that I've heard used by architecture
| critics.
|
| "That building probably won an award."
|
| Who cares if there aren't enough elevators, or if the cooling
| system can't keep up with insolation, or if windows fall out or
| plumbing is always breaking down. That pretty glass box with
| the innovative lobby won an award! (And now we have to work in
| it...)
| leepowers wrote:
| > "But I Have No Choice!"
|
| > I see this argument pop-up frequently when taking to design
| leaders or developers. I call bullshit on this excuse. You
| absolutely have the choice to avoid implementing bad designs -
| that's your job! Either you're not fighting hard enough against
| those pushing for it, or you're just trying to build a "pretty"
| portfolio.
|
| _sigh_ I 'm so tired of this absolutist, ranty way of thinking.
| Its indicative of Twitter-brain or social media outrage brain.
| Design is almost always a collaborative process. You literally
| have no controlling choice on the outcome, because the choice
| itself is being made by multiple stakeholders, be it your
| customers, your coworkers, your clients, etc.
|
| Also, the author lists himself as the "UX Designer & Front-End
| Engineer @ Donorbox." Their web site at https://donorbox.org
| appears to be using a hamburger menu on mobile. I hope he isn't
| beating himself up over it.
|
| It's hard to move away from established UI patterns like a
| hamburger menu because stakeholders expect it, and I suspect
| users look for that little hamburger icon as well.
| lezojeda wrote:
| It also has the typical annoying dialog open 2 secs after
| opening the page.
| lostgame wrote:
| lmao, as if the designer is in charge of what they'd like to do
| 90% of the time.
| dylan604 wrote:
| and thank the gawds for that. it's like letting the Jony Ive
| types rule the world.
| permo-w wrote:
| yeah this is an odd article. hamburger menus are not perfect,
| but they do the job and they're expected by the user, which is
| important in UI
|
| this article's main justification for them being poor is that
| they don't work well without a mouse and/or when you have
| javascript turned off. okay there are times and places and
| people for whom javascript will be off, that's understandable,
| but still rare. who is browsing the internet with just a
| keyboard though?
|
| they're fixing an issue for the vanishingly few by worsening
| the experience of overwhelming majority, and acting as if this
| is an obvious solution that developers are too blighted to see
| Pxtl wrote:
| The fact that this is an article about design-language that
| contains zero pictures speaks volumes about the author's
| perspective on the subject.
| cmdialog wrote:
| [dead]
| jnwatson wrote:
| The hamburger menu is the junk drawer of UI. It is where you put
| everything that doesn't have a place.
| gwern wrote:
| Which is itself OK. It's not always possible to put things in a
| place. The problem is when people hide away the important
| things in the hamburger menu, even when they have plenty of
| unused space. Which begs the question: if it's so useless that
| it can't even be allowed to be visible lest it take up a bit of
| screen real estate, why is it useful enough to include in the
| hamburger - or exist?
| methodical wrote:
| I don't understand this take at all. Why would you bury your
| navigation on your (hypothetical) marketing site in the footer on
| mobile? Most users don't even scroll far enough to make it to the
| footer and they certainly wouldn't expect the navigation there.
| mikae1 wrote:
| _> Why would you bury your navigation on your (hypothetical)
| marketing site in the footer on mobile?_
|
| There's a link in the header to the nav element at the bottom.
| I think it works.
| Kwpolska wrote:
| I think it doesn't, and it's not even necessary. The name
| "sitemap" is very unintuitive. For this site specifically,
| all the links could comfortably fit in the header:
| https://i.imgur.com/7VH4UJ6.png
| jdiff wrote:
| It works like setting up a yard sale with nothing actually in
| your yard but a sign that says "the good stuff's around back
| ;)"
|
| Yes, the necessary information is technically conveyed, but
| what's improved by this over headers or hamburgers? You'd be
| better off just having a fat header with all your links.
| waboremo wrote:
| Which by the way is horrible accessibility wise (by default)
| because if there are other links on the page, it scrolls
| right back up to them when you navigate them with the
| keyboard, negating the entire point of the shortcut.
| deltarholamda wrote:
| >Why would you bury your navigation on your (hypothetical)
| marketing site in the footer on mobile?
|
| I've been on some sites where the hamburger menu was atrocious
| and/or unhelpful.
|
| When I encounter this, I will often just scroll to the bottom,
| where a lot of templates will put the "sitemap" stuff, usually
| with more descriptive text, so I can then find what I'm looking
| for.
|
| It's not ideal, but people design mobile sites as if they're
| applying for a graphic designer job. Mobile design has become
| "smoosh it till it fits," and it just doesn't work well. It's a
| small screen, operated by a meatsack with a single giant thumb,
| who is probably driving 127 mph through a suburban
| neighborhood. It's a lot more than just "flow the three columns
| into one" kind of problem.
| DaveSchmindel wrote:
| > The biggest headache when coming across these menus on the
| web is the complete disregard for accessibility.
| twelve40 wrote:
| placing the links at the bottom is very bizzare and not a
| great improvement to accessibility because nobody in the
| world expects those links there and its hard to even scroll
| there. If one is worried about accessibility maybe have both,
| why not, because I found the footer to be less intuitive and
| convenient.
| usr1106 wrote:
| It's easy to scroll there. Just click the link at the top.
| Did it on my 10 year old mobile phone and it worked.
|
| The blog post says users are conditioned. That's exactly
| the problem. The author hopes that users would be
| conditioned to find a site map at the bottom. I have the
| feeling 15-20 years ago in the ages of pure HTML that was
| more common. Nowadays 99% of the users don't learn that. It
| wouldn't be hard or impossible to learn. It's just that
| marketing driven design for fancy UI has ruined
| accessibility because those user have no voice.
| tsimionescu wrote:
| What if you're not at the top, but in the middle? What if
| this was a 5000-word or 10k-word article? Would you add
| random nav items here and there?
| methodical wrote:
| I read that part, but I don't think trading off massive
| amounts of usability for the majority of people to slightly
| increase the usability for the minority is the right decision
| in almost any case.
| SebastianKra wrote:
| It's ironic that I confusedly searched the header for links to
| other parts of his blog, before realising that he had actually
| followed his own advice and put everything in the footer.
|
| Man, I hate these broad reductive arguments. They never consider
| the trade-offs and focus on a single arbitrary principle. Once
| you actually try to design something, you'll realise just how
| many conflicting requirements need to be juggled.
|
| I don't agree that hamburger menus hurt accessibility. I've never
| seen a user confused about them. I can navigate them just fine
| with the keyboard [1].
|
| Further, they match how I interact with most marketing- & news
| pages. I first scan the landing page for useful details, and then
| look for specifics in the menu. Having this list at the bottom of
| the landing page would require scrolling. Having all the links
| visible at the top would make it harder to get through the
| landing page. The trade-off presented here forces you to loose
| your scroll position every time you want to access the menu.
|
| [1]: Don't forget that Safari requires holding down option to
| focus links
| d--b wrote:
| > Best Alternative: Sitemap Footer
|
| These authors ought to ask themselves: if all websites using a
| hamburger menu were to be concerted to sitemap footers, how many
| people would write blog posts about how shitty this design is?
| zichy wrote:
| As one user said before, this absolutist way of thinking is
| tiring. Hamburger menus can absolutely be accessible and I would
| have liked to read how to do so. Here's my take:
| * It uses valid HTML and JS. (You could also make it work without
| JS as a fallback and I love progressive enhancement, but it's not
| a requirement specifically for accessibility. Actually, JS can
| contribute a lot towards accessibility. * The toggle
| button uses either `title`/`aria-label` or visual text in
| addition to the [?] icon. * The focus states are
| clearly visible for keyboard navigation. * The correct
| ARIA attributes for the interactive elements are used.
| * Depending on the menu, think about a focus trap/loop.
|
| Bonus tip: While I prefer using `<button aria-expanded>` since I
| believe it is more accessible for screen readers, you can also
| use `<input type="checkbox">` + `<label>`. If you have to do it
| this way, please do no use `display: none` on the checkbox input
| - this will make it unusable by keyboard. It should be only
| hidden visually.
| mmphosis wrote:
| Offer a consistent menu system. Offer a choice of one of: Menu
| bar, Hamburger menu, ...
|
| Right now I have:
|
| * a Global panel that looks like a global menu bar but isn't.
|
| * Menu bars usually displayed in each window. I had to right
| click the Hamburger with my one-button mouse and click the check
| box for Menu bar.
|
| * a Hamburger menu displayed off to the right side that I can't
| hide.
| morkalork wrote:
| The worst is when an app has multiple levels of hamburger menu or
| "[?]"/"..." buttons. I'm always opening the wrong one! Looking at
| the git panel in vscode, I see 4 different clickable "..."
| buttons stacked above the each other, its terrible! It's like a
| designer decided to make a UI with only "OK" buttons and no other
| labels.
| xkcd1963 wrote:
| I'm a webdev and put out websites 1:1 to the designers creations,
| but my private projects have little to nonexistent css, just
| plain text everywhere, no hidden objects. Sometimes when working
| on designs I have brainfog events like when you watch a movie and
| the cutting is well done, you don't notice the cut. I imagine it
| is similar with designs, a good design hypnotises the user, even
| though objectively it is unpractical.
| Eduard wrote:
| > The biggest headache when coming across these menus on the web
| is the complete disregard for accessibility.
|
| Just because most websites / frontend frameworks fail to
| implement hamburger menus in an accessible way (including
| Bootstrap 5), does not mean that hamburger menus in general are
| bad when it comes to accessibility.
|
| With that logic, images / img elements are a core problem per se
| and should be prohibited, because most pages don't use them
| correctly from an accessibility standpoint (e.g. forgetting to
| provide an explicit "alt" attribute).
|
| WCAG / WAI has pretty good recommendations in how to achieve it.
| Here is their hamburger menu pattern example:
|
| https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/example...
| joshspankit wrote:
| I genuinely hope someone makes an Accessibility AI gets used by
| companies worldwide to fix their sites and webapps.
|
| There are so many great properties waiting to be implemented
| properly.
| sebzim4500 wrote:
| I think it's far more likely screenreaders with AI become
| good enough that disabled people can browse the web as
| normal.
| anonymouskimmer wrote:
| Accessibility features can be bonuses for people who don't
| have any problems, too.
| fauntle wrote:
| Articles like these are always good for the humor, at the very
| least. There's a reason hamburger menus are in use everywhere,
| and it's not because we haven't read your blog post.
| marginalia_nu wrote:
| I think the main thing is that hamburger menus are stupid on
| desktop.
|
| It's a symptom of attempting to build hybrid interfaces for both
| mobile/touch and computer screen/mouse+keyboard by basically
| ignoring the affordances of the latter altogether. When pixels
| aren't scarce, [] is a menu but strictly worse.
|
| Desktop interfaces don't have a pixel shortage. Like at all.
| Replacing text+icon buttons with cryptic line icons in general
| means your users have to learn to decode Linear B to use the
| interface like it's a Myst puzzle.
|
| The design choice is strictly a bad trade-off on desktop. If
| you're on mobile, where pixels actually are scarce and input
| precision is low, it makes sense though.
| JohnFen wrote:
| > I think the main thing is that hamburger menus are stupid on
| desktop
|
| That's probably why I hate hamburger menus. I use a desktop for
| 95% of my computer use.
| _kst_ wrote:
| > When pixels aren't scarce, [] is a menu but strictly worse.
|
| The character in the square brackets is "AEGEAN NUMBER THIRTY",
| U+010112. It doesn't display in my browser (Chrome on Windows).
| Oddly, it does display in my xterm, though that's likely to
| depend on which fonts you're using. (It's three horizontal
| lines.)
|
| I presume most hamburger menus use an image.
| medstrom wrote:
| Bulma CSS uses three blank <span> elements, which it'll style
| into a hamburger.
| runarberg wrote:
| I normally just use something like: <svg
| viewBox="0 0 5 5"> <path
| d="M0,0h5v1h-5m0,1h5v1h-5m0,1h5v1h-5z" /> </svg>
| kps wrote:
| How about [?] U+2261 IDENTICAL TO
| U+1D118 MUSICAL SYMBOL THREE-LINE STAFF U+1D362
| COUNTING ROD UNIT DIGIT THREE
|
| and HN strips U+2630 TRIGRAM FOR HEAVEN
|
| and of course U+1F354 HAMBURGER
| crazygringo wrote:
| Agreed, but fortunately you rarely see them on desktop, or else
| it's a hamburger icon that actually toggles a whole sidebar
| (e.g. Gmail, but I wish they would use a different icon).
|
| I think most designers are developers are aware that hamburger
| menus are a mobile thing.
|
| Of course sometimes there aren't enough dev resources to do
| both mobile and desktop and the desktop site is just an
| embiggened mobile version, with hamburger. But that's resource
| constraints.
| nuxi wrote:
| Unfortunately I see them all the time on desktop.
| Ubuntu/Gnome apps are literally littered with them, because
| someone thought regular menus are "evil" or something like
| that. So now most of the apps have a single entry in the
| regular/global menu (Quit), and all other actions are crammed
| under the hamburger in the app window.
| crazygringo wrote:
| Oh, ugh. I'm on a Mac so I don't see anything like that.
| That sounds horrible.
| marginalia_nu wrote:
| See them quite a lot in desktop-only applications. Firefox is
| a good example. Sure there is Firefox Mobile, but it has a
| completely different GUI.
| anonymouskimmer wrote:
| Firefox on Linux and Windows has a toggle to show the old
| menu bar. Just right-click anywhere on the navigation bar
| and check the "menu bar" option.
| iambateman wrote:
| The core problem is that they demo super well.
|
| There are a handful of tricks that help sell a design for a
| client, and one of them is hamburger menus.
|
| Along with background video, scroll jacking, over the top
| parallax, and (cliche) large logos, they make up a quiet set of
| ways to get a dev out from under the thumb of an irritating
| client...at the expense of an actually great website.
|
| Ask me how I know.
| wkat4242 wrote:
| ohhh I agree sooo much with this.
|
| And also, the very concept of hiding "complex" options under a
| "more options" option. Windows 11's new right-click menu in the
| file explorer is one such example. Every time I had to press
| "refresh" I now have to do two clicks instead of one. Because
| someone at Microsoft feels like I should be punished for wanting
| to do something not many people do all the time.
|
| Luckily this particular nonsense can be switched off in the
| registry. But many can't.
| bbarn wrote:
| This was infuriating until I found the hack work-around.
|
| It's not just "complex" things - it's any context menu
| extension you may have used for a decade hidden behind that
| wall. In my example, it's "Edit with Notepad++". Is that a
| "complex" use case for most people? No, it's just Microsoft
| trying to force you to do things their way with their tools.
| PcChip wrote:
| I 100% agree with you, but fyi you can just hit F5
| wkat4242 wrote:
| I can't believe I never tried that lol. Thanks!
| laweijfmvo wrote:
| The footer on this simple page is atrocious. Seems like a not-
| great alternative IMO.
| scrollaway wrote:
| I don't think the alternative "just put everything in the footer"
| is always acceptable.
|
| A site with simply "Home", "About us", "Contact" + a wide logo
| already has too many links for a portrait orientation small-
| screen device. You can get around it by finding a square version
| of the logo and shrinking stuff but it's not necessarily pretty.
| jbay808 wrote:
| It would be nice if more sites offered a "site map" page, which
| used to be popular, where you could ctrl+f for a link even if
| it was too large to fit on the display.
| wolpoli wrote:
| Not to mention the author didn't address that footers aren't
| visible with infinite scrolling.
| cyberax wrote:
| Infinite scrolling must die, too.
| switch007 wrote:
| Infinite scrolling should also go away.
|
| Yes yes it's fine if you implement it perfectly and cover all
| edge cases...which many developers don't.
| lwansbrough wrote:
| We've got a pretty large mobile app (hundreds of screens)[0] and
| we've so far resisted the urge to add a hamburger menu. Hamburger
| menus are particularly bad with modern screen sizes and force the
| user to make a physically uncomfortable action by stretching
| their thumb or adjusting their phone in their hand to reach it.
|
| It comes down to understanding what exactly your users are trying
| to do and developing contextual UI based on the few primary
| flows. In our case, our main nav at the bottom exposes the most
| high priority features, and additional pages can be found in the
| "More" menu. The More menu is functionally similar to the
| Hamburger menu, but varies in a couple key ways: it sits bottom
| right of the device, which is much more reachable, and it doesn't
| include items already shown on the main nav.
|
| [0]
| https://play.google.com/store/apps/details?id=network.tracke...
| bendur_ wrote:
| It's really not that hard to build an accessible hamburger menu
| if you just test it out and don't make it overly complicated. A
| lot of design frameworks/templates are completely ridiculous in
| this regard though.
| codetrotter wrote:
| I was gonna criticise OP for how many times I would have to press
| the tab key to get to his footer navigation menu but then I
| actually tried to navigate his page with just the keyboard and I
| have to admit it's pretty good.
|
| If you have a lot of links mentioned in the article text then it
| might become more uncomfortable but OP solved that by having a
| link in the top of the page that will skip to navigation.
|
| Would like to hear from screen reader users how OP's page works
| for them. I expect that the navigation experience is good for
| them too.
|
| And in general the bottom navigation is a pretty good idea
| actually. Most websites I land on I land on via links from
| elsewhere and I am initially not interested in navigating the
| page. But if I read a good article on some page and I want to
| explore more then it is convenient that the navigation is at the
| bottom because I just finished reading the article, and it also
| avoids the awkwardness of hamburger menus that arises when the
| hamburger menu content is too big to fit so it either might not
| scroll at all, or it might scroll in a weird way.
|
| In conclusion, OP has a valid point and I will use more footer
| menus and less hamburgers in the future.
| waboremo wrote:
| >OP solved that by having a link in the top of the page that
| will skip to navigation.
|
| Just tested that, and it doesn't skip to navigation. It
| _scrolls_ down, but the next tab is still the links in the
| content.
| FinnKuhn wrote:
| and it breaks the back button by doing that :D Hamburger
| menus are fine for mobile devices where space is limited and
| for desktop devices just use a normal nav bar instead of this
| mess.
| codetrotter wrote:
| > it breaks the back button
|
| No it doesn't. One extra step back is not "breaking the
| back button" when you explicitly have clicked an inline
| link. That is your browser working as intended.
| codetrotter wrote:
| > it doesn't skip to navigation
|
| Maybe your browser is broken
|
| It works for me as it should both on mobile iOS Safari and on
| desktop Brave browser. (Brave is Chromium-based.) I didn't
| test on Firefox because although I used to use ff for many
| years I am currently not using it.
| chrismorgan wrote:
| Firefox handles it properly. Every browser I've ever known
| always has.
| codetrotter wrote:
| Exactly.
| isomierism wrote:
| for a moment i thought op was talking about hamburger restaurant
| menus like innout
| poniko wrote:
| I always say to my peeps, if you have stuff you don't want users
| to find/use then put them in a hidden menu.
| Eliah_Lakhin wrote:
| Well, the Footer Sitemap maybe was not that good idea, but why
| not consider the Header Sitemap instead? HackerNews menu looks
| good to me.
|
| If the Sitemap structure is too large to be in the Header, maybe
| it's a good marker to think about reducing the amount of
| information on your website in general.
|
| Also, I like to have sidebar menus on the left or right of the
| page for quick navigation, and when I see the webpage on my home
| widescreen desktop monitor, or maybe even notebook. But I don't
| like clicking Hamburger buttons each time to expand them. So,
| personally, I'm fine to always have such menus stay expanded on
| Desktops, and to be completely absent on mobiles. If I use the
| mobile device, I'm acknowledged that it's functions are limited
| by design.
| jahlove wrote:
| > Cons: Footer can become large with many links (although I
| really don't see this as a big deal)
|
| Also: you now have to scroll all the way to the bottom of the
| page to navigate to other parts of the site?
| me_bx wrote:
| Here's another alternative [0], from a team well versed into
| usability and accessibility issues:
|
| "gov.uk Design System" puts the navigation at the top of the page
| inside their header component.
|
| > Use the header with navigation if you need to include basic
| navigation, contact or account management links.
| * A list of links is directly visible in wider screens *
| These are collapsed into the equivalent of a hamburger menu on
| smaller screens * The label "Menu" and a downwards-pointing
| arrow are shown instead of a "hamburger" icon * The
| possible interactions are highlighted on keyboard navigation
| (yellow border moves when Tab is pressed) * Degrades
| gracefully when JavaScript is disabled by leaving the menu
| expanded.
|
| I haven't taken the opportunity to check how this works with a
| screen reader.
|
| [0]: https://design-system.service.gov.uk/components/header/
| thecosas wrote:
| I fully expected a sharp criticism of fast food menu design
| rather than UI design. Only one?
| DoneWithAllThat wrote:
| If the "core problem" with something is that they're mildly
| inconvenient for a tiny fraction of users that's not really a
| compelling argument of there being a problem at all.
| bariswheel wrote:
| Also a pain in the ass for left handed folks on mobile. Mobile
| UI's are atrociously inaccessible for left handed people like
| myself. Try it and see. Completely unacceptable.
| onychomys wrote:
| They're lousy in very specific use cases, but there's clearly
| some reason why every website in the 90s had a footer menu and
| now they all have hamburgers instead. Is it all just 100% because
| they're cleaner looking? Or is there some actual usefulness
| reason for the switch? I don't know enough about the space to
| have an opinion on it, but there's obviously something at work
| here.
| prenoob wrote:
| Mobile changed UIs profoundly, screen real estate is at a
| premium and that's how we got to hamburger menus
| Andrew_nenakhov wrote:
| No. Use hamburger menus where appropriate if you feel that this
| is the best way to offer additional options.
| cosmotic wrote:
| It should not be based on what YOU (the developer or designer)
| feels, it should be based on user research. User research shows
| hamburger menus are bad.
| idopmstuff wrote:
| User research doesn't show that anything is good or bad, full
| stop. User research shows that things are good or bad for a
| particular use case or audience. That's why companies have
| user research teams - because there are few universal
| principles, and it's important to understand what's best for
| your users in your context to achieve your objectives.
| hulitu wrote:
| And changing the way the user interacts with the system in
| every release is good, isn't it ?
| snowwrestler wrote:
| User research does not show hamburger menus are bad.
| bogwog wrote:
| > User research shows hamburger menus are bad.
|
| (citation needed)
| CamperBob2 wrote:
| "We want faster horses." - User research conducted by Henry
| Ford
| anonymouskimmer wrote:
| That's bad user research. You don't ask them what they
| want, you ask them what individual features are helpful
| (e.g. "speed", in the case of Henry Ford), and you give
| them some product options and ask them which one they most
| prefer, and why.
|
| The top speed of a Model T was about 42 MPH, comparable to
| the fastest horses. So Ford wasn't delivering on this user
| request regardless. https://techhistorian.com/ford-model-t-
| top-speed/ https://horseyhooves.com/how-fast-can-a-horse-
| run/
|
| While horses couldn't maintain this speed for long, horses
| also broke down much less frequently than the earliest
| cars.
|
| Given what was state of the art at the time, I would
| believe that people would have asked for smaller trains
| that don't need a track, and not for "faster horses", if
| they'd been given the question. And this smaller, trackless
| train, is effectively what automotive manufacturers
| delivered.
| Andrew_nenakhov wrote:
| One of the companies I own (rather smallish one) creates
| commercial websites. Hamburger menus work just fine according
| to our research and a/b testing, sometimes superior to other
| navigation methods, sometimes not. YMMV.
| usr1106 wrote:
| Does your research and a/b testing cover users that access
| the site via a screen reader?
| Andrew_nenakhov wrote:
| Not really, unfortunately. Very few customers require
| good UX with a screen reader, and we certainly can't
| afford the expenses necessary to research it on our own
| initiative.
|
| To be honest, I didn't even think about it until now, but
| since you mentioned it, I'll ask my design team to do a
| small-ish research and in the future try to build
| navigation better accessible for people with impaired
| vision. I'll hardly be a top-notch experience, but at
| least we'll try to pick the lowest hanging fruit.
| usr1106 wrote:
| I was not the first to mention it, the submitted article
| was.
| ddevault wrote:
| I take pride in making my websites accessible for
| everyone regardless of the monetary incentive to do so,
| and to make inaccessible websites simply because you
| don't think there's money in it is very shameful.
|
| Not saying that hamburger menus can or cannot be
| accessible; just saying that, as an engineer, you really
| have an obligation to make _something_ that is
| accessible. This is a basic, non-negotiable requirement
| for all software.
| bluepizza wrote:
| Should it be based on user research? Why? What are the
| advantages of basing decisions on user research?
|
| What research shows that hamburger menus are bad? Why the
| conclusion is this one? What makes them bad?
|
| If you are to advocate for data oriented decisions, you'd
| better present the data!
| hulitu wrote:
| > Should it be based on user research? Why? What are the
| advantages of basing decisions on user research?
|
| No. Not at all. Users are the suckers who shall know from
| the birth what a hamburger menu presents to them. They
| shall have special religious skills to ask the deity what a
| GUI element represents: a label, a menu, a link. They shall
| be punished with 1 px borders on 4k screens. The windows
| are not meant to be resized.
|
| Users suck /s
| bluepizza wrote:
| I am very confused and couldn't follow. What do you mean?
| hulitu wrote:
| I was just saying that "Users are idiots". Keep up the
| good work. /s
|
| https://github.com/bigjohnson/Real-Programmers-Don-t-Eat-
| Qui...
| bluepizza wrote:
| I'm sorry, I still don't follow. Any of it.
| paxys wrote:
| So I should have to scroll all the way to the bottom of every
| page to navigate anywhere? What an idiotic "solution". Hamburger
| menus are fine. If they aren't accessible, that means they
| weren't implemented correctly. It is fully possible to use them
| perfectly with keyboards and screen readers just by adding some
| extra tags.
| arkaic wrote:
| The hamburger icon is certainly miles better than the harder to
| see three-dot one Chrome uses. Not sure why they ever decided
| that this was a better choice.
| mrozbarry wrote:
| My only real gripe with hamburgers is inconsistent
| implementations with various "works on browser X and Y, but not
| Z." On top of that, not many (or no one?) has take advantage of
| publishing web components that aren't framework-dependent, so not
| only are there inconsistent implementations of hamburgers, some
| implementations require managing multiple js/css frameworks.
| VoodooJuJu wrote:
| Unfortunately, not going to happen. Even though they were a bad
| idea ten years ago, and still a bad idea now, with them being
| forced down everyone's throats over the course of a decade,
| they've become a standard that users expect and understand, much
| to their chagrin.
|
| It's a a nice case study, as with ipv6. You can ignore the needs
| and wants of your users, force-feed them crap, and as long as you
| standardize that crap, the user will eventually submit, for
| better or worse.
___________________________________________________________________
(page generated 2023-05-05 23:00 UTC)