2

Background:

Recently I was working with a widget (Select2), and found what I felt was a rather large UX issue, the <select> box (dropdown) was being treated as modal interaction with a transparent mask blocking interaction to the webpage below. The creators defense was this is standard interaction in Mac OS (and also solved several technical problems for him as well).

Question:

My question to this community is what patterns or UX research defends Apples decision to make standard select boxes a modal interaction? To be specific, it blocks interaction with the application until a selection is made or the user closes the dropdown by clicking outside the dropdown. To me this flew in the face of the expected users mental model, and seems to diminish usability, though this is simply my opinion and I open it up to you guys to better defend or argue against.

Additional Info

As of right now I know this happens in at least Mac OS 10.9. If you have that version installed you can try this by going to W3Schools select box. which is a vanilla select. Click on the select, and try to interact with anything else, such as browser tabs, switching to a different app in the background (by clicking on it), or even click on the main OS bar at the top. You should notice that your click is ignored and instead only closes the select dropdown.

|improve this question|||||
  • 1
    Following the link, I don't see the widget exhibiting this behavior. Am I missing something? Also, I prefer to avoid modals wherever possible. – Matt Lavoie Jan 6 '14 at 21:57
  • @MattLavoie You must use one of the customized dropdowns (In the first example it shows a standard select, and then what it turns into) Click on the second dropdown and then scroll up (if needed) and hover over one of the buttons or links. You should notice it does not trigger any hover effects making them appear disabled. Now click on one of them. Nothing happens, reinforcing that they are disabled. However, now notice after you clicked the hover effect is triggered, click a second time to use the button. – Chris Janssen Jan 6 '14 at 22:44
  • Hmm, I dont know that I would necessarily consider that a modal. It doesn't prevent the user from cognitively processing any of the rest of the content on the page. Really all it does is inflict a click to close before I can click on something else, but without the gray overlay it doesn't mentally prevent me from jumping to something else. hmm. – Matt Lavoie Jan 6 '14 at 23:28
  • I'm not sure OSX does create modals from drop down lists. Can you cite the source of this information? – DA01 Jan 6 '14 at 23:44
  • 2
    I don't know that you have to re-word. I'd maybe say "Modal-like interaction" to be a bit more specific, but that's just me. It is a rather unique thing. For the record, the definition of a modal window is that you do have to interact with the window to dismiss: en.wikipedia.org/wiki/Modal_window It's all fuzzy terms, of course, but one could argue that if you don't have to interact with the window to dismiss it, then it's not a true modal. (People may call it an overlay, or pop-up pane, or any other number of terms...many of them vague enough to be debatable) – DA01 Jan 9 '14 at 1:13
1

My question to this community is what patterns or UX research defends Apples decision to make standard select boxes a modal interaction?

Since you can click outside of the select box to close it, there's a danger that you could click on something destructive: what if you accidentally clicked a Delete button on the page below? To prevent this, the select box behaves like a modal so that any click outside of it simply closes the box – much safer.

Apple uses this elsewhere in OS X, too. For example, if you have a Mail window open in the background, clicks on destructive buttons (like Delete or Mark as Junk) are ignored so that you don't accidentally delete a message when clicking the window to bring it to the front.

|improve this answer|||||
  • Certainly preventing miss-clicks for destructive actions is a consideration but this is why destructive actions generally must be confirmed or can be undone. I think if this is the only reason they did this, it is throwing out usability and changing the mental model of the user for a corner case. It assumes the user isnt looking where they click, and they happen to click on an undesirable undo-able action. Switching windows probably has a higher case of this, but preventing click-through when switching application windows should be dealt with on its own, not only in this case. – Chris Janssen Jan 15 '14 at 21:07
  • Well, in the browser, there isn't necessarily a confirmation or undo feature for each destructive action, since it depends entirely on the specific site/page – so it's much safer for an open select box to simply block any click outside of it. In the case of a desktop app like Mail, preventing click-through on destructive buttons avoids the need for a confirmation dialog, which would be very annoying the rest of the time. And undo doesn't necessarily help since you might not realize you accidentally clicked a destructive button while bringing the window forward. – daGUY Jan 16 '14 at 14:42
  • @ChrisJanssen What is the alternative though? Leaving the select open until a choice is explicitly clicked? What if it has 50+ options like a state select and covers up important parts of the page? What if checking a box elsewhere in the form changes the contents of the select? What if the user changes their mind and doesn't want to make a selection? It's better if they can click anywhere to dismiss it instead of having to find click a specific item in the list to put it back with no changes. – Nathan Rabe Jun 10 '15 at 13:05
  • @NathanRabe I think you misunderstand, the expectation is that clicking outside of a select indeed closes it. The issue is that in OS X all other actions (hover, etc.) are suppressed with no modal underlay to indicate. This to me is confusing to a users (previous) mental model, with no visual indication that the choice is modal. Per the interaction in OS X the user would not be able to check a box elsewhere to affect the select (though I question that interaction anyway). But yes clicking anywhere other than the dropdown should close it, the question is simply do you treat it as modal or – Chris Janssen Jun 17 '15 at 19:05
  • @ChrisJanssen Not every mode requires a modal dialog. There are lots of interface elements that cause software to briefly enter a different mode, but because the duration is expected to be short, no overlay or separate dialog is used. Selects, menu bars, right-clicking a dock icon, the classic Start Menu, etc. all briefly enter a mode without overt indicators. If anything, selects are more consistent with mental models of "You must make a choice from the list before doing anything else." Modal dialogs that dim the screen are generally the exception. – Nathan Rabe Jun 18 '15 at 16:52
0

Update: I've tested fiddling with dropdowns on a mac osx 10.9.1 and they work just like you would expect. If you click in the combo and then click anywhere else, the combo closes with the option you had previously selected.

Dropdowns require lots of precision to select the option you want. This is crucial when you are working on a device makes it difficult to input data such as smartphones and tablets. So for these scenarios, turning the dropdown into a modal interaction has benefits, like:

  • You make sure the user is focused on making a choice
  • You can make the choices bigger so that a choice is not made on accident
  • If the user touches a dropdown (which can make a choice) the user will quickly realize that a choice is being made, and can revert it.

Now, modal interactions always introduce a burden since the user is surprised at first, which can be reduced if you keep the user in the same context for example by dimming the backgroud but leaving it visible so the user can understand where she is. For devices where you have lots of input precision, like desktops where you use a mouse it probably does not make much sense to turn a dropdown into a modal window.

|improve this answer|||||
  • Yes, I get the point on Mobile Devices, there is limited space, the way you provide input is different, etc. However none of this supports why you would do this on a desktop browser when none of these concerns apply. (as you note in the end of your answer). – Chris Janssen Jan 14 '14 at 19:32

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.