Friday, September 24, 2010

Links ahoy

Yeah, I haven't said anything in a while. The reason: Starcraft II. It's highly addictive. So, while I'm playing my way through the campaign here are a few web pages I've found interesting:

Jeef Atwood's posted on the latest developments when it comes to SSDs. Apparently, they've gotten cheaper and faster. Ah but who's the fastest?

xkcd's worried that the windmills will kill us all.

.. and my good buddy Guillaume's posted his take on how to get the most out of Dragon Naturally speaking. You don't have dragon? You should. :-)

Also... did I mention starcraft II?

Tuesday, September 7, 2010

Dialog Boxes

Dialogs suck. They rudely jump in your face, block you from doing anything else, can be cryptic and are often just plain pointless. When a dialog comes up users (that includes myself) want to make it go away as fast as possible. It is the computer equivalent to wack-a-mole. As a result nobody is really interested in what the dialog is trying to say.

When a dialog pops up in front of a typical user they will start looking for the fastest way of making the dialog go away. The easiest thing to do is look at the buttons first. If the buttons are labeled "Save", "Don't Save" and "Cancel" then you really don't need to read the rest. It's a save confirmation dialog so press save if you need to do that, "don't save" if you don't and cancel if you were really trying to do something else. Labeling dialog buttons with what they do is excellent practice.

(This isn't the standard windows buttons order but otherwise a fine example)

Even if you don't buy the speed argument, putting the actions on the buttons themselves can help the user decode the rest of the dialog text. Example: A dialog with the text "The pliny has splonged the wirly. A momi is required." with "Get Moni Now" and "Get Moni Later" buttons is probably asking whether we'd like to do something now or a delay it until a little later. This isn't the best dialog because it's not clear what the consequences of the actions are but it's nice to see we can continue our work without getting a moni right away. Hopefully the pliny can limp along with a splonged wirly until then.

If the dialog has two buttons "Yes" and "No" then the user has to read the dialog text to find out what to do next. You can make this even worse by asking the user a question in the dialog text that doesn't require a yes/no answer. "Do you want to save or discard?" with "Yes" and "No" buttons, for example. That is not a yes or no question! You forfeit the rest of your questions! Again, labeling the buttons with the actions the user can take can avoid this class of error.

(Consider which options to put in a dialog carefully. 3 buttons is plenty. Don't be WinSCP.)

If the dialog text is incomprehensible the user starts to cast about looking for clues. This includes reading your dialog's title. Most of the time a dialog boxes' title is not that informative so the next thing the user tries to do is close the dialog with the close box. The idea here is the the close box essentially maps to cancel and so "canceling" whatever the dialog box is talking about is usually a safe action. Knowing this don't go and disable the close box action. That's like removing a panic button and replacing it with a profiterole.

So there you have it: a user will tend to look at the buttons first, then read the text then start looking for clues in the dialog title. They read them backwards I tells ya!