Monday, January 19, 2015

navigation - Horizontal and vertical menus in web applications


It is now very common to find top horizontal menus in websites. Some reason of that might be habits and Jakob's law.


In web applications you might find a menu on top or on the left side equally. Most of the time it seems to be a combination of vertical and horizontal menus though. With no constant reason.


Apparently there is no real convention for that matter. Hence the following question:


What reasons/factors are relevant when choosing orientation of menus in web applications?


We are talking about navigation menus - leading to other pages - not action menus - modifying the current page.


The question is not about tablets or phones. It is okay not being exhaustive. Personal methodologies can also be answers.



Answer



Horizontal menu's don't readily support more than one level. Nesting or indentation are difficult to achieve, leading to many hard to use solutions widely documented in many articles and here on UX.SE. I'm no big fan of the Windows 8 website for instance, at the third level deep it just becomes weird.



Web documents are usually laid out for scrolling vertically. People are more used to scrolling in this direction and both hardware interfaces (mice, trackpads) and current HTML/CSS standards are designed to primarily support scrolling vertically. This makes that the width of a web document is usually fixed, while the height is free to grow with content. Horizontal space quickly becomes a problem.


There usually is very tight limit to the amount of items a horizontal menu can harbor, especially if you need to accommodate a 1024 pixel wide screen while using a 16 pixel font-size. Users can change font-size on the web, for instance if they have limited eye-sight, which increases this problem. There are hardly any real solutions to this space problem. Wrapping a horizontal menu over multiple lines is also problematic, e.g. if only one item wraps to a new line it breaks the visual unity of the menu. Wrapping also makes it near impossible to have multiple level and interferes with drop-down menus.


In the context of applications another issue supports choosing a vertical menu for navigation: UI elements (e.g. button bars) for interacting with the current page are usually laid out horizontally. This matches most common desktop applications, except perhaps PhotoShop and Illustrator (and similar), but they just put buttons everywhere :). Also, buttons need to be visible, to make sure all available functionality is visible to the user. While people are used to scrolling vertically, most displays actually offer more space in the horizontal direction. Also, actions can usually be offered by using icons (especially if they're common like "save" and "delete") rather than words, which saves a lot of space in horizontal direction (but hardly any in vertical direction).


Having a horizontal bar also offers the possibility of fixing that bar to the viewport (i.e. have it stay put at the top of the screen even when the user scrolls). This is by now common behavior in web-based mail clients, and many web apps like Facebook, Twitter, etc. While you could fix a vertical button bar, vertical space is more limited and could also quickly become problematic. Facebooks horizontal bar sticks to the viewport, while the vertical menu scrolls with the page. This is a strong advantage to a horizontal menu, so you could opt for your most important navigation to go there.


So, in many ways horizontal menu are preferable. If you can make yours work for the screen and font sizes you need to support, go for it. Just make sure you visually differentiate with button bars etc.


However, vertical menus scale better in both length and depth, so if you need to offer lots of items, go vertical.


Also, you can use both. Top level navigation horizontally, sub-levels vertically and on the left. Or mix it up with a mega-menu.


No comments:

Post a Comment

technique - How credible is wikipedia?

I understand that this question relates more to wikipedia than it does writing but... If I was going to use wikipedia for a source for a res...