select2 v4 does not allow you to begin typing immediately on focus

1,898 views
Skip to first unread message

jms...@utah.gov

unread,
Jun 2, 2015, 5:32:05 PM6/2/15
to sel...@googlegroups.com
In the previous version of select2 (v3) you could tab to the select2 box and begin typing. This would pop open the select drop down and begin selecting based on the keys pressed.

In version 4.0 when you tab to the select2 (it has focus) when you begin typing nothing happens! You have to hit RETURN first then start typing.

On the select2 v4 examples page when you tab to the "tagging support" example or the "automatic tokenization" example you get the same behavior even though the design leads you to believe you can just begin typing.

This is huge slowdown from a UX perspective.

Anyone have any ideas how to get this behavior back in v4?

Kevin Brown

unread,
Jun 2, 2015, 10:26:53 PM6/2/15
to sel...@googlegroups.com
This is being tracked on GitHub at https://github.com/select2/select2/issues/3279, and the explanation for the change in behaviour in 4.0.0 is explained at https://github.com/select2/select2/issues/3279#issuecomment-96450069.

I am willing to entertain the idea of bringing this back in the form of search autofocus on the multiple selects, when the search box is displayed. That is being tracked at https://github.com/select2/select2/issues/3415, but alternative pull requests are encouraged.

Kevin Brown

--
You received this message because you are subscribed to the Google Groups "select2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to select2+u...@googlegroups.com.
To post to this group, send email to sel...@googlegroups.com.
Visit this group at http://groups.google.com/group/select2.
For more options, visit https://groups.google.com/d/optout.

jms...@utah.gov

unread,
Jun 3, 2015, 12:57:20 PM6/3/15
to sel...@googlegroups.com, jms...@utah.gov
I thought about just letting this thread die... but I think the devs on Select2 need to know...

These changes in v4 are UX dealbreakers. I am in the process of converting our project back to v3.

The user experience in v4 is quite frankly worse than using a built in single select box, which is in my opinion the whole reason for choosing select2.

The user should be able to tab to a single select or multiselect and quickly choose stuff then tab on the next field in the form. In v4 this is not happening.

FWIW

Kevin Brown

unread,
Jun 4, 2015, 9:44:30 PM6/4/15
to sel...@googlegroups.com, jms...@utah.gov
I definitely agree that the UX is worse when it comes to keyboard access in 4.0.0 (with this issue). I also would love to see a fix for this that doesn't restart the problem cycle we had before and have actually reopened the issue (forgot that I closed it) while we determine the best way to handle the issue.

Select2 is designed to be a replacement for select boxes, so if there is a poor user experience (when compared to standard select boxes) it's something we want to improve. We've addressed one UX issue in this thread so far, are there any others that may have been overlooked that might need to be addressed?

I've posted the key sequences for native selects as well as Select2 3.5.2 and 4.0.0 for selecting an option, which makes it very clear what the impact of this issue is. Right now this isn't as much of an issue for those using Select2 with a mouse, because clicking on the select will open it and automatically focus the search box. But for keyboard users, the keyboard is not opened until either the enter or space key is pressed. These keys were selected because they are the common keys for opening the dropdown and they did not conflict at all when doing accessibility testing.

And while writing this I thought of a possible partial solution.

What if the dropdown was automatically opened when the select was focused? In order to avoid breaking the standard tab order (as tab currently closes the dropdown), the tab key would also need to be intercepted such that it moves the focus to the next item when the dropdown is already opened.

This still wouldn't fix the UX issue if the dropdown is closed for some reason, but there is another partial solution there: Just opening the dropdown when any letter is pressed and the dropdown is closed. Keep in mind that this is step 1 in the cycle of events that caused this current UX issue.

Does anyone else have a recommendation for how the UX could be improved here?

Kevin Brown

Reply all
Reply to author
Forward
0 new messages