Change 936066 merged by jenkins-bot:

[design/codex@main] FilterChipInput: Add variant with separate input

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

Change 939386 had a related patch set uploaded (by Jforrester; author: Eric Gardner):

[mediawiki/core@master] Update Codex from v0.14.0 to v0.15.0

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

Change 939386 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.14.0 to v0.15.0

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

Due to the discussions on how to make FilterChips editable, how should we proceed? Moving to next sprint? cc: @CCiufo-WMF

In T337095#9061879, @Volker_E wrote:

Due to the discussions on how to make FilterChips editable, how should we proceed? Moving to next sprint? cc: @CCiufo-WMF

@Volker_E the editable FilterChip is being discussed in this other task T341970: FilterChip: Evaluate need for a selectable/editable/open state

I would like to suggest a new open question. On Wikifunctions, we use a very similar component for letting editors add multiple name aliases to a function.

What we noticed during the initial roll-out and testing is that it's not immediately clear that in order to submit a FilterChip in the FilterChipInput people have to press the enter/return key on their keyboard. More details on T326304.

That's why we added a temporary helper text below the FilterChipInput, but we would be more than happy to adopt any standard Codex might suggest.

Some of the ideas we briefly touched one during a design meeting are:

• Have a FilterChipInput placeholder that explicit this, thou it might be not clear for an input with pre-existing FilterChips?
• Add an helper text when using the FilterChipInput inside a Field component?
• Turn text into a FilterChip when moving focus, thou it might be not clear what to do with multiple spaced words?

@AAlhazwani-WMF thank you for flagging this. I view 4 possible options to solve this:

• Op.1: we could use the input's placeholder to explain that user needs to press ENTER (as you comment above)
• Op.2: we could use the Field’s helper text to explain that user needs to press ENTER (as you comment above)
• Op.3: we could just display the error state if the text was not submitted, indicating that user needs to press ENTER to submit it
• Op.4: text could turn into a FilterChip when moving focus (as you comment above)

I've prepared these proposals explaining how the FilterChipInput would be displayed on 1. Default state, 2. Focus-active, 3. If user clicks or moves the focus outside the input.

Anyway, I would use the placeholder to indicate the user that they need to type the alias there. @AnneT the placeholder is missing in the Codex demo, could we include it as prop as we have in other components such as TextInput?

@bmartinezcalvo I can add placeholder to the configurable demo

That said, I would recommend against using placeholder to explain the fundamental interactivity of the input. It should be used to give a hint to the kinds of values that are expected. I think the Wikifunctions user testing points to a pretty significant usability issue for this component, and we should not expect users of the component to add help text to fix this.

What about adding an "Add" button, similar to search input, that adds a new chip with the current input value? That would provide a clear way to add chips, while still allowing for enter keypresses for more experienced users.

In T337095#9064026, @AnneT wrote:

What about adding an "Add" button, similar to search input, that adds a new chip with the current input value? That would provide a clear way to add chips, while still allowing for enter keypresses for more experienced users.

I think @Volker_E mentioned this approach too in the design meeting chat, but I forgot to include that suggestion in my comment above. Thanks Anne!

I'm having a hard time picturing the "add" button when the chips remain in the input after being created. Does someone have an example of this in a different library/product? In practice, I only recall seeing an explicit "add" button for chip input type patterns when the chips do not remain in the input field once submitted. In those cases, the chips are usually populated below the input field, and the input is exclusively used to add 1 new chip (either by pressing the input submit button or hitting the enter key).

I feel like I've almost always seen some form of dropdown menu to signal adding a chip when the chips stay within the input after they are added/created (like this). That being said, autocomplete might not always be desired, and this same library has an example of what we currently have implemented + the placeholder proposal discussed above.

Either way, I think we should consider this going back into design exploration. I'm going to move it out of this sprint board for now, which I'm planning to archive.

In T337095#9064573, @CCiufo-WMF wrote:

[...] and this same library has an example of what we currently have implemented + the placeholder proposal discussed above.

What I also find working well from this example is that when users move their focus, the text (no matter if it's a single word or multi-word) is automatically turned into chip, gif attached below.

After T343474 and T343479 are done, we'll be ready to move this component out of WIP, then put this task in Pending release, and close it after the release.

There are a few more things needed before this component can be released:

• Consider renaming it, now that we are not releasing FilterChip
• Remove FilterChip from the Figma library and the docs site
• Add basic accessibility support (T344849)

cc @bmartinezcalvo

In T337095#9127035, @AnneT wrote:

There are a few more things needed before this component can be released:

• Consider renaming it, now that we are not releasing FilterChip
• Remove FilterChip from the Figma library and the docs site
• Add basic accessibility support (T344849)

cc @bmartinezcalvo

Removed the FilterChip spec sheet from the Figma library. I will rename the FilterChipInput component once we decide the new name.

awesome, thanks @bmartinezcalvo!!

some more feedback from the wikifunctions community about the chip input component, cc @bmartinezcalvo

• I don't know how to expect the keyboard to work (how do you finish adding one and start adding another? space? tab? enter? how do I remove one? backspace? shift-tab to the x? how do I edit one? can I just move the arrow key into it or do I have to shift-tab? can I even edit it? will it even work properly via the keyboard?)
• they're very likely to interfere with what I'm used to being able to do in input fields in some way or another
• it's not obvious whether you can edit existing values at all, let alone how
• the position of the x being dependent on the length of the text means it's in an unpredictable position on the screen, which ruins any sort of muscle memory you might have when using a mouse or touchscreen, you have to see where the x is before you can aim for it, and removing one repositions all the ones after it which makes removing more than one even harder

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

[design/codex@main] ChipInput: Release MVP component

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

Change 955766 merged by jenkins-bot:

[design/codex@main] ChipInput: Release MVP component

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

@bmartinezcalvo how should the chips behave when the input is readonly? Should they look the same, but not be clickable or show any interactive styles?

We can easily increase the space between the chips to 8px; it's set to 4px right now. Can you help me understand what you mean about the maximum behavior?

In T337095#9156570, @AnneT wrote:

@bmartinezcalvo how should the chips behave when the input is readonly? Should they look the same, but not be clickable or show any interactive styles?

@AnneT I think the best solution is to do the same as we are doing with TextInput, where we use the read-only style just in the input background's color, leaving the rest as it is. You can check the "States" section in the Figma spec to inspect the styles used.

We can easily increase the space between the chips to 8px; it's set to 4px right now. Can you help me understand what you mean about the maximum behavior?

@AnneT no, I meant to increase the chip's maximum to occupy the entire available space within the ChipInput (purple color in this image):

Ahh gotcha, thanks for clarifying! I think the only way we could reasonably change the behavior there is if we decrease the max-width of the individual chips. It's currently set to @size-3200. Decreasing it would mean that chips are more likely to appear on the same line, but would also cut off more text for very long chips. What do you think? I'm personally on the side of leaving the max-width as-is; the way the chips stack in the input completely depends on the content of all the chips, which will vary so much that I don't think it's worth trying to predict for it.

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

[design/codex@main] styles, ChipInput: Increase gap between chips

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

Change 956473 merged by jenkins-bot:

[design/codex@main] styles, ChipInput: Increase gap between chips

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

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

[design/codex@main] ChipInput: Implement read-only state

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

Signifying readonly visually and then having ability to interact (remove) FilterChips is contradictory in my opinion and we should limit the readonly ChipInput to FilterChips without remove button only.

Since adding read-only is escalating in complexity, I've moved it to its own task (T346113), so that we can close this task.

Change 956973 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/core@master] Update Codex from v0.18.0 to v0.19.0

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

Change 956973 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.18.0 to v0.19.0

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