In Praise of the Unambiguous Click Menu
css-tricks.com
css-tricks.com
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.
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!
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.
This is how I want websites to look :)
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.
I need a tube fitting in stainless steel? Here’s a MASSIVE list of all of them for every single size imagine that’s easily Ctrl+F’d. Click on the item, enter a qty, add to cart, keep going.
When you have about 200 line items to fill each morning across multiple POs, racing the clock to secure that same-day delivery, modern UI design paradigms are a massive waste of time.
McMaster-Carr is designed with purchasing teams in mind, and the people who work in such teams are (by training or experience) oriented towards certain optimizations that to the casual user may seem overwhelming to parse or ugly.
The day McMaster goes “modern UX” is the day I lose hope.
Edit: forgot to add that in many cases, purchasing on McMaster is done via CSV imports on their order page. Literally do not have to interact with the catalog if I want to. Which is also a godsend.
But I'm also not a fan on desktop - it's just so busy it almost makes my head hurt!
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.
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.
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.
Basically a slide-left menu system.
Desktop, web, wherever.
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.
That it's the default behaviour is still mind boggling.
I'm always accidentally triggering the gigantic hover menu. So annoying.
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.
:)
Like every link in Wikipedia. The preview feature is just awful.
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.
This is close to my biggest pet peeve on the internet. Fortunately, the "kill sticky" bookmarklet[0] gets rid of those as well as other fixed elements on the page. Works on iOS too.
[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.
IIRC, there was a time window when you could do hover menus with pure CSS, and this might have been part of the draw.
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.
Jira does this in several places, but not everywhere.
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.
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.
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.
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)
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…
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.
One reason is that underlines are quite distracting when you have so many of them. Even Wikipedia avoids underlines for better readability.
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.
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.
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.
Says who? If a standard had to be forced I'd vote for desktop on web over your kind of web any day.
'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
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).
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.
It might have been 20 or 30 years ago, but not any more, and Jakob's Law is as relevant as ever.
And obviously those aren't being used as menus or controls in the web app sense anyway.
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.
It's a semantic html nightmare but it works.
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/
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.
nav:focus-within > .submenu {display:block}
(Edit: oh it’s mentioned in the article briefly without much explication of the need for js)
I could open hover menus on mobile from 2012-2018 when not all sites were adjusted to mobile yet.
It was glorious.