[EuiComboBox] Improve changing selection by highlighting current text

[mdefazio]

Describe the solution you'd like
When changing options in the combobox with only single selection available, the current option should be highlighted so I can start typing the new option.

CleanShot.2024-09-25.at.15.26.09.mp4

Happy to discuss some alternatives or pushback on this. I acknowledge that using the keyboard to select all is easy here. But it does trip folks up for a second when interacting with this component.

Desired timeline
This occurs on the add field mappings flows, and these have a lot of focus within the company at the moment.

[JasonStoltz]

@mdefazio Is what you describe a standard behavior for combo boxes?

[JasonStoltz]

It seems to me the solution here is to highlight the current text when focused. If you focus the combobox by tabbing to it, currently, it does work that way. So in this case, we'd be changing it so that any focus event highlights the text, including a click.

This behavior can be seen in Material UI: https://mui.com/material-ui/react-autocomplete/#combo-box

Does this make sense?

mui.mp4

But it does trip folks up for a second when interacting with this component

Can you provide any additional context or evidence here?

[cee-chen]

My (very) informal 2c: I would personally hate this UX as a user, although in general I just hate my mouse being hijacked 😅

Just throwing out another scenario that this would add friction for: let's say I started typing to search, made a small typo, tabbed away to google the correct spelling (which causes the combo box to lose focus) and tabbed back and wanted to insert a character in the middle of my typo - I'd be super annoyed that I couldn't do so and my click is getting hijacked.

I also worry it might be an accessibility concern(?), although that's maybe an unfounded concern. It is worth noting that W3's combobox patterns does not include this UX: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-both/

[mdefazio]

It seems to me the solution here is to highlight the current text when focused.

Yes. I think this is correct.

Can you provide any additional context or evidence here?

We've noticed folks reviewing our semantic text mapping flows consistently getting tripped up on this. I can't speak to this happening in more places with similar frustration though.

I'd be super annoyed that I couldn't do so and my click is getting hijacked.

Not sure I follow here. If the text is simply highlighted when clicking into it, using the arrow keys to fix your typo would still work and I could fix the typo. Right? I would also say that typing halfway, then googling a correct spelling before completing is more of an edge case than a common scenario.

I'm not sure how to go about seeing if the current way is more ideal for other situations. Happy to explore other component options as well. This usage just exposes this UX nuance moreso through a repetitive action (adding multiple fields) and having to constantly select all the text first.

[cee-chen]

If the text is simply highlighted when clicking into it, using the arrow keys to fix your typo would still work

To clarify I meant clicking to a specific character while typing, not using arrow keys to get to where I want. I'm kind of an oddball user in terms of mouse UX though (I click a lot, everywhere, almost at random) so I'm not necessarily the most common use case here. Definitely agreed that more data/research would help!

[mdefazio]

Following up on as I wasn't sure if we were all on the same page...

Is what you describe a standard behavior for combo boxes?

I think so. Maybe more 'common' than 'standard'.

It seems to me the solution here is to highlight the current text when focused. If you focus the combobox by tabbing to it, currently, it does work that way. So in this case, we'd be changing it so that any focus event highlights the text, including a click.

Confirmed. This is my expectation as well.

Do we think it's worthwhile to go through the various usages in Kibana to see what this would change? I'm happy to help here, but I don't know how to go about this portion of work.

If we are simply highlighting the text as shown in @JasonStoltz 's example, do we feel this is a concerning enough change to do that audit?

[MichaelMarcialis]

FWIW, I'll drop my two-cents here. In either direction (highlight or no-highlight on mouse focus), there will always exist a scenario where it isn't ideal. If the experience the combo box is embedded within leans more toward users typing new strings every time they interact with the combobox (ex. searching or typing a custom value), then having the highlight would be more efficient. On the other hand, if the experience leans more towards a situation where the user is more likely to make minor edits to an existing string (ex. URL or IP address), then not having the highlight would be more efficient.

In all honesty, the combo box component is used in so many places across Kibana, I'd hesitate to presume that one case is more common than the other. We could of course consider the possibility of making the focus behavior a prop on the combo box component that could be toggled on/off depending on the context it is used. However, I would have concerns about that sort of approach as well, as it would introduce a behavioral inconsistency with no affordance provided for the user.

As @JasonStoltz mentions above, the current EUI combo box honors the default browser behavior by either A) highlighting the string of text on keyboard focus, or B) placing a text cursor at the position specified on mouse focus. In looking at other design systems, I'm seeing examples in both directions, with no one clear winning pattern. Given the hazy nature of the topic, I'm personally inclined to keep it the way it currently operates as it honors default browser behavior. However, if there is compelling evidence that combo box usage across all of Kibana is better suited to always highlight the full text string on mouse focus (in addition to the semantic text mapping flows already mentioned), I could certainly be persuaded otherwise.

[JasonStoltz]

The verdict appears to be that without compelling evidence to suggest that one approach is better than another, we will leave this component as is.

For that reason, I am closing this issue. If someone brings a strong case for this change, we are happy to reopen this issue and reconsider.

[mdefazio]

Can we clarify this a bit more?:

As @JasonStoltz mentions above, the current EUI combo box honors the default browser behavior by either A) highlighting the string of text on keyboard focus, or B) placing a text cursor at the position specified on mouse focus.

Where does this component honor the default behavior of highlighting the string on focus? This was the expected behavior originally, so if i'm missing a way to implement this, let me know.

How is that this honors both of those scenarios? Seems to me it's a one or the other for how we handle focus? Am I misunderstanding you @MichaelMarcialis

[MichaelMarcialis]

Where does this component honor the default behavior of highlighting the string on focus? This was the expected behavior originally, so if i'm missing a way to implement this, let me know.

Highlighting a full string of text on keyboard focus and placing a text cursor at the position specified on mouse focus is default browser HTML input element behavior.

How is that this honors both of those scenarios? Seems to me it's a one or the other for how we handle focus? Am I misunderstanding you @MichaelMarcialis

Not sure I'm understanding here. Mind elaborating? I'm just saying that the behavior is different depending on whether a user is tab focusing or mouse focusing the element.

[mdefazio]

Highlighting a full string of text on keyboard focus and placing a text cursor at the position specified on mouse focus is default browser HTML input element behavior.

Ah, I see your point. Ignore my last comment then.

---

So maybe this will help bring context to where I'm at and you all can correct me on any of these points:

1. We have a list of specific items that the user should be able to select from. It's a long enough list that searching is necessary
2. We do not allow the user to enter new / custom items into this list. Basically a select field, but with search
3. The recommended component here is the Combobox because it provides that searching capability

If we take two of the most common scenarios in Kibana, selecting a Data view and selecting a field type, we have two different experiences:

Selecting a Data View
EuiSelectable in a popover (right?)

• Same criteria as listed above (single select, no custom options, must have search)
• We do not allow the user to drop the cursor into a specific spot and change the string.
• We do no prefill the current option in the search bar
• Needs to start typing from the beginning for each search

CleanShot.2024-10-17.at.12.30.28.mp4

And the same page, but without the extra affordances of creating a new one, switching language, etc.
https://github.com/user-attachments/assets/d29de0ba-3682-4b69-8636-bc001f8c79f5

For both of these, we force the user to do an extra click or tab into the search bar and retype (without pre-filling the current option—so I have to start fresh if I only want to change a portion)

Selecting a field type
Combobox with single select and no custom options allowed
(And the use case I'm also leaning into for this change)

When setting up filters, and I click into the field dropdown, my expectation (and behavior) is that I am replacing the entire string with my selection. (I'm not placing my cursor and appending my selection. So it seems to me that clicking into this dropdown should have the same behavior as tabbing into it, since my expectation is that i'm replacing my selection with a new one.

CleanShot.2024-10-17.at.12.54.48.mp4

---

The experience with these should be different than a simple search bar showing results. Here, I absolutely want to put the cursor where I clicked and update my search term.

CleanShot.2024-10-17.at.12.41.03.mp4

---

Yes, this change making the mouse interaction match the keyboard interaction would effect an incredibly wide usage in Kibana. But I think this is the expected behavior for these instances (specifically selecting a field type).

[MichaelMarcialis]

Thanks for that context, @mdefazio! I agree with you that when the EuiComboBox is configured in a way that 1) only allows a single selection and 2) doesn't support custom options, changing the mouse focus behavior to highlight the entire string would be a better user experience. However, EuiComboBox components are not always configured this way across Kibana. In fact, I would assume that's a minority use case for this component, as EuiSelect and EuiSuperSelect are probably more widely used in those cases. Where I get concerned about changing the current behavior is when the EuiComboBox component is configured to support multi-selection or custom values (which I assume represent the majority cases with this component).

So how do we proceed? I imagine we can take one of three possible directions:

1. Do nothing and continue operating as we do today, with the focus behavior mirroring HTML input elements.
2. Change the mouse focus behavior for all EuiComboBox components (regardless of configuration) and risk adversely affecting the assumed majority use case.
3. Conditionally change the mouse focus behavior when the EuiComboBox component is configured to use single select with no custom options (in which case, it always highlights the full string on mouse focus). The only concern here would be possible confusion over inconsistency in behavior within the same component, but I imagine that's not a huge risk.

Personally I lean more towards options 1 and 3, but curious to hear what ya'll think.

[mdefazio]

@MichaelMarcialis Thanks for summarizing those options.

Obvs...my choice is 3. But maybe there's an option 4 (which you elude to...)

The need here is to have a single select dropdown with search, so perhaps improving EuiSuperSelect to allow for search and we can just bake this UX into that component? And then removing the option for single select in EuiComboBox. Might help clarify the choice between these components? (Ref: #7049)

[MichaelMarcialis]

This fourth option you describe would indeed be interesting. Since you mentioned that the list of selectable options you need to support is long, does that mean virtualization is required as well? If so, that may be a determining factor, as I don't think EuiSuperSelect supports virtualization (while EuiComboBox does). If that is indeed the case, I'm guessing that option three (conditional behavior on EuiComboBox) is the way to go. If not, I would defer to @elastic/eui-team to determine which of the two directions would be preferable.

As a side note, I'd personally love to see our number of selector components reduced from three (EuiSelect, EuiSuperSelect, EuiComboBox) to one at some point if possible. It feels unnecessary to maintain three separate components that largely perform the same or similar actions for different situations. It would be nice to have one that can be configured as necessary and not have to point designers/developers to documentation in order to guide them on which component to use and when.

[JasonStoltz]

Alright, so we took this offline and discuss. The conclusion is this:

We're not totally aligned that this is a change we want to apply across the board yet.

@cee-chen Will provide @mdefazio a snippet to allow him to apply this behavior to just this one particular flow, as it is especially important in this use case.

@mdefazio Will ask the dev team to include a link to this issue in a comment in code to track this behavior as a one-off.

In the future, or after some validation on Michael and team's side, we may choose to adopt this as a supported behavior for Combobox.

In the meantime, I will move this issue to a discussion. We will re-open it as an issue if we decide to adopt it into the backlog as a feature to add.

@MichaelMarcialis @mdefazio @cee-chen Can ya'll drop a 👍 on this issue if you agree?