Chosen-like Functionality

[Xethron]

The Problem

The main problem I have with Selectize is, if you tab through your form, the Selectize will actually open when it gets focused. If nothing is selected, tabbing again will close the Selectize and remove focus altogether. Tabbing a third time would take you to the next element in the form. This means that you have to tab twice for every empty Selectize in your form.

This behavior is however not consistent if an option is selected. Once the Selectize receives focus, it opens as before, a second tab however closes it again, and a third tab, unlike before, re-opens it.
The only way to move to the next item in the form is to hit enter when the Selectize is open.

If however, you typed some text to filter the list, and then hit tab, it cancels the current selection and goes to the next item (no extra tab required). This causes a lot of people to have to go back, re-select, press enter, and then press tab to go to the next input.

This is not only confusing but requires more keystrokes than required and mental processing of different key combinations for different scenarios in a sometimes very specific order.

The second problem I have is, when the fields do need changing, you first need to hit backspace to delete all the text before you can start typing. The default behavior for a select is you simply start typing to filter down to the item you need. As Selectize does this differently, most users get confused.

The Solution

Lets take a quick look at the way Chosen handles this: http://harvesthq.github.io/chosen/

Once the select gains focus, it simply glows¹. Tabbing again, takes you to the next element in the form¹. If you start typing or click on it, it opens the select waiting for user input^{1 2}. Pressing Escape cancels the new select and reverts back to the old selection², and pressing enter/tab makes the selection¹.

I would go one step further here and say pressing tab should make the selection and go to the next item in the form as well. This is actually the default behavior for a native select and would come natural to most users.

¹ Similar behavior as a native HTML select.
² Improved behavior as a native HTML select.

Use Case

We currently use Selectize for a large system where data-capturing forms a large part of it.

The efficiency of the data captures are key, and removing a single second from small tasks, on a team of 150 data captures working 8 hours a day, could save hours for work time each day, drastically improving efficiency.

As for websites with customers and first time users, this will also feel a lot more natural, and does what you would expect.

[PhiLhoSoft]

I haven't tried, but perhaps setting the openOnFocus property to false might solve part of your problems.
But it comes with its own problems, which I plan to list (I do a search to see if they are already listed).

[arturgspb]

Hi @Xethron, @PhiLhoSoft ! I have a problem 2, users do not want to press the backspace to start the search. In addition, the backspace deletes the currently selected item, but it is not always acceptable. I found issue #181 with similar problem.

Time has passed since the last discussion of the problem. I wanted to ask - anybody found an elegant way to search without resetting the current element and without press backspace?

[joallard]

@Xethron thanks for this report. I'm currently investigating select-like behavior and what you say makes a lot of sense. For now, it looks like openOnFocus should answer part of your problems, and I will follow along to #783 for the rest.

I'll have to close this issue as I find it a little un-actionable. However, if you want to suggest more precise enhancements, you're most welcome to do it and refer to this issue which will be a great resource. But on the ideal that we should behave like a vanilla HTML select by default, I agree. Cheers