Page MenuHomePhabricator

OOUI ComboBoxInputWidget (filtering on input) updates
Closed, ResolvedPublic5 Estimated Story Points

Description

Background

Follow up ticket from investigation: T271399: Investigation: OOUI Combobox widget behavior. This problem was confirmed yet again in multiple usability tests. The current component has been found to be very confusing when encountering a combobox with a value already inside (this was especially true of custom values). Users did not understand what the dropdown button did (with custom values nothing happens when clicking it and it appears broken). Many users did not figure out that they needed to clear the current value to see the other options.

Behavior should match this example of Vue component: https://vuetifyjs.com/en/components/combobox/#usage

Requirements

  • After a selection has been made, if the user clicks back in or clicks the expand button, the full list is shown with the selected item highlighted
  • After a custom value has been put in, if the user clicks back in or clicks the expand button, the full list is shown but with nothing highlighted.
  • Filtering still works in the same way when user is putting in initial value or starts typing again after clicking.

Mock

A few examples:

Filled, value from dropdown
filled.png (223×514 px, 6 KB)
Filled, value from dropdown, user returns and clicks on arrow button. Displays full list with highlight.
opened.png (223×514 px, 10 KB)
Filled, custom value, user returns and clicks in the text field. Displays full list, no highlight.
custom value.png (223×514 px, 9 KB)

Technical implementation

Technical requirements:
  • always show the list of all values on focus:
    • when there is no value,
    • an unknown value or
    • a known value (with highlight)
  • on blur hide list of values
  • on typing filter the list of all values
Implementation
  • in MenuSelectWidget.js (where ComboBoxInputWidget gets all the dropdown magic from)
  • we store the previous value of the menu in OO.ui.MenuSelectWidget.prototype.bindDocumentKeyPressListener
  • and compare with the current one in OO.ui.MenuSelectWidget.prototype.updateItemVisibility
    • if it matches we show all values
    • if not we filter the menu
  • to prevent the menu to show up during editing again (when the previous input might be entered again) we delete the storage

Outcome

click to play

Peek 2021-11-26 16-39.gif (466×918 px, 256 KB)

Event Timeline

ECohen_WMDE set the point value for this task to 5.
ECohen_WMDE renamed this task from OOUI Combobox updates to OOUI ComboBoxInputWidget (filtering on input) updates.Nov 17 2021, 3:44 PM
ECohen_WMDE updated the task description. (Show Details)

@Volker_E We think that these changes would be useful to upstream (the issues being solved came up frequently in testing as very confusing and would apply to other situations as well). Would like to discuss with you. Let me know if you'd prefer to do this in the ticket or elsewhere?

Change 742162 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[oojs/ui@master] [POC] Make MenuSelectWidget's \"filterFromInput\" easier to use

https://gerrit.wikimedia.org/r/742162

Change 742164 had a related patch set uploaded (by Svantje Lilienthal; author: Svantje Lilienthal):

[oojs/ui@master] [WIP] Show menu before filtering

https://gerrit.wikimedia.org/r/742164

Change 742164 abandoned by Svantje Lilienthal:

[oojs/ui@master] [WIP] Show menu before filtering

Reason:

duplicate with 742162

https://gerrit.wikimedia.org/r/742164

@ECohen_WMDE We could also use the the suffix search instead of the prefix search. Do we want that? It is already an option we can easily use.

Not sure I completely follow the task description and the problem statement here with the outlined improvements? The ComboboxWidget comes in different variants of interaction currently. Only the “filtering on input” doesn't show all values when input is already provided.
Rephrasing for myself, even if there's a value selected, focussing the input field or clicking the dropdown button would show all available options again, correct? With the selected one highlighted? As soon as keyboard input is provided the options list is filtered again?

@lilients_WMDE I don't think there is any reason to change the way the search is functioning as that was not the source of any issues. Please leave that as-is.

@Volker_E Exactly, this is only about the filtering version of the widget. I think the screencast Svantje added in the description shows the behavior well, F34770042. From your rephrasing, though, I think you've understood correctly.

I can try to re-describe the problem as well. After initial research on comboboxes, this seems to be the standard approach and what users were expecting in testing. They had a lot of trouble when coming across a combobox with a custom value already inside which they wanted to change. They would try clicking the dropdown button and then assumed something was broken when nothing happened. This was also true about changing an already selected value from the list. It took users awhile to figure out that they had to clear the content in order to see all the options again, with some never figuring it out and giving up.

Change 742162 merged by jenkins-bot:

[oojs/ui@master] Make MenuSelectWidget's \"filterFromInput\" mode easier to use

https://gerrit.wikimedia.org/r/742162

WMDE-Fisch moved this task from Demo to Done on the WMDE-TechWish-Sprint-2021-11-24 board.

Change 753557 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] Update OOUI to v0.43.0

https://gerrit.wikimedia.org/r/753557

Change 753557 merged by jenkins-bot:

[mediawiki/core@master] Update OOUI to v0.43.0

https://gerrit.wikimedia.org/r/753557