After a heated and very public debate about how a menu should work, I figured I would take a moment to do a little research and write up on menus, with some thought and consideration to the environment within which they sit and are used. So without much ado, here it is :

Design and Function Considerations

When putting a menu together you might want to consider some of the following options:

• Look – Should the menu look like a button, a list item or something else?
• Direction – Whether the menu is horizontal, vertical or both.
• Screen size – Available screen/viewport real estate to show the menu within.
• Stickiness – Length of time the menu stays open after a click or a hover.
• Failover – How the menu works without JS and or CSS.
• Device – The device or software through which visitors will access your site.

For the purpose of this article I am going to focus on access your sites through a desktop browser and worry less about the needs and requirements of mobile devices, which could fill a whole other blog post.

So What The Big Boys Do?

Needless to say it makes sense to look at some of the largest sites on the web and figure out what they are doing with menus and what kind of functionality web users will be used to for us to replicate.  Sites we can look at with strong menu and navigation offerings include: BBC News, Flickr, GMail, John Lewis, Amazon, and for a side demonstration Windows XP.

Look

In terms of the look of the elements being used for drop menus, in most instances the hit area for the initial menu item is clearly delineated.  In no case are menus drawn from strings of text or links, and in every case where drop options are available this is indicated with rightward or downward pointing arrows.  Buttons are clearly buttons, with calls to action, whilst list items are obvious categories with highlights for further inspection.

Direction

Concerning the direction in which the navigation and drop menus open it is always downwards, though in certain cases the downward shift contains a horizontal list of columns to maximise use of space, as in the case of the Peter Jones web site.  That being said, it seems that there is no consistent or apparent rule for the layout of a menu.

Anything goes, so long as the menu as sure as you ensure that the user can navigate as quickly and as easily as possible through the menu, and interestingly a site like Apple’s uses a heavily stylised conveyor belt mechanism.  Ultimately, you has to ask yourself the question:  “Can the same navigation mechanism truly be achieved by better means?”

Screen Size

Menus always work “great” when you have enough screen real estate but what about when your user does not?  How do you handle what happens? In this scenario you also have to remember that not all visitors are created equal when it comes to pointer devices, with some using a track-pad, some a 2-button mouse and some with a mouse wheel also.  In this case you need to handle the worst case scenario, which is the track-pad.

Ok, so notwithstanding the pointer device and how this affects the user interaction in a limited viewport size, how do you handle this scenario?  One option is to shift the menu or the sub-menus into view, but this might not be enough.  The other is to keep the menu open based on a specific action, with a logical means to close it.

Beyond this, if there just may not be enough space at all, even after scrolling the page, it would be logical to ether provide scroller arrows for the menu items or to identify to the user that content is hidden due to the lack of space such as is the case on the Windows Start Menu.  Whatever you do, you want to ensure that the user has clear, easy, and quick access to visible content.

Menu Stickiness

Every menu visited so far, from BBC News to Flickr forces users to click on the header option in order to open the initial menu.  In all cases the menu remains open indefinitely as a result.  This is inline with more traditional operating system functionality.  There are slight deviations from this when hovering over the menu for a sustained period of time will cause the drop menu to hide after a specific action (hovering) is completed or a period of time has elapsed.

Interestingly, it is on the e-commerce related sites and not the service orientated sites that retain menus that auto-close after a period of time.  Few of the menus open on hover, responding on click only and closing on mouse out.  Of those menus that stay open on mouse out, all of them close when clicking outside of the respective area.

Dynamically applying a setTimeout function to close the menu after a specific time lapse would be once way to ensure the menu doesn’t stay open indefinitely, but at the same time you need to be mindful of the user and their ability to skirt around the page, scroll and do everything else to achieve their intended goal. Sites like Flickr keep menus open indefinitely, so it’s hardly a crime for you to do so also, and let your users decide when in fact they want the menu to close.

Functionality Failover

Needless to say the BBC’s pure HTML menu survives the fallback test every time, but how about the others?  There’s no reason why menus can’t work with pure CSS, a little less finessed perhaps, but working nonetheless.  Any menus that rely exclusively on JS to work should degrade such that without JS the menu won’t appear and the navigation on your site shouldn’t be impeded.  Exceptions might be possible when working on closed systems, but on public websites you only end up with egg on your face if things don’t work as billed.

Amazon degrades the menu to a long list, having used the JS to compressed it and apply styles to the sub-menus, whilst Facebook removes the drop menus and opts for the traditional click through to a destination page with a differently formatted list of the appropriate content.  Flickr, however, opts for a more coercive approach, telling users that they must have JS enabled to use the site properly and leaving buttons in view that do not function at all, even the CSS reacts to hover and other selectors.  Apple’s conveyor belts degrade less beautiful, but at least they still work  – surely the desired result.

Defining The Purpose

In all of this discussion one has to remember that the real purpose of the menu in all of this is to help your site visitors to get where they need to go in as a few clicks as possible.  Excessive menu items is as much a design flaw as shoddy functionality, and divining the right path is up to you.

If you aren’t sure how effective your menu is then you should try out some A/B testing with defined goals, or perform click tracking tests and see how and how often the menu is being used.  One thing you definitely shouldn’t do is assume, just because it is there, people will use it, or that the contents of the menu will even make sense to them.

Consider the menu in the context of your global navigation and your search tools, and provide it as a helpful means by which to more easily dig deeper within your site, but not at the expense of other content.  Last but not least, and most importantly, make sure it works logically and as expected, in terms of what your site visitors are used to from the sites they might visit most often.