Page MenuHomePhabricator

ChipInput: Explore improvements to add new chips
Open, Needs TriagePublic

Assigned To
None
Authored By
CCiufo-WMF
Sep 13 2023, 9:23 PM
Referenced Files
F41548710: CleanShot 2023-11-30 at 14.52.19.gif
Nov 30 2023, 1:53 PM
F41548697: image.png
Nov 30 2023, 1:53 PM
F41545808: Captura de pantalla 2023-11-29 a las 12.39.11.png
Nov 29 2023, 11:44 AM
F41483408: image.png
Nov 10 2023, 3:41 PM
F41483406: image.png
Nov 10 2023, 3:41 PM
F41483404: image.png
Nov 10 2023, 3:41 PM
F37625892: Captura de pantalla 2023-08-24 a las 12.11.22.png
Sep 13 2023, 9:23 PM

Description

Background

In T337095 we implemented the MVP of ChipInput component. There was some internal feedback and existing user feedback from a similar component built for Wikifunctions that suggested the experience of adding a new chip could be improved. There are a number of possible improvements we could explore to improve the experience. This task is about collecting feedback about the existing experience and ideating on potential solutions.

We need to consider the 2 types of FilterChipInputs we have:

Captura de pantalla 2023-08-24 a las 12.11.22.png (286×2 px, 44 KB)

Use Cases

Wikifunctions

some more feedback from the Wikifunctions community about the chip input component:

  • 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

JFYI consider this feedback in the context of Wikifunctions, where we use the chip input component for multi-word chips (thou i'm unsure if this is the best use of this component).

image.png (818×1 px, 123 KB)

the feedback might change if there would be a recommendation to use this component also for single-word chips.

Design spec

Once a component spec sheet has been created in Figma, remove the note stating that the spec is missing and link to the spec below.

Component spec sheet

Open questions

Add here the questions to be answered in order to design and implement the component

Acceptance criteria (or Done)

Design

  • Determine if the existing experience is even an issue.
  • Explore the different design solutions and test them with users.
  • Design the final Figma spec sheet and add it in this task.
  • Update the component in the Figma library. This step will be done by a DST member.

Code

  • Implement the component in Codex

Event Timeline

CCiufo-WMF added a subscriber: AnneT.

Pasting various ideas around this from previous threads:

@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)

Captura de pantalla 2023-08-02 a las 17.59.55.png (738×2 px, 187 KB)

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 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.

  • Determine if the existing experience is even an issue.

@CCiufo-WMF sharing some more tasks and comments left by the Wikifunctions community.

last week we conducted a series of usability study on the function editor page on wikifunctions https://www.wikifunctions.org/w/index.php?title=Special:CreateObject&zid=Z8. we observe that 100% of the participants who provided a function alias did not press the return/enter key to submit said alias.

(being aware that the team is at an offsite next week) is there space to prioritize this task @CCiufo-WMF once you're back? in the meantime, some ideas as food for thoughts:

  1. driving inspiration from the OOUI TagMultiselectWidget we could use a similar solution with the addition of a call to action too. thou it feels a bit too overly designed and probably too crowded, especially on mobile
    image.png (1×698 px, 88 KB)
  2. rely on direct manipulation and content-visual parity and create an empty chip when people focus a chip container
    image.png (1×690 px, 77 KB)

and here how the 2 options might work in page

image.png (1×3 px, 308 KB)

last week we conducted a series of usability study on the function editor page on wikifunctions https://www.wikifunctions.org/w/index.php?title=Special:CreateObject&zid=Z8. we observe that 100% of the participants who provided a function alias did not press the return/enter key to submit said alias.

(being aware that the team is at an offsite next week) is there space to prioritize this task @CCiufo-WMF once you're back? in the meantime, some ideas as food for thoughts:

  1. driving inspiration from the OOUI TagMultiselectWidget we could use a similar solution with the addition of a call to action too. thou it feels a bit too overly designed and probably too crowded, especially on mobile
    image.png (1×698 px, 88 KB)

@AAlhazwani-WMF I agree with the option with the button to increase the usability of the component in some cases. We also use the option with the button in some other components such as the SearchInput. If we finally implement it, I would go with a simplified button content (e.g. "+ Add") so the button doesn't occupy too much space in small screens.

Captura de pantalla 2023-11-29 a las 12.39.11.png (428×2 px, 58 KB)

  1. rely on direct manipulation and content-visual parity and create an empty chip when people focus a chip container
    image.png (1×690 px, 77 KB)

and here how the 2 options might work in page

image.png (1×3 px, 308 KB)

I don't really understand why we need this use case. Anyway, currently in the ChipInput in Codex the chips become input text when clicking on them, so the chip's edition is not within the chip itself.

@AAlhazwani-WMF I agree with the option with the button to increase the usability of the component in some cases. We also use the option with the button in some other components such as the SearchInput. If we finally implement it, I would go with a simplified button content (e.g. "+ Add") so the button doesn't occupy too much space in small screens.

Captura de pantalla 2023-11-29 a las 12.39.11.png (428×2 px, 58 KB)

+1! there might be even enough context to use a icon-only button.

image.png (306×1 px, 39 KB)

I don't really understand why we need this use case. Anyway, currently in the ChipInput in Codex the chips become input text when clicking on them, so the chip's edition is not within the chip itself.

ohhh but i see a new behaviour for the ChipInput now (gif below)! if you enter some text, and then you escape the focus, it turns the entered text to a chip. this is already helpful, thank you @bmartinezcalvo!

CleanShot 2023-11-30 at 14.52.19.gif (464×800 px, 148 KB)

bmartinezcalvo renamed this task from ChipInput: Explore improvements to the experience of adding a new chip to ChipInput: Explore improvements to add new chips.Mar 4 2025, 6:59 PM