Combo box - Use case adaptation

[cdpestitschek]

Component: Multiselect Combobox with max height

I would like to improve or adapt the combo box to cover a massive use case. In the use case of selecting a list of representatives/agents we have the selection of a massive number, and considering the example bellow it would not be the best experience so far.

I would like to propose something to provide or verify the possibility of improvising where we could have a better experience in our context of use, where there is a massive selection of a number of items from the list.

Eg. Having the first selection name +2...30

Benchmark example - Google flights filter
!

PS: This truncation would not be a problem because we would have the list explained below with the selected names. YOu can check the example bellow how it would look:

1. Having the "first representative name +"

or
2) Having the "+ Representatives"
![Group 1367]

And another question about "select all". Could we support one of the itens with a switch? or should I have an item as a "select all"?
![Group 1375]

Or the Paste team has any other recommendation?

[loreina]

Hey @cdpestitschek, the team will discuss this and get back to you very soon. Thanks for your patience!

[loreina]

Hi @cdpestitschek,

It seems like you're looking for an added feature to show # of selected options without pills and to select all options.

For showing the # of selected options, this was a consideration we had while building the Multiselect Combobox though it was left out of scope. We encourage your team to file a dependency request so our team can prioritize the feature in our backlog.

For a "select all" feature, placing a switch inside the combobox to "select all" isn't accessible as it wouldn't be possible to focus on the element. I suggest making the first option in the list to have "select all" text instead.

Let us know if you have any further questions. :)

[serifluous]

@cdpestitschek Digging into this more, when you say "not the best experience", do you mean that it's easier for customers to scroll through a vertical list of options than the pills, or because it's not ideal to have the input grow in size with more pills added to it?

One thing to keep in mind is that the Combobox options list also doesn't float selected items to the top like you've shown in the images you shared. The representatives' names would stay in the same position in the list regardless of whether they're selected or not.

I added a ticket to our backlog for us to do a design iteration on this: https://issues.corp.twilio.com/browse/DSYS-3799 Would love to hear more context about the experience issues, though! That'll help us figure out timing + level of effort on this. Feel free to share more here, or if it's easier to talk through it, through office hours.

[serifluous]

@cdpestitschek Nudge here, can you share an answer to this so we can estimate the work to do this?

[cdpestitschek]

Hi @serifluous,

Scenario: We are creating a data visualisation page.

Grow in size with more pills added is one of the problem, because the size of the components that will accommodate them.

Currently we do not have the selection team of representatives. So, for example, if the supervisor wants to understand how the team is performing, he has to select 30-40 representatives. (so it would be 40 names + surnames). Visually the combo box would be bigger than the graph itself.

Not the best experience.
Doesn't float selected items - This is something that could be considered? This would greatly help in the findability of the selected options.

[serifluous]

Hey @cdpestitschek , totally understand the concern with having combobox grow in size!

We could be able to update our pills so they can batch selections (e.g., show "+3 representatives"). However having the selections in the list float to the top wouldn't be doable in our component by default. Having the items stay where they are was an intentional decision so users knew where items were in the list if the ordering was predictable (like, alphabetical ordering). We also support groups in the list, and having the list items move to the top would make it less clear which groups items belonged to.

But! If you do need both behaviors (pill batching + selected items appearing at the top), which I agree need to be paired for the experience reason you already mentioned, an alternate option could be moving the selection and filtering experience to a Side Modal, like @Fazle-Jahangir shared an example of here: #2338, and using the Listbox Primitive to build the behavior for the selected items. This could be somewhat similar to the Call Transfer UI in Flex.

Let me know if you have questions about that suggestion, and what you decide on for a solution.