Double-Click Must Die

Recently, we had this strange problem with a particular smart client application at work. It happened when the user clicked the OK button on a specific form. Like all difficult bugs, it was impossible for us to replicate. We put a bunch of diagnostic scaffolding into the deployed executable; this provided a number of clues. We knew that the submitted data had duplicates, somehow, and this was throwing duplicate record exceptions in the API. After a week of head scratching and asking ourselves how this could possibly happen, a fellow developer had an simple idea: what if we double-click on the OK button? Sure enough, that second click was somehow getting through to the UI and causing the OK button code to execute twice.


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/10/double-click-must-die.html

My friend was trying to help his mom use the computer over the phone (he was at work or something). And he kept telling her to click the button, and sometimes it would work and sometimes it didn’t. Finally, in exasperation he yelled, “Are you clicking the LEFT mouse button?!” She replied that she didn’t even know there was a difference, and would just “click one of them” which would account for the roughly 50% success rate. :slight_smile:

[Double-clicking] was basically forced on the
industry by Apple Computer when they elected to
use a single button mouse on the original Mac in
1984.

  • Microsoft develops two-button mouse in 1983
  • Microsoft releases Windows 1.0 in 1985

Would you mind explaining how double-clicking was “forced on the industry” by Apple? I really don’t think that the original Macintosh had such momentum that it prevented Microsoft from choosing what you seem to think is the superior interface.

Oh, right… well, maybe if Microsoft had actually done any original work on interfaces of their own, they might have been able to make those kinds of decisions.

The state of UI at this point is so confused w/r/t clicking that users don’t know whether to click or double-click. If clicking doesn’t immediately do something, they’re apt to try double-clicking just to see if that was the appropriate action. As your anecdote points out, in applications that don’t anticipate this, “unexpected result can occur.”

I work with an app that uses single-click and double-click for separate actions. The double-click action is extremely expensive (it downloads a file, which can take 15+ seconds), but just as unfortunately, single-click is not always responsive. As you also note, the double-click interval is generous defined, so the action single-click/pause to see if anything has happened/single-click often ends up being a double-click, much to my annoyance.

It truly makes me want to sit the developer down so he (as I happen to know) could see what it’s like to use the app.

we have a huge application for gov of brazil, something like 3000 pages of aspx and we dont use this Enable/Disable button for operations in webpages now ive got alot troubles cos this, maybe you know how i can change my 3000 pages button control to do this, and listen the bad thing we dont use a specific custom control to button… we use de default button control…

Yes i know im in bad days …

Help us if you can…

As you point out, you’ll have to replace those standard buttons with a custom ASP.NET server control. Won’t be much work to write the control, but retrofitting the existing pages probably can’t be automated…

roberto-

you could write a HTTP module that scans the HTML generated by every one of your pages, looks for button or input type=“submit” tags, and modify the on click events accordingly; just make sure that you propogate any existing postback (__DoPostback()) logic that might already be wired up.

it’s a bit expensive to do this at runtime, but in general, the CPU hours that you spend will almost deftinately be cheaper than the developer hours that you would spend to change every reference to button. :wink:

erm, in that last post, my example tags got stripped out; instead of saying:

looks for or tags

it should say:

look for button or input type=“submit” tags.

i guess thats what that “preview” button is for, eh?

You’re saying a couple different things here:

  1. Double-click is not intuitive
  2. The user should have another button for that action

Correcting either of the two (from an OS level) would cause the user more trouble than leaving it alone. For whatever reason the double-click is here… and change hurts a user more than anything.

As far as Apple, they are UI innovators. The single-button mouse is more usable for the average user. Users like my mom who don’t really understand the distinction between left and right (and would almost never use the right button anyway) are better served with a single method by which to express themselves to avoid confusion. And adding a second button to an apple mouse to indicate a double-click wouldn’t be very nice to the www.apple.com/switch 'ing user either.

I think that’s the most innovative part about every facet of Apple’s UI. Less options equivalent power. That, and jewel buttons. Jewel buttons is perdy.

“1. Double-click is not intuitive
2. The user should have another button for that action”

Actually, I’m proposing that the entire UI be made single-click just like the Web.

Microsoft did introduce this in either Windows 98 or ME, I can’t remember which. Open any explorer window then do Tools, Options, General, Click Items as Follows, Single-click to open an item.

“Oh, right… well, maybe if Microsoft had actually done any original work on interfaces of their own, they might have been able to make those kinds of decisions.”

You’re right; even though 2 button (at least!) mice are standard on Windows systems, we still need to double click to invoke activation. So that was a squandered opportunity for improvement.

More disturbing is the way that Apple still ships a single button mouse out of the box with their systems, and perpetuates it in their latest interfaces. The mistake is 15 years old; the time to start fixing it is, uh… any day now. Click and hold if you agree with me!

I expect more from Apple than I do from Microsoft in this regard (eg, being ui innovators). The sad thing is, as Mike points out, the users are the ones that suffer.

" She replied that she didn’t even know there was a difference, and would just ‘click one of them’ which would account for the roughly 50% success rate. :)"

That’s really funny.

I do think there’s a point of diminishing returns for mouse buttons, but that point is DEFINITELY more than one. Probably two, with the third wheel button as an optional bonus.

I doubt this particular user would have been any less perplexed with a single mouse button to ‘choose’ from. :wink:

Interesting idea [disabling buttons], though I’ve experienced weird behaviour when using this method in the past, presumably because when the button is disabled, it’s value is not posted, and .NET needs this data to process a postback.

My solution was to use some javascript and the onsubmit handler, setting a flag when submit was pressed the first time, and then checking the flag on subsequent presses to verify whether the submit button had already been pressed, and if so, disallowing the subsequent submit.

Btw, just wanted to say - cool blog! Found it recently, after clicking through from an article on CodeProject (the one about custom exception handling). Wish you had full text in your RSS feed though :slight_smile:

Thanks!

I agree you probably wouldn’t want to use the .Enabled property in ASP.NET to disable the button, but rather disable the button using pure Javascript. The fact that the button isn’t enabled after the click shouldn’t be relevant to any server side processing anyway…

You would think that disabling the button after it has been clicked (using button.disabled = true) shouldn’t affect server-side processing, but having done some more testing, it does appear to interfere with postbacks.

Feel free to give me a shout by Email or on MSN, and I’ll send you my test pages :slight_smile:

Hmmm, all interesting. The original blurb does seem to accuse non-IS folks of being stupid when choosing dble-click or not.

What about the idiot mouse driver that clicks twice, being too sensitive to any movement and has no interface to adjust it??? huh? You know detection of false clicks?

So now the fault is back in the lap of the designers!!! LOL. Idiots.

I have had the same problem with our new accounting package. It duplicates data. Having been a programmer I know the difference between the single and double clicks. So I am positive that I am not double clicking. The only thing I can think of is that my Radio mouse is sending double clicks when I single click. I changed the mouse to normal mouse today and am eager to find out if this is the problem. Have you had any cases like this?

Thanks
Sai

Have you considered the possibility that the idea of double-click iis/i a good idea?

This is not information, this is a rant, man.

I don’t buy that having a two-button mouse in 1984 would have replaced double-click. In 10+ years of multi-button mice it hasn’t; and even Windows 98 went for a different model than left-click-select, right-click-open.

Perhaps that’s because double-click claimed the Open function (or vice-versa), and right-click has mainly become a context menu. So right click is no longer free for Open.

I’m on the side of not having objects selected unexpectedly (e.g. by hovering). Leave single-left-click the way it is. Move Open to a context menu if you want (“you” meaning all developers and designers)

Douglas Engelbart, the inventor of the mouse, says mice should have many buttons:

http://www.engadget.com/entry/1234000840068219/

Jef Raskin, who created the original one-button Apple Macintosh mouse:

“What I did not see at the time is that multiple buttons on a mouse can work well if the buttons are labeled. If the Macintosh mouse had had multiple buttons, if the buttons had been permanently labeled, and if they had only been used for their intended function, a multiple mouse button might have been a better choice. A better mouse might have two buttons, marked Select and Activate, on top and on the side, a button activated by a squeezing action of the thumb. This last button would be marked Grab. Some mice at present have a scroll wheel on top that is used primarily for scrolling. Better still would be a small trackball in that location. The mouse would control the position of the cursor; the trackball could be used, for example, to manipulate objects or to make selections from menus that float with the cursor.”

That’s on page 209 of his book The Humane Interface (2000). The trackball comment is awfully prophetic considering the Apple Mighty Mouse introduced in 2005 has one exactly like that…