Developing Programmers .com

How often do you design user interfaces? Some of us don’t need to work with them much. Others have professional designers to do UI design for them. For the rest of us, well at least creating a User Interface is easy these days. Creating a Usable Interface on the other hand can be quite a challenge.

Recently, I went looking for an old web site by “iarchitect”: the “User Interface Hall Of Shame”. The original site seems to be down but I found English and German copies of the site are still around. The hall of shame is well worth reading to make sure you don’t make the same mistakes as others. Another amusing read is the Award for the Silliest User Interface.

It is worth reading through those sites: they’re amusing and should get you started forming ideas about what makes a good UI and what makes a bad UI.

One common theme is that people form expectations of how things will behave. A friend once pointed out to me that if hooligans see a glass bus shelter, they expect to be able to break it. If the same bus shelter is ply wood, which might be significantly weaker than the glass, it’ll get spray painted but it’s much less likely hooligans will think to break it.

She went on to assert that the same principle works in User Interface design. If a design plays to people’s expectations it will be much easier to use and require a lot less explanation.

Many of the Hall of Shame examples use the wrong control for certain actions. For example, a check box acting as a radio button. People who have got the hang of what the difference is in one application expect the controls to behave the same way in any other application, and for the User Interface designer that’s a good thing. If you make your application behave in a predictable way then others are training up your users for you.

This isn’t just a UI principle. I’ve mentioned before that playing to expectation is a good idea in writing code that others can understand. The more people can make guesses based on experience and have those guesses prove correct, the easier it is to maintain your code.

The next major UI principle also seems to have coding parallels: Keep it simple. This is known to some as the KISS principle (for “Keep It Simple, Stupid”).

Every extra bell or whistle you add is just another stumbling block for someone who isn’t quite sure how to work your application. Identify what’s important and stick to that. If extra features are needed, offer an “Advanced…” or a “More Options” button to access all the tricky stuff.

The Silly User Interface Award article I mentioned before got a little criticism for comparing Windows Search with Google. I think the comparison is valid. With Google Search, you have a text box where you type what you know about what you’re looking for, and a Search button. All other complexity is hidden out of the way.

I suspect Windows will imrpove its search when Longhorn is finally released, especially since Apple’s Spotlight feature has set the standard for desktop search quite high. As with a Google search, you simply enter what you know about a file and it will list files or even program controls that match your search. It “just works” and it’s both technically brilliant and simple enough to require almost no explanation. Really think through what information is needed by the user and what is the minimum information you need from them.

While we’re on the topic of “just working”, a good UI should fully work. Don’t display options you don’t support yet. Get the enabling and disabling of fields spot on. Spell correctly. Line labels up nicely and in ways that make sense.

Simplicity and functionality combined give you elegance. According to Dictionary.com, “elegant” means this to programmers:

adj. (common; from mathematical usage) Combining simplicity, power, and a certain ineffable grace of design.

A good UI is elegant, and the three aspects of elegance I’ve quoted here are exactly the points I’ve been making above:

• Keep It Simple (simplicity)
• Do the job well (power)
• Exploit users’ expectations (grace).