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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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].
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.
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.
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.
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?
>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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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
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.
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
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).
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.
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.
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.
260 comments
[ 4.1 ms ] story [ 251 ms ] threadAnd 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.
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.
Maybe it's more like something they would not like people to miss if the more powerful options go away in the future.
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.
Yes yes it’s fine if you implement it perfectly and cover all edge cases…which many developers don’t.
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.
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.
Info for the underinformed: https://www.shrm.org/resourcesandtools/hr-topics/behavioral-...
https://www.whoisaccessible.com/guidelines/largest-web-acces...
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!
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
https://github.com/bigjohnson/Real-Programmers-Don-t-Eat-Qui...
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.
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.
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.
(citation needed)
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.
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.
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.
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.
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.
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.
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.
But yeah, where’s the pagination!
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.
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.
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.
Or the engineers are in a situation which requires having non-engineers making engineering decisions.
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.
"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...)
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
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.
There's a link in the header to the nav element at the bottom. I think it works.
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.
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.
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.
Also: you now have to scroll all the way to the bottom of the page to navigate to other parts of the site?
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 would try to enlarge the browser window to see if the full menu shows. Nope.
- 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.
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.
I agree with the "stop resorting to hamburger menus so fast" take however.
(I reordered the links to make them fit better; this could be made prettier with fancier rules than `display:inline-block;margin:0.75rem`.)
Hamburgher menus, albeit fancy, where really confusing at the start. Personally I still think overusing them is design laziness.
The authors webpage is functionally similar except the menu is labeled "sitemap" and it's text is always visible to screen readers.
It contains some mystery meat, that's for sure.
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.
That's always fun.
Not using Safari is an excellent solution.
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.
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.
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
I think anyone doing "Down with X" ought to define X...
And I think I like them, anyway :)
And the burgers are good, but they're not "more expensive than the local roadhouse" good.
It isn't a bad secondary navigation, but kinda odd to say.
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.
I had nojs button for a time in case of the pages that are unreadable due to all js and adverisement.
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?
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.
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.
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.