Dropdown navigation menus - should top menu option link to content?

Question

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.

Questions:

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?

screenshot:

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

Answer 1

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.)

Background
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:

Answer 2

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.

Answer 3

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.

Answer 4

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)

Answer 5

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).