Combobox Improvements

[henrieri]

Hi team,

There's few improvements I'd like you to consider or to be discussed:

Basic Combobox

1. Right now when you click to select options it hints with cursor that you can edit the field, perhaps to search, however this is not true. You can't edit right now.
2. Regular html5 "select" when you type something there it will automatically choose the element that matches depending on what you type. For instance in a country dropdown, if you type "Est" it will place you at "Estonia". I feel like this is something that most people use when they want to get to knowable option very fast - otherwise finding your country can be very time-consuming. I could use auto-complete for that, but it seems like this feature should generally exist. Otherwise I'd use Select, but Select doesn't have as nice design.

Autocomplete Combobox

1. I would still like to see the dropdown arrow (chevron) there. I implemented the component for phone numbers list and users generally seemed to feel that there's an arrow missing, since it actually works similarly to select.
2. When I have already selected an item, when reopening it should show all items not only what is matching, since the intention is to probably change it. And only auto complete once again when user types something. Otherwise it might seem for user that there's actually only one option.
3. If there's no options, it shows completely empty. It would be nice to have some sort of default to show "There's no items matching your query." or similar.

Wish you the very best and thank you for your amazing work.

[SiTaggart]

Thanks @henrieri, this is some super useful feedback we'd like to consider when promoting the Combobox from Alpha. Some initial thoughts on each one of these points:

1. Right now when you click to select options it hints with cursor that you can edit the field, perhaps to search, however this is not true. You can't edit right now.

I see your point, but I am conflicted. The text cursor doesn't denote editing on the web platform, it simply denotes text selection (MDN). If you hover over text in this comment, you'll see the same cursor. It's the same with the readonly input, the cursor indicates I can select text from the value, but is unrelated to the editing state. It's maybe a little confusing though, so I do understand the concern, but something I'd be cautious of diverging from. Something we'll consider.

2. Regular html5 "select" when you type something there it will automatically choose the element that matches depending on what you type. For instance in a country dropdown, if you type "Est" it will place you at "Estonia". I feel like this is something that most people use when they want to get to knowable option very fast - otherwise finding your country can be very time-consuming. I could use auto-complete for that, but it seems like this feature should generally exist. Otherwise I'd use Select, but Select doesn't have as nice design.

Agree, it's a feature I wouldn't mind having.

1. I would still like to see the dropdown arrow (chevron) there. I implemented the component for phone numbers list and users generally seemed to feel that there's an arrow missing, since it actually works similarly to select.

We recently removed the chevron. I want to say it came up in a usability study, I'm not 100% sure though, but the reason is there was some confusion that with the chevron you couldn't type into the field. This detail will likely come out in the usability studies we do when promoting the component to Beta and Production.

2. When I have already selected an item, when reopening it should show all items not only what is matching, since the intention is to probably change it. And only auto complete once again when user types something. Otherwise it might seem for user that there's actually only one option.

I feel like you should be able to achieve this, but I need to investigate it. The filtering of the list is controllable by you, in our examples we filter the list onInputValueChange but it's not a requirement, just an example. There are a number of other event callbacks you can hook into, and even the full state object, where you should be able to create this desired behaviour.

3. If there's no options, it shows completely empty. It would be nice to have some sort of default to show "There's no items matching your query." or similar.

Empty states are pretty specific to use case and flow. We don't provide one, because there could be many valid reasons to do something different based on the user task trying to be completed. For example, in Console.Zen, they should a nice illustration and help text. So we leave this intentionally up to the consumer of the component as it's the most flexible option we could provide.

[henrieri]

I feel like you should be able to achieve this, but I need to investigate it. The filtering of the list is controllable by you, in our examples we filter the list onInputValueChange but it's not a requirement, just an example. There are a number of other event callbacks you can hook into, and even the full state object, where you should be able to create this desired behaviour.

I think it's achievable. I managed to do it, but it wasn't 100% straightforward, maybe there's a simpler way to do it than I did. But I think yes, maybe that's out of scope for Paste.
I think it would be great if in the documentation there were some guidelines on how to achieve it better or some guidelines for best practices. Because otherwise I feel like many developers might not consider the case after value is selected and user selects from the dropdown again and sees only one option, instead of all.

[henrieri]

We recently removed the chevron. I want to say it came up in a usability study, I'm not 100% sure though, but the reason is there was some confusion that with the chevron you couldn't type into the field. This detail will likely come out in the usability studies we do when promoting the component to Beta and Production.

Intuitively it makes sense for me to have a chevron there. I think "Combobox Select" should be handled a bit differently. Input should not perhaps be visible while you are selecting options, so there wouldn't be issues with the "text cursor" that I brought up before.
Looking at material UI for instance, the "Select" there hides the input, so it doesn't have that type of issue:
https://material-ui.com/components/selects/

And if you look at Autocomplete, it also has chevron.
https://material-ui.com/components/autocomplete/

Also with Material UI Autocomplete they seem to handle it by default having "no options" and also the way it resets autocomplete.

Not that Material UI is authoritative source, but this feels more natural at least to me.

[SiTaggart]

Yeah, I think all in all the examples we have on the site are limited and we're planning on adding a bunch more. So these are really useful additions we can add to the site when we get to it. @richbachman might be interested in this thread.

As for the blinking carrot in the input, there isn't a whole lot we can do with that, it is the correct accessible implementation for a combobox, it's just an unfortunate gap between HTML and ARIA and we suffer some minor inconveniences because of it, unfortunately.

Finally for the chevron, we'll be sure to factor that feedback and competitor analysis in when we do the next iteration of design work on Combobox. It is an alpha, so the level of design work in this iteration was very limited.

[henrieri]

@SiTaggart
Should we make combobox always be auto completable in this case? I don't see if there's anything to lose by that? In which case do we want this dropdown to not be auto completable?

If you look at examples here:
https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html
These are all mostly auto-completable.

However there's this one:
https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.0pattern/combobox-autocomplete-none.html

This isn't auto-completable, but you can still write your option there - although it is mentioned it's legacy and it doesn't seem to be that much of a good experience anyway, when you could just make it auto-completable - unless you want user to be able to input their own values. But in this case we maybe want "Create "what user has typed" option" to be an extra option in the list.

[SiTaggart]

Sometimes there is a need to basically have a nice looking html <select /> element where you can only select an option from the list of options. The only feature missing would then be the single key jump to in the listbox.

The options it gives us for the system then include:

• Select - html <select /> with excellent mobile device support
• Combobox - fancy looking Select with styled options, only valid options are accepted as a value, not as good mobile support
• Autocomplete Combobox - typeahead to search for option and any string can be a valid value, not as good mobile support

And these work in a kind of inheritance model, where Select is the basically the super class, inheriting as you go down the chain (or as close to as possible).