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.
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!
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.
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.
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.
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.
As someone whose job entails buying a lot and very frequently from McMaster-Carr, their website is a godsend.
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.
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.
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.
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.
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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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. :-(
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.
>That would be topbars that disappear when scrolling down and then reappear if you scroll up
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
> 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)
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.
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.
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.
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.
> 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.
> 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
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).
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.
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.
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.
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.
> 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.
An accessible (or at least a no-js) way to expose a menu on click would be to use a checkbox, the :checked state in CSS, and a label element for the actual click handler.
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.
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.
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.
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)
It’s okay for submenus 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.
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.
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.
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?
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.
The BlackBerry Classic from 2014 worked this way too. It had an optical trackpad that controlled the focus, except in the browser where it was an actual pointer.
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.
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.