[HN Gopher] Using hamburger menus? Try sausage links (2019)
___________________________________________________________________
Using hamburger menus? Try sausage links (2019)
Author : bradley_taunt
Score : 147 points
Date : 2022-03-16 12:04 UTC (1 days ago)
(HTM) web link (tdarb.org)
(TXT) w3m dump (tdarb.org)
| gowld wrote:
| The analysis of Good and Bad is good, and strongly convincing why
| Bad wins.
| BatmansMom wrote:
| Takes up way more space, the point of the page isn't to serve
| menu options. They should be tucked away until the user
| determines they want to use them. Also its so hard to scroll the
| window without accidentally clicking the buttons on mobile.
| autoexec wrote:
| > Zero JavaScript needed
|
| As someone who has JS disabled by default I was happy to see this
| and excited to see what 'sausage links' look like, but when I
| went to the link I was hit with a giant "CodePen requires
| JavaScript to render the code and preview areas in this view."
|
| Since this person has a website (this isn't a tweet or something)
| and feels it's "Pretty simple, eh?" to implement such a menu,
| _and_ already wrote up some sample code, why not have the example
| on the page itself? At least I have the code so I can copy/paste
| and throw it back in the browser, but the author came soooo close
| to making that unnecessary I can't help but wonder what happened
| or what their thought process was.
| bo1024 wrote:
| I also was frustrated that CodePen seemed to need to set a
| cookie before it would function.
| pygy_ wrote:
| Yeah, for that use case, https://bl.ocks.org is better than
| CodePen. Publish a GitHub gist, replace gist.github.com with
| bl.ocks.org, and sneak in "/raw" between the username and the
| gist id. You can even point to specific commit hashes.
| KimJongUndrpnz wrote:
| zamalek wrote:
| > Without proper fade / cut off visual cues, users may not
| understand they can scroll
|
| You could resolve this by connecting the sausages with a line.
| The continuity would give the user a hint that something is going
| off to the right.
| kazinator wrote:
| > _I should start by mentioning that this concept is far from
| new. There are a good number of websites that already implement
| this menu type in some form or another. The point of this post
| isn't to blow your mind with some new-never-thought-of navigation
| design. I'm just trying to bring awareness to another available
| menu concept._
|
| More like "I'm just trying to bring awareness to my blog, and go
| down in UI history as the person remembered for the term _sausage
| link menu_ ".
| spansoa wrote:
| The bulk of my browsing is done with JS turned off, and I'm
| astonished how many sites rely on a JS-powered hamburger menu, so
| I have to enable JS on specific sites just to use their menu!
| There are pure CSS ways to do hamburger menus, and I encourage
| all devs to use pure CSS for a hamburger menu for those visitors
| who browse with JS disabled by default!
|
| For those curious: I have JS turned off because of privacy
| reasons, and accessibility. I find having JS turned off decreases
| the amount of annoyances and popups you see when browsing, and
| the 'fingerprintability' of the browser is drastically reduced.
| zelphirkalt wrote:
| Wait, but then web developers would need to actually learn
| their standard tools like HTML and CSS and how to achieve the
| goal with a minimalist approach. They might need to invest an
| hour or two, instead of downloading an NPM package and slapping
| everything with a meg of JS.
|
| Not sure how realistic this is. When I look at most websites
| these days, I can see clear signs of bad engineering (and lack
| of ethics) everywhere.
|
| I am totally on board with the idea to use CSS for things,
| where we do not need JS. But then again I am not a "modern
| style" web developer.
|
| In my opinion knowing one or two hip and trendy web frameworks
| (I will intentionally not say their names now.) doesn't make
| anyone a good web developer. Real basics are lacking these
| days. When you only have a hammer, everything starts looking
| like the head of a nail. Websites with zero requirement of
| dynamic pages are rendered in JS frameworks, even taking longer
| than static server side rendering of some template, which could
| have been used, given the character of the websites. All done
| under the guise of "This is how websites are developed these
| days." No, not all websites need to be a SPA.
|
| Anyone, who learned a framework can call themselves web
| developer these days. I am sure there are good web developers
| out there, who know their stuff and the basics as well. Even
| good ones working on the websites I criticize, but they may be
| forced to use inappropriate tooling by their environment. One
| does not simply come into an existing project and decide
| oneself to change a whole stack. Basically many projects are
| already locked into their inappropriate use of tools.
| ftio wrote:
| No no no. Hamburger menus are terrible[0] for navigation, and
| this is worse. The only user-centric "Pro" listed by the author,
| namely that users understand its functionality, is totally
| unsubstantiated, and I think, exactly the opposite of what is
| true.
|
| These kinds of menus are fine as "filtering inspiration",
| shortcuts for commonly chosen filters on a dataset, but they are
| not at all OK as general navigation. They hide the vast majority
| of menu items, especially in a long list; their sorting logic is
| typically impenetrable; and horizontal scrolling is terrible on a
| huge array of devices.
|
| On mobile, prefer a tab bar for navigation. If you have a huge
| number of top-level items, deeply consider your information
| architecture before downgrading to a hamburger menu. I won't go
| on, but I could.
|
| Please do not use this ridiculous thing for navigation.
|
| 0. https://www.nngroup.com/articles/hamburger-menus/
| [deleted]
| tbran wrote:
| Please do go on! I'd love to hear more of you thoughts on
| better menus or better info architecture.
|
| I have a project that _could_ have many menu items, and the
| sausage is an interesting idea but not common /well known
| enough that I'd want to use it. Tabs might work.
|
| For many websites, there are SEO implications to having menu
| links (or so we are lead to believe) so I think ridiculous
| menus are sometimes partly a consequence of optimizing for SEO.
| slimsag wrote:
| I love this type of highly-opinionated design thoughts. At work
| we have a pretty complex UI that seems a little bit inescapable
| to me (hard to keep legible due to complexity, etc.) Could I
| get you to critique it?
|
| https://sourcegraph.com/search
|
| https://sourcegraph.com/search?q=context:global+errorf&patte...
| hallway_monitor wrote:
| Disclaimer: am dev, not designer. Home / welcome feels good,
| search is front and center but I can find out more easily.
| Results are eye-friendly as well. I would suggest getting rid
| of the internal scroll panes in the left bar if possible -
| it's difficult to scroll that and / or the left nav or the
| main page. Maybe show the top N and then a "show more" or
| expand / collapse button.
| pwdisswordfish9 wrote:
| So you're saying that either is mystery meat navigation?
| amarshall wrote:
| See also:
| https://twitter.com/LukeW/status/591296890030915585/photo/1
| cobertos wrote:
| Horizontal scrolling isn't that bad on mobile devices. I
| wouldn't want to scroll one of these on desktop but it's so
| simple to just, flick through it with my finger on a phone.
|
| Just put it behind a media query when your desktop-sized nav
| bar gets too big?
| chrisweekly wrote:
| Strong disagree. Horizontal scrolling ~= bad UX.
| seltzered_ wrote:
| It's not bad UX per se (I love it for certain mobile uses),
| but it's bad to make an assumption that horizontal
| scrolling is always available.
|
| Similarly, it's bad to assume that everyone is always using
| a keyboard and mouse (a frustration I encounter in Desktop
| environment communities (e.g. Gnome / Linux) in gesturing
| that some use tablet PCs).
| AlexandrB wrote:
| It can be OK in _some_ cases, but it can be hard to discover
| unless it 's very obvious. Thanks to Apple hiding scroll
| bars, if the elements in a horizontal scroll happen to line
| up with the edge of the screen it can be impossible to tell
| that horizontal scrolling is even an option unless you
| trigger it accidentally.
|
| Edit: Oh yeah, and horizontal scrolling interacts
| unpredicatably with horizontal gestures on mobile. E.g.
| forward/back in iOS Safari.
| jokteur wrote:
| Once I got confused on Google maps android, because I
| thought they had removed the "Share" button. It was a
| sausage menu, but the size of the buttons were such that
| the rest of the buttons were perfectly hidden (you could
| not see the rest of a half button) and of course there was
| no visible horizontal scrollbar.
| u2077 wrote:
| > Horizontal scrolling isn't that bad on mobile devices
|
| I disagree, it's not easily discoverable and I have yet to
| see a single website that implements it well in any context.
| I alway find elements scrolling multiple directions at once
| or end up scrolling down the page instead.
| slaymaker1907 wrote:
| I suspect the writer of this blog post wrote it on a machine
| with a track pad or a magic mouse.
| seanp2k2 wrote:
| I had to read the article a few times to figure out that I was
| supposed to scroll horizontally. When I did that in Chrome on
| MacOS, the following happened:
|
| - the notification widgets popped out from the right of my
| screen
|
| - The entire center-aligned blocks of text on the page moved
| over in relation to my scrolling for some reason
|
| - The browser navigated "back"
|
| - The H scroll bar appeared for a few seconds then went away
|
| Some of these were due to my cursor being outside of the 'nav
| class="sausage-links"' tag, but it seems strange to expect a
| user to first place their cursor inside of an invisible box
| somewhere around the nav strip to be able to navigate it by
| scrolling to and fro.
|
| Seriously, H scroll is way overloaded, and there are so many
| ways to subtly "do it wrong". That, combined with the lack of
| affordance to show users that "there is more to see here if you
| scroll left and right" makes this a really poor UX.
| titanomachy wrote:
| - The entire center-aligned blocks of text on the page moved
| over in relation to my scrolling for some reason
|
| This one kind of makes sense to me. It's the browser's way of
| telling you "you're doing the right thing to scroll the whole
| page over, but there's no content outside of your viewport so
| we'll just snap you back after we let you peek to see for
| yourself".
|
| The rest... yeah, it's definitely an overloaded pattern.
| satyrnein wrote:
| _If you have a huge number of top-level items, deeply consider
| your information architecture before downgrading to a hamburger
| menu._
|
| Ir seems like you can hide all the items (hamburger menu), hide
| some of the items (sausage links or overflow menu), or have a
| deep hierarchical navigation.
|
| While breadcrumbs were fairly established on desktop, mobile
| apps typically only have a single-level back/up button. It's
| easy to lose your place if you have a deep hierarchy. Are there
| are good solutions for this?
| TuringTest wrote:
| Accordions, lists where selecting one item scrolls the view
| one screen to the right to show a sublist... there are many
| common idioms for nested structures.
|
| But the best strategy is always to simplify the number of
| different nodes to flatten navigation as much as possible.
| danielyaa5 wrote:
| The only thing I like about this is the name
| oldstrangers wrote:
| I thought this was presented as a tongue in cheek kind of thing,
| but I guess its not. =(
| fleddr wrote:
| As for the bad of hamburger menus:
|
| "Adds an additional point of interaction from the user (click to
| open, then proceed to read through available options)"
|
| The real world impact of this downside cannot be emphasized
| enough. People click on things they can see by several factors
| more (sometimes 10 times more) compared to the "clean design"
| approach. This is why in very large companies there's internal
| political battles on which links get to be placed in this prime
| digital real estate.
|
| Sausage links is a weird name though. They're horizontally
| scroll-able menu items, which can be anything: links, icons,
| pills, combinations.
|
| As for this creating an ugly scrollbar on desktop, this pattern
| is for about 6-8 links max, which should all horizontally fit
| without a scrollbar on desktop.
|
| As for the "problem" of this not supporting longer lists of links
| or even hierarchical links, don't bother, because those don't
| work anyway. I work on very large ecommerce sites and in one case
| (billion+ page views across 80 countries) even a 3 tier
| navigation structure found only 8% of users actually using it.
| And the trend is downwards, as mobile traffic is now 70%. Nobody
| navigates beyond level 1.
|
| Finally, some polish for the demo: scroll fading should be
| stronger so that people get that it is horizontally scrollable.
| Also, use CSS scroll snapping. This way when people give a strong
| swipe, it doesn't keep going when you let go, it snaps into a
| favorable position.
| bjornlouser wrote:
| jfoster wrote:
| For hamburger menus, I would add an item under "the bad" that
| they make every website feel like it's intended for mobile.
|
| I think one significant advantage of sausage links is that they
| feel less uniquely intended for any single form factor.
| evanmoran wrote:
| I enjoyed thinking about this. A few thoughts on usability!
|
| The text on these sausage links makes the buttons quite visible
| and readable, but I find these joined buttons to be most helpful
| when one is always active and the options are mutually exclusive.
| For example, at the bottom the zoom buttons (1x, 0.5x, 0.25x) do
| this very well. One is always highlighted so it's very easy to
| understand the current state and to pick a different state.
|
| I'd argue this works less well in the top-left buttons (HTML,
| SCSS) because there is a hidden behavior that collapse and
| expands the sidebar. It's clever, but I didn't expect the bar to
| open, nor did I expect it to close when I tapped it a second
| time. It workes pretty well in this website preview example
| because html/css feels like good use of the side panel, but I'd
| argue most hamburger buttons hide much more rarely used views
| like logout, account and privacy settings, payment options, etc,
| so not sure the sausage links can replace all these, but an
| interesting thought experiment.
| uallo wrote:
| On our website we do a similar thing. But we just wrap the
| navigation to multiple lines. Of course, that only works when you
| don't have that many navigation items. But when there are only
| few of them, I prefer wrapping over having to scroll.
| jokethrowaway wrote:
| Not a fan of hamburger menu but I disagree this is an
| improvement, the scrollbar wasn't visible on my platform (chrome,
| mac) and it wasn't clear how to scroll.
|
| I'm not even sure how I would horizontally scroll with a mouse (I
| seem to remember something about hold middle clicking and
| dragging).
|
| Why not just have all the links in multiple rows or have a few
| subcategories + expand and navigate through the list of links?
| onion2k wrote:
| Clear menus that aren't hidden away are great, but a
| _significant_ problem with horizontal 'sausage' menus is that it
| isn't obvious that you can scroll, especially on Apple devices
| that hide scrollbars. The article mentions this as a bit of an
| after-thought ("Without proper fade / cut off visual cues, users
| may not understand they can scroll") but it's the key reason why
| you should avoid them.
|
| To demonstrate, I've forked the example and set the main element
| to 625px wide instead of 600px -
| https://codepen.io/onion2k/pen/mdpVWmr
| davidspiess wrote:
| Airbnb comes to mind, they added left and right arrows to their
| tabs. https://imgur.com/a/MXDabnS
| jdsampayo wrote:
| You can edit ::-webkit-scrollbar to always show it -
| https://codepen.io/jdsampayo/pen/zYprwao
|
| Not a fan but could be forced if needed.
|
| Based on - https://stackoverflow.com/a/7855592/1342097
| ddlutz wrote:
| Yeah it took me several minutes to figure out how to scroll on
| a macbook because there is no visible scrollsbar, to hit right
| arrow, and then the scroll bar appeared. I couldn't click and
| drag it.
| josho wrote:
| That's solved by adjusting the scroll starting position so that
| the first element is partially offscreen. It may initially look
| jarring, like the designer made a mistake but it provides a
| nice visual affordance that you can scroll and it will work
| regardless of the screen width.
|
| https://codepen.io/blipo/pen/Rwxrgpd
| onion2k wrote:
| Now your menu requires JS though, which isn't ideal,
| especially on a brochure site that could work perfectly well
| without it.
| kfarr wrote:
| I just went ahead and made the hamburger menu look like a
| hamburger in this (out of date) project: https://aframe.city/
| didip wrote:
| Why not slot machine menu?
|
| Same idea, but vertical scrolling 3 items at a time and the list
| is a circular linked list.
| klyrs wrote:
| That implementation is annoying to scroll on my desktop. I can
| only imagine that I'd sausage-finger a button trying to scroll it
| on my phone. No thanks.
| tpoacher wrote:
| how about just good old plain html links that reflow exactly how
| you want them to?
|
| </luddite>
| thrusong wrote:
| I could see "sausage" catching on, but I knew these as "pill"
| buttons or links up until now.
| kulix425 wrote:
| Zecc wrote:
| These are not the sausage links I thought they would be.
|
| The sausage links I remember were older than internet on mobile
| being a thing, they were laid out vertically, and they were
| proportional in size to the target sections such that clicking a
| link or clicking the scrollbar right at their side would
| essentially scroll you to the same place on the page.
|
| They were, in my opinion, a much better paradigm than this.
|
| Alas I cannot easily find the demo page again. It might have been
| lost to history.
| timwis wrote:
| Interesting idea, but (a) unless you ensure the second or third
| item is cut-off on all device sizes (may be possible with css
| tweak), it won't be obvious that there's more, and (b) how will
| windows users scroll horizontally? With a scroll bar in the UI?
| Kaze404 wrote:
| So the author is trying to argue that on a (usually) vertical
| rectangle screen the better option to display interactable
| information is horizontally? I'm so confused.
| jonathanlydall wrote:
| Sometime back UberEats switched from a hamburger to a sausage
| menu for the restaurant's menu categories and I really feel the
| experience is worse overall for it.
|
| While I suppose it's now more obvious that the categories are
| there, it's way less usable trying to scroll left and right to
| see them compared to before where you scrolled up and down the
| old vertical hamburger menu.
|
| On a related note, it's incredible to me that Uber never seeks
| feedback on whether or not you think something in their app is
| crap, they only ever ask you for feedback on riders and
| restaurants as if they're the only aspect of the experience that
| could possibly be poor.
| benatkin wrote:
| The scrollable sausage links make it harder to skim them, and
| make you instead read them. I think they might be doing that to
| get you to see more of the menu and perhaps order more, which
| makes them more money.
| kingnothing wrote:
| Uber A/B tests everything extensively before it gets rolled out
| to everyone. They would not have switched away from the
| hamburger menu unless it drove better metrics. I used to work
| there.
| jonathanlydall wrote:
| I suspect that it would have been better in A/B testing as a
| lot of people probably didn't realise the hamburger menu
| would reveal the categories.
|
| So it probably won due to discoverability rather than
| usability.
|
| So on average more people now navigate the menu, but doing so
| is a less pleasant experience for those "in the know" before.
| benatkin wrote:
| If it's an intentional dark pattern, they may take A/B
| testing into consideration, but still decide to make
| usability tradeoffs.
|
| https://www.darkpatterns.org/
| fuzzythinker wrote:
| Having a "..." at the end that drops down a menu panel like
| most hamburger menu do instead of having a horizontal scroller
| may be the best of both worlds.
| eatonphil wrote:
| I noticed this recently on the React docs site on mobile [0].
| It's also used on Github mobile's view of repository for
| switching between Code, Issues, Pull Requests, etc [1].
|
| [0] https://reactjs.org/docs/getting-started.html
|
| [1] https://github.com/multiprocessio/datastation
| cjlm wrote:
| Zach Leatherman has my favorite hamburger menu implementation on
| his homepage: https://zachleat.com
| lnxg33k1 wrote:
| I really hate those menus, didn't know their names but thank you
| for telling me, now I can hate something by name
| unethical_ban wrote:
| It adds a scrollbar or else some kind of cue that scrolling is
| available. Horizontal scrolling in desktop feels unnatural
| personally. And finally, the oval links look like tags in an
| article, not navigational controls. That last point could be
| adjusted by squaring off the buttons, by adding a symbol between
| links indicating a nav path, or something like that.
| dumpsterdiver wrote:
| Not to mention when using a laptop it would be easy to
| unintentionally trigger a "navigate back or forward" browser
| event when scrolling horizontally. Such an annoying browser
| feature.
| felix_n wrote:
| _chef kiss_
| RugnirViking wrote:
| Perhaps a little mean, but its odd that this article about
| website design is plaintext with maximum contrast and default
| font, and the viewport to the code pen is so small I can't even
| see what it's trying to show me without clicking through
| _Algernon_ wrote:
| Why would that be mean? That's great, readable design...
| pupppet wrote:
| I don't mind these on mobile. You can argue that part of the menu
| is cropped out, but with a hamburger menu _everything_ is cropped
| out. You can at least put the most important stuff at the
| beginning, one less click for visitors in many cases.
| css wrote:
| Horizontal scrolling should be avoided in almost all cases.
| bentcorner wrote:
| I'm curious about why horizontal scrolling feels so bad.
|
| Like it works just fine in mapping apps, which naturally align
| to a 2d canvas, but why does it feel so lousy to use with
| almost any other form of information?
|
| Is it because we write left-to-right, top-to-bottom? So text
| chunks fit better with no horizontal scrolling? (I think this
| is also why vertical tabs are so much better than horizontal
| tabs).
| Izkata wrote:
| Next time you use a mapping app and scroll with your fingers
| or thumb, pay close attention to the direction: Most likely
| you're actually dragging it slightly diagonally then
| adjusting vertically afterwards.
|
| I think a large part of it is that horizontal navigation as
| in OP is too thin, so if you do these natural dragging shapes
| your finger leaves the scrollable area. It may still work
| fine, but it feels wrong. Vertical scrolling on the other
| hand, because of what you say with our writing style, has a
| much larger grab area so we can easily stay within the box.
|
| There's also parts specific to it being a menu: A vertically-
| aligned one usually has empty space on the right because the
| menu items probably aren't the same length, giving you a nice
| "grab area" (either your finger with touch or a place to put
| the mouse pointer for a scrollwheel) that doesn't hide
| anything. Plus scanning down a list is easier than sideways
| anyway because every item starts at the same place; just
| imagine how annoying it is to read a bulleted list on here
| when someone accidentally puts it all on one line because
| they didn't add an extra blank line between bullets.
| seanp2k2 wrote:
| what we need are literal site maps with (lat, lon) defined
| for each link, so users can scroll around a fun treasure map
| to find what they're looking for
| coastflow wrote:
| Intuitively, it might be because the mouse predates the
| touchpad, and most mice only have vertical scroll wheels (so
| it conditions users to avoid discovering horizontal scrolling
| as an option, unless you click and drag a horizontal scroll
| bar).
|
| Currently, it's also rare for webpages to feature horizontal
| scrolling, so by habit most users scroll vertically to access
| new information.
|
| Discovery is also another reason mentioned by users elsewhere
| in these comments. Since horizontal scrolling is a rare
| behaviour, a clear signifier [0] is needed to quickly
| communicate that horizontal scrolling is a possibility, which
| is an extra problem that other potential methods don't have.
|
| [0] https://sites.google.com/site/thedesignofeverydaythings/h
| ome...
| CharlesW wrote:
| On PCs, at least. On mobile, it's very natural.
| josefresco wrote:
| Side swiping is "normal behavior" on mobile, side _scrolling_
| is not (on really any device)
| gsich wrote:
| No, as there is usually no proper indication that you can
| scroll.
|
| Even if, it's annoying one missclick and you might land
| somewhere else.
| wanda wrote:
| Mobile browsers frequently come with gestures that can
| effectively override any attempts to scroll horizontally,
| instead taking the user backwards/forwards in browsing
| history, for example.
|
| This is certainly true of Safari, the default web browser for
| iOS, to the point where even trying to cycle through a
| horizontal slideshow of images can bait the user into
| accidentally going back to the previous page.
|
| Not only that, but on iOS I believe it was/is possible to
| cycle between open apps with a very similar gesture as going
| back/forth in browser history -- this already proved pretty
| dumb for browser usability and would prove worse still for
| horizontal scrolling elements on websites.
|
| Personally, I like to operate my mobile device one-handed a
| lot of the time, and at the very least I'm not scrolling
| websites or switching back/forward with both hands even if
| I'm holding the device with both hands.
|
| So the last thing I want to do, especially if I'm carrying
| something in one hand, is to have to try and stretch my thumb
| to the far side of the phone to scroll through a horizontal
| menu.
|
| My other argument against this sausage menu idea, which has
| been around far longer than the date of the linked article,
| is that on many viewport sizes your links may not be half-
| occluded by the edge of the screen. Given that mobile
| browsers tend to hide their scrollbars, since without a
| cursor the scrollbar is just a progress indicator w.r.t. how
| far down the page you are.
|
| Thus, on some screen sizes -- and it isn't difficult to
| encounter, given how many different devices there are out
| there -- _n_ links will be visible in full before the edge of
| the screen, and then there may not necessarily be any visual
| hint that there are more menu items to scroll to. So you don
| 't discover that there are more menu items until you
| accidentally scroll that region.
|
| Finally, I would argue that even for the technophile the
| hamburger menu is preferable at this point, simply because
| they have been conditioned by a good decade's worth of
| responsive web design UX. The sausage menu, being often an
| edge case, is less obvious even to the technophile purely
| because not many sites elected to do it that way.
|
| * * *
|
| It seems to me that the superior alternative to both
| hamburger and sausage menus would be to adopt the hamburger
| menu style, but simply replace ≡ or the menu icon with
| the word "Menu"
|
| The hamburger style can be done without JS too. If you really
| want to avoid JS, just use :target selector or other CSS
| shenanigans.
| lrdd wrote:
| See https://jenne.uk as an example
| jfoster wrote:
| And one advantage of short or medium length sausage menus on
| PCs is that they probably don't require any scrolling.
|
| In my opinion, that's what's so nice about them; natural to
| scroll on mobile, and probably not requiring any scrolling on
| PCs.
|
| If the items don't entirely fit on most PC screens, then I
| would take that as a hint that there's too many items for a
| sausage menu to be a good solution. (subsequently reaching
| for hamburgers, reducing the number of items, or exploring
| other options... eg. a sausage menu could also be more than
| one line?)
| css wrote:
| I do not agree. Content should fit the viewport.
| jokethrowaway wrote:
| This. I still don't understand why editors all have
| horizontal wrapping disabled by default.
|
| Every time I scroll horizontally I die a little.
| Jaruzel wrote:
| Unless you are left handed, in which case those 'natural'
| swipes, become unnatural shoves.
| dangus wrote:
| Absolutely not on sausage links most of the time. I can't tell
| you how many times I didn't realize that menus like this could be
| scrolled.
|
| Another negative not mentioned in the article: they're biased
| toward touch and trackpad users. My browser (and probably most
| browsers) hides the scroll bar by default, so anyone using a
| vertical scroll wheel mouse is going to be confused and/or have
| some kind of difficulty scrolling.
|
| At first I didn't even know that the example in the article was
| functional! I thought it was a screenshot.
|
| Hamburger menus function the same for all platforms, are easy for
| non-technical people to figure out (especially by this point),
| they also don't _have_ to be a hamburger (they can be a word that
| says "Menu," or some other kind of icon like a settings gear),
| and they can expand to a regular menu that quickly shows all
| possible options.
|
| An alternative I thought of: a grid of colorful/contrasting icons
| with text (example: The Uber app for mobile). I think sometimes
| you shouldn't be afraid of taking up screen real estate if your
| app needs to have a lot of options.
| grumbel wrote:
| Isn't that just reinventing tabs or tab-like top menus that have
| been around for decades? Works nice enough when you only have a
| few items to deal with, but really doesn't scale to a larger
| number of items. Horizontal scrolling might work better on mobile
| than on desktop, but it's still not great due to the items being
| so much wider than they are high.
| thesuitonym wrote:
| I guess you missed this bit:
|
| >Better suited for small to medium menu lists compared to
| massive sitemaps
| IYasha wrote:
| These "hambugger" symbols wouldn't look so hambuggerish (but more
| like menu) unless someone had less maniacal affection towards
| rounding all the corners... (typo intended) And now sausages...
| oh no.
| vincentmarle wrote:
| I really had something else in mind when thinking about sausage
| links
| ilamont wrote:
| _When designing medium to large sized menu navigations on the
| mobile web the default go-to, for some time now, has been
| hamburger menus. This isn't necessarily a bad thing_
|
| Tell it to the many people who have no idea what it means on a
| mobile device, or increasingly on desktop websites. I've said it
| many times before, but it's worth repeating: Most people are
| frustrated by modern information tools. According to a 2015 OECD
| computer skills study, <6% of Americans are level 3 (highest)
| while half have only basic skills and 20% can't use computers.
| (https://www.oecd-ilibrary.org/education/skills-matter_978926...)
|
| I like the sausage link concept _because it clearly labels
| options with text_.
| dpcan wrote:
| Well, human beings have grown quite accustomed to using symbols
| to represent actions they need to take. In the United States, I
| remember learning about Mr. Yuck stickers by the time I was 4,
| or the shape and color of a stop sign, green means go, walk and
| don't walk figures, even an exit sign always looked the same
| even if I couldn't read.
|
| The hamburger menu takes someone explaining it to you just one
| time to know what it is every time.
| at_a_remove wrote:
| Mr. Yuck is green, Mr. Yuck is mean, Mr. Yuck also has the
| shape of a face absolutely filled with disgust at having put
| something terrible in his mouth. In short, Mr. Yuck
| communicates something purely by expression rather than
| association.
|
| The hamburger menu looks like decoration, or a portion of the
| I Ching. Nothing about three horizontal lines says "I contain
| options for navigation."
|
| Now, were six lines used, with every other line being
| indented, and then a \ or a / here and there, it would look
| like something folded up, and I would think, "Oh, unfold this
| thing." But three horizontal lines just ... no, I got
| nothin'.
| gowld wrote:
| It's an iconic representation of a list or menu. You learn
| it once, and it works everywhere. And it fits on a small
| screen.
| josho wrote:
| I encourage you to go watch a novice computer user. After
| seeing them struggle I suspect you'll change your mind.
|
| I personally view the hamburger menu similar to my junk
| drawer at home. It's where the designer stuffs crap that
| isn't very important. So, it's the last place I look for
| when I need to get something done in an app.
| Angostura wrote:
| 'You learn it once' is doing quite a lot of work there. I
| tend to use a hamburger labeled with 'Menu'
| seanp2k2 wrote:
| In Chrome right now, it's 3 dots aligned vertically. Not
| much better really.
| II2II wrote:
| The other thing to note is that traffic signs are designed
| to alert people of one particular thing and are intended to
| be language neutral. Hamburger menus are designed to
| conceal multiple things and the contents are usually in a
| specific language.
| [deleted]
| rmetzler wrote:
| Icons don't work with on page search (e.g CTRL+F).
|
| And it's hard to describe icons to someone else on the phone.
| I'm not sure if Word is still the mess it used to be, but
| this kind of interface design can be really hard to
| understand and learn. Currently for me this is Blender. The
| software is complex, the interface mirrors this, but if
| you're new to it, this is really hard to learn.
| kaba0 wrote:
| I guess after a point it is simply inherent complexity.
| Like, I can't even imagine a GUI that would make someone
| seeing it for the first time know some semi-advanced
| feature in Word.
|
| First of all, the whole problem domain has to be
| taught/discovered. And sure, people often learn by trial-
| and-error and it makes sense to try to maximalize this sort
| of discoverability in all software, but I would say that it
| doesn't scale. Even with the "better" labeled menus, gimp
| is not intuitive to say the least.
|
| So perhaps the (often annoying) teach you by showing is the
| better direction? My gripe with it is that it is often
| applied for trivial mobile apps for things like "search by
| using the search bar".. but I think an all-menu/all-action
| text-based search functionality would be a must as well.
| brimble wrote:
| Firefox and Chrome have proven Apple right, in forcing a top-
| of-screen menu bar to appear whether the application wants it
| to or not. This was demonstrated to me recently when my parents
| couldn't figure out how to print on Windows in Firefox (because
| there's no standard menu on it--they know "file -> print" just
| fine) and called me for help. After a moment of confusion on my
| part as I remembered that FF doesn't have a normal menu
| anymore, then a brief and totally failed effort to talk them
| through finding the beyond-stupid, tiny, "everything" drawer
| button, I finally just told them to press the keys for the
| keyboard shortcut, which they won't remember and will have to
| ask me again next time.
| slowmovintarget wrote:
| You can turn the regular menu on for them in the options.
| (Firefox: Right-click on tool bar, choose "Menu Bar" option
| to enable.)
| ilamont wrote:
| I suspect many people reading this HN thread also serve as
| their family's tech support team. Every week I get calls or
| emails from my parents requesting help figuring out something
| that's not obvious from the UI, is accidentally triggered by
| users, deliberately activated (by the app) during a software
| update, or buried deep in some settings or submenu. This
| week's selection includes:
|
| - Turning off yet again the annoying computer voice
| announcing any navigation or volume change on my parents' new
| Samsung TV (accessibility option, not sure why it turned on,
| but it required me visiting their home in person again to
| turn it off)
|
| - Trying to help my father disable the "get Outlook for iOS"
| line that suddenly started to be appended to the bottom of
| his work emails.
|
| - Helping my spouse troubleshoot a Shopify app feature that
| prevents >1 item being subtracted from inventory at a time
|
| - Figuring out how to enable a social media save shared
| photos to her phone's photo album
|
| Yes, sometimes software is so complicated and feature rich
| these items have to buried deep in the settings. But often I
| find that the lack of obvious text labels for basic features
| and navigation items is the problem. Hamburger menus and the
| three dots "more actions" icon are a poor substitute for
| clear text labels and links.
| brimble wrote:
| The thing about modern software that infuriates me the
| most, watching my parents struggle with it, are the damned
| screen-takeover or focus-stealing on-launch notices,
| usually about some update they don't care about. They
| opened the thing to use it, not to read your changelog or
| marketing shit. Coupled with auto-updating, it confuses the
| absolute hell out of them, and the way modern design (and
| Android especially) make it hard to tell what's a button
| and what's text, and inconsistent cutesy button labels,
| make it even worse (it often takes them a while to figure
| out how to make the thing they didn't ask for and never,
| ever want go away). Google loves to do this pretty much
| everywhere, and it's especially bad on mobile, but FF
| desktop's post-update new-tab-to-market-at-you-about-what-
| changed (nothing important, 95%+ of the time) is almost as
| bad.
|
| Hell, I don't like that stuff either (does _anyone_?) but
| it 's just a minor annoyance for me. For them it can mean
| they give up trying to do whatever they wanted to do.
| ryandrake wrote:
| > The thing about modern software that infuriates me the
| most, watching my parents struggle with it, are the
| damned screen-takeover or focus-stealing on-launch
| notices, usually about some update they don't care about.
|
| I would bet in almost all cases, these can be directly
| attributed to the developer company's poorly devised
| career incentives. Behind every full-screen "OMG CHECK
| OUT WHAT'S NEW" takeover or notification-spam lies a
| product manager or engineering manager whose bonus is
| tied to some vanity measurement of how many users are
| _engaging_ with the new feature they launched. "How much
| of the user's attention and screen space can I take over
| in order to try to jam this unwanted feature down their
| throat and show huge usage numbers next performance
| review?"
| flutas wrote:
| > - Turning off yet again the annoying computer voice
| announcing any navigation or volume change on my parents'
| new Samsung TV (accessibility option, not sure why it
| turned on, but it required me visiting their home in person
| again to turn it off)
|
| For this one, I don't think it's a software update but
| rather user error (though it's not clear even to me how).
|
| I myself have accidentally enabled it, there seems to be
| some combination of buttons on the remote that will enable
| it. Still not sure on the specific combo though.
| rustyminnow wrote:
| I know this is besides your point, but in Firefox there is an
| option to turn the menu bar back on (at least until they
| remove the option :/).
|
| If you go to the "Customize Toolbar" page, on the bottom left
| where it says "Toolbars v" you can check "[ ] Menu Bar". Hope
| that helps (a little)!
| qwertox wrote:
| Or right-click on any free space on the top row. There's an
| option in the menu.
| rustyminnow wrote:
| Oh you are right! That's how I was getting to the
| Customize Toolbar page too haha. Totally missed that!
| anon_123g987 wrote:
| Or press the Alt button to show the Menu bar temporarily.
| brimble wrote:
| It'd occurred to me there was probably a setting to fix it,
| but I've forgotten to check the last couple times I've been
| over, because I'm a bad son :-( Thanks for confirming my
| suspicion, will try to remember to change that setting for
| them next time.
| unethical_ban wrote:
| You can also tap "alt" to make it appear, I believe, if
| it isn't enabled.
| layer8 wrote:
| That's anecdotal, but my mother who "grew up" on DOS and
| Windows was never able to grasp the relationship between the
| top menu bar and the application window on MacOS. I bought
| her a Mac in 2010 because they are supposedly more intuitive
| and I didn't want to provide PC support anymore, but it was
| no better than Windows for her at all (also not worse overall
| I guess).
| seanp2k2 wrote:
| The first time I discovered that "dragging an icon to the
| trash" was one of the few ways to uninstall an application
| on Mac, my mind was a bit blown. I was struggling so hard
| to find an "Add/remove programs" equivalent or an
| uninstaller.
| layer8 wrote:
| I believe it's because that literally just deletes the
| application file/directory, there's no hook for
| application-specific uninstall routines.
| not2b wrote:
| Remember when the way to eject a floppy or other
| removable disk on a Mac was to drag its icon to the
| trash? That was weird.
| stouset wrote:
| Another anecdote, my mom was essentially a lifelong Windows
| user. I would have to answer basic tech support questions
| for her several times a month.
|
| She's switched 80% of her use to an iPad and the rest to a
| Mac laptop, and I get a question about once a year.
|
| YMMV.
| layer8 wrote:
| I ended up switching my parents to iPads as well, which
| was a huge improvement.
| brimble wrote:
| I spent years thinking they [EDIT: Apple's always-top-of-
| screen application menus, that is] were dumb for that
| reason. It never occurred to me that major software vendors
| would be stupid and/or user-hating enough to ditch the
| standard top menu, when they have a whole bunch of stuff
| that _should_ go in it.
| felix318 wrote:
| I seem to recall Steve Jobs saying the reason the menu is
| at the top of the screen is that it's easier to hit it
| with the mouse, you just push it all the way up. I think
| it's a valid point.
| dec0dedab0de wrote:
| I have had my second monitor on top of my main one for
| the last 20 years, when I switched to a Mac this was the
| hardest thing to get used to.
| roughly wrote:
| Apple's HIG used to have a bunch of these nuggets -
| things about predictability of where inputs are, what was
| clickable, etc. Not sure how much has been preserved over
| the years, but the original docs are pretty legendary.
| brimble wrote:
| I've noticed it's really nice if you like quarter- and
| half-screen layouts (or anything else that's sorta
| tiling-like). Four different programs on the screen, only
| one "file, edit, ..." menubar eating space.
| layer8 wrote:
| The top menu made sense when computer screens were small
| and the mouse pointer thus never far away from the top,
| and applications were fullscreen most of the time anyway.
| ziml77 wrote:
| To me it seems the top menu bar is a holdover from early
| Mac OS. I saw a demo of one of the early versions of the
| OS, and it made a ton of sense there. The OS could only
| run a single application at a time, but that application
| could have multiple windows. From that perspective it's
| very sensible that whichever application had full control
| over the screen would want a menu bar global to its own
| windows.
|
| Now though, it's just weird to have the menu bar at the
| top of the screen. And it's especially strange when
| there's no windows for the application left but the menu
| bar for it is still visible (something that wouldn't be
| strange in the single app at a time model)
| babypuncher wrote:
| The way Apple does it is also better design than a
| conventional menu bar.
|
| I can see why FF and Chrome hide it by default. Most of the
| actions tucked away in it are either used infrequently, or
| have common keyboard shortcuts. Turning it on in Firefox
| makes the chrome feel cluttered to me.
|
| By exporting the application's menu bar to an OS-provided
| panel that includes other OS-provided functions (clock,
| status indicators, wireless controls), they enforce both a
| strong level of consistency while allowing for reduced window
| clutter.
| [deleted]
| JadedBlueEyes wrote:
| On Windows, and most Linux apps, pressing Alt reveals a menu
| similar to MacOS's global menu. It's basically impossibe to
| discover, but it's there!
| brimble wrote:
| I knew that from long long ago adventures in mouseless
| Windows-using, for focusing it, but not for causing it to
| appear if there isn't one. Thanks.
| thevoiceless wrote:
| In case it's helpful: You can also tell them to right-click
| anywhere in the main toolbar area aside from the URL field,
| select "Customize Toolbar...", and then drag the "Print"
| button to wherever they want it. Alternatively: Hamburger
| menu > More tools > Customize toolbar...
| fiddlerwoaroof wrote:
| I'm curious if words do better if you test people who don't
| know the language.
| abortionlover69 wrote:
| reaperducer wrote:
| The problem isn't the mechanics of the hamburger menu, it's
| that we use an icon to represent it. I've never seen a case
| where space was so scarce that the icon couldn't be replaced by
| the word "Menu."
|
| Perhaps there is some issue with internationalization, but I've
| been to restaurants in 30+ countries, and "Menu" seems to be
| pretty universally-used word.
| at-fates-hands wrote:
| I can give you some anecdotal evidence that supports what
| you're saying.
|
| The very large health care company I work for now is currently
| redesigning their global nav. We've had no less than 10-15
| design working sessions. The same thing that continually comes
| up is the hamburger menu and how to handle it.
|
| The reason is the company did some pretty extensive research
| with seniors (a big chunk of our clientele) and found many
| don't have any idea the hamburger menu is a standard menu now
| for both desktop and mobile apps. We were told we either have
| to use it minimally, or not at all. Its been a struggle to find
| something that everybody can agree on. We have a very small
| team of 5 people - 2 designers, 2 devs and myself
| (accessibility) working on this.
|
| I also happen to work in accessibility which many of the
| apps/sites that use hamburger menus on mobile either create
| keyboard traps or are totally unusable for screen readers. I'm
| at least happy our company is trying to move to something
| different.
| hn_throwaway_99 wrote:
| > I like the sausage link concept because it clearly labels
| options with text.
|
| 100%. I'm kinda surprised how the 3 lines hamburger menu got so
| prevalent in the first place, because it _always_ user tests
| poorly. My guess is that when flat minimalism (my favorite
| shitty example of this is when Android expected everyone to
| know what a flat square, circle and triangle are supposed to
| mean) was the rage, even though user testing always showed a
| ton of people didn 't know what the three lines meant, that
| designers felt it would eventually become "the standard" and
| people would know.
|
| Problem is, years later, tons of people _still_ don 't know
| what it means - every time we do user testing, words do better.
| I think these days design fads change so frequently that there
| really isn't enough time for any design to be that "standard"
| long enough for everyone to really grasp it.
| ridgered4 wrote:
| But seriously, what does the hamburger icon mean?
| jayd16 wrote:
| It's three lines. A minimalist list.
| politelemon wrote:
| Not quite, the usage of lines are still conveying something,
| it's similar to pause, play, stop on media players, it's
| similar to back, forward and refresh icons on the browser.
| Line based symbols are easy to pick up and have been picked
| up by users from our testing, I'm really not sure what
| studies you're referring to (?)
|
| For an actual shitty example, look at Macos window button
| controls. Red yellow and green circles, they convey
| absolutely nothing, you're expected to learn them. Instead of
| slating this shitty design, everyone just rolls over and
| learns them.
| dkonofalski wrote:
| I think you're either unaware or ignoring that, in both of
| those cases, there was precedent that people were already
| familiar with when those icons came out. Pause, play, and
| stop, for example, were found on nearly any
| media/cassette/tape player and served as simple indicators
| of the direction the tape/spool was going. The arrow to
| left meant the reel was spinning backwards because the tape
| moved to the left, the square meant stop because the reel
| didn't move at all, and the play icon meant that the reel
| was moving to the right. Add in double arrows to denote
| speed. Add a line at the far left/far right to indicate
| beginning/end.
|
| The hamburger has no such lineage. It started as a menu
| icon and changed slightly but no one had any idea what even
| the initial icon meant without an explanation that it's a
| list.
| underwater wrote:
| The hamburger menu represents a list of items. It's
| symbolic, but at least a direct representation of the
| outcome the user wants.
|
| The play and stop icons were icons that describe an
| operation of a machine that will then indirectly produce
| the outcome the user wants. They require the user to know
| how the machine functions. No one thinks "I would like
| the tape to move to the right" or "I would like the music
| to stop, which means the tape needs to stop moving, which
| means stopping the spools, which means selecting the
| least circular shape".
| Izkata wrote:
| The original symbol represented a menu that pops up from the
| bottom of the screen, as they worked in the early Android
| versions: https://www.cnet.com/a/img/resize/06c3657d29dbfaf9c
| c921d2690...
|
| The three-lines version was an evolution of that, just
| chopping off the sides to go extra minimal, and happened very
| quickly.
|
| And nowadays we have an even more minimal one, shortening the
| three lines to three dots.
| TuringTest wrote:
| At least the three dots look like the ellipsis, which has a
| standard meaning of "there's even more..."
|
| At the end of a list of other menu entries, there's a
| chance that it can be inferred to mean "let's me see some
| more".
| slowmovintarget wrote:
| Kebob menu isn't much better than the hamburger menu. Why
| are all these web affordances named after food? I'm hungry
| now.
| gary_0 wrote:
| > flat minimalism
|
| "Modern" design is so opposed to any skeuomorphism that every
| item on the screen has been totally drained of color and
| detail. So many UIs are frustrating to use because everything
| is an abstract monochrome glyph. The extreme of fashion over
| function we're suffering right now is mind-boggling.
|
| In the early 2000's we had books like Steve Krug's "Don't
| Make Me Think"; but now, for some reason, decades of design
| and engineering knowledge are being totally ignored, to
| society's great detriment.
| pmontra wrote:
| I wonder if those books are ever read nowadays or if the
| sheer number of projects requiring design skills led to
| uneducated masses of coders or whatever (me too) doing the
| job of real educated designers. And fashion, and Bootstrap
| and all those time saving toolkits.
| jayd16 wrote:
| Designers like the hamburger because it lets them sweep
| anything they haven't considered under the rug. They're
| simple so no one attempts to cram in carousels or videos or
| what have you, so its the easiest way to add functionality
| into an app that doesn't have any other thought put into
| expanding the navigation. So in that sense they're highly
| productive.
| tshaddox wrote:
| > Designers like the hamburger because it lets them sweep
| anything they haven't considered under the rug.
|
| Aren't you just describing all collapsible menus? I thought
| the complaint about the hamburger menu was specifically
| that the icon is unclear. It seems odd to disparage all
| collapsible menus, particularly on mobile where it's very
| easy to have a small number of reasonable menu options with
| no way to possible fit them onto the screen without a way
| to collapse them.
| johannes1234321 wrote:
| Other collapsible menus need a name of some sort and then
| can only take things /somewhat/ related to that name. The
| "Hamburger" can take anything.
| kitsunesoba wrote:
| This is one of the things I dislike most about hamburger
| menus: they're effectively junk drawers than can contain
| anything and everything and are painful to try to search
| through.
|
| Just about every prior type of navigation is better.
| jstummbillig wrote:
| The hamburger menu on the web is what the touch screen are
| for cars. You can fit anything on there, no matter what the
| future might hold. No need to think about your content too
| hard.
|
| And in fact the designer is really not supposed to think
| about the content too hard. It's not how we do web. This is
| how we do: There's a CMS and you can add and remove items.
| How many? As many as the client later discovers they want.
|
| It makes sense, kinda. It solves issues for different parties
| that are involved in the process. Like with touch screens in
| cars, we get something for what we give and it might just be
| the best we can reasonably do given constraints.
|
| It's just not that great.
| Jiro wrote:
| Flat minimalism (compared to using words) is popular because
| you don't need to have translations of square, circle, and
| triangle into foreign languages.
|
| (Square, circle, and triangle is also the old Electronic Arts
| logo, but that's probably not the reason.)
| qwertox wrote:
| > Problem is, years later, tons of people still don't know
| what it means
|
| This is a problem which could get solved if every mainstream
| media presents this icon for 30 seconds with a short
| explanation for one week during the main news hour. Or every
| newspaper would dedicate 1/4 of a page to it for one week.
|
| Viewers educated, problem solved. Make an exception for such
| an important icon.
|
| I personally find the sausage link horrible. I have to scroll
| by picking the scroll bar with the mouse because the scroll
| wheel is not working in the demo, and it's anything but a
| compact display of information, unlike what you get with a
| drop-down popup menu.
| the_pwner224 wrote:
| > my favorite shitty example of this is when Android expected
| everyone to know what a flat square, circle and triangle are
| supposed to mean
|
| What is this referring to?
|
| Edit: I'm so used to these buttons that I didn't even realize
| they were just simple flat shapes. It definitely would be
| confusing for someone new to Android or for someone who's not
| good with tech.
| throwawayben wrote:
| The soft buttons on Android:
| https://i.stack.imgur.com/YKCPp.png
| qwertox wrote:
| I believe the navigation buttons on the bottom. I see no
| issue with them, since it's easy to associate the left
| triangle with back, the circle with something that affects
| everything and the square with something else which does
| something which is obvious once you tap it.
| Sohcahtoa82 wrote:
| In Android[0], the "back" button on the bottom is a
| triangle pointing left. The "home" button is a circle. The
| "show recent apps" button is a square. All are just flat
| shapes.
|
| Completely unintuitive to anybody that's never used Android
| before.
|
| Contrast that to the early days of Android where the Back
| button was a curved arrow, the Home button was an icon of a
| house, and the Menu button was the hamburger menu people
| are familiar with, except the lines were thinner.
|
| [0] This may actually vary depending on what phone you have
| and if the maker changes these, but on my Pixel 6, this is
| the description.
| kozd wrote:
| Back symbol pointing left is probably less intuitive if
| your language isn't left to right oriented. Wonder if
| back symbols or back animations have ever been
| "localized" to orient based on the language used.
| ryanbrunner wrote:
| Android sort of gets a pass in that it's something that's
| constantly used by the user, so there's some ability to
| train people into arbitrary and unclear UXes, especially
| if they're only a few buttons (a good example is game
| controllers where what buttons do is completely
| disconnected from the letter or symbol they're assigned).
|
| iOS is pretty similar in that a good number of the
| navigation gestures aren't super intuitive and not really
| discoverable until you build some muscle memory.
| ggambetta wrote:
| I can confirm that the Meatverse [0] will be built on these UX
| primitives.
|
| [0] http://meatver.se
| flak48 wrote:
| Better known as pill navigation
| karaterobot wrote:
| I think of pill navigation as connected, like: (___|____|___)
|
| These remind me of what Material Design called Chips.
| krossitalk wrote:
| Yes, these are Chips exactly (especially when scrolled
| horizontally, ala YouTube mobile Home page).
| https://material.io/components/chips
| dpcan wrote:
| I think this would be a problem in terms of accessibility.
|
| Gestures are required, text disappears horizontally, no visual
| indicator that you may have to scroll horizontally... I don't
| know, maybe I'm wrong, but I've also been a fan of the hamburger
| menu since it arrived.
| oh_boy wrote:
| This isn't less accessible than a hamburger menu. Even the
| opposite might be the case as defacto most hamburger menus are
| implemented without proper focus handing or correct aria
| attributes for announcing open/closed states.
|
| With the sausage menu, at least as screenreader user, you will
| have less issues as you can tab through a list of links
| immediately without the need to open a broken menu . Also
| scroll position is adjusted by the browser automatically to the
| element in focus, so it isn't even a problem for keyboard users
| with eyesight.
___________________________________________________________________
(page generated 2022-03-17 23:01 UTC)