Clicking and the art of user interface design

Wednesday, October 20, 2004 04:17 PM

Raymond Chen discusses double-clicks (and higher-order clicks). For years, mouse clicks were interpreted in a fairly standard manner: clicking an item selects it, and double-clicking it activates some default action, like displaying a window and editing the selected item. The mouse messages logic in Windows is tuned to support this model. Other models, as demonstrated in Raymond's posts, require some trickery.

One model in particular caught my eye. In this model, both a single-click and a double-click invoke an action, but the single-click action is only invoked if the user will not double-click. Since there's no way of knowing whether the user will click the mouse again, the trick here is to delay the single-click action for the amount of time specified for double-clicks (in the Control Panel's Mouse applet). If the user doesn't click the mouse within that period, the application can run the single-click action.

The "clairvoyant" mouse input model is getting pretty common these days. I've implemented this model for the in-place editors in Planners, and even though Windows has no internal support for it, it is implemented by parts of the Windows user interface, such as Explorer. The model belongs to a family of user interaction techniques that go beyond the simple, deterministic rules of the past, and try to interpret the user's intention. In other words, "Do What I Mean".

We see more and more DWIM algorithms in modern software, and have come to expect them. For example, many program support text selection using several mouse operations. You can push the mouse button and select an arbitrary portion of the text, but if you move past a word boundary the selection model changes and selects complete words. A single click positions the caret, a double-click selects a word, and a triple-click selects an entire paragraph. This model is even supported internally by the Rich Edit control in Windows.

A lot of the time, these models are the result of usability testing. Watching how users interact with software, figuring out what their intentions were, then teaching the software how to interpret the user's actions. Other times, we just copy such behaviors from programs we find easy to use. In fact, it's important that we, as developers, do that. It let's us provide a consistent interface to our end-users, making our programs easier to use and - hopefully - more attractive.

Implementing such behaviors isn't easy, but these days it's absolutely crucial. The main problem isn't the actual implementation - if you take a look at Raymond's posts you'll see the code is fairly trivial - it's correctly analyzing the correct process to implement. One of my favorite examples is the way programs handle multiple selection and drag-and-drop. This process is so complicated that it's difficult to find two programs that handle it exactly the same. Here's how Windows Explorer handles it, roughly:

The table above is incomplete: it only includes left-button handling on file names. Other things, like the right mouse button or focus changes, can affect this behavior. Also, when clicking on file icons rather than on file names, the rules change a little. You can even select ranges using the mouse (without using the Shift key).

Notice the different selection behavior for single items: if an item isn't selected, pushing down the left mouse button is enough to select it and unselect any other item. If an item is already selected, other items will only be unselected when you release the button. This is implemented to allow the user to drag multiple items while still responding to user requests as soon as possible. Ideally, a single click selects an item as soon as you push the button. If Explorer did that, however, you would never be able to drag multiple items without using the Ctrl or Shift keys, so the program delays that decision until the user does something else, like releasing the button or moving the mouse.

If you want your programs to be user-friendly, you have to pay attention to details. It may require a lot of work to make a process intuitive for the user. Even things we take for granted, like multiple selection, require a lot of thought, and a lot of work. It's easy to avoid that extra effort - at the end of the day, most users won't even notice these features. But they will use them, and they will notice if they're missing. and they might even look for alternatives to your program.