How do I make it harder to click this button by accident?


  • QA Engineer

    The dialog box shown below constantly has me clicking the wrong button—despite the fact that I designed it!

    The way it works is, the user types some text into the line edit box, and program output is shown in the widget below it (grayed out in this example). The user may want to further processing of the inputs, and so if s/he checks the “Show Transductions” checkbox, the dialog box pictured below will expand and show that additional information below the “Show Transductions” checkbox. This is instantaneous.

    The “Generate Debug” button opens a new window with debug output. This operation takes a long time to perform, but it is occasionally necessary.

    (These functions are autonomous. Whether chooses the “Show Transductions” option has no effect on whether one would then click the “Generate Debug” button.)

    Despite being both the designer and a frequent user of the program, I find myself constantly clicking “Generate Debug” when I mean to click “Show Transductions”. How should I design this dialog box differently to prevent that from happening?

    One thought I have is to simply move the button—it can't help that it's at the lower-right corner, where action buttons usually go. I'd also be interested in the computer equivalent of the clear box covering the big red button in the power plant—to prevent accidental clicks—but I can't recall seeing that done in computers. (I would like to avoid clunky confirmation dialog boxes if possible.)

    picture showing the dialog box described in the text



  • Full-time Transductions

    What if you show the transductions all the time? Don’t make the user click to see transductions. If transductions can be shown instantaneously, then just show them whether the user wants them or not. Make the computer work, not the user.

    [[Transductions text box under Parsing box --no check box

    If users don’t want to look at the transductions, then they don’t look at them. Even if users only need to see the transductions 30% of the time, it still saves 0.3 clicks per interaction, as well as removing the confusion with Generate Debug.

    On the other hand, maybe:

    • The user needs to see the parsing in the context of whatever is behind your window (i.e., the content of the parent window). Expanding to show transductions makes that harder.

    • Some users are confused or distracted by transductions, so it’s best to make it an item of progressive disclosure to insulate certain users.

    Visual Weight

    If both transductions and debug information should be under progressive disclosure, then the problem you have is that, as a consequence of visual design and layout, the Generate Debug has more visual prominence than Show Transactions.

    • The lower right of a dialog is where users tend to be looking after studying the parsing, and, by habit, the lower right is where users expect the “do this next” control to be (like in a wizard).

    • With its border and shading, a command button appears larger and has more visual contrast to its background than a check box, so it stands out more.

    So swap it around. For example, debug can be a lightweight link, which it is, in a way, in the sense that it links to a new window. I’d label it “Debug Info” rather than “Generate Debug” to emphasize this, and make it consistent with what the user wants to do (which is see the debug, not generate it per se). Transductions can be a progressive disclosure button (with the “>>” symbology), which makes its effect on the window more predictable than a check box does.

    Debug Info link left, Show Transductions button right

    In (Weak) Defense of Confirmation Dialog

    Regarding the general problem of preventing accidental activations, the confirmation dialog is indeed the GUI equivalent of physically covered button or switch. It has the advantage over a physical cover that you can provide user with text explaining exactly why the command may be a bad idea. For example, the confirmation could say “Generating debug may take several minutes.”

    On the other hand, users almost always think they know what they’re doing (and, believe it or not, they’re usually right about that), so they’ve gotten into the habit of not reading confirmations and going ahead anyway, so all you get with a confirmation dialog is a clunky annoyance.

    Safety Covers

    If you’re only worried about slip-of-the-mouse accidental clicking (“I meant to click “Insert” but instead I clicked “Nuke”), not misunderstanding the UI (“I thought ‘nuke’ was like ‘warm up the data’”), then a better alternative to a confirmation dialog is to use a single-item menu button:

    Nuke menu button with single Nuke All Data menu item

    It’s not a conventional use of menu buttons, but it’s faster than confirmation dialogs because there’s less mouse movement and no mental re-orientation to a whole new dialog. So there’s less self-documentation, but also less clunk.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2