@devs - added this based on our quick convo, please update if not accurate.

Notes:

• I edited the wmde-alpha-deploy branch directly, see https://gitlab.com/wmde/mediawiki-extensions-VisualEditor/-/commit/c970b78788f6c775c757e5d3cf98fffd0bf91268.
• I followed T260773 to update the test instance.
• I updated a template to contain 100 suggested values. Go to https://en-wmde-templates-alpha.wmcloud.org/wiki/Testing_Soft_Validation?veaction=edit and edit the large template on the page.
• The ComboBoxInputWidget doesn't seem to do anything when filtering is disabled.
• The MenuSelectWidget (this is the dropdown part of the ComboBoxInputWidget) does have several configuration flags, e.g. highlightOnFilter and filterMode. But it looks like none of this does anything without filterFromInput, which we don't want because it's confusing.

Results:

1. Yes, it scrolls, but only when I type the exact string.
   • Nothing happens as long as my input is incomplete. No search, no highlight, no scroll.
   • filterMode is "prefix" by default, but this doesn't do anything when filtering is off.
2. In my opinion, both versions are bad, and both should be updated upstream.
   • When filtering is enabled, the dropdown should only be filtered as long as my input is incomplete.
   • The moment my input is complete, the item should be selected, and the filtering be undone. In other words: When an item is selected, the dropdown should show all other items as well and not do any filtering, even if filtering is enabled.
   • Without filtering, the list should always scroll to the first position that matches, but not select the item as long as my input is incomplete.
   • The filterMode configuration should work in this mode as well. For our use-case we might want to stick with the "prefix" default, but can play around with "substring" as well.

@thiemowmde Thanks for the helpful overview! Will review with @Lena_WMDE when she's back next week.

This was very helpful to be able to test them both out in detail. After looking into this and discussing quite a bit, it's clear that both combo boxes (with and without filtering) have room for improvement. Goal was to understand which is most useful without any changes, and what would be the ideal state for each. Then to decide our next steps.

@Volker_E I want to bring this discussion to your attention since it is about improving the OOUI component: ComboBoxInputWidget. Essentially, during usability testing the filtering worked very well for adding the first value. But then most users got confused and frustrated when they tried to change the selection but the dropdown had disappeared (it continues to filter, until the field is emptied). They could not figure out how to get the dropdown back.

With filtering
For our use-case, the filtering is pretty important because the values will be inputted by users and we have no way of knowing how long a list might be. It could be very long (for example, list of languages or countries).

The ideal behavior would match this combobox example from Vuetify. It matches OOUI behavior for the most part (filters based on input) but after a selection has been made, if you click back in the full list is shown with the item highlighted. If a custom value is put in, the full list is still shown but without any highlight. Another alternative would be including a clear button, shown with the 'clearable' option on the right. If we're able to do the first part though, I don't think this is necessary.

Without filtering

Without filtering, the list should always scroll to the first position that matches, but not select the item as long as my input is incomplete.

Agree that without filtering, this would be the ideal behavior. I think though effort would be better spent improving the filtering option. At the moment, the lack of filtering makes it easier to change an existing value but harder to input the first choice (which I think should be prioritized). It's a problem that users have to type the full item name without typos before it's confirmed if that value is part of the list.

Next steps
As decided with @Lena_WMDE :

• Use out of the box combobox with filtering component for MVP
• Plan improvement to the component (aligned with above ideal behavior) in future release. TBD if this is done as a one-off change just for the template dialog or if we coord with WMF to update the component upstream.

Adding one more comment here. Was going through open questions on https://phabricator.wikimedia.org/T260157#6402243 and saw that @thiemowmde noted one other piece of missing current behavior:

When typing and filtering the list, the first match should be highlighted (gray), which means it will be selected when pressing enter. This doesn't always work. A OOUI bug?

We should also consider if we want to add it in. I see it as a nice to have, while the above changes impact the functionality more signficiantly.

@ECohen_WMDE From a product perspective, I agree with the filtering being advantageous usability-wise, upstream!
Please also note T100876

Hey @Volker_E sorry I'm a bit late following up on this!

Please also note T100876

I think this ticket might be out of date. The combobox already allows filtering - the dropdown is the widget which requires an exact match to highlight.

What I outlined above are simply improvements to the filtering behavior since we found that it caused confusion during usability testing when trying to change the value (choosing the first value went very smoothly).

Sounds like you're on board with these changes being upstreamed, but just wanted to clarify that it would be improvements to the filtering not the creation of filtering. Happy to have a quick call to review if you'd like!

We're not planning to pick this up anytime soon, but just wanted to wrap up this investigation ticket and be clear on what our next steps would be if we have the bandwidth to take this on. Should I already create a ticket outlining the changes and just tag with OOUI?