4

Assuming we have a dropdown menu which closes on a mouse click (instead of automatically when the mouse leaves the area).

Should this mouse click perform its standard actions, if the mouse happens to be above an element which can be clicked upon?

I've seen both versions being implemented in very similar applications.

If the rest of the user interface is complex, and can have context-sensitive items triggerable by mouse, it makes sense that the user has to click again to perform it. For example, in a web browser, it would be annoying if a link was followed because the user clicks only to close a dropdown menu. In a paint program, it's annoying when a new pixel is painted on the canvas because some menu was closed.

However, if there is an emergency stop button (or similar functionality) on the interface, it can be annoying if the user has to click twice if a menu was open somewhere.

  • 5
    I don't have enough data for a real answer – just personal opinion – but I would make items behind a menu NOT clickable. To make sure that the user doesn't get confused about having to click twice, make sure that the menu is prominent when it's opened (use a strong border or shadow, or gray out the background), so the user will naturally want to close the menu before they move on. – Samuel Bradshaw Apr 26 '17 at 14:20
  • Interestingly, Mozilla Firefox on Windows and Linux behave differently in this regard. On Linux (checked it on Ubuntu) the click only closes the menu, on windows, the link is followed if it happens to be under the cursor. – vsz Apr 26 '17 at 14:50
  • 2
    I think you've already answered your own question. It's annoying if you accidentally activate something (potentially destructive) by clicking outside of a menu to deactivate it. Personally, I'd say a dropdown/popup menu should have an explicit close button, similar to how windows usually have one too, instead of relying on being able to click outside it in the first place (which is not always guaranteed). – Clearer Apr 29 '17 at 15:17
2

I don't think there's the One True Way to solve this, so you can choose either behavior for your application. That said, the behavior should not depend on what kind of object user would click, because consistency is key!

(There is a reason why "Strive for Consistency" is the very first of Ben Shneiderman's Eight Golden Rules of Interface Design.)

If closing the menu requires a "dead" click, which does not trigger anything else, that should be the behavior every time. If clicking outside the menu would directly trigger the underlying widget, than that should be the exact behavior every time.

(In your example of the Emergency Stop button, I'd argue that the effort of clicking a second time in the exact same location when targeting that button is negligable compared to the risk of unintentionally hitting the button and triggering an actual stop when you just want to close the menu.)

Further, in case you're working on a web application, you can easily help your users predict what will happen, if you display the "pointing hand" cursor over every interactive widget on the page.

In fact, this is the behavior I noticed for the toolbar menus right here on StackExchange, so you can play around with this right now! :)

enter image description here

1

Given the use case you have suggested I would go for both options

if there is an emergency stop button, that should be clickable, other things should not.

The important thing is making it obvious which is which.

My personal way of doing it is putting a thin overlay over the things that arent the user cannot interact with. Has the added bonus of popping the dropdown nicely and highlighting those things one can still directly interact with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.