[HN Gopher] In Praise of the Unambiguous Click Menu
___________________________________________________________________
In Praise of the Unambiguous Click Menu
Author : sandebert
Score : 172 points
Date : 2021-03-20 08:15 UTC (14 hours ago)
(HTM) web link (css-tricks.com)
(TXT) w3m dump (css-tricks.com)
| SiVal wrote:
| From the article: "When you think about it, click menus are
| actually what we expect already in most other contexts."
|
| [slapping my forehead] For more than a decade I've been
| dumbfounded that nobody seemed to be thinking about something so
| obvious. I mean, the browser itself had well-functioning,
| standard menus. By the time CSS enabled web dropdown menus, the
| behavior of dropdown menus had been extensively tested in
| usability labs (all sorts of variations) and almost completely
| standardized across Windows, Mac, NeXT, BeOS, etc: Menus,
| consistent with all types of button, wait to be told to open
| which, also consistently, can be done by mouse, keyboard, touch,
| voice, eye-controller, etc.
|
| Then some web developer decided to create menus that didn't wait
| for you to ask. You'd click a link at some scroll position so
| you'd navigate to the new page with your mouse in some random
| position, which would then trigger some random menu to leap out
| and cover what you were looking for, forcing you to find a way to
| get off of it so it would close without accidentally triggering
| another menu and starting over. And if you finally saw what you
| wanted on some other part of the page and moved your mouse toward
| it: BLAT! Some other random menu was triggered en route. Or you
| have menus arranged so that trying to reach one keeps triggering
| another nearby that then covers it (looking at you, Amazon!)
|
| Then everyone else seems to have said, YES, I too want visitors
| to my page to feel as if they had just stumbled into a minefield.
| Instead of the extensively tested, usability-research-based
| standard menu behavior of clicking a menu or button when you want
| it, I want them to experience the thrill of not knowing what
| might happen and for it to happen differently depending on where
| they enter the page and whether they enter with a mouse or touch
| device.
|
| (Tooltips are okay if they are so small that they are very
| unlikely to cover anything you might need. You still have to set
| their delay long enough to not trigger at all when passed over.)
|
| We should be using the menu lessons that were well researched,
| well known, well liked, and well established back in Win95 days.
| We can pretend it's a newly invented concept called "click menus"
| if that helps.
| kitsunesoba wrote:
| Fully agree. Mobile variants of sites are another matter of
| course, but for desktop versions much of UX/interaction has not
| only been solved, but highly refined for decades. Traditional
| desktop design patterns might not be particularly flashy or
| compatible with current design trends but they work and work
| well which is what's most important when it comes to software.
| dehrmann wrote:
| > some web developer decided to create menus that didn't wait
| for you to ask
|
| IIRC, there was a time window when you could do hover menus
| with pure CSS, and this might have been part of the draw.
| dillondoyle wrote:
| It's hard to get a good solution on mobile.
|
| Seems most solutions either expand like accordion, which makes
| accidental clicks (especially when they animate for like 1s).
| Same issue as an 'overlay' z-indexed over the navigation. Simply
| expanding can take up the whole screen, i've seen a lot of 'side
| navigation' that expands right, or a hamburger that goes full
| screen. I don't like those...
|
| And it seems less accessible for screen readers if it's not
| actual selects? Maybe not with good aria hints
|
| I have been experimenting with using actual selects for a current
| plugin tool I'm building.
|
| If anyone has good examples to build on?
|
| Trying to combine the nice desktop styling of this codepen, with
| an actual mobile os select ux.
|
| https://codepen.io/ahmedhosna95/pen/GGRXBR
| https://demos.jquerymobile.com/1.4.5/selectmenu/
| rapnie wrote:
| The final result has the annoying effect that things scroll up,
| when I scrolled lower items to the middle of the bounding box (on
| FF/Android). But maybe this is just the fiddle viewport's
| behavior.
| brianzelip wrote:
| > Since click menus require JavaScript, we should consider how
| this menu can be progressively enhanced in case JavaScript fails
| for any reason. Our classic hover CSS trick is still good for
| something after all!
|
| Yet the demo linked to in the article[0] doesn't work w/out js at
| time of writing. The article makes me want to buy in, but the
| lack of non-js implementation seems awkward.
|
| I make css hover dropdown menus a la "Setup 2" in the article's
| diagram, ie: the drop down top level nav item is not clickable,
| but expands on hover and keyboard navigation.
|
| I personally prefer one less effort. A mouse click is always a
| mouse hover first.
|
| [0] https://github.com/mrwweb/clicky-menus
| oneeyedpigeon wrote:
| > Using an application menu (e.g. File, Edit, etc.)? Those almost
| never appear on hover!
|
| The author is clearly not a macOS user. In macOS:
|
| - clicking a top-level menu label toggles between 'menu open' and
| 'menu closed' state
|
| - in 'menu open' state:
|
| a) entering a top-level menu label opens that submenu
|
| b) switching to a different app or clicking outside of any
| submenu toggles to 'menu closed' state
|
| I'd be interested in hearing if other OSes do something
| different. Maybe the fact that it's a global menu is relevant.
|
| > All links are contained in submenus except for top-level items
| that have no submenu (e.g. "Home"). We'll deal with what happens
| to those top-level pages in a moment.
|
| Did the article end up covering that? As another comment
| suggests, having some links stay on-page and others navigate away
| is a potential problem. If it's _only ever_ Home, that might be
| mitigated -- you can always leave Home out anyway and utilise the
| site logo. I guess, for other top-level-only menus,
| differentiating them visually would be the answer -- maybe blue
| underline for links and three-dimensional rectangles for
| 'buttons'? (ducks)
| anoncake wrote:
| Same on Windows and Linux.
| still_grokking wrote:
| This was also my first though: Did this person never saw a
| properly working menu before?
|
| The proposed solution in the blog post is just crap. That's not
| like menus work!
|
| That one needs to click to close a menu is especially bad UX.
|
| But the root of all evil is clearly that web-tech just isn't
| suitable for application development! You need to "reinvent"
| basic stuff. Like menus...
| snarfy wrote:
| How do you hover on mobile?
| mtVessel wrote:
| If it's implemented at all, it's typically "long press", which,
| for my money, is about as counter-intuitive as it gets.
| lucb1e wrote:
| Back in the good ol' days, that is 2018, I had this Galaxy Note
| 2 with a little pen. When hovering the pen over the screen, it
| would create a cursor under it and trigger onhover events when
| moving it around just like a desktop cursor.
|
| I could open hover menus on mobile from 2012-2018 when not all
| sites were adjusted to mobile yet.
|
| It was glorious.
| gmueckl wrote:
| Still works in all the newer Samsung devices with an S-Pen,
| even in some regular apps, where you get to see e.g. button
| tooltips when hovering. This little stylus is what makes me
| stick with that brand, admittedly.
| gabipurcaru wrote:
| My one contention with click menus is that clicking on _anything_
| has a nonzero chance of accidentally navigating away from the
| page, depending on the particular website's implementation (and
| depending on whether the JS assets have finished loading). Hover
| menus are risk free in this regard
| strogonoff wrote:
| That's one thing the article forgets. Going with a click rather
| than hover means you need to implement the "one click to
| select, double to activate" if things can be activated
| inadvertently with a single click.
|
| I'm familiar with this issue as I've been trying to abandon
| excess hover effects and switch to clicks in apps I build on
| web stack. It's difficult since most good UI frameworks rely on
| hover effects, and requires care in preventing accidental
| actions from a single click if you want your users to go with
| your paradigm and not hate you.
| thaumasiotes wrote:
| > Hover menus are risk free in this regard
|
| Well, the web site is perfectly _capable_ of using an
| onmouseover trigger to navigate you away from the page you're
| on. You have to trust them not to be jerks about it.
|
| Clicking is pretty much the same thing.
| mbg721 wrote:
| Using a phone basically gives me the motor control of a
| toddler. Stuff pops up on hover, or the page jumps down because
| of some laggy ad, and I'm clicking on stuff inadvertently and
| swearing at clouds all the time. The best menus for me avoid
| that by being in the same place on the page and being big
| targets.
| shmooth wrote:
| good point -- i like way-too-large/unambiguous clickable areas.
| alpaca128 wrote:
| Which would not be a problem if sites wouldn't make it
| increasingly impossible to open links in new tabs.
|
| Will clicking the link delete all progress? Better click with
| the middle mouse button. Now there's another set of
| possibilities: 1) the linked site opens in a new tab, 2)
| nothing happens, 3) an empty tab opens, 4) a tab containing a
| borked site opens, 5) the button is so broken the browser can't
| even recognise it as interactive UI element and instead turns
| on autoscrolling.
|
| Yes, please give me hover menus, and when you're at it use
| links for links. HTML tags aren't just there as suggestions for
| weird JSX component names.
| Izkata wrote:
| 6) the site uses Javascript to disable the default action and
| reimplements it, treating middle clicks as left-clicks and
| browsing away from the current page instead of opening a new
| tab.
|
| Jira does this in several places, but not everywhere.
| etxm wrote:
| I have a hard time not smashing my laptop when this
| happens.
| dlkmp wrote:
| Atlassian software is definitely the champion in creating
| unexpected behavior within their apps. I'm using
| Tridactyl to use vim motions in my browser and they've
| made it entirely impossible for me to search within a
| page as they capture '/' to open the issue search.
| superjan wrote:
| I think he's right. Hover menus are slow (often you need to wait
| for it to open), and if you accidently hover just before trying
| to click something, you will click on the surprise menu, not what
| I want to click.
| datavirtue wrote:
| I have been using them for several decades and I still
| accidentally hover wrong nearly every time.
| Kye wrote:
| I gave up on using a mouse on them a long time ago and just
| use arrow keys if it's more than one deep past the initial
| popup.
| shmooth wrote:
| i had no idea one could write so much about the unambiguous click
| menu.
|
| that said, i agree -- the Wordpress top nav bar kills me daily.
| now i'll look for a fix.
| weeboid wrote:
| tldr, author recommends click (instead of hover) to activate
| dropdown menus
| blunte wrote:
| The "why" is the important bit, so your tldr is not helpful.
| adontz wrote:
| To my taste this is totally wrong. Web is web and not desktop.
| Some web designers try to draw web as a desktop for years and
| that confuses even more because these two are not the same.
|
| Whatever navigates you to a different page is a hyperlink.
| Hyperlinks are underlined, blue or purple if already visited.
| Sounds boring and does not fit your favorite orange-lime color
| theme, I understand that. But that is also an actual standard
| users are used to. Desktop application have no similar concept.
| In Windows (Not sure about Mac) buttons or menus which open other
| windows should have ellipsis (...) at the end of in their name.
| For instance "File\Save" does not have one, but "File\Save as..."
| has one, because opens another window.
|
| All texts in the examples are hyperlinks, but none are underlined
| and that is confusing in the first place. I do not understand why
| people do that. I feel like that should be prohibited, or at
| least considered a very bad practice. None have ellipsis either,
| if you follow Desktop standards.
|
| Want to know if menu parent is a hyperlink? Easy, it is, if
| underlined. Period. No confusion.
| Silhouette wrote:
| _Hyperlinks are underlined, blue or purple if already visited.
| Sounds boring and does not fit your favorite orange-lime color
| theme, I understand that. But that is also an actual standard
| users are used to._
|
| It might have been 20 or 30 years ago, but not any more, and
| Jakob's Law is as relevant as ever.
| adontz wrote:
| Do Google, Bing, Yahoo, Yandex count as other sites?
| Silhouette wrote:
| I don't know what you see when you visit Google, but I get
| one of those pop-over hassle boxes with some buttons, and
| then having cleared that, a search bar with some buttons
| and a few links across the top and bottom of the page. None
| of those items has any underline visible unless you hover
| over them. None of them is blue or purple. None of them
| changes colour when the link has been visited.
| DangitBobby wrote:
| Sorry, that's not going to happen. People are people, not
| machines, and if you tell them all the discovery and excitement
| of UI design has already been had by past designers, and that
| all future work should be purely derivitive, you won't have
| that many people staying in UI design. You're going to have to
| learn to live with the fact that creative people don't want to
| paint by numbers. Same applies to every complaint about new
| generations of people reinventing any wheel that applies to
| their field.
| thaumasiotes wrote:
| > People are people, not machines, and if you tell them all
| the discovery and excitement of UI design has already been
| had by past designers, and that all future work should be
| purely derivitive, you won't have that many people staying in
| UI design.
|
| What's the problem? We want those people to get out of UI
| design because they're making things worse by trying to be in
| it.
| still_grokking wrote:
| You mean, you would just need to tell the people that they
| have to do their jobs proper, and the ones that don't like to
| would leave?
|
| This would be so great!
|
| Or to put it more clearly: There is not space for any
| "creativity" when doing the job proper means to follow the
| text-book by word. If those people don't want to "paint by
| numbers" they should try to make money with art. But there is
| no space for them in product design.
|
| Form follows function! Point.
| preommr wrote:
| > Want to know if menu parent is a hyperlink? Easy, it is, if
| underlined. Period. No confusion.
|
| 'Comment#1':: There's more to UI design than disambiguity
| through explicitness.
|
| 'Comment#3':: Follows 'Comment#1' : Sometimes it's about things
| like simplicity
|
| `Comment#2`:: Follows `Comment#3' : Other times, it's about
| things like removing redundancy, e.g. knowing a navigation menu
| is a special ui element and shouldn't be over-complicated with
| underlines, and changing colors. A navigation menu is not a
| text body which is usually against a simple backdrop like
| white, and is far more standardized. It also has do things like
| show child elements, which is what the whole article is about.
|
| `Comment#5`:: Follows `Comment#2' : It's also about
| establishing brand identity that has a direct impact on market
| performance - like having custom color themes
| neogodless wrote:
| > Web is web and not desktop.
|
| Have you ever watched users try to interact with the web, their
| phone, and their desktop?
|
| Many do not differentiate, and why should they have to? They
| all should be built using intuitive, unambiguous paradigms.
| AndrewOMartin wrote:
| Every time I see someone double click a link.
| Kye wrote:
| I convince people not to do this by making it potentially
| cost them: get out of the habit or end up double charged
| some day. Not true for the majority of ecommerce sites that
| handle doubled requests sensibly, but there's one poorly
| coded site out there just waiting to blow their bank
| account out.
| jeswin wrote:
| > All texts in the examples are hyperlinks, but none are
| underlined and that is confusing in the first place.
|
| One reason is that underlines are quite distracting when you
| have so many of them. Even Wikipedia avoids underlines for
| better readability.
| layer8 wrote:
| Color or other styling can replace underlining. But it should
| always be made visually unambiguous what is a
| hyperlink/button and what isn't.
| jeswin wrote:
| That's true for some sites, and that's what Wikipedia does.
| But in apps, I don't mind if some discoverabilty (such as
| for non-essential links) is sacrificed - people will
| eventually learn if the app matters to them.
|
| Take the case of HN. The "15 minutes ago" and the username
| are both clickable for a topic. But not underlining or
| differentiating them makes the text more readable. Most of
| these things are opinions of course.
| masswerk wrote:
| However, in the click-configuration top menu items are buttons.
| Which are legitimate control elements, as well. The author also
| makes this distinction (a link navigates, a button controls)
| quite clear. As for menus, these have been around for longer
| than the web itself. (In the beginning, these were just an
| alternative way to display an array of related buttons, compare
| the Xerox Star.)
|
| Regarding the ellipsis, while it's true and recommended for
| menu items, this is not applicable to menu bars (or similar
| horizontally stacked items, like a bar of tab-options - mind
| that these are in principle just an array of buttons, as well).
| Daho0n wrote:
| >Web is web and not desktop.
|
| Says who? If a standard had to be forced I'd vote for desktop
| on web over your kind of web any day.
| caseyross wrote:
| IMO there's an even better design, which is to not hide links in
| an expandable menu at all.
|
| Just show all the links at once! With appropriate headers and
| visual hierarchy to provide organization, this is better in
| pretty much every way: faster to use, easier to implement, and
| more accessible.
|
| The biggest practical objection I see to this kind of "flat" menu
| is simply that it's hard to make it look good at the top of a
| page. But any competent visual designer should be able to manage
| that, aesthetically.
| RHSeeger wrote:
| Doesn't this make it take up a bunch of real estate in the
| header? Or am I misunderstanding you?
| [deleted]
| input_sh wrote:
| Let's say you sell a handful of products in a few categories.
| I'd rather click on the category and then the product, as
| opposed to the product being directly accessible behind a
| dropdown of a category.
| newmnhn wrote:
| I'm not fond of big nested menus in general either, but
| they are good for quick exploration and can be pretty
| forgiving of poor categorization.
|
| I do wonder if sometimes the nested nav is too in-between.
| Maybe the solution is not to try to squeeze it all into
| that structure but make "finding the page I want" to be a
| more top-level experience. EG don't take me to a Category
| Page, but do let me select a category and start drilling
| down, whilst keeping it easy to switch between top level
| categories.
|
| Big nested navs are often just ... fiddly.
| marcosdumay wrote:
| As a related point, stop trying to shove the entire site
| navigation into a minimal top menu.
|
| Your site is probably just leaving more than half of the screen
| of desktop users blank, and phone users can gain a lot from a
| top menu that actually does what it says and an expanded menu
| that takes the entire screen and lets them see what they are
| doing.
|
| People keep reevaluating how they implement the top menu, keep
| finding their implementation harmful, and yet do not stop to
| question the menu itself... No, it must be the implementation
| details, it can't be that the menu is a bad idea!
| open-source-ux wrote:
| _"...not hide links in an expandable menu at all "_
|
| On desktop screens, I agree, but how could this work on mobile?
| On a mobile viewport, presumably the navigation links collapse
| ino a menu. The only other mobile option I can see is to place
| all site links in the footer which feels clunky.
| chrisweekly wrote:
| The footer is a great place to put all the things people
| usually try to cram into the header.
| shakna wrote:
| Right up until someone else demands that infinite scrolling
| is implemented to fulfill some metric, and then you can
| never access the footer again.
| Y_Y wrote:
| What about defining "viral engagement trendability" as
| 1/(page length)?
| overgard wrote:
| Great thing about this too is its very ctrl+f friendly.
| leephillips wrote:
| Strongly agree. I dislike these menus as a reader, and never
| use them when I design web sites.
| Blikkentrekker wrote:
| I noticed too that there is a strange design drive of
| "submenu's for it's own sake" when the options fit perfectly
| well into one.
|
| The other that annoys me is "icons for it's own sake" when text
| suffices; I do not like having to figure out the meaning of
| arcane icons.
| GordonS wrote:
| Can you point to some examples where you think it's being done
| well?
|
| In principle I agree that multi-level menus are awkward on the
| web, but showing all the links at once is something I think I
| only really see in a tiny font at the _bottom_ of the page,
| which is in addition to a menu at the top.
| UweSchmidt wrote:
| https://www.mcmaster.com/
|
| This is how I want websites to look :)
| andrepd wrote:
| Also a delight that I click on uBlock origin and there is
| only one domain being contacted :) very rare nowadays from
| the web that a site doesn't want to pull and include shit
| from 30 different websites.
| Noumenon72 wrote:
| Very minimalist menu design, until the menu component
| finally popped in about five seconds after I loaded the
| page.
| Daho0n wrote:
| That is hideously bad design on mobile. Not only do you
| have to zoom in and move around while zoomed in to find
| items it also breaks down so the right part moves more than
| the left. Yes it is good on desktop but on mobile I'd click
| on to a competitor ASAP.
| GordonS wrote:
| As others have pointed out, this is not pleasant on mobile
| (at least in Brave on Android).
|
| But I'm also not a fan on desktop - it's just so _busy_ it
| almost makes my head hurt!
| ysavir wrote:
| Doesn't look too great on a mobile view. Do you have an
| example that handles that scenario elegantly?
| 0xCMP wrote:
| How does it not look great on mobile? It simplifies the
| number of options and simplifies the navigation
| accounting for the fact that mobile devices would require
| lots of scrolling on a tiny screen to see as much as you
| could on the desktop. On the desktop it uses all the
| screen space to show you more detailed sections you can
| click right to if you know what you already want.
| ysavir wrote:
| My apologies. I forgot to whitelist the site for JS, and
| when I viewed it, almost the entirety of the page was
| taken up by the categories sidebar[0].
|
| With JS it looks much, much better, and navigation is
| definitely usable. Though at this point it's raises the
| question of what is navigation: are all those item
| categories navigational aids, on par with other nav
| items? Or are they a product index and separate from
| navigation items? In regards to the GP's suggestion of
| "showing all links at once", I think it's fair to say
| that links that only go on some pages but not others
| don't count towards the "overpopulated navbar", which is
| usually intended to hold navigation aids that are
| available on all pages.
|
| So while I think the site in question does a good job of
| navigation, I think it does so not by choosing a flat
| design with all links available in the nav, but by
| cleanly keeping the navigation to just a few key elements
| ("Contact Us", "Order", "Activity", "Log in") and
| deferring all other links to separate UI elements that
| exist only on the relevant pages.
|
| [0]https://i.imgur.com/Plg3JSl.png
| Y_Y wrote:
| For one, there's a huge shitty thing that pops over half
| the screen straight away which ublock didn't catch.
| at_a_remove wrote:
| This sounds great when you are also in control over the number
| of links on the homepage. This is often not the case. When Big
| Players demand links (and even _redundant links_ ), well,
| you're gonna end up with more than you wanted.
| c22 wrote:
| I note that the first "hover menu with tab navigation" worked
| fine on my phone with javascript turned off and behaved exactly
| as expected with a click on the root opening the menu. None of
| the other examples worked at all or were even displayed?
| blunte wrote:
| I very much agree. Simple, consistent, even boring is much less
| friction or cognitive load for the user.
|
| We have passed the "look what cool effect I can do in a browser".
| Hopefully soon we will also pass through the control-your-car-
| entirely-via-proprietary-touchscreen phase, as it is a dangerous
| user hostile system. (Edit: yes, small tangent; apologies)
|
| Boring is good if your thing had real content, utility, value.
| Fancy and sparkly is what you do for a one-off show or when your
| thing has no real substance.
| clord wrote:
| I didn't test this but won't the focus-within trick work for
| click menus too? The user clicks the button (which must be a
| child of the container) so focus moves within the container and
| hence the submenu can show.
|
| nav:focus-within > .submenu {display:block}
|
| (Edit: oh it's mentioned in the article briefly without much
| explication of the need for js)
| layer8 wrote:
| It's okay for _sub_ menus to expand on hover, because the user
| is already mentally in a menu context if they clicked to open
| the top-level menu. That is common desktop behavior too.
| However, it's preferable for the submenu to stay open until
| some other menu navigation takes place (e.g. a sibling submenu
| opens), because it's much too easy to accidentally leave the
| submenu area with the pointer.
| datavirtue wrote:
| As a user I despise hover menus. They are always a point of
| distraction. "Oh, it's a hover menu. Now let me try to figure out
| how to hover through this nested nightmare."
|
| Desktop, web, wherever.
| etxm wrote:
| I thought I was the only one. They boil my piss.
|
| I'm not sure which is the more annoying aesthetic:
|
| - mousing across the screen and accidentally passing over an
| item that on-hovers a giant div in front of what you were
| trying to access
|
| - expecting a click to expand and click, but it hovers, and now
| you've clicked, so you're going to some random page you didn't
| intend to
|
| Ok, I can go about my weekend now that this is off my chest.
|
| :)
| ectopod wrote:
| > _mousing across the screen and accidentally passing over an
| item that on-hovers a giant div in front of what you were
| trying to access_
|
| Like every link in Wikipedia. The preview feature is just
| awful.
| lutoma wrote:
| Personally I really like Wikipedia's preview feature. It
| makes it easy for me to decide if a link is worth
| following. The German language version does not have it,
| and whenever I use that one I quickly start to miss it.
| still_grokking wrote:
| Opinions may differ.
|
| I for my part love the Wikipedia preview hovers!
|
| I actually don't even understand what could be perceived
| bad about them. Are people really moving the mouse cursor
| randomly around the screen without having conscious control
| of their hand movements? (I understand that this could be
| true in case of some medical condition like Parkinson's
| disease but not a general issue at all). Don't want to
| sound offensive; honest question.
| Riseed wrote:
| When navigating, I of course pay close attention to where
| my cursor is. When I scroll to read through lots of text,
| I'm not moving the mouse cursor randomly around the
| screen, but I'm also not paying attention to where it is
| because scrolling up/down behaves the same regardless of
| where the cursor happens to be. On a site like Wikipedia,
| this means that my cursor can happen to trigger a preview
| hover that covers the very text I'm trying to read. Even
| if it's in a different spot, the movement is enough to be
| annoyingly distracting and often means I lose my place.
| andrepd wrote:
| I love that feature. If you don't, it's literally 2 clicks
| to disable. Come on.
| Pxtl wrote:
| Especially when the tree is deep and you have to trace a narrow
| path to your option. It's like the Polus Maze task.
| etxm wrote:
| God forbid your cursor leaves the third hover menu and it all
| vanishes before your eyes.
| Chris_Newton wrote:
| If you really must have hover-based nested menus in a web
| app, you can at least use the transition controls so a
| momentary loss of hover doesn't immediately hide the whole
| menu again. Sadly, this technique doesn't seem to be widely
| known and a lot of sites aren't using it, which increases
| unnecessary frustration for users. :-(
| thaumasiotes wrote:
| I don't really like hover menus, but I don't find them to be
| the worst thing about "modern" "design". That would be topbars
| that disappear when scrolling down and then reappear if you
| scroll up, thus preventing you from seeing the content you just
| scrolled up to look at.
| vidanay wrote:
| Hover _anything_ sucks IMO. I have noticed a trend lately where
| the hover delay seems to be drastically reduced. This means
| that as I move my mouse around a page, I am constantly
| bombarded with hover popups that come and go. Quite often,
| these are right next to a top level thing that I want to click,
| so I then have to wait for the popup to disappear before I can
| click on my target.
| ryandrake wrote:
| Another reason hover-anything is bad is because it is totally
| inaccessible. Observe a 90 year old with poor vision or
| someone with shaky hands trying to precisely position a mouse
| cursor over a UI element, while hover-popups are animating
| all over the place. It's a disaster. Do screen readers even
| work on hover elements? Need to stop designing the web as if
| all of your users are healthy 25 year olds.
| wwalexander wrote:
| The most frustrating part of using Visual Studio Code for
| me is the hover/scroll behavior for error/warning messages
| in the code. You have to hover to view the error, and
| usually the message is out of the hover pane viewport at
| the bottom, below the type/value documentation. This would
| be fine, except for the fact that once you have scrolled to
| the bottom of the hover pane, further scroll events are
| applied to the code itself, so the hover pane scrolls out
| of focus and disappear. I spend an inordinate amount of
| time scrolling one notch at a time hoping for a glimpse of
| an error message.
|
| I only have in-depth VS Code experience writing Go with
| gopls so maybe this is a very niche issue but it's so
| frustrating seeing so much wasted effort go into making and
| using and solving the weird inconsistencies of hover-based
| UI elements. The inevitable mess of hacky state management
| is an invented problem - the cursor should only affect
| state when buttons are pressed. I miss Plan 9.
| eplanit wrote:
| The web interface to Amazon Prime videos is basically
| unusable because of the many hover behaviors they've added.
| leephillips wrote:
| Hover states also make the Netflix website annoying.
| jagger27 wrote:
| Right! When I'm just scrolling through the list I don't
| need an autoplay kicking off just because I happened to
| rest my mouse there.
| leephillips wrote:
| Netflix is one of those sites where I find it hard to
| imagine that its designers ever tried to use it. It's
| maddening.
| suzzer99 wrote:
| Utterly egregious example right here:
| https://www.thesaurus.com/browse/hover?s=ts
|
| I'm always accidentally triggering the gigantic hover menu.
| So annoying.
| datavirtue wrote:
| I feel like they reduced the delay in an attempt to increase
| usability. It's tough to slough through all the gatekeepers
| to get rid of something like the menu styling in a web app.
| You might get buy in across the team and then a key
| stakeholder goes on a diatribe of why they think we should
| keep it and then everyone else runs out of energy trying to
| counter every one of the rationales. The people fighting for
| change get tired and pick another battle.
| blondin wrote:
| since we are on the topic of hovering, i have come to notice a
| negative consequence for ignoring it altogether.
|
| in a few modern applications i have been using that the
| iconography is foreign to me. my first instinct is to hover those
| icons to see a help text or tooltip. most often, these modern
| apps also take away the tooltips because mobile devices don't
| have them anyway.
|
| this is a loss in accessibility imo.
| ytjohn wrote:
| I'm not a UX guy myself, but our team has a rule to use some
| form of indicator like the "i in a circle" or ? in a circle.
| These are always clickable, so if you see an "i" you can click
| it to get the pop-up. We do avoid hovers, though our reasoning
| is that we're making information dense applications. Having a
| bunch of hover tips pop up as you're trying to navigate a table
| can get frustrating. If hover is used, it'll most likely be a
| different indicator and in the header or footer area.
| jfengel wrote:
| Mobile consistency is the big win here. A lot of users lack the
| ability to hover. That means the mobile language works it's way
| back to desktop. Either you maintain (and test) two different
| interactions, or you give in and appeal to the broadest audience
| with least work.
___________________________________________________________________
(page generated 2021-03-20 23:01 UTC)