## Background goal
NOTE: this task is blocked by {T363515}. Once we complete it, we will solve this one.
We need to solve some usability issues in Lookup:
##### Issue 1: "search (type) + select" pattern
During a couple of usability sessions, we observed that it's not immediately clear to editors that they **must** select a result (aka menu item) from the menu to submit a valid (lookup) entry.
What we observed is the following:
- they click on the lookup to focus the field
- they type a query, eg. "string", then
- they move to the next field in the form (via click or tab navigation), without selecting a "valid" query result from the menu, eg. "String"
The lookup looks filled, but it's a non-valid entry, meaning that on form submission the entry is not recorded. When we prompted editors with an error, some didn't understand what was going on, because the lookup look filled.
{F56916596}
##### Issue 2: clearing strategy of initial value
During usability studies we observed that when a lookup field is pre-filled, it's not immediately clear to editors that the initial value is something that has been pre-selected from a defined list of values. the issue seems to be related by the visual appearance of text in a lookup, which looks exactly like text in a text input component.
When editors try to edit this field, the experience is similar to editing text in a text field, but as soon as you remove one character from the text in the lookup, that entry becomes immediately invalid because it has been not selected from the menu.
{F56916593}
##### Issue 3: type+select process
We need 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?
to give you a concrete example:
1. you focus the lookup field
2. you type "potato"
3. you escape focus from the Lookup, click outside/something else
4. the "potato" value is entered, but no result from the menu was selected so the entered value is non-valid
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?
{F56916606}
---
### Proposed solutions
##### Issue 1 solution
We could solve the issues related with non-valid entries 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 [[ https://doc.wikimedia.org/codex/main/components/demos/lookup.html#clearable-with-start-icon-1 | clear button ]] could be used to indicate that a value has been entered in the Lookup.
{F56829684}
##### Issue 2 solution
The previous solution could also solve the non-valid entry when editing a selected result. 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.
{F56829714}
NOTE: We should implement first the error in Lookup to solve these issues {T363515}.
##### Issue 3 solution
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. This solution 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.
---
### Acceptance criteria (or Done)
[] Indicate with an `error` when the entry within the Lookup is non-valid
[] The Field containing the Lookup displays the error Inline Message
[] The Lookup input uses the error state {T363515}