Combobox (Unique Value): Research and ideation

[benjamin-kurien]

Research

• Explore other design systems and how they treat "combobox - custom value" interaction. Examples: Material, Spectrum, Ant, Atlassian, Polaris, Lightning, etc. Here is a Repo list of design systems too for reference.

• Look at internal IBM design patterns if they exist. Here are some good ways to do this. A good way to do this is to search the #carbon-design-system channel history to look at past threads around this topic. Also looking around in current products live sites. We have a boxnote listing out how to access some of these sites

• And checking out PAL sites to see if any of the PALs already have existing guidance around this

Design iterations

Iterate on possible design solutions for "combobox - custom value" interaction.

[tay1orjones]

It would be good to include the APG examples in the research

[grahamharper]

I'm currently working on an issue we've encountered with ComboBox relevant to this work.

ComboBox offers no suitable affordance to indicate values entered by typing will not be accepted.

Currently when you type into ComboBox, then blur the input, the entered text is cleared and it reverts to the previous value/state. I believe the intention of this was to indicate to the user that custom text was not allowed.

Now imagine a scenario where the ComboBox has a default selection. User enters some text that exactly matches another option in the list, but instead of moving focus away from the field—because maybe there are no more inputs in the form—they use their mouse to click the Submit button.

Combobox will blur, clear their entered text and revert to the default selection. This all happens faster than the user can perceive. Form submission validation won't catch it because the input has a valid selection, but nonetheless, the user has submitted a selection they did not intend.

Now, why might the user type text as their value instead of explicitly selecting an option from the list? Well, maybe they find that faster, maybe they're pasting text, using autofill, but also the input does not indicate in any way that values entered by typing will not be accepted.

There is no affordance to users when allowCustomValue is true or false.

I think an non-obvious way to improve the affordances for when custom text is allowed is to consider keeping the design of combobox as-is but changing the design for when custom text is not allowed.

For example, utilising more of a filterable select pattern which separates the UI showing the current selection from the input used to filter/search the options.

• The current selection is shown in the button that triggers the popup.
• The search/filter input is inside the popup.
• When the popup is closed, the search/filter text is discarded and the selection remains.

Here are two examples of this:

Chosen

GitHub

In these examples the state of the current selection is clearly distinguished from the search/filter text. A user is less likely to think that the text they have entered will be accepted as a value for the field.

[github-actions[bot]]

Thank you for submitting a feature request. Your proposal is open and will soon be triaged by the Carbon team.

If your proposal is accepted and the Carbon team has bandwidth they will take on the issue, or else request you or other volunteers from the community to work on this issue.