Horizontal vs Vertical UI's

This evening, the old topic of horizontal button layouts vs vertical button layouts popped up again. Here are just a few thoughts about the pros and cons associated with these choices...


Personally, I think that horizontal UI's have a lot to offer in terms of efficiency, especially for experienced users. This is particularly the case when you've got a set of fixed options that can all be accommodated on screen at once (instead of requiring any scrolling, whether vertical or horizontal), in the same layout everytime (or very similar). As most modern screens are wider than they are tall, you've got quite a bit of screen real-estate to work with, if you spread your controls out along the width of the screen (relatively speaking, with vertical UI's, there are only so many rows of options you can include per screen before needing to scroll and/or use additional columns eating up horizontal space, which may not necessarily be desirable).

Especially when you can lay out all the controls so that they don't need scrolling to be accessed, horizontal layouts can therefore become very efficient, as muscle memory can be developed relatively easily. Furthermore, at least from personal experience, it's somewhat easier to perform horizontal movements compared with vertical ones when using various pointing devices. Actually, to be precise, it's not a strictly horizontal movement, by rather a diagonal movement of about 30-45 degrees in a slight arc, which has a distinctly significant horizontal component. I like to term this the "characteristic stroke arc". Something that'd be interesting to investigate sometime is a novel type of menu which would be based on this observation, which would be used in conjunction with a natural, "deck-fanning" gesture to select items.

On the other hand, horizontal UI's are really not that well suited as soon as you have dynamic lists of data. That is, anything that can naturally be represented as a list of items, or perhaps as a hierarchical tree which can be represented by recursive traversal into a list-representation, is really better suited to its natural form as a vertical presentation.

This is really the case that vertical UI's really excel at: list of data. Trying to shoehorn such data into horizontal layouts is really tricky, and does lead to many less-than-optimal consequences.

Another benefit of vertical UI's is the relative ease with which they can be extended (i.e. have new controls added). Instead of reshuffling buttons to make space within already well-packed+laid-out horizontal layouts, with a vertical layout, it's as simple as just chucking the new controls in a few extra rows at the bottom of some existing panel or column of controls. This approach is certainly a better compromise at times so that coders of varying levels of UI design strength can easily dump in new buttons for features without too drastic consequences (i.e. the risk is minimalised... but as we'll soon see, not totally non-existent!)

The real Achilles heel of vertical UI's is the amount of scrolling that you'll inevitably end up having to do. If you don't believe this, go ahead and create a simple vertical UI, then gradually work on it for a few months, progressively adding features in response to changing requirements/etc. then have a second look at it then. While it may at first be possible to keep this complexity under control, at some point or other, you'll find a situation where you have settings scattered amongst between the top and bottom of the button space, and for that you'd need to frequently jump between these to get a task done.

Sure, it can be argued that "good" organisation (i.e. categorisation of items) should be able to alleviate this problem. Indeed, when the number of controls involved is still small, and you have a "simple" UI, this may still be able to apply. But at some point, you're just not going to be able to cover several different workflows with your carefully crafted categorisations. One workflow might just need a single button from some panel at the top and then all the buttons at the bottom, but then moving that button to some panel at the bottom wouldn't make sense because it's kindof better suited in it's current context most of the time instead. (Perhaps more use of formal Boyce-Codd normal form analysis approaches (from database schema analysis) for this task could alleviate some of these problems? Though probably, it might not help that much in the long run).

Another argument is about whether that many controls are really needed. Indeed, we should try to get by with less. But, even then, there will come some point where you have an irreducible "atomic" set of items which must be represented. Don't forget that screens are only so tall vertically, and that you need a minimum of about 16-20 pixels per button (vertically, incorporating about 10-12 pt font sizes for the text in labels), which doesn't really leave that much space on screen for that many rows.

Also, you can't make vertical layouts too wide, otherwise they start becoming more like overgrown horizontal messes that sprawl downwards in long columns, and are spread across horizontally several columns wide. With some a scheme, you risk having columns of uneven height, or splitting content between the bottom and top of two adjacent columns (incidentally, this is one major problem with reading papers in modern on-screen environements. Navigating around a page to jump from the bottom of one column to the next is a major PITA, and is something which I don't think that current PDF viewers seem to help much with. A suggestion here is to be able to spit off the paper into a long continuous stream of text, chucking the referenced figures/tables off to the side of the content, using some kind of special "paper reading mode".)

Anyways, in conclusion, horizontal layouts are IMO still superior for fixed sets of options, as long as you can fit them all on screen at the same time and in a logical way. Vertical layouts are great when you've got lists, and are great if you wish to be lazy, but be very wary about "scrolling explosion".