The core problem with hamburger menus
bt.ht
bt.ht
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.
> 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.
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
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.
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
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.
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 probably related to the rise in popularity of Bootstrap
>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.
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.
Something about the lowest common denominator, whether that can be considered real progress or not.
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.
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.
The character in the square brackets is "AEGEAN NUMBER THIRTY", U+010112. It doesn't display in my browser (Chrome on Windows). Oddly, it does display in my xterm, though that's likely to depend on which fonts you're using. (It's three horizontal lines.)
I presume most hamburger menus use an image.
<svg viewBox="0 0 5 5">
<path d="M0,0h5v1h-5m0,1h5v1h-5m0,1h5v1h-5z" />
</svg> ≡ U+2261 IDENTICAL TO
𝄘 U+1D118 MUSICAL SYMBOL THREE-LINE STAFF
𝍢 U+1D362 COUNTING ROD UNIT DIGIT THREE
U+2630 TRIGRAM FOR HEAVEN
U+1F354 HAMBURGERI 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.
That's probably why I hate hamburger menus. I use a desktop for 95% of my computer use.
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?
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.
Just because most websites / frontend frameworks fail to implement hamburger menus in an accessible way (including Bootstrap 5), does not mean that hamburger menus in general are bad when it comes to accessibility.
With that logic, images / img elements are a core problem per se and should be prohibited, because most pages don't use them correctly from an accessibility standpoint (e.g. forgetting to provide an explicit "alt" attribute).
WCAG / WAI has pretty good recommendations in how to achieve it. Here is their hamburger menu pattern example:
https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/example...
There are so many great properties waiting to be implemented properly.
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.
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.
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.
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.
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
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
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.
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.
"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.
[0]: https://design-system.service.gov.uk/components/header/
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.
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?
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.
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.
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.
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.
The problem with "Google's design language" is that only Google speaks that language.
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.
I would try to enlarge the browser window to see if the full menu shows. Nope.
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.
* 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.
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.
It comes down to understanding what exactly your users are trying to do and developing contextual UI based on the few primary flows. In our case, our main nav at the bottom exposes the most high priority features, and additional pages can be found in the "More" menu. The More menu is functionally similar to the Hamburger menu, but varies in a couple key ways: it sits bottom right of the device, which is much more reachable, and it doesn't include items already shown on the main nav.
[0] https://play.google.com/store/apps/details?id=network.tracke...
- 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.
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.
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:
"Home - About - Projects - Sitemap".
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.
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.
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.
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".
Also: you now have to scroll all the way to the bottom of the page to navigate to other parts of the site?
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 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?
In that view, I understand them even though they're terrible. I just wish they'd stay on smartphones and not appear elsewhere.
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.
There are a handful of tricks that help sell a design for a client, and one of them is hamburger menus.
Along with background video, scroll jacking, over the top parallax, and (cliche) large logos, they make up a quiet set of ways to get a dev out from under the thumb of an irritating client…at the expense of an actually great website.
Ask me how I know.
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.
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.
Just tested that, and it doesn't skip to navigation. It scrolls down, but the next tab is still the links in the content.
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.
Maybe your browser is broken
It works for me as it should both on mobile iOS Safari and on desktop Brave browser. (Brave is Chromium-based.) I didn't test on Firefox because although I used to use ff for many years I am currently not using it.
Product usually wants something to look familiar. "Can we make a website like _pulls up phone_, I want ours to look modern".
Is there a source for this? If there was a poll or something I'd be curious to see.