I had a reader write in with an interesting question:
When one has multi-level navigation, do you think it crucial to have an actual page for the top-level item? For instance, About > Company, Founder, History.
There isn’t really anything worth putting on the About page that wouldn’t be on the three sub-pages. In the nav, should About just redirect to Company? Should there not be a Company page and its content be moved to About?
Any best practices you’ve found over the years?
I’m picturing this kind of thing:
And the issue is that “About” by itself isn’t particularly useful. But it is useful as a grouping for the sub pages.
I would think the “About” link should be functional no matter what. It’s just a matter of what to do with it.
Just make an intermediary page
Have the parent link:
http://website.com/about/And the subpages:
http://website.com/about/company/
http://website.com/about/founder/
http://website.com/about/history/They said there isn’t anything “worth” putting on the About page, but that’s just a matter of content wrangling. You could write some new content introducing the other content there. Or show some elaborate breadcrumbs encouraging them to go deeper. Or show some images or snippets from the sub pages. I’m sure you can think of something.
Redirect the intermediary page
Have:
http://website.com/about/Redirect to:
http://website.com/about/company/That way the URL stays nice and hierarchical and gives you the opportunity to create an About page alone in the future.
It might feel a little unexpected though, so it might be nice to offer some kind of sideways navigation. Seems like the kind of thing that could be tabbed:
Skip the hierarchy
If there is really no point to having a parent page, maybe the URL’s should be clear that there isn’t one.
http://website.com/about-company/
http://website.com/about-founder/
http://website.com/about-history/And then use the redirect for the top-level navigation option.
Put them all on one page
Is there any value in separating them? You could go with a tabs design pattern with all on-page content. Or just make a long page, the web can handle it =).
The URL’s could use hashes to go to the relevant place (or tab):
http://website.com/about/#company
http://website.com/about/#founder
http://website.com/about/#historyBest Practices
I’m not sure any one of these is any better than the other. I think the best practices here come in the form of don’ts:
- Don’t do it one way then change it to another next month. Cool URL’s don’t change.
- Don’t make your dropdown 100% reliant on JavaScript.
- Don’t make the About link not-actually-a-link just because you don’t have this figure out yet. Link it to something or redirect it.
Have you all gone through this kind of thing before?
Good advice. And thanks for the many resources you’ve built up on this site!
That’s really all there is to say about it. Pick one of the first three and use it consistently throughout the site. The fourth suggestion, tabs, may work on some pages but will not work on all of them so it is a page organization option not a top level navigation option.
We designed entirely separate pages on the website I work on, and each page has links to the sub pages that are in the navigation.
It works, but in useability testing we noticed that a lot of people don’t realize that those pages exist. They hover, see the sub nav, and click on one of those pages instead. That works alright for us because they aren’t essential pages, but my advice is to be cautious “hiding” pages in this way. It’s not a bad technique, but it can be risky.
Another, slightly related issue is when you have a submenu opening on hover in desktop browsers. Since you can’t hover on a touch device, you probably will have to open the submenu when tapping on the menu and prevent navigating the top level page menu. This means that the top level is unreachable on some devices.
We found that some people click on everything, and get frustrated if the top level doesn’t do anything — particularly if there are no submenus on some items so some top level menu items are clickable. So we do create intermediate navigation pages for several of the reasons described in this article, but also make sure that no necessary information is in these optional pages.
I’m dealing with the top level link/drop down menu issue literally right now. I’ve decided to move away from hover activated drop downs because of the touch issues, but the top level item being a link gets in the way of click to reveal drop downs.
The site I’m working on is in Drupal, which makes customizing markup exceptionally painful, especially when dealing with menus. You can’t even have a menu link that doesn’t start with
http://without installing a stupid module or some other hassle, so a link that just activates the drop down and doesn’t go anywhere is not always an easy option.A solution that I’m trying is having the menu link and the drop down toggle as separate items, so you can click the link and go somewhere, or click the little triangle next to it to toggle the drop down. I’m still not sure about the usability of it, though. I can tell I’ll have the be really mindful with the design so that it’s super clear what does what.
There’s also the issue that CSS does hover but can’t handle clicks, so unless I want to get hacky with radio buttons or something my thing will depend on some JavaScript. Not the end of the world, but something to keep in mind. If my script doesn’t load for whatever reason, then what?
Just letting you know Chris, the images from this post are’t showing up. I’m getting a 502 Bad Gateway message from cdn.css-tricks.com. Just thought I’d give you a heads up!
I agree with Robert. Unless you can guarantee that the number of tabs on every page are not going to proliferate, or that a long ridiculous name won’t be imposed on you by a stakeholder, tabs are risky.
My personal opinion is if you can’t think of anything to put on a landing page then you need to rethink your hierarchy. In this case I see no reason the About page can’t be merged with the Company page.
Of course the designers of some well-known frameworks have set up their navigation in such a way that the default is no landing pages at all and the top level link just opens a menu. Both Foundation 4 and Bootstrap 2 required some hacking to get the top level link to go to an actual page in all devices. Don’t know if the latest versions have addressed that issue.
Along the lines of what Reidar said, hover menus are a mistake (even on desktop).
I tried having the menu show on click instead of hover in a usability test with users, and it worked beautifully. Since then, I’ve only used click events to show sub menus.
Yes, you have to use some javascript, but only very little. It has the added benefit of working just as well across devices.
Hi, Nick. That’s an intriguing and bold assertion, that hover menus are a mistake on desktop too. What sort of usability problems have you found with them? (Or are the problems all technical?) I’m struggling with this issue right now, trying to plan for mobile breakpoints on a couple sites. I’ve toyed with the idea of click-to-dropdown on touch and non-touch, just to reduce the maintenance burden of having two different behaviours to manage and debug.
So what sort of behaviour have you created? Click once on the top-level to drop down, click a second time to navigate to the top-level page? Or click a second time to hide? Have you considered an accordion-style affordance — some sort of disclosure triangle? I’m curious about whether you’ve tested this with users too, and what you found out.
Here’s my most recent example: http://www.cynthiaeden.com (See the action on the Books and Series navigation links.)
I’ve used hover submenus in the past. They work, but they do create unintended actions. People will hover over them when they don’t mean to or hover off when they meant to stay on. If there is more than one layer to the menu, the problem gets worse. Click menus just work better. If you observe users using the two in a usability interview, it becomes real obvious.
In the above example, my only complaint is that I prefer to designate drop down navigation items with an icon of some sort, and there, I did not. Note that the menu changes on smaller mobile devices.
@Nick –
So what happens if you need a second level landing page?
Do you just have mega-dropdowns that skip to a third level?
No dropdown at all?
Or some kind of “Overview” option in the menu that takes you to the page?
I’m currently working on a really large site, and I don’t think doing away with 2nd level pages is an option.
I tried replying once, but it looks like it got caught somewhere.
Paul: Hover menus aren’t that bad. I’ve used them, but click menus are easier and more usable. Also, they address most of these problems. The problem that hover menus have are a) accidentally triggering them when just moving across the page and b) accidentally making them going away when just looking through them. Click menus work better. I have a real good example of what I’m talking about. I’ll post in a second.
Riobrewster: I try to only have one level of submenu. I think a second level could work but always avoid it. If I need an overview page, I include it in the submenu. For instance, in the example I’ll provide (following comment) I have a Books menu item and include All Books in the submenu under it.
To answer my own question (re: how do you get to the first-level nav item’s page if you have to click on the item to expand the dropdown) this seems to be a good pattern, and apparently well-established:
http://uxmovement.com/navigation/why-hover-menus-do-users-more-harm-than-good/
Near the bottom of the page, it gives examples of a ‘All’ or ‘More…’ link in the menu itself, so:
etc…
In my experience having the landing pages help the SEO slightly, so for that reason we tend to stick with them and include a further navigation to the child pages within this landing page, this also gives users another way of getting to the target content
An almost identical issue/decision often comes up when a site displays a ‘Categories’ drop-down menu item in the main nav, like my own (or WebDesignerDepot or any number of well-known sites for that matter)… in this case I always prefer for the menu item to NOT link to anything (best of all to not even suggest that it will link to anything as you hover over it); the reason being that a new page would, in my view at least, be a meaningless? distraction… but hey, each to their own! ;)
Having a top level page, then sub pages can be used to your advantage when it comes to siloing those pages.
Lets say you have an about page at
company.com/about/
you could have some basic info on that page, broken up under different headings. Under each heading you could have an excerpt and a link to the page with the main content. ie:
company.com/about/who-we-are/
company.com/about/what-we-do/
and so on.
On each of the pages you would have a list of links to the other pages, including a link the top/main about page.
What you are effectively doing is creating a silo of pages (google SEO Silo for more info) which can be quite good for SEO and help more pages of relevant info rank in SERP’s.
With all that in mind, when it comes to the menu, it would probably be best to be able to click on the parent menu in a dropdown (for better user experience across devices) (js can be used if you want to click to view sub-menu, then click again to go to url from menu parent).
I prefer to first conception domain.com/about/company/.
Google will this rewards.
Actually Google would prefer domain.com/about/company.html
I don’t necessarily agree with this approach (and it isn’t always practical is the taxonomy node in question contains so much content it warrants actual subsections) but their guidelines recommend this practice.
What about this for usability: Keep the dropdown menu – and the about page as a standalone page with an optional small intro text; with links to it’s subpages. You still get to spread the content over several pages; but for people who clicked the main menu item you still offer them to navigatie further down the hierarchy.
Sure; it adds a page with little content; but for accessibility it solves both problems in my opinion :)
I was thinking the same thing; you could have the “About” page as a landing page with a brief paragraph, possibly from the Company page since a lot of “About” pages tend to go over company history. You could then have links or asset links going to the other pages. I’d imagine this would be mostly used for people using touch-based interfaces or keyboard interfaces, and as it’s not redirecting to somewhere else it keeps the user from thinking “But I clicked on About, why am I on About/Company?”.
If a plus, arrow, or hamburger icon is situated aside the text then it must be clicked to open the menu and an About page is not needed. Otherwise, the About link should be functional and hovers are welcome.
I always make it a page for a couple of reasons.
For SEO.
I’ve never had a situation where every menu item had a drop, so having some that are pages and some that aren’t (because they have a drop) breaks the pattern and is poor usability.
It makes the mobile nav easier to develop AND easier for the users. You can drop the secondary pages from the nav on mobile, no more click the hamburger icon, click the menu item and then click the page. I’m not a fan of making users do multiple clicks just to get to a page. I then put the secondary nav in a “widget” below the page content. On the desktop, that usually is part of a widget in the sidebar.
Generally my ‘go-to’ with this is no, it is not worth having a top-level functional link. Like with anything though, there are certain scenarios where deviation becomes worth it.
One of the internal projects I work on is a management system that our clients can access to review their order status. One top level link is ‘Reports’ which allows them to select a variety of metrics by which they can review their order history.
THAT top level link actually does something though. It goes to an overview page full of charts of the various metrics so they can get an ‘larger picture’ of their order history. The reports links then just let them dive in and get into the nitty-gritty of each measurement.
I think this is good advise for hover drop-downs, but I think it is unnecessary for on-click dropdowns because the top level item already has a function (to expand its own content).
I try to follow a few what should be simple assumptions
1. All items in a menu are clickable
2. All menu items in a menu are unique (no duplicates)
3. All pages have real content
If a site is deep enough to have submenus, then I would think those intermediate pages (I think of them as secondary pages or landing pages) should have content that gives an overview of that section. That may include links to the submenu pages, but if it’s just that I get frustrated as a user since it’s a “waste of click.”
Over the past year, I’ve received more and more complaints from clients that their users didn’t know to click the top item which often contained unique and valuable content (see #3 above). Therefore, as some others in this thread have, I’ve switched to click-triggered submenu. Luckily, I was using the amazing superfish script and so it was a breeze to switch to superclick. This unfortunately does mean that I’m fairly JS reliant, but I can live with that.
And of course, when possible, I’m pushing more people to just ditch submenus altogether unless there’s a compelling reason. There often is, but we shouldn’t overlook the possibility.
I wrote about this all in more detail on my blog recently, so I’m glad to see Chris take it up here.
To answer the reader’s question: What I have done in the past is to put a link called “Overview” that takes the user to the top level page, in this case, About. The reason I’ve done this is because I’ve implemented the dropdown menus to be visible on click rather than on hover (for usability reasons which I’m going to mention next), thus clicking on ‘About’ would trigger the dropdown but not the link.
Now, the reader’s question has a(couple) “hidden”, much deeper problem(s) than deciding to create a page for the top-level item or not: Should he/she be using a dropdown at all? And if so, should he use hover or click to trigger the dropdowns?
Is it really necessary to use dropdowns as part of the menu?
It’s been many, many years since I’ve implemented a main navigation bar with dropdowns (I did implement a navbar with megamenus though and small utility nav a few years ago [ * ]), let alone triggered on hover. An added value as a Web Designer one can suggest is placing the secondary/tertiary navigation(s) menu(s) within the inner pages, always visible. HUGE benefits in many areas by doing this:
Spend less time in implementation
Less scripts to manage
One less HTTP request helps with page/site performance, which in turn:
Better user experience
Better for SEO
If done correctly, secondary/tertiary navigation(s) menu(s) can be much more scalable
And should he/she use hover or click to trigger the submenus?
Many here have already mentioned here their preferences and reasons to trigger dropdown menus on click instead of on hover. +1 to them.
Also, this topic has been discussed for decades here, here, here, here, here, here, here, here, here aaaaand here. And practically everyone agrees that the optimal way to implement dropdown menus is to trigger them on click.
[ * ] When I implemented the megamenus I mentioned above, the agency that provided the designs (it was BBDO by the way, yes THAT agency) suggested to use hover to trigger the megamenus. Since it was my responsibility to do the front end and knew better, I implemented the megamenus on click.
But I went several steps further.
The megamenus are not only triggered on click but:
There can only be one megamenu or dropdown (from the utility navbar) open at a time.
Clicking on any other nav item will collapse any open megamenu/utility dropdown.
Clicking on a nav item will open/collapse its corresponding megamenu/utility dropdown.
Clicking inside the megamenus/utility dropdowns will NOT collapse them. The visible megamenu/utility dropdown will remain open until the next page starts loading.
Clicking OUTSIDE the megamenu/utility dropdown will collapse any open megamenu/utility dropdown.
You can see the site here: http://www.lexisnexis.com/en-us/home.page
And I also created a CodePen demo here where you can see the simplified version of what I did for those megamenus and utility navbar: Nav bar megamenus (on .click or .hover)
These are some good, thorough thoughts on the matter. I like the UX for the mega-menu on your example site; it works well. One thing I was confused about was this comment about single-level menus with subnavigation in the target page:
Which HTTP request are you referring to? The call to the JS that controls the menu? I’d argue that that benefit is offset by the need to click, then wait, then click and wait again.
Thanks a lot Paul :)
You’re right, I should’ve maybe said “Less HTTP requests” in case more than one file (JS and/or CSS) are being used for the dropdowns.
Yes, I was referring to the JS file that would control the dropdown mechanism.
When you say “waiting” in both instances, I think it’s good to understand that the reason users click on menus is not with the main purpose to look for the secondary level menus necessarily, but because they are trying to find the content they came to look for in the first place. Is content that drives the click.
So the case of “waiting” can be arbitrary to some degree.
If you think about it with hover dropdowns users also have to wait for things: Hover and wait (albeit less) for the dropdown to appear. Hover again over the link they want, if that item has another flyout menu, then wait for that one too. See? “Waiting” is pretty much unavoidable. Yet, it’s not detrimental in any of both experiences if you ask me.
Now, in the example I just mentioned, let’s not even get into what happens when the user after “waiting” for the dropdown to appear, accidentally moves his mouse away.
That’s actually a very good point. I guess I’m seeing it from the perspective of one who already knows the nav structure, rather than someone who’s just looking around. That said, I think there are cases when it’s valuable to show the sub-levels sooner rather than later, if you can think of a good way to do it. Vertical menus lend themselves well to showing two levels of hierarchy as long as there’s not too many items.
The thing is: how many are too many?
I would think that if someone already knows the navigation style of a website and came back looking for something they’ve seen before, their mental model about the type of navigation is set. So either menus on hover or click, at that point it may not really matter since they could be ready to “accept” whatever navigation the site has.
Which is fine and that point the content is the driver of the whole experience: As long as they find the content they need/want, who effin’ cares about the navigation style :p
In turn, this leads me then to say: It’s the content itself that defines your navigation style, not the will of the web designer/developer, which is often the case.
The ‘about’ link can be a link to the top of the ‘about’ page. Each submenu item can then link to a specific subsection (# fragment) within that page.
Keeps it all together and gives the user a choice in terms of specificity.
Innit.
From my experience, I’ve found as soon as dropdown menus have child items, users don’t click the parent.
It’s surprises me how often I had clients complain a certain page was missing from the menu when in fact it was the parent item with child items. :) Example: A client wanted the Privacy, and Terms pages listed on the About menu. I already had an About page.
I’m loathe to disable the parent link as it creates an inconsistency with other menu items that don’t have children. So, I simply duplicated the About page as a child item. Client happy – and truthfully, none the wiser!
I guess I learned sometimes you’ve got to follow user behaviour rather than try to form it.
Not this blasted issue! :)
My thoughts…
Making the top link a landing page is nice in theory, but sometimes the extra content is just too much and dilutes the story you are trying to share. Less is more, right?
I tend to have the top link display its submenu on hover and link to its first child when clicked. If you redirect to the first child, it is important to have a clear way finding system set up on the next page. Either secondary navigation or breadcrumbs so the user knows where they are in the experience.
I’m loving the discussion on the hover versus click. I prefer hover, but clicking definitely makes sense too. I’d like to see a usability study on it. Thanks for sharing.
That solves the problem for people who don’t know to click the top item but “punishes” those who [I think rightly] expect the top item to be a unique page if using a hover-triggered submenu. That’s a hyperbolic way to put it, but I have definitely experienced frustration in that situation. If the top and first items have identical link text, then you could argue that’s the expected behavior, but all the site owners I know don’t like that because it’s redundant.
You are right. It is definitely not a perfect solution. You do a great job at pointing out the pros and cons in your blog post. It really comes down to the content you have in front of you.