We had a instance of this recently, where a admin accidentally cleared the Newcomer Help-Panel because they had assumed that they had selected articles for it because the Lookup looked filled, but they did not actually interact with the menu.

From the discussion here and elsewhere, my intuitively preferred outcome would be a combination of "automatically highlight the first menu item to be selected on focus lost" + "Lookup looks different if 1) actively being edited without selection, 2) with selected item, 3) with input but no selected item and no focus anymore".

Thanks for looking into it here! I'd like to note that the preferred solution is likely to differ among various users of the component. For example, Special:Block represents pages as their IDs internally, which means it needs to use something in the input list. On the other hand, in the Growth case @Michael mentioned, Growth represents pages as string titles, meaning we can process inputs such as mw:Downloads as well. Special:Block is not interested in external titles (it isn't able to process them), but Growth is (we use them in certain cases).

So, maybe there should be a parameter to indicate whether suggestions are binding or informative, and let the component's user decide which behaviour is more appropriate for their use-case?

In T362650#10022328, @Urbanecm_WMF wrote:

Thanks for looking into it here! I'd like to note that the preferred solution is likely to differ among various users of the component. For example, Special:Block represents pages as their IDs internally, which means it needs to use something in the input list. On the other hand, in the Growth case @Michael mentioned, Growth represents pages as string titles, meaning we can process inputs such as mw:Downloads as well. Special:Block is not interested in external titles (it isn't able to process them), but Growth is (we use them in certain cases).

So, maybe there should be a parameter to indicate whether suggestions are binding or informative, and let the component's user decide which behaviour is more appropriate for their use-case?

It is a Lookup, so I'm not sure if adding support for setting the input as the selected value is a good idea to use the component as intended. Though, I wonder if we maybe can cover our use-case by introducing a synthetic first option that is "the current input" unless it exactly matched one of the looked-up options?

I've been exploring possible solutions to make non-valid entries in the Lookup clearer. We could solve this issue by using some existing solutions from our Codex components:

1. We could prevent users from entering non-valid text in the Lookup by displaying the "No results" within the Menu if the typed text doesn't match any preexisting result from the Lookup.
2. If the user still enters that non-valid value, we could show an error state within the Lookup (that is pending to be implemented in T363515) and display the existing error Inline Message within the Field component that includes the Lookup.
3. The clear button could be used to indicate that a value has been entered in the Lookup.

This solution could also address the issue flagged in T362657. If the user starts editing a selected result within the Lookup and enters that non-valid text, the Field and Lookup will display an error.

In case we agree with this solution, we should first implement the error state in Lookup in T363515: Include error state in Combobox, Lookup, and Radio components.

Thanks for investigating improvements!

In case it's helpful, the Growth team is also discussing improvements (since the current UX created an unexpected Community Configuration issue: T370941) . and we have editor feedback about what they expected from this field here: https://phabricator.wikimedia.org/T371228#10023642

That being said, the Community Configuration form is essentially meant only for very trusted editors so I can see how our preferred solution might differ slightly from the general use case.

@CCiufo-WMF - Will the engineering improvements associated with this task be complete by DST? If yes, can you provide an estimated timeline for when these Lookup UX improvements will be complete? (I'm trying to determine if Growth needs to make a fix on our side to ensure the Community Configuration form isn't responsible for generating more production errors).

In T362650#10033228, @bmartinezcalvo wrote:

I've been exploring possible solutions to make non-valid entries in the Lookup clearer. We could solve this issue by using some existing solutions from our Codex components:

1. We could prevent users from entering non-valid text in the Lookup by displaying the "No results" within the Menu if the typed text doesn't match any preexisting result from the Lookup.
2. If the user still enters that non-valid value, we could show an error state within the Lookup (that is pending to be implemented in T363515) and display the existing error Inline Message within the Field component that includes the Lookup.

This solution could also address the issue flagged in T362657. If the user starts editing a selected result within the Lookup and enters that non-valid text, the Field and Lookup will display an error.

In case we agree with this solution, we should first implement the error state in Lookup in T363515: Include error state in Combobox, Lookup, and Radio components.

@bmartinezcalvo would it be possible to include in your proposal something to improve the type+select process. how might we make it clearer that typing is not enough in the lookup, but that editors must select an option from the menu? would it be possible to find a solution that doesn't rely only on error messages, but that it improves the usability during use instead of after?

to give you a concrete example:

1. you focus the lookup field
2. you type "brussels sprouts"
3. you blur the lookup field (aka you escape focus, click outside/something else)
4. an error "This value doesn't match any result" is displayed, but you don't understand what's happening. you know that "brussels sprouts" is a valid entry.

beside displaying an error for invalid entries afterwards, what can we do when the entered text is valid (in theory) but invalid for the system (in practice) because the editor didn't click/touch the menu item? are there ways to make the component usage (visually/interactively/...) more explicit?

In T362650#10033805, @KStoller-WMF wrote:

@CCiufo-WMF - Will the engineering improvements associated with this task be complete by DST? If yes, can you provide an estimated timeline for when these Lookup UX improvements will be complete? (I'm trying to determine if Growth needs to make a fix on our side to ensure the Community Configuration form isn't responsible for generating more production errors).

I'll let @bmartinezcalvo provide an update for how to move forward with these tasks and continue explorations. In the meantime, I would recommend Growth incorporate the suggestions from T362650#10033228 even without T363515. The border color of the Lookup won't be correct, but all the other recommendations can be implemented with current Codex components/behavior to hopefully prevent these errors.

El T362650#10035527, @AAlhazwani-WMF escribió:

@bmartinezcalvo would it be possible to include in your proposal something to improve the type+select process. how might we make it clearer that typing is not enough in the lookup, but that editors must select an option from the menu? would it be possible to find a solution that doesn't rely only on error messages, but that it improves the usability during use instead of after?

to give you a concrete example:

1. you focus the lookup field
2. you type "brussels sprouts"
3. you blur the lookup field (aka you escape focus, click outside/something else)
4. an error "This value doesn't match any result" is displayed, but you don't understand what's happening. you know that "brussels sprouts" is a valid entry.

beside displaying an error for invalid entries afterwards, what can we do when the entered text is valid (in theory) but invalid for the system (in practice) because the editor didn't click/touch the menu item? are there ways to make the component usage (visually/interactively/...) more explicit?

A possible solution could be to focus on a matching result in the menu if the typed text matches that result. While this result may not be selected if the user clicks outside the menu, it could at least be highlighted.

In T362650#10036335, @bmartinezcalvo wrote:

A possible solution could be to focus on a matching result in the menu if the typed text matches that result. While this result may not be selected if the user clicks outside the menu, it could at least be highlighted.

That should be easy to implement, we already have code that checks whether the typed text matches the selected menu item for other reasons, that could be extended to check whether the typed text matches any menu item pretty easily.

As decided during the DST Sprint Planning, we need to include the error in Lookup to solve this task. So moving this task outside the sprint. We will come back to this task once we complete T363515: Include error state in Combobox, Lookup, and Radio components.

This task is ready for development, so moving it to Up Next.

After exploring more how to solve the Lookup usability issues listed in this task, here are additional solutions:

1. Auto-selection for exact matches: When the text entered in the Lookup perfectly matches a menu result, that option could be automatically selected.
2. Warning for non-selected item: If no item from the menu is selected and a text typed in the input is entered, a warning Inline Message will automatically appear within the Field containing the Lookup, alerting the user that no result was selected from the menu. Once the field validation is completed, the warning will turn into an error.
3. "No results" in menu: When the input doesn’t match any result from the menu, a "No results" message will be displayed in the menu to prevent errors. If the user enters an unmatched value, the same process described in bullet 2 will be followed. A warning message will appear when non-validated, and an error message will appear once validated.

Next steps:

1. Implement the automatic selection when the text typed in Lookup matches with one result T376466
2. Since these Inline Messages are shown only in the Field component (not in the Lookup itself), we'll need to update the Lookup guidelines to clarify this. Additionally, we will include a new demo in the Lookup pages to represent the non-valid entries T376628.
3. If this is the desired behavior for the Lookup component, I would follow the same approach in Combobox, as it includes the same issues with non-valid entries.

@bmartinezcalvo are you planning to update the guideline for next steps #2 in this task?

Change #1078378 had a related patch set uploaded (by Bmartinezcalvo; author: Bmartinezcalvo):

[design/codex@main] docs: update Lookup guidelines

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

Change #1078430 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] Lookup: Add warning message to field demo

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

Change #1078378 merged by jenkins-bot:

[design/codex@main] docs: update Lookup guidelines

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

Change #1078977 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] docs: Add error and warning messages to MultiselectLookupField

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

Change #1078430 merged by jenkins-bot:

[design/codex@main] docs: Add error and warning messages to LookupField

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

Retroactively accounting for this ending up requiring some eng time.

Change #1078977 merged by jenkins-bot:

[design/codex@main] docs: Add error and warning messages to MultiselectLookupField

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

Change #1080747 had a related patch set uploaded (by LWatson; author: LWatson):

[mediawiki/core@master] Update Codex from v1.13.1 to v1.14.0

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

Test wiki created on Patch demo by LWatson-WMF using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/ff2c211f43/wiki/Main Page

Change #1080747 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v1.13.1 to v1.14.0

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