@tdarb I do agree with you. Hamburger menus - especially those that won't work without #JavaScript - should be eradicated.
However, your proposed solution of puttint the navigation at the bottom of the page doesn't solve one of the problems created by hamburger menus: The navigation options aren't visible after loading the page, so visitors cannot see at a glance what's on offer. I think the navigation should be at the top of the page whenever possible, even if it takes up screen space. 1/2
@tdarb A book has table of contents at the beginning, I think we should aim to normalise putting a table of contents (at least the first level of navigation) at the start of the page and incorporate that into #WebDesign. Most print media offers an overview of "what's there" in the beginning, so why not the #web?
I think it should be okay to cover half of a phone screen with a table of contents before the page body begins.
Just when I think I've tinkered enough with my own small site idea ( inspired by the 1mb club and a few others ) along comes another good idea and it's back to the tinkering mode...
@tdarb "Looking for an example? This very website utilizes this technique, so give it a spin!"
I read that and looked at the top of my screen and found no link. Then I looked at the bottom and found no links. I was smack dab in the middle of the page so I had to scroll to the top or bottom to actually see the links. And then I had to scroll back and find where I was to keep reading. Not a big deal for such a short piece but for longer pages this would definitely get annoying
@cybergrape I think the only way to solve that would be to have a “fixed” or “sticky” menu - which is another poor UX design. Most sites do not have access to headers or footers when viewing the middle of a page, so I’m unsure why this issue is specific here?
@tdarb Most sites don't have constant access to headers/footers, but most sites have a menu button, which you want to replace with headers/footers. I guess I'm conflating hamburger menus with "sticky" menus since the majority of hamburger menus I see are always present on screen. For the record I'm not saying those menus are great, just that there's a benefit to having some kind of menu/sitemap that one can access at any point on the page without needing to scroll to the top or bottom.
One very minor note on your implementation: You should still use a ul with li's in your header nav element, despite only having the two links, since if you press the next key when navigating with a screenreader while focused on the home link, it currently brings you to the next section, rather than the next item in the menu.
@Bradley Taunt On older smart phones with small screens they seem surely needed.
This also tackles: How would you propose to keep things accessible for people who can't afford to always run the newest devices with bigger screens otherwise? (not a polemic question, really)
This, the little balls variant, all the odd shaped variants, they’re all bad
They’re bad because they occlude
You can’t see what’s inside them – you can’t even see why you’d even want to open one of them
That’s assuming you’ve been indoctrinated by the design gatekeeping to have been forcefully educated into recognising that these things are actually an affordance that does things instead of a passive decoration for no real reason, which most normal people would take it for
If you want to hide some options, hide some menu items, hide some vital information, use one of these stupid things – otherwise, don’t
@tdarb@sirber
Do they work on safari on iOS? Because Firefox on iOS uses the same engine underneath, because of Apple's ridiculous anticompetitive policies.
@benjaminhollon@sirber Nope - they break there as well. Just how things are implemented or become outdated as browser engines change. If the navigation was listed as plain, semantic HTML links things would never break ;)
@benjaminhollon@sirber@tdarb This is one of the reasons I switched blakes.dev from Parcel, and the entire site in Preact, to Eleventy/Vite, and only updating parts in Preact. I made sure to have some no-script fallbacks where they were needed, which iirc was only the statuses fetched from this account and the Bridge Wizard which runs client side.
edit: I also forgot icons don't work without JS at the moment because Iconify. I have to think of a way to work around it.
Add comment