IanG on Tap

We developers are, on the whole, a lazy breed. It goes with the territory, I think. And I’m not talking about common low-grade laziness here. I’m referring to total commitment laziness: being prepared to put in an extraordinary amount of effort to avoid doing something.

The canonical test for this is to make someone perform a task that will take 8 hours of repetitive work to perform in Excel. The non-programmer will just do the work. But a natural developer will be too lazy to do the work. Instead she will spend 7.5 hours writing a program to automate the task.

And even if the task would only have taken 3 hours, a real developer will still spend 7.5 hours writing an automated version. This transcendental form of laziness - being prepared to expend more effort than necessary simply because you’re too lazy to do the work - is what I’m talking about.

For the most part, it’s a Good Thing: the ability to notice and avoid unnecessary work is a useful trait in an engineer. However, it has its downsides.

When Laziness Goes Bad

While laziness in the name of avoiding repetition is all well and good, a mindless preference for the path of least resistance is not so useful. Take the MessageBox API for example - if you need to get certain kinds of input from the user, MessageBox has its attractions. Particularly when you look at your options this way:

1. Devise a dialog especially for the task at hand. Prototype it. Run usability tests, focus groups, etc. Employ graphic designers to create a visual design for the dialog. Get developers to implement the dialog and the code behind it. Re-employ graphic designers to explain to the developers exactly how they failed to execute on the exquisitely-crafted design vision. Get developers to re-implement the dialog. Iterate the last couple of steps until it looks right and works, or until nobody cares any more. Ship it!
2. Call the MessageBox API. Ship it!

To the naively lazy mind, the second option looks much more appealing. The problem is it can result in a pretty crummy user experience. Here’s a particularly egregious but not exactly unusual example:

If you don’t see the problem, then I’m guessing you’re a developer. ;-) (Hint: what exactly am I agreeing to if I click Yes at this point?)

Poor wording notwithstanding, this style of interaction is always likely to be sub par. The buttons labels bear no direct relationship to what will happen when you click on them. (I’m guessing that the first panel in this comic from usability site OK/Cancel is poking fun at this widespread poor design practice.)

Enlightened Laziness

Anyone truly committed to laziness will find this unacceptable. Every time such a dialog appears, we are making the user expend some mental effort to map between the generic Yes/No labels and the outcome. If your software gets used a lot, the sheer volume of unnecessary work this generates is unbearable. Oh! The humanity!

Clearly the efficient (i.e. lazy) solution is to provide a UI that doesn’t require the user to translate Yes and No into Save and Discard. We should just make the buttons say what they mean. And as mentioned in the my previous entry (on command links) the Vista style guidelines encourage us to move in this direction.

While in the long run, making life easier for our users will easily balance out the initial effort required at development time, the mere presence of extra effort at any stage will surely set your lazy senses tingling. In an ideal world, we could offer the improved user experience without having to write a dialog from scratch. Wouldn’t that just be heaven?

Lazy Nirvana

Enter Vista’s new Task Dialog.

Just like MessageBox, the Task Dialog saves you from building a custom dialog from scratch. But it gives you the option of building a better dialog than you can with MessageBox.

It still lets you build one exactly like MessageBox if that’s what you want...

(And yes, thank you film buffs, I know that’s not the line from the film. But the real line wouldn’t have made sense in context, would it now?)

OK, so it’s not exactly the same. It’s a slightly different icon. We’ve lost the redundant disabled close button. Also, notice how the grey section at the bottom has a slightly darker line at the top, which is rounded off at the edges. And more interestingly, we have a main question and a note beneath it. This lets you ask the question succinctly, and then provide a slightly more verbose explanation beneath if necessary.

But that’s not terribly interesting as it still suffers from the same basic problem as the previous dialog: meaningless button labels. That’s what you get if you use the basic TaskDialog API - a slight upgrade on the basic message box.

But with only a little more work we can use TaskDialogIndirect. (If you’re familiar with Win32 dialogs, this name might make you think you need to supply a dialog template. In fact you don’t. You just supply a data structure with some settings and a list of the buttons you’d like.) This API offers all sorts of variations on style, including the ability to use Command Links, the new style of button discussed in my previous entry. Here are the results:

There are a variety of options on offer. You can use normal buttons if you prefer. You can show a progress bar. You can add in a collapsible section to contain more detailed information for users who would like to see it without cluttering things up for everyone else. You can add radio buttons and a checkbox if you really must. And you can embed hyperlinks in any of the text fields. (Although not the text of the buttons, since buttons already do something when you click on them - embedding hyperlinks would just be confusing.)

Obviously you wouldn’t want to switch all of these features on at once. (Except perhaps to see what it looked like. And yes I did. I’d describe the result as: crowded.) Just pick the options that make sense for your scenario. And you’ll never want to use MessageBox again!