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.
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.
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
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
My wife chats with them so often, in the app I just have to go to hamburger menu > contact us > return to chat.
If your shortcuts don’t include “contact us” you should be able to find it by scrolling to the bottom of the hamburger menu and tapping “customer service”. getting a live agent entails some dark magic, but if you bother the bot enough she’ll connect you.
what region are you in? I accidentally switched my region to USA a while ago and the whole app’s UI changed drastically. on my app Contact Us is hidden 3 layers deep with each link at the bottom of its layer
but (on desktop) if you want to speak to a human once you are actually in chat, there’s a very subtle button in the centre just above the message bar that will bypass the automated system if you click it
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.
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.
Conspiracy theorist's take: Apple intentionally requires a second click to decrease ad clicks. Given the bottom anchor ad is a very popular ad format, this feature is negatively affecting most publishers. Advertising platforms like Google already implement two-clicks penalty as a safeguard for advertisers.
In USA, Safari accounts for one-third of total mobile traffic, and mobile traffic itself makes up two-thirds of total traffic.
This seemingly small feature is single-handedly wiping out billions of dollars in revenue for publishers... and Google.
Yea, this is something I find annoying… I wonder what the solution is? Increasing the height of the bottom menu? Moving it a little higher and just wasting some of that vertical space?
Yes, but as a designer/developer, it would be useful to know if there’s a CSS/HTML/Javascript solution when your target audience includes a significant number of iOS users who will use the default browser on their device, namely Safari.
Between chrome, firefox and safari, I choose safari every time, because navigation is soooo much nicer, I can very easily switch between tabs in safari compared to literally every other browser. flipping back and forth between two tabs in safari is the same as swiping to another app, which in all the other browsers you need to open the tab menu and find the other tab
There are scads of articles like this, either from the accessibility > all or the page size > all tribes, that obnoxiously "solve" problems by sticking their fingers in their ears and ignoring all objections. Throw in a snarky tone and sanctimonious justifications and bam: you got a black text white background web dev blog.
Sorry, but for 99% of websites, businesses, and individual browsers, the harm of moving all your navigation a flat hierarchy in your footer VASTLY outweighs the harm of a hamburger menu.
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.
When you look at a website with a burger menu, you know what the burger menu does. When you look at a website without a burger menu, you know what the website does.
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.
What exactly is this constituency of jscript-disabled people? It sounds a bit nuts to me. I can't imagine why I should be catering to them. Asking because I sincerely don't know.
People with impaired vision that rely on screen readers. They may not always have JavaScript disabled, but it's the same effect. They can't hear the navigation options.
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."
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?
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".
The article discusses the problems of a hamburger menu but doesn't address why its used, and then goes on to suggest a solution which does a worse job of what the hamburger menu is actually designed for.
You asked "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?" The article answers this question, quite clearly and in detail.
Ironically it seems like you didn't read my comment. The first line explains why thats a bad solution, because its just moving clutter around the page but with extra steps
I read it, it just doesn't make sense. There's nothing harmful or disruptive about having lots of links tucked away at the bottom of the page, out of the way. Hiding those links in a hamburger menu doesn't fix the problem, because there's no problem to fix. But it does introduce several other, more significant problems, which are described in the article.
> 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)?
Why are you (and most of the commenters!) ignoring "...and link directly to them [the footer links] from your header"? You're arguing against a claim nobody made.
In this scheme, you still click a button right up at the top to see a menu; it's just that the menu is at the bottom of the page instead of in a pop-out, avoiding all the listed problems with JavaScript, screen readers, keyboard navigation, etc.
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.
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.
> 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.
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.
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).
You could always put a link at the top that will scroll you down to the footer menu. If you do it the simplest way possible the back button will bring you back to where you were if you change your mind.
> 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.
when the did anyone start expecting a hamburger menu? all these old websites i used to poke clearly labeled buttons on all of a sudden have three lines one year. its like all these web3 node js assholes took over the planet within an 18 month cycle and brainwashed everyone.
im old. i expect buttons with words on them.
now i have to spend a significant amount of my time, hours per year, explaining to users to click the "thing with the three lines, then scroll down, there should be a menu that says XYZ, no, you have to go down farther, its between PDQ and ABC. no its not categorized very well i agree. i agree nobody would know what three lines mean. ".
>It's hard to move away from established UI patterns like a hamburger menu
>when the did anyone start expecting a hamburger menu? all these old websites i used to poke clearly labeled buttons on all of a sudden have three lines one year. its like all these web3 node js assholes took over the planet within an 18 month cycle and brainwashed everyone.
That's why it's really not established, nobody really wanted a hamburger to begin with when websites used to be able to afford to serve steak.
The appearance of such a non-satisfying menu item has always lacked the flavor that attracts patrons the most.
First, I actually like hamburgers! Probably prefer them to steak, to be honest - especially when cost is factored in.
The problem, as I see it: people went from nice useful computer screens to these tiny phones, with very narrow horizontal space. If you show up to a restaurant and can't eat steak, the smarter restauranteurs are going to adjust.
Some sites are able to figure it out, but lets not blame the proprietors for giving the people what they want: a horizontally tiny viewport for nav. If you use that space for nav, you don't use it for actual content - I'm sure people in this forum hate that as well.
> You absolutely have the choice to avoid implementing bad designs - that's your job!
Ha, seems like this someone doesn't know when and where to pick their battles. Yes, sometimes you can really push for change when you come up with a real, convincing argument. Or, A/B test the crap out of it.
When I was on the front-end of the stack, it really taught me "disagree and commit" often with product and design. Unless it's something existential, there's almost no reason to accept "good enough", move forward, measure, and iterate.
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
There are people that can't use a mouse and have to use keyboard navigation.
The negative attitude against towards accessibility vexes me greatly. Are wheelchair ramps a pointless waste of money because the vast majority of people can walk just fine? Should we not care about making cities safer for blind people because they are just a small minority?
These kinds of attitude wouldn't be socially acceptable in the "real world" but the web still likes to pretend that it is the Wilde West. And yes, actively excluding people from being able to use your services is a bigger problem than you site being slightly less pretty.
I don’t believe that you’re replying to the strongest possible interpretation of what I said. you’re replying to a strawman that you’ve allowed to make you angry
the point is that a ramp is of equal use to a non-disabled person as a disabled one. what this author wants is to make everyone use stairlifts
People with disabilities (mostly vision impaired) browse the internet with "just a keyboard" or a screen reader. It's quite cumbersome, but for some people, that's the best they can do.
At a previous job, we had to follow their extensive rules for making everything accessible. A few things that I can remember:
* minimum contrast ratio
* support for the high-contrast mode that some browsers have
* screen reader support for every UI element - this requires a ton of different things
* everything must be usable without a mouse
There were tools to check for a lot of this. There was a separate team of accessibility people who would check the result and create tickets for things that were not good enough.
It was annoying when the designers specified low-contrast colors, then we'd build it with the colors specified by the designers, and then the tool tells us the colors are unacceptable. Why can't the designers check the contrast ratio of their colors?
Testing with a screen reader was extremely annoying (because it reads a description of the currently focused item), but it gave me a lot of empathy for the poor people for whom this is the only way to use a web UI.
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.
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.
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.
> 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.)
Exactly this. I kind of understand if you want a design that works the same on mobile and desktop. And very occasionally I think it might make sense, e.g. in browsers.
The real head scratcher is Gnome. Why are they moving from normal menus which work very well to hamburger menus for apps which have plenty of space and are desktop only?
I guess it wouldn't be the first time the Gnome people have made inexplicable UX decisions. Maybe it's just too boring doing the thing that we know works and they want to try new worse things?
"Mobile first design" calls for designing for mobile first, then adopting for desktop second, if there's time anyway.
>Desktop interfaces don't have a pixel shortage.
Combined with designers adding more and more padding, attempting to fit 2 web sites on desktop on a 1080p monitor ends up triggering mobile design anyway.
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.
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.
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.
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.
> 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.
> hamburger menus are the junk drawers of software
Love this metaphor. Hiding the main nav behind a generic button always gives me the impression that the designers don’t really see it as an important part of the website. Imagine you’d have to open up an unlabeled closet to find the navigation signs in a public building that actually show you what is where. Or if the table of contents in a book was hidden inside the folded cover.
I can see the problem with space and touch target size on mobile and don’t really have a better solution for that (maybe call the button “menu” instead and limit the number of top-level items like you would in a “proper” nav), but I hate to see hamburger icons on desktop screens.
>Hiding the main nav behind a generic button always gives me the impression that the designers don’t really see it as an important part of the website.
Or the engineers are in a situation which requires having non-engineers making engineering decisions.
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.
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.
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.
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.
> 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:
My natural inclination was to say “so hamburger menus can be implemented badly, but they can also be implemented properly so this is no reason to advise against hamburger menus as a whole”.
But I think it’s also worth remembering that patterns matter, and if almost everyone gets something wrong, it’s small consolation that it was an unforced error. If a different pattern is similarly acceptable and done badly far less often, pragmatism suggests pushing the alternative, because the average result will be better.
When I use hamburger menus on regular web pages, I implement them so that they’re entirely adequately accessible, and work with no JavaScript. (Depending on the situation, I’ll either use <details> or a checkbox hack with reasonable labels and such, and I may enhance things with a small snippet of JavaScript.) But I lack faith in almost anyone else’s implementations.
I would note also that the ARIA example you link to fails one of the criteria of this article: JavaScript-free operation. It’s also only suitable for some sorts of hamburger menus; it’s unlikely to be a suitable pattern for website header navigation menus, which are really more a navigation palette than a menu (to use very fuzzy terms!), and which are the main focus of this article.
I'm not sure* that the "just put everything the footer and link to the footer" is a solution I'd present seriously to the business stakeholders.
The thing I really want to kill with fire is the "junk drawer" method of UI design. This has infested almost all apps, with a three-dot (••• or vertical ⋮ ) scattered literally everywhere in every UI. It says "We couldn't be bothered to build a thoughtful UI, or even to classify the types of actions you might want to perform into a few categories. Even with a full-screen window on a 5K monitor, we'd rather have a sea of whitespace everywhere than to just put the actions where they are visible, discoverable, and can develop muscle memory.
I used to think about 15 years ago that a big problem was that developers and designers all used expensive high-res, large monitors and forgot that most users were on 1280x800 or (eek) 1280x720 laptop screens. Today it's the opposite direction with everything being optimized for tiny screens and minimal information visibility.
I know "mobile-first" is important but (A) phone users want things to be visible just as much as desktop users do, and (B) the right design for a phone is almost never the right choice on a massive screen.
*for an "application" - sure, it works great for a 8-page blog like the article. By all means. I just don't think it'll work for Expedia, Facebook, etc.
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.
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.
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.
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.
Wow, I didn't realise this was a risk picking up steam. Can only imagine how frustrating the internet was for screen reader users in 2020, which probably spurred this campaign on.
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.
> 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.
Real user research should be in the context of your application flow but there is research that shows hamburger menus aren't great for users.
People look at research like this and treat it like a maxim to never use hamburger menus. Sometimes it's a lazy way to avoid having to design good navigation. Sometimes it's the best of a bunch of bad choices. Overall, it's a 'use the right tool for the job' thing.
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.
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.
Nielsen Norman's research does. That doesn't mean they're never the right choice, it just means it hurts your navigation so they shouldn't be your goto. Use the right tool for the job.
NNg said they caused confusion in 2016… 7 years ago. Users are familiar with them now. NNg have recommendations for how to implement them effectively.
I’ll also add that NNg spent years trying to get people to adopt the “pie menu” despite clear evidence that they confuse the heck out of users. So, I’m not always inclined to take their word for things without doing my own testing.
I saw a NN video about vertical navigation published 6 months ago in which they recommend avoiding hamburger menus on desktop sites specifically. Whether or not a pie menu confuses users depends on the visual implementation, how it fits into the workflow, and how well it conceptually represents the users understanding for how to accomplish their goals. A few tool options for a right-click menu in a desktop application? Adding toppings to a sandwich? Maybe a great solution. Navigating a linear workflow on a website? Likely a stupid idea. Like any other common UI element, including the hamburger menu, it can be used correctly and incorrectly. Of course do your own testing – that's not a good reason to ignore other research.
Beyond that, when you're doing research that few other organizions are, you're bound to get things wrong sometimes. That's fine. Modern medicine only recently discovered that peptic ulcers, which affect 1 in 10 people in their lifetime, are often caused by a treatable bacterial infection rather than poor lifestyle choices. Nobody gets it perfect. Self-correction is a sign of trustworthiness.
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.
>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.
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.
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.
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
A button that scrolls you to the bottom where all the links are really isn’t that different from a button that shows all the links in an overlay is it?
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.
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.
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.
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
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.
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...)
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].
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.
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.
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.
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.
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.
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".
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.
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).
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.
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.
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?
> 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.
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.
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.
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.
Nice, skipped the headline yesterday. Today this blows up with >200 comments and I thought the article must be about how fast food chains rip people off. Time to go outside.
To contribute something: I feel that some more refined approaches of dealing with limited space are emerging. Also I see less and less collapse-hamburger-hell on desktop, where the space is actually available in the plenty.
There is one problem that is not solvable by technology: invest a lot of time, energy and expertise into organizing your content to make digestible pieces. Especially regarding how many subpages you have, their name etc.
I also feel that multi-level mega menus are on their way out, making room for more thoughtful forms of site organization.
There will always be tradeoffs. You cannot show all content at once (or you shouldn't).
But indeed, less pages with more content on them, landing pages instead of multi-level navigation, both can help to clean up a sitemap.
Then show your most important pages immediately, if you have too many, make each of them a "landing page".
For menus in web applications (not just websites) with lots of actions, plenty of alternatives to the hamburger exist. E.g. horizontally scrollable menu bars with "..." instead of the hamburger.
Or just lists of links and buttons. Design them in a nice way, then there's no need to hide them.
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.
These aren’t problems at all if you follow common practice and have the hamburger be a css styled list. It can be made accessible, usable with a keyboard, and vanish on larger screens.
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.
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.
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.
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.
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.
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.
I was a little bit disappointed when I discovered which type of hamburger menu they were talking about, I initially thought this article was going to address issues with the common types of sandwiches provided by fast food restaurants. But otherwise, I agree with the points stated in this article.
Although I would put my links in a <nav> section at the bottom of the page above the footer instead of inside the footer itself. Putting links in the header or the footer always seems to cause accessibility issues.
Or better yet, I would put links to the two or three most prevalent pages of the site as well as a link to a separate sitemap page in a navigation section under the header, so it would be something like:
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.
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.
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.
Why does practically everyone in this comment thread think the author said "you should have to manually scroll to the bottom of the page to get a menu," when he said very clearly (with working example!) that a menu button at the top of the page should give you the menu (which happens to be at the bottom instead of inside a pop-out)?
I mean, I know responding to titles instead of articles is a thing, but here it seems like everyone opened the article and then stopped reading at a very precise point in the middle of the fifth paragraph.
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.
> It seems like most people don't actually like hamburger menus. So why do we, as developers, keep using them in our products and designs?
Oh my. what a great question. Simple answer: Because there are as many incompetent designers as there are incompetent managers, and we usually think "well, i guess he knows what he is doing" (yes. he. almost always)
Spoiler: He does not. And modern UIs are full of actively unusable widgets, confusing displays, bad readability and are in a general state of "the emperors new clothes".
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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."
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.
This is IMHO one of big fails of web, that navigation is not out-of-band browser feature (like it is for example in PDF browsers), but it is in-band part of a web page.
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.
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?
this argument is long past its prime. hamburger menus are here. they have been here. and they aren’t going anywhere. could it have been better? probably. could it be still? maybe. will it change today? no.
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.
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.