unicornucopious

I really try to be positive and helpful in this blog, but today I'm posting three poorly designed user interfaces that I use daily in Windows XP. Note that I'm not trying to Microsoft-bash here. I can find poor interface decisions in Linux too (don't get me started on the Gnome start menu, and I still can't find a sane console-based IRC client).

Usability is the answer to the question, "What is the user trying to do, and how can it be made easy?" It's fairly difficult to get right, and the big players can certainly get it just as wrong as the n00bs.

On to the fun stuff:

Case One: Windows Media Player, minimized and unusable

Windows Media Player can be minimized to the task bar. It's handy and attractive, but why is the mute button more prominent than the volume control? Why is there a mute button at all?

When I'm listening to music at work and the phone rings, I want to stop the music now. I press the big blue Pause button, and I don't miss a note. Mute is also quite prominent, which is redundant. Yes, Pause and Mute are technically different, but they do the same thing for me - stop the music now.

Another thing I need to do constantly is futz with the volume. Either different songs are normalized differently, or I like this song more, or my ears are fatigued and I want to turn it down. This requires a click on a tiny button to take me to a secret interface, where a second action (moving a slider) is required.

That little volume button is hard to click, and it doesn't look like a volume button, and two clicks are required, and then the slider is non-intuitively horizontal. Really, show me a horizontal volume slider in any other audio program. Vertical sliders suggest what they mean: high/low = volume high/low. Plus, we feel cool because we can pretend we're at a mixing board in a recording studio. Think of the YouTube volume slider: prominent, vertical, and only one action is required. 'Nuff said.

Case Two: Opening an Outlook appointment

This drives me nuts. When I'm five minutes late for a conference call, I double-click the appoinment in my Outlook calendar. Before it's opened, I'm forced to make an important decision:

Gaahh! I want to see the dial-in information for the meeting I have to be in right now! How arrogant.

This seems like a product development person and a self-important developer had it out, and the developer won.

Case Three: The Event Viewer dialog

The first two were minor annoyances, but this item is a conclusive fail. It's egregious, and has cost me a lot of time, many times over.

Event Viewer displays system events, generally exceptions and errors. If you're looking in Event Viewer, you're an IT professional and you need to find very specific information. The designers of Event Viewer, however, think you're window shopping. The interface is set up for leisurely, casual, amateur browsing. Technically, there's a Filter control (tick that off the list), but you can't search by the text of the exception.

When you find an interesting event, good luck consuming it in the tiny, non-resizable window.

When I'm logged into a production web server, investigating an incident, I can always expect this deceptively simple task to become 45 minutes of click-scroll-click-scroll.

Conclusion

Good usability is difficult because it requires standing in some different shoes. It's not about the developer's craving for detail and complexity, or Marketing's new strategy, or Product Development's favorite new feature. There's only one question worth asking: What is the user trying to accomplish?