I have a client with a group of users which seem to have constant troubles using a menu like these two examples:

  • Pages (links to a list of pages in a grid from where the user has access to edit/remove page functionality)

  • Create new page (links to new page form)*

  • Page categories (links to a list of page categories)*

  • Create new page category (links to new page category form)*

When you hover over Pages the dropdown appears (think of Superfish dropdown). User can either click on the hovered Pages link to go to the list of pages or select any one of the other three options in dropdown (marked with *).

It seems my users (a proportional amount of them, at least 50%) have a problem clicking on/understanding how to get to the list of pages. They end up looking for a "Page List" menu option in the dropdown. It has been explained and written numerous times that just clicking on the Pages top option will get them to list (the cursor does change so that's not the issue).

A similar example would be where hovering the top item brings out the dropdown or mega menu but also allows direct click which takes you to a "landing subpage" - think of it as an aggregate in-between page.

I am now almost certain that this design is flawed.


  1. Your opinion, do you get it?
  2. Should I remove the link on top item and introduce the "Page list" option into dropdown?
  3. Should I leave the link on top item and in addition to that introduce the "Page list" option for users who simply don't get it?


enter image description here

Unfortunately my screen capture tool does not capture the cursor - so please note, the News and Posts option is clickable and goes to the list of posts and the cursor changes to hand

  • I think a screen shot of what is going on would help. Personally I am not getting the difference between the "Pages" and "Page categories" and the "Create new page" and "Create new page category".
    – PL3X
    Commented Jun 12, 2012 at 14:50
  • I see a correlation within your question: Menus that open on hover (and hover that opens horizontally as well as vertically) and users that can't find the pages. Simple suggestion: Get rid of hovering to activate menus. users don't like hover menus
    – JonW
    Commented Jun 12, 2012 at 14:52
  • my users like hover menus and the menus are here to stay. This is another one of those religious anti-something movements because people didn't take enough time to get them right. That's why I am asking this question. IMHO hovered dropdowns are one of the most natural structures because people understand hierarchical structures easily. Also, they've served well for decades in DOS times.
    – mare
    Commented Jun 12, 2012 at 15:01
  • My point isn't about the menu structure themselves (although vertical pull-out menus are particularly bad from a usability point of view) my point was around them being activated via hover instead of click. Primarily because they are not accessible and are not usable on touch devices. (I'm not sure how you would have had hover menus in the DOS days anyway)
    – JonW
    Commented Jun 12, 2012 at 15:07
  • right..I understand you..touch doesn't have hover I know. But the point is my menu does work on click. Clicking on "News and Posts" takes the user to a list of this content. However, besides that hovering it does render the dropdown too. So it kinda has two functions - serves as a link and displays dropdown. Also please note that the pages in this app are touch enabled by providing links to the content that is also available via dropdowns.
    – mare
    Commented Jun 12, 2012 at 15:14

5 Answers 5


Simple Solution
Make the menu expand on click so it's mobile-friendly. Then add "All Posts" to the dropdown. That will make it clear and usable for everyone.


download bmml source – Wireframes created with Balsamiq Mockups

In this example, I also simplify your dropdown options; consider leaving out "Add Category" from this list, since it doesn't make sense to add a category until you've seen the list of existing categories. That should really only be an option on the index of categories. (Please ignore the down arrow, I couldn't figure out how to make an expanded menu dropdown, so used a combobox.)

When you say "it has been written down many times…" that is my clue that people aren't reading what you're writing. The rule in my old office (college administration) was that if you have a sign that nobody reads, don't put up another sign, take down the first one and redesign the system (so that you don't need a sign in the first place).

Mobile First
You'll really want to create a solution that works for mobile, because it will also work for desktop devices. So, make the menu "click to open."

Put Signposts Where People Look for Them
When you drive down an American street, you look for street signs at the corner. If people are looking for a particular item in a submenu, make sure it's there so they can find their way.

Wordpress Is a Good Example
I cribbed my mockup from Wordpress. Here's a screengrab:
Wordpress Example

  • +1 good examples on when the top item is a header and not a link to content.
    – JOG
    Commented Jun 14, 2012 at 8:40

Yes, the top menu option should link to content. Several reasons:

  1. The pattern, and user expectation, of navigation sets is that they link to content; how is the user to know that some links point to content and that others are just empty containers?

  2. Users read labels and follow them. Support that behavior by making sure all of your links go somewhere.

  3. Economic use of screen real estate. Typically nav sets are competing for space with lots of other top-of-page elements. Can you really afford to waste space with links that lead nowhere?

  4. Better accessibility -- screen readers and some search bots may have trouble with drop-down menus -- providing an index page at the top level of each category ensures that each piece of content will have a readable link pointing to it and it will quickly orient new users to the contents of each section.

  • +1 and it could be added that The top menu option should link to content IF it looks the same as the drop down items. If it has another design, then it's behaviour would be expected to be different.
    – JOG
    Commented Jun 14, 2012 at 8:38

I think the issue you are having is cuppled with verbiage. Users really dont read, they look for key terms that reflect that task they are trying to preform.

Based on your screen shot (as an example) you should chance the menu option names. Change "New" to "Create" for something like "New Post". Try something like "List categories" or "Manage categories" Action verbs will clear up a lot of there confusion.

Also your root level menus should only take users to a backing page that contains all of the menu options on it. This way menu options are better accessible to users with disabilities. Its a good "rule of thumb" for navigational designs.


Here's a few of my personal rules of thumb for hove/click based dropdowns:

  • For the hover based menu make the top level item clickable and when clicked send them to the detail/list the top level menu item (noun) refers to.
  • There are two keys to making the top level item clearly clickable: 1) language - if the menu item is titled "Pages" and is clearly clickable and it takes you to a list of pages then I would say you are good provided "Pages" makes good contextual sense to your users (e.g. is that what they refer to them as amongst themselves) and 2) style - mouse turns to pointer finger on hover and color/underline/something visually changes.
  • In general if you go the hover menu route, just as a side note, make sure the menu has a good level of onblur/onmouseout tolerance so that you don't run into issues with the menu closing unexpectedly.

  • For the click based menu make the entire top level item trigger the opening of the menu, not navigate to a page. Easy big click target and no possibilities for accidents to happen clicking on arrows vs. links.

  • The arrow is usually a good enough visual indicator that you can click this area, but a joined hover/active (meaning the link and arrow respond similarly when state changes) usually doesn't hurt.
  • Once opened "Pages" again should work.

One other aside, if you do add an additional "Pages" or "Page List" menu item is to better visually distinguish actions from simple categorical navigation items. Try using a simple menu hr divider or changing the visual styles (background color/font color) to make those items properly differentiate in a scannable way.

If the above isn't gaining any traction I would suspect that "Pages" is not the right noun. Or maybe more appropriately you might need to spend more time getting to know who you are building the site/tool for. Most popular tools/websites use simple nouns to describe top level navigation categories. I would not suspect the issue is verb related unless the item in question is an action.

Never under-estimate a few quickie usability tests with your various ideas to really see what works. (Steve Krug is a good starting place)


Firstly, you should certainly hook up a link to the top-level menu item so that users can access the sub-content if the menu JS doesn't load for some reason. Personally, though, I believe you should remove that link once your Javascript menus load (and by remove I mean more than just making the click event return false).

The issue with drop-down nav menus on the web is that they generally open on hover instead of click (as in traditional menus). That means the "click" action is unused for the top-level item, which allows developers to overload its purpose (i.e., it's both the menu's name and an action).

In my own usability testing I can say hover-menus are often a usability nightmare. Less-savvy participants tend to click when they need only hover and then move their mouse down to the sub-items in the menu (so if the top-level category is a click target, they generally perform an action they didn't expect).

If I had my way, web-based drop-down menus would behave more like traditional menus. That's how the menus on sites like Google work (where a hover effect highlights the top-level menu name and a click actually opens the menu). That also drastically improves the second major usability issue with hover-menus; they generally collapse when the cursor leaves the bounds of the menu. That's especially terrible for users when the menu has sub-menus that slide out horizontally (generally forcing the user to slide their cursor horizontally with only about 16px lee-way vertically to target the sub-menu without accidentally removing focus from the top-level category).

  • I like this answer. But slightly confused by the removing the link once the Javascript menu loads. Wouldn't that confuse people if it behaves differently at different points in time? Perhaps people just don't notice. Another down side would be that the link covers the website if it is brought up on a touchscreen. So maybe moving it is a bad idea. Commented Jun 13, 2012 at 9:25
  • I tend to set long enough waits (up to 2 seconds) for when users cursor goes out of a menu to deal with the menu disappearance problems which are trouble, I agree. However, the problem with my users is not in misclicking an item but rather in not clicking anything. They seem to hover, then wait, search and scan for an item that doesn't exist because it's already in there as a top level item which they just hovered but should have do one more step and that is click on it.
    – mare
    Commented Jun 13, 2012 at 9:45
  • @LisaTweedie: I hook my JS up on DomReady so it's almost certain that users won't see the non-JS behaviour with JS enabled. It's also worth noting that until the JS loads there are no drop-down menus either, so the behaviour is inherently different at different points in time. I'm not sure I understand your second point regarding touchscreens. Can you rephrase it for me?
    – Kit Grose
    Commented Jun 14, 2012 at 2:51
  • @mare: If you're using hover-driven menus then I'm glad to hear you're addressing the target acquisition issue I reported. I still think your best option is to move the top-level menu item into the menu itself (e.g. "News and Posts > Manage News and Posts" as opposed to requiring a click on the top-level menu item). I think you'd make that much more unequivocal if your menu only opened on-click though.
    – Kit Grose
    Commented Jun 14, 2012 at 2:54
  • 1
    @Kit Good point about the JS load time. My comment wasn't clear... in fact so unclear that I have no idea what I meant now either.. sorry! Commented Jun 14, 2012 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.