Luke Wroblewski gave an excellent talk called “Design Patterns” at SXSW. A highlight was when Luke presented the results of user interface research into the advantages of various form label alignments.

I’ve condensed the slides from Luke’s talk down to just the ones on form labels because that information holds up particularly well on its own. The information here is based on research and is actionable. I highly recommend it to anyone interested in UI design.

Download Luke Wroblewski’s slides on Form Label Alignment

The full set of slides from Luke’s talk are available on his blog.

“The principle of the Kodak system is the separation of the work that any person whomsoever can do in making a photograph, from the work that only an expert can do. . . . We furnish anybody, man, woman or child, who has sufficient intelligence to point a box straight and press a button, with an instrument which altogether removes from the practice of photography the necessity for exceptional facilities or, in fact, any special knowledge of the art. It can be employed without preliminary study, without a darkroom and without chemicals.” Found via Lawerence Lessig’s Free Culture

And so the people became photographers.

Having “sufficient intelligence to point a box straight and press a button” was all that was needed to take a photo. Simplifying a task was all that was needed to create an industry.

Web applications can benefit from subscribing to this same level of simplicity.

Are we getting stupid? François Joseph de Kermadec

Big Beautiful, Dumb Whitespace

Odeo goes simple and only insults us a little 33inc.com

[Big buttons] implicitly say, “Hey, you’re too foolish to choose what to do next, so I’ve put a really big button right here just for you.” Cameron Moll

Most of these comments are a reaction to the recent Odeo redesign which, if you agree with the general consensus, does have some problems¹. But behind these comments is a sentiment that I often hear expressed in the software design community that I do not agree with: if you design something to be simple to use, you are designing it for simple people.

While I agree that the knowledge level of your audience does affect how complex you can make your software, I do not agree that it is a factor in how simple you should make your software. The answer to how simple should you make your product is always the same: as simple as possible.

There is no inherent value to complexity. It can lead to advantages, by allowing more features and greater flexibility, but new features and greater flexibility only become advantages if your users take advantage of them. Simplicity, on the other hand, does have inherent value. It reduces how long your interface takes to learn and use. Therefore, the comparison between the benefits of simplicity and complexity is between features and flexibility that may or may not become advantages to your users and immediate guaranteed benefit to all of your users.

The following factors should be considered when deciding whether to increase the complexity of your software by adding new features:

1. A percentage of your users will use the new feature, for most of these users, the value of your software will be increased by adding the new feature.
2. A percentage of users will not use the new feature, for every single one of these users, the value of your software will be reduced by adding the new feature.

In some cases, it is a no brainer. If 98% of your users will take advantage of a new feature then it should usually be added. The amount of value gained by adding a new feature that most of your users will use almost always trumps the value of leaving that feature out to preserve simplicity. But some decisions aren’t so easy, what if only 30% of your users will use a feature? Do you increase the value of your software for 30% of your users only to reduce its value for the other 70% What about 55%?

These are hard questions to answer. Every feature adds different amounts of value and complexity. But simplicity’s inherent value means your tendency should always be to lean in that direction. Note that I never mentioned the intelligence of your users as a factor in determining how complex you should make your software. That is because a far better question than “how many users can handle the new feature?” is “how many users will use the new feature?”

Finally, a counter to the stance “if you design something simple to use, you are designing for simple people.” You don’t create simple designs because people can’t figure out your product otherwise, you create them so that people don’t have to figure your product out.

1. I took a close look at the Odeo redesign while I was writing this post, and I now believe that this “redesign” is really Odeo promoting their “create recordings from your browser- or your phone” feature. This is a very interesting feature that lowers the high barrier of entry to recording your own audio. I suspect they are making a trade-off, reducing the visibility of the audio content available to download, in order to increase the number of users producing audio content on Odeo. ↑

To summarize the articles: after testing subjects by having them complete the same tasks with the mouse and with only the keyboard, Tog found that subjects consistently believed they had completed the task faster with the keyboard, when in reality they had completed the task faster with the mouse.

Tog states:

• Test subjects consistently report that keyboarding is faster than mousing.
• The stopwatch consistently proves mousing is faster than keyboarding.

Tog then gives an explanation for the difference between perceived and actual time:

It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.

Tog’s articles are a great read, he makes points that contradict people’s instincts and backs them up with cold hard research. But, on the subject of whether the mouse is faster than the keyboard, Tog’s data is inconclusive.

A simple thought experiment will help me explain the reasoning behind that observation: imagine using a software application that is just one window. The window contains a picture of a keyboard and each letter on the keyboard is a button. Click on a button and it types that letter. What do you think would be faster for typing, the keyboard application or a real keyboard?

Most would agree that typing with a real keyboard is faster, which shows that at least the keyboard is faster for something (you may have started to doubt this after reading Tog’s articles). But what’s more important is the reason that it’s faster. The reason that typing with a keyboard is faster is a phenomena absent from Tog’s articles: muscle memory. Typing with a keyboard is faster because we have trained ourselves to the point that the minutiae of typing¹ is instinctual. We don’t think about hitting the individual keys to type a word anymore than we think about moving our hand to flip a light switch. We simply think about the result we want and the rest just happens.

Tog does not address muscle memory in his articles. In fact, his argument seems to be based on the test subjects not having committed the keyboard commands to muscle memory:

Part 1:

It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function.

Part 3:

[When using the keyboard], how can someone spending twice as as long at a given task be more productive? They can’t…Under such circumstances, the user must set aside the original task of writing or editing a document in favor of figuring out what key to press and how many times to press it.

In the case of muscle memory, you don’t have to remember anything. The argument that there really isn’t anything to remember when hitting a sequence of keys from muscle memory is supported by reports of people being able to type a password without being able to tell you what they are typing. It follows that there wouldn’t be a “two seconds to decide upon which special-function key to press.”

Tog seems to be making speed comparisons between a the equivalent of a hunt-and-peck typist vs. the mouse, instead of testing a touch typist. This is not surprising. The most straight forward way of performing a speed test would result in just such a comparison: take a random cross section of computer users, tell them which keyboard shortcuts they will be using, and then have them perform a series of tasks using these keyboard shortcuts followed by using the mouse.

This test will get you some great data. It will show you that the mouse is faster in many circumstances. It will help you discover a fascinating phenomena where users “forget” time that they spent “[deciding] upon which special-function key to press.” But it is a far cry from testing a seasoned computer user, who’s been using the same keyboard commands for years, completing real tasks while in flow, on the machine and in the work environment they spend 8 hours a day at.

Please note, that while Tog’s articles are based on actual research, this article is purely speculation. I am not trying to discount Tog’s observations. I am confident that the “high-level cognitive function amnesia” is a real phenomena that results in reduced speed gains when shortcuts not committed to muscle memory are used. This article was written to clarify the articles findings in the pursuit of truth.

Tog is among the most interesting user-interface experts on the web. For those interested in user-interface design, I highly recommend these two Tog articles: A Quiz Designed to Give You Fitts and First Principles of Interaction Design.

1. Moving our fingers to the right keys. ↑