I believe @bmartinezcalvo is providing feedback on this. I'll backlog for now until we have actionable next steps.

El T362650#9749861, @CCiufo-WMF escribió:

I believe @bmartinezcalvo is providing feedback on this. I'll backlog for now until we have actionable next steps.

I provided feedback to @AAlhazwani-WMF in a previous Design Review and also async. We discussed finding alternative solutions using the available props of Field and Menu, to avoid updating the Lookup at first instance. What is the status of this @AAlhazwani-WMF ?

In T362650#9752856, @bmartinezcalvo wrote:

El T362650#9749861, @CCiufo-WMF escribió:

I believe @bmartinezcalvo is providing feedback on this. I'll backlog for now until we have actionable next steps.

I provided feedback to @AAlhazwani-WMF in a previous Design Review and also async. We discussed finding alternative solutions using the available props of Field and Menu, to avoid updating the Lookup at first instance. What is the status of this @AAlhazwani-WMF ?

@bmartinezcalvo we've tried out your suggestion but i'm afraid that given that we display a menu header on focus, people might have a hard time noticing the change of wording once they start typing. i'd like to find a solution that doesn't rely on additional messaging if possible, i'm wondering if a different visual and interaction treatment might make things clearer without the need of additional helper text.

similarly to the clearing strategy, i think that the lookup component might benefit of a visual treatment and interaction similar to how you enter an email in gmail. i'll try to describe step by step the experience of use. for our own case, it doesn't have to be exactly like this, or it doesn't have to use a filter chip.

as you type in the (lookup) field, gmail displays relevant search results. this is similar to the codex lookup.

gmail	lookup

if you enter a non-valid email, the provided text gets a clear visual treatment that something is off. in the case of the lookup, when you provide a non-valid entry the text looks as if the entry is valid.

gmail	lookup

if you select a result from the list (or if you escape focus) gmail turns any valid entry/selection into an "immutable" item, making it clear that a selection has been made, while in the codex lookup the selected item looks like plain text, and during usability sessions we observed people confused about it, they weren't sure if their selection was successful. this is especially true when you edit a page where a lookup is already pre-filled. a pre-filled lookup field looks exactly like an input field.

gmail	lookup

This issue does feel very closely related to T362657. I think we do need to explore the user story of "As a user interacting with a page that uses the Lookup component, it is clear that one of the predefined options must be selected and when the current value in the Lookup does or does not match one of the predefined values in the list".

Some approches to solve this, based on @AAlhazwani-WMF's suggestions could be:

• Have a distinct visual treatment to the Lookup when the current value does match one of the predefined values which looks different from just text in a TextInput (maybe more similar to the design of ChipInput).
• Have a distinct visual treatment to the Lookup when the current value does not match one of the predefined values but the user is not trying to submit the value (different from an 'error' state).
• Add an error state for when the value in the Lookup does not match one of the predefined values and the user is trying to submit the value (T363515).

just as food for thoughts. i was playing around with the template feature, and they have a couple of interaction patterns that might be interesting for the "search (type) + select" pattern.

when you start typing, the component auto selects the first valid match in the menu (highlighted by light grey background), meaning that if you escape focus (eg. via the tab key) or if you click on the "add" button it automatically picks the first match, without the need to click on a specific menu item to provide a valid entry.

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

just as food for thoughts. i was playing around with the template feature, and they have a couple of interaction patterns that might be interesting for the "search (type) + select" pattern.

when you start typing, the component auto selects the first valid match in the menu (highlighted by light grey background), meaning that if you escape focus (eg. via the tab key) or if you click on the "add" button it automatically picks the first match, without the need to click on a specific menu item to provide a valid entry.

@AAlhazwani-WMF this sounds like a reasonable solution. We could include a prop in the Lookup to show/hide the button (as we have in SearchInput) so it can be used in those cases where the selection is an issue.