Adding some comments during the meeting about this task:

• Given that "info chips" are non-interactive labels (or 'tags'), should we consider this as a separate component type? It would also enable more colour/style variations to be introduced for this more informational component.
• "Suggestion chip" is really a selection input (similar to checkboxes) so a better name suggested might be "Selection chip"
• Relatedly, since the filter and suggestion chip are both interactive form elements, it may make more sense for these two to be variants of the same component type.

Adding some other open questions (with screenshots) after chatting with @bmartinezcalvo and @SWoodruff-WMF:

• Is it possible to set a max-width limit for the chip component?

• What happens if the the container of the chip is shorter than the length of the chip?

Re-posting @scblr's comment on T280681#8380172:

In T280681#8380172, @scblr wrote:

Examples from Android per “Design Practice & Systems + DS Office Hours” meeting:

• Chips used in the 'Tag images' Suggested edits task (Zeplin | T240196)
• Chips in 'Reading lists' search (Zeplin | T214506)
• Chips design in the component library that is work in progress (Figma)
  

@RHo @bmartinezcalvo @Volker_E

PS: Also for reference: Material 3 Chips and its new Figma design kit are quite impressive (and extensive)

And on that note, should this other task be merged or made a sub-task to this one?

In T322524#8383398, @RHo wrote:

And on that note, should this other task be merged or made a sub-task to this one?

This epic task is to add the Chip component just in the Codex demo while T280681 is to add the Chip component in the DSG. Since currently we don't have the chip component page in the DSG I think we can maintain both tasks. cc: @ldelench_wmf should we merge both or should we separate them in different tasks?

In T322524#8383583, @bmartinezcalvo wrote:

In T322524#8383398, @RHo wrote:

And on that note, should this other task be merged or made a sub-task to this one?

This epic task is to add the Chip component just in the Codex demo while T280681 is to add the Chip component in the DSG. Since currently we don't have the chip component page in the DSG I think we can maintain both tasks. cc: @ldelench_wmf should we merge both or should we separate them in different tasks?

Gotcha. As the person who wrote that other task before adding components to Codex existed I have no issues merging with this one.

In T322524#8383647, @RHo wrote:

Gotcha. As the person who wrote that other task before adding components to Codex existed I have no issues merging with this one.

I think it would be good to merge T280681: Add Filter Chip to the DSG and T309249: Add Tags/Chips component to Codex into this task, and then we can spin out an MVP sub-task here when ready. Are there still design questions that need to be answered before work on an MVP version of this component can start?

Google's Material Design system includes a well-documented Chip component that may be worth looking at: https://m3.material.io/components/chips/overview

Like us, they have identified a couple of different types of "chips": assist, filter, input, and suggestion

It would be great if we could similarly identify a small number of "types" and make things as consistent as possible between our variations.

The expanded chip behavior in the Suggested Tags feature on Commons could be considered non-standard in my opinion – that future of that entire feature is somewhat uncertain as far as I understand, so I would not give too much importance to supporting that use-case.

In T322524#8393633, @egardner wrote:

In T322524#8383647, @RHo wrote:

Gotcha. As the person who wrote that other task before adding components to Codex existed I have no issues merging with this one.

I think it would be good to merge T280681: Add Filter Chip to the DSG and T309249: Add Tags/Chips component to Codex into this task, and then we can spin out an MVP sub-task here when ready. Are there still design questions that need to be answered before work on an MVP version of this component can start?

Google's Material Design system includes a well-documented Chip component that may be worth looking at: https://m3.material.io/components/chips/overview

Like us, they have identified a couple of different types of "chips": assist, filter, input, and suggestion

It would be great if we could similarly identify a small number of "types" and make things as consistent as possible between our variations.

I wonder if the "info" use case could be considered more like a badge or tag as it is non-interactive and conveys status, and is an "appendage" on something. Atlassian calls theirs a "lozenge" when it is a text label (as opposed to badges being numbers only) but it is the same type separate from chips. In general, the info chip use case we have here seems to be commonly split out as a separate "badge" or status "tag" component in other design systems:

• https://nordhealth.design/components/badge/
• https://www.lightningdesignsystem.com/components/badges/
• https://design-system.service.gov.uk/components/tag/
• https://atlassian.design/components/lozenge/examples

The expanded chip behavior in the Suggested Tags feature on Commons could be considered non-standard in my opinion – that future of that entire feature is somewhat uncertain as far as I understand, so I would not give too much importance to supporting that use-case.

We use the same chip on the Growth project for topic filters so I want to lobby for continued need for this use case :)
The intention is to allow someone to scan more easily and select multiple items in a group than if the items were presented as a checkbox group. Looking at the Material guidelines it maps to what they class as a filter chip.

@RHo do the Growth topic filters expand? It's the big expanded state in particular that I want to get away from. The general suggestion/filter chip behavior is useful I agree (complete with selected/unselected states).

In T322524#8394460, @egardner wrote:

@RHo do the Growth topic filters expand? It's the big expanded state in particular that I want to get away from. The general suggestion/filter chip behavior is useful I agree (complete with selected/unselected states).

Ahh do you mean the "detailed" states with title and description? Sorry I had completed missed that this was implemented on Commons after the initial chip type we share. Growth only uses non-expanded selected and non-selected states so would not need this, and completely agree that seems not a use case to prioritise (maybe more of a taco or potato wedge component for much, much later on...)

In T322524#8394448, @RHo wrote:

I wonder if the "info" use case could be considered more like a badge or tag as it is non-interactive and conveys status, and is an "appendage" on something. Atlassian calls theirs a "lozenge" when it is a text label (as opposed to badges being numbers only) but it is the same type separate from chips. In general, the info chip use case we have here seems to be commonly split out as a separate "badge" or status "tag" component in other design systems:

• https://nordhealth.design/components/badge/
• https://www.lightningdesignsystem.com/components/badges/
• https://design-system.service.gov.uk/components/tag/
• https://atlassian.design/components/lozenge/examples

@RHo regarding Chip, Tag and Badge in each Design System they work them differently so we should decide which solution is the best for our particular system. In my opinion, Badge is the small dot or number that appears on top right of an icon when there is a new notification like in this Badge from Material.

While in Shopify they call Tag to any non interactive or interactive component that helps organize and categorize objects.

Non interactive	Interactive

I like this approach where they work visually the same both non interactive and interactive Tag/Chip. I'm curious about what the rest of the team think about these component's categories as specified in the Open questions section in the task.

After the inventory created for this and the MVP tasks I've created these explorations trying to unify all the possible chip use cases with a systematic solution:

We could organize the chip into the following variants and properties:

• Type of chip or functionality:
  • Informative (also Informative with Feedback for the user): this type of chip will be just informative (non clickable).
  • Filter (removable)
  • Selection (toggle)
  • Clickable (or link)
• Size
  • Small: we'll need a 20-24px chip to be included within other components (e.g. chips included within Inputs)
  • Medium / Large: we'll need a large size for toggled chips (e.g. the ones used in Growth).

In T322524#8626671, @ldelench_wmf wrote:

The Design Systems team is removing the majority of our "meta" tasks like this one.
Followup steps:

• create mvp tasks for selection chip, clickable/link chip
• pull background info from this task into mvp tasks

On what task should we be marked as blocked, in these cases?