Monday, April 4, 2011

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


  1. Good points, but ignoring the best option of tabbed vertical layouts (and modal dialogs) like those used in many options-heavy packages. Why Blender opted to do away with these is beyond me. I don't think reinventing the wheel was necessary in this instance and a lot of speed in workflow was lost

  2. you're also assuming that it's better to have the most controls on screen at one time. in the case of blender, i'd rather have more screen space taken up by editors, rather than buttons, since that's where i spend more time. most of the time buttons are just sitting there doing nothing.

  3. ASkinner:
    - Tabs are ok, and in fact I think we actually do make some use of them already, even if they don't look like it (NOTE: you don't always need to go for the full-blown "draw a box around it" route to group things!)

    - Modal dialogs sure do have a role, just not as great a role as they have traditionally been assigned. They're really "you MUST handle this NOW" things and quite narrowly constrained. But this doesn't fit well with the model of users tweaking one or two settings, and needing to do so seeing the effects in-situ.

    There is a very common trap to start chaining these dialogs together, either horizontally (one after the other, wizard-style, you-must-complete-each-step-now-and-provide-this-info-at-this-stage), or vertically (button in the corner brings up a dialog, which brings up another, ad infinitum). It's easy to get 3-6 layers of dialogs stacked on top of each other that you have to click out of after changing one setting, only to have to go back in moments later to tweak something.

  4. I too enjoyed the ability to have horizontal button layouts(in 2.x)
    There are many cases in which a horizontal layout works much better with my screen real-estate than that of a vertical one. I too have always used vertical button property windows from day one in Blender, though too have I used horizontal ones.
    IMO, Its a shame, that they're not back in again, even if subtle changes need to be made with horiz layouts to make them 2.5x friendly. There are definitely more pressing matters, but I agree with MANY of your points here @Aligorith.
    I work with MANY property regions open in certain screen layouts, MANY, and vertical layouts just aren't as efficient due to the wider nature of modern displays, imo.

  5. Thanks god i'm not alone...I miss the old UI layout, and i'm not good enought in english to explain it, your article enjoyed me.
    For me, this new layout is a "regressive standardization", after one year of testing, i still feel very unconfortable to work with.