Replies: 4 comments 1 reply
-
I've been talking about this with some of the other folks I work with, and our thoughts are:
So in our case, the behavior of quickly closing/opening (with a brief flash) should probably be addressed so that the dropdown remains open without a flash. |
Beta Was this translation helpful? Give feedback.
-
I am in favor of keeping the list open. But if we did an analysis on Mobile devices maybe it makes more sense to close the select. I came to this conclusion because there are screens with little space and sometimes the user opens the select but does not want to select any option there to close he needs to click on the side and outside the select, but sometimes the space to click outside the select is too small so it's much easier to click on the select input. |
Beta Was this translation helpful? Give feedback.
-
QA guy here - not intending to be authoritative, but the way I'd treat it if it came to me - for single item select (so, this), that feels like it ought to behave as an open/close toggle to me, both from a UI icon perspective (the flipping arrow indicates an open/closed state, so clicking/tapping it twice feels like it should toggle it) and in terms of useful function (I as the user may want to drop it down and then close it without making a selection, and that icon is how I would intuit that to be done). Currently clicking the UI arrow twice just reopens the dropdown, which is visually a bit annoying and as far as I can see functionally useless. (I may be missing something, though.) Certainly the "flash" of it reopening is something I'd want to change, even if leaving it open was landed on as the 'correct' behavior. Multiselect, as Ris mentions above, really isn't relevant - it has type ahead search and no arrow icon, so clicking in the input twice correctly leaves you in the input field and leaves the dropdown dropped. That's what should happen, and I can't really think of any argument for a different behavior. |
Beta Was this translation helpful? Give feedback.
-
Once more thing related to open-close behaviour with single select is the "keyboard" navigation: closed and focused native selects let you move up and down in options with the arrow by changing the selected item without opening the selection/dropdown window. As an intensive keyboad user I felt that feature missing when I moved our native selects to selectize.js. |
Beta Was this translation helpful? Give feedback.
-
When faced with an open dropdown, what is the expectation of the user that clicks the input control?
Following ticket #1261, this UX question emerged. I'm not sure which one is the right call. As of now, what Selectize does is it keeps it open (or rather, the mousedown closes it and mouseup opens it back up, so click yields a brief flash).
I've personally tried a few examples (Firefox url and search bars, Selectize, a vanilla select, Github dropdown menus), but still can't come up with a good rationale for one of the other. In all cases, it would probably be good to define that behavior more clearly.
Interested to hear different perspectives about this. (Maybe it's a good question for UI-UX StackExchange?)
Beta Was this translation helpful? Give feedback.
All reactions