After a conversation with @JKieserman and @bmartinezcalvo we are thinking about extending the scope of this MVP to also include "feedback chips", which currently used in the implementations and tests tables on Wikifunctions.

@bmartinezcalvo proposed to use implement this visual treatment in order to align the feedback chip with the info chip designs.

In T323524#8484177, @AAlhazwani-WMF wrote:

After a conversation with @JKieserman and @bmartinezcalvo we are thinking about extending the scope of this MVP to also include "feedback chips", which currently used in the implementations and tests tables on Wikifunctions.

@JKieserman @AAlhazwani-WMF I've checked this with the DST and we all agree with extending the MVP task to cover these feedback chip cases. I've updated the Figma spec sheet adding the statusType property for the InfoChip component.

As explained in the recommendations section, the icon is just a startIcon prop. In the Notice chip this prop is totally free and the user could show/hide according to the need of each project. Also they could replace the icon.

But in the case of Success, Warning and Error, this startIcon can't be hidden since it's the only way to show the feedback status.

@JKieserman I'm going to update the task description to explain these new use cases and you can start implementing them when needed.

Should there

In T323524#8487056, @bmartinezcalvo wrote:

In T323524#8484177, @AAlhazwani-WMF wrote:

After a conversation with @JKieserman and @bmartinezcalvo we are thinking about extending the scope of this MVP to also include "feedback chips", which currently used in the implementations and tests tables on Wikifunctions.

@JKieserman @AAlhazwani-WMF I've checked this with the DST and we all agree with extending the MVP task to cover these feedback chip cases. I've updated the Figma spec sheet adding the statusType property for the InfoChip component.

As explained in the recommendations section, the icon is just a startIcon prop. In the Notice chip this prop is totally free and the user could show/hide according to the need of each project. Also they could replace the icon.

But in the case of Success, Warning and Error, this startIcon can't be hidden since it's the only way to show the feedback status.

Just to check, is the intention that the respective icons for Success (), Warning (), and Error (cdxIconError) be used instead of the coloured circles? This would be add an additional a11y element which reinforces the connection of success, warning, and error to the respective icons too.

---

@JKieserman I'm going to update the task description to explain these new use cases and you can start implementing them when needed.

In T323524#8495470, @RHo wrote:

Just to check, is the intention that the respective icons for Success (), Warning (), and Error (cdxIconError) be used instead of the coloured circles? This would be add an additional a11y element which reinforces the connection of success, warning, and error to the respective icons too.

@RHo I used the IconNotBright as startIcon since it's a circle and we could use a startIcon prop for the Notice (default) InfoChip as decorative icon. But as recommended in the Figma spec sheet the StartIcon could be removable and replaced just in the Notice (default) InfoChip. In the Warning, Error and Success status we should always use this dot icon since the warning, error and check ones would not be readable in 12px size.

In T323524#8497736, @bmartinezcalvo wrote:

In T323524#8495470, @RHo wrote:

Just to check, is the intention that the respective icons for Success (), Warning (), and Error (cdxIconError) be used instead of the coloured circles? This would be add an additional a11y element which reinforces the connection of success, warning, and error to the respective icons too.

@RHo I used the IconNotBright as startIcon since it's a circle and we could use a startIcon prop for the Notice (default) InfoChip as decorative icon. But as recommended in the Figma spec sheet the StartIcon could be removable and replaced just in the Notice (default) InfoChip. In the Warning, Error and Success status we should always use this dot icon since the warning, error and check ones would not be readable in 12px size.

Thanks for the reasoning @bmartinezcalvo, but if the concern is that the warning, error, and check icons are not readable at 12px size, wouldn't that be the same for the replaceable one in the Notice info chip? In other words, can we be more consistent in the recommendation that no icon is changable from the circle coloured differently, or else consider how the icons could be revised/refined fit more legibly in the info chip?

In T323524#8497801, @RHo wrote:

Thanks for the reasoning @bmartinezcalvo, but if the concern is that the warning, error, and check icons are not readable at 12px size, wouldn't that be the same for the replaceable one in the Notice info chip? In other words, can we be more consistent in the recommendation that no icon is changable from the circle coloured differently, or else consider how the icons could be revised/refined fit more legibly in the info chip?

@RHo the reason why the 12px icon in the Notice chip is more readable is because it's using color-subtle that is contrasted enough. While warning, error and check/success would use yellow, red and green colors that are not as contrasted as color-subtle.

Updated recommendations to explain that IconNotBright (dot icon) can not be replaced with other icons in Success, Warning and Error status.

{F35980302}

In T323524#8498855, @bmartinezcalvo wrote:

In T323524#8497801, @RHo wrote:

Thanks for the reasoning @bmartinezcalvo, but if the concern is that the warning, error, and check icons are not readable at 12px size, wouldn't that be the same for the replaceable one in the Notice info chip? In other words, can we be more consistent in the recommendation that no icon is changable from the circle coloured differently, or else consider how the icons could be revised/refined fit more legibly in the info chip?

@RHo the reason why the 12px icon in the Notice chip is more readable is because it's using color-subtle that is contrasted enough. While warning, error and check/success would use yellow, red and green colors that are not as contrasted as color-subtle.

Updated recommendations to explain that IconNotBright (dot icon) can not be replaced with other icons in Success, Warning and Error status.

{F35980302}

Gotcha, I misunderstood that you meant the size of the icon was the issue. However, I still don't quite agree that the Success, Warning and Error icons would be less readable than the solid circle in that case, if the argument is that the icon in these chips are only for the blob of colour. One consideration would be if the success should be in a solid shape like the error and warning icons in that exploration:

I do like and agree with @RHo on the usability/accessibility advantage of our own success/warning/error icons over the solid circle. We originally put them into different shapes to strengthen uniquely identifying them.
Also @bmartinezcalvo haven't we discussed a solid background success icon recently (which would defer the unique shaped difference with notice icon) in a different context, which you've asked for? :)

In T323524#8500071, @Volker_E wrote:

I do like and agree with @RHo on the usability/accessibility advantage of our own success/warning/error icons over the solid circle. We originally put them into different shapes to strengthen uniquely identifying them.
Also @bmartinezcalvo haven't we discussed a solid background success icon recently (which would defer the unique shaped difference with notice icon) in a different context, which you've asked for? :)

@Volker_E yes, I proposed a circled solid success icon for the message component in T322428. So I've created this new task T326557 to design this new success icon.

After my 1on1 this morning with @RHo where we discussed about the feedback icons and chip start icon size, I proposed the following changes for the chip component:

1. Use the warning (alert), error and success (this new circled success icon T326557) instead the dot icon. These icons provide more feedback context for the user so they are more accessible.
2. Start icon size from 12px to 16px (12px is too small in some cases, specially for warning, success and error if we use the feedback icons).

{F36076743}

These changes will also be added to FilterChip T324223 that will use a 16px startIcon too (if the chip uses a start icon).

You can check the new Figma spec sheet version where these changes have been captured. @AAlhazwani-WMF please tell me if these changes are ok for your AW project. They will specially affect the Wikifunctions table.
{F36076772}

Change 875436 had a related patch set uploaded (by Jkieserman; author: Jkieserman):

[design/codex@main] WIP: InfoChip component

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

Agree with the latest designs with one small exception, I would defer from using 'heart' as notice. We don't know what notice messages are about in general, for this we should use a neutral icon ('notice').

In T323524#8510843, @Volker_E wrote:

Agree with the latest designs with one small exception, I would defer from using 'heart' as notice. We don't know what notice messages are about in general, for this we should use a neutral icon ('notice').

@Volker_E I used the heart as icon in the base (notice) chip since the icon in this chip could be replaced with any other icon (or removed) as documented in the recommendations.

Looks good to me! I have only a couple of nits, feel free to take them into account or ignore them!

With rounded icons, the padding of the success chip looks a bit off. I'm aware this is for needed in order to account for the warning and error icon, but I still wonder if we can find a more elegant solution.

For example, what if we opt for a border radius of 2, similarly as the rest of the codex buttons? With this approach we could opt for equal padding for all 4 variants.

Another tiny thing I noticed is that the chip is 24px high, this might be an issue when we try to layout a chip with single line text. Our current typography tokens set single-line text to 22px. We could address this by setting the chip label to Small text/Regular instead of UI Text S/Regular

Last but not least, icon size. The icons are a bit tight inside their green/yellow/red box, and at such small size their path might get too close to the background borders. What if we reduce the white path a bit?

As I said, feel free to take these ideas into account or not. On the Wikifunctions side of things, we're good!

Thanks for these thoughtful inputs @AAlhazwani-WMF. Reason I'd stick with rounded corners on Tags, err, excuse me, Chips is that overflow of rounded corner rectangles otherwise. Most prominently Special:RecentChanges

The fully rounded elements here have a strong advantage on interface composition to me.

In T323524#8517403, @AAlhazwani-WMF wrote:

Looks good to me! I have only a couple of nits, feel free to take them into account or ignore them!

With rounded icons, the padding of the success chip looks a bit off. I'm aware this is for needed in order to account for the warning and error icon, but I still wonder if we can find a more elegant solution.

For example, what if we opt for a border radius of 2, similarly as the rest of the codex buttons? With this approach we could opt for equal padding for all 4 variants.

@AAlhazwani-WMF we need the chips to be more rounded to differentiate chips from other actionable components like buttons. Also because, as commented by Volker, we will add FilterChips on inputs and other non rounded boxes so rounded corners help us to differentiate chips on not rounded corners.

I've tested different border radius solutions:

A) border-radius-pill 999px: it works well both to differentiate chips from buttons and to differentiate chips on inputs
B) border-radius-base (2px): chips on inputs are difficult to differentiate since both borders are equal
C) New border token: another solution (if we want the chips to be non full rounded) is to use a new border radius like 6px or 8px (in this case we would need to add this new border radius token)

Another tiny thing I noticed is that the chip is 24px high, this might be an issue when we try to layout a chip with single line text. Our current typography tokens set single-line text to 22px. We could address this by setting the chip label to Small text/Regular instead of UI Text S/Regular

Regarding this, I used 14/22 for the text and I added 1px on top and on bottom so the chip were the same height of one of our spacing tokens (24px). If you feel this it's really unbalanced next to the text we could delete the top and bottom paddings to be 22px heigh. But I think having the same heigh of one of our size&spacing tokens is better, at the end the difference between chip and text is not too much.

Last but not least, icon size. The icons are a bit tight inside their green/yellow/red box, and at such small size their path might get too close to the background borders. What if we reduce the white path a bit?

@AAlhazwani-WMF the icon inside the shape is a bit tight because the original 20px icon was scaled to this 16px size in the component. @Volker_E I'm wondering if we should redesign a specific 16px size for these icons to avoid them to be tight and also to avoid them not being pixel-perfect.

As discussed in the DS design sync today, I'd lean towards not introducing specific 16px icons as the maintenance overhead long-term, both in design and development and possible performance impact of two icons loaded with very minimal differences seems contra-productive for our environment.

In T323524#8520202, @bmartinezcalvo wrote:

@AAlhazwani-WMF the icon inside the shape is a bit tight because the original 20px icon was scaled to this 16px size in the component. @Volker_E I'm wondering if we should redesign a specific 16px size for these icons to avoid them to be tight and also to avoid them not being pixel-perfect.

@AAlhazwani-WMF as Volker commented above, we decided yesterday during our DS Design sync to design our iconography just in our base icon size (20x20) and then scale each icon to the different sizes we use in our components. So in this case, the success icon designed originally to be 20px will be scaled to 16px and the check mark will be a bit tight in this case.

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

[design/codex@main] WIP: InfoChip component

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

I'm reviewing @JKieserman's patch today, and I have a question about background color. The Figma spec and task description here define the background color as background-color-transparent, but the patch uses background-color-notice-subtle. Did something change at one point?

What is the expected bg color for a standard Info Chip (no icon)?

Also, can someone let me know what the padding should be on all sides of the optional Icon element? I think that I only have read access to the Figma spec and can't figure out how to see an inspector; having these measurements annotated in the file would be helpful.

In T323524#8535799, @egardner wrote:

I'm reviewing @JKieserman's patch today, and I have a question about background color. The Figma spec and task description here define the background color as background-color-transparent, but the patch uses background-color-notice-subtle. Did something change at one point?

What is the expected bg color for a standard Info Chip (no icon)?

As defined in the Figma spec the background color should be background-color-transparent. Maybe it was misunderstood with the gray box background but the token used is transparent.

Also, can someone let me know what the padding should be on all sides of the optional Icon element? I think that I only have read access to the Figma spec and can't figure out how to see an inspector; having these measurements annotated in the file would be helpful.

All tokens used where added in the first section in the spec. The paddings used for the icon are 8px on left and 4px on right.

Regarding your access to Figma, you should be able to inspect any spec sheet with the right panel ("Inspect" panel). If you can't find it we can check it in a quick call.

Change 875436 had a related patch set uploaded (by Jkieserman; author: Jkieserman):

[design/codex@main] WIP: InfoChip component

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

I've checked the last InfoChip patch and there are some visual aspects to fix:

• Text color should be color-subtle
• Text size should be 14px for both desktop and mobile chips. 16px is too big for this element.
• There is an extra padding between the icon and the text. It should be just 4px.

• Success icon should be replaced with the new icon designed in T326557
• Default icon color in notice chip should be color-subtle.
• As documented in the spec sheet, notice chip might have StartIcon if needed. At the moment, the StartIcon is not visible for the notice chip in the configurable demo.

Thanks, I'll make the changes! On the last bullet: there is a "default, with icon" demo, which shows what happens if an icon is added with the notice status...is that something different from the StartIcon?

hey @JKieserman! I think Bárbara is asking for the icon prop to be included in the configurable demo. You can check out the TextInput demo (and associated markdown file) for an example of how you can add an icon prop to the configurable demo.

Ah gotcha, can do. Thanks!

Hey @bmartinezcalvo – I see that one of the images in the task description features InfoChips which have colored backgrounds/borders (based on status) instead of Icons. But the Figma spec has no mention of these.

I assume the Figma spec is definitive here, but could you confirm? In the design there, it looks like there is no way to indicate status unless an Icon is also used. Is this the intent?

@JKieserman sorry, I forgot to comment about the icon size. It should be 16px instead. We should use the size-icon-small in T260617

Also, a property should be added so the chip is fixed width as specified in the spec sheet. This fixed width will be used when chip text length is similar, so in AW project will be used for language chips.

{F36483040}

In T323524#8554442, @bmartinezcalvo wrote:

Also, a property should be added so the chip is fixed width as specified in the spec sheet. This fixed width will be used when chip text length is similar, so in AW project will be used for language chips.

{F36483040}

Hey @bmartinezcalvo, I think that the rule you are proposing here is something that will need to be handled at the level of whatever component ends up using these chips – probably something outside of Codex in most cases. For example, if Abstract Wiki is building a Table component that displays InfoChips side by side, it would make sense for that table component to apply a rule that enforces a fixed size. What you are proposing would be a property of the parent of the Chip in a specific use-case, not part of the Chip itself.

In T323524#8555081, @egardner wrote:

In T323524#8554442, @bmartinezcalvo wrote:

Also, a property should be added so the chip is fixed width as specified in the spec sheet. This fixed width will be used when chip text length is similar, so in AW project will be used for language chips.

{F36483040}

Hey @bmartinezcalvo, I think that the rule you are proposing here is something that will need to be handled at the level of whatever component ends up using these chips – probably something outside of Codex in most cases. For example, if Abstract Wiki is building a Table component that displays InfoChips side by side, it would make sense for that table component to apply a rule that enforces a fixed size. What you are proposing would be a property of the parent of the Chip in a specific use-case, not part of the Chip itself.

Ok, since the fixed/hug property will be added in each component use, I've deleted it from the component properties in the spec sheet and I've moved it to the recommendations section.

Change 875436 merged by jenkins-bot:

[design/codex@main] Chip, Message: Introduce Chip component and StatusType constant

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

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

[design/codex@main] docs: Update types and constants docs to reflect new StatusType

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

Change 883667 merged by jenkins-bot:

[design/codex@main] docs: Update types and constants docs to reflect new StatusType

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

@JKieserman just checking the last implementation and fining some new small things to fix:

1. There is still an extra left and right paddings in the icon that makes the icon more separated from the left edge and the text. Icon should be 16px and just having the 8px on left and the 4px between icon and text. Now the icon width is 20px, it should be 16x16px instead.

2. Could we add another more explicative text in this example? Something like:

"Long text in an info chip will not wrap into two lines, but will be truncated into ellipses"

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

[design/codex@main] Chip: Follow-up fixes

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

Latest patch preview link here: https://884053--wikimedia-codex.netlify.app/components/demos/chip.html

Could we add another more explicative text in this example? Something like:

"Long text in an info chip will not wrap into two lines, but will be truncated into ellipses"

All was successfully fixed except the Long text example text. Could we update it with a more representative text?

Apart from that, when the chip is long it exceeds the demo box maximum. Chip width should scale when resizing the screen or the demo box.

{F36524789}

Just checking that the name of the component in the demo is "Chip" while we decided to separate chip into InfoChip and FilterChip. Should this component be renamed to "InfoChip"?

In T323524#8564804, @bmartinezcalvo wrote:

Just checking that the name of the component in the demo is "Chip" while we decided to separate chip into InfoChip and FilterChip. Should this component be renamed to "InfoChip"?

My understanding was that we wanted a single Chip component which supported two variants – FilterChip and InfoChip. There is a single Figma spec called "Chip component", so we've been following that in the code.

In T323524#8565478, @egardner wrote:

In T323524#8564804, @bmartinezcalvo wrote:

Just checking that the name of the component in the demo is "Chip" while we decided to separate chip into InfoChip and FilterChip. Should this component be renamed to "InfoChip"?

My understanding was that we wanted a single Chip component which supported two variants – FilterChip and InfoChip. There is a single Figma spec called "Chip component", so we've been following that in the code.

@egardner ah ok, I though we wanted to do the same as with ButtonGroup where we separated ButtonGroup from ToggleButtonGroup. Keep in mind that InfoChip and FilterChip have different functionalities since the first is just informative and the second is removable and filterable.

Can filter chips ever be used outside of a chip input? If not, we may want to consider making FilterChip a separate component that is not featured in the Codex docs, or just something that's internal to the ChipInput component. If we add it to the existing component, it might be confusing for users, because as @bmartinezcalvo said they're quite different despite some similar design features:

• InfoChip is meant to show information and will be used directly by developer users, while FilterChip is a functional part of an input and will not (I think)
• Only InfoChip has different statuses available
• Only FilterChip is dismissable

I think it might end up being confusing to users if all of these features are available in a single component, and they have to figure out how to use them properly. This might be a case where it's worth a bit more complexity in the library (two components that maybe share some base styles) for the sake of simplicity for the user.

We definitely *can* make InfoChip and FilterChip into separate components, I just wasn't sure about what was originally desired. We should clarify this before any work starts on the filter chip variant. Right now it would be simple to simply re-name the current Chip component as InfoChip and then start a new one with some shared styles for FilterChip.

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

[design/codex@main] InfoChip: Re-name component to InfoChip

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

Change 884053 merged by jenkins-bot:

[design/codex@main] Chip: Follow-up fixes

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

Change 884985 merged by jenkins-bot:

[design/codex@main] InfoChip: Re-name component to InfoChip

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

In T323524#8570972, @egardner wrote:

We definitely *can* make InfoChip and FilterChip into separate components, I just wasn't sure about what was originally desired. We should clarify this before any work starts on the filter chip variant. Right now it would be simple to simply re-name the current Chip component as InfoChip and then start a new one with some shared styles for FilterChip.

In the list of core components and components architecture we defined InfoChip and FilterChip not as different variants but as different components. Although InfoChip and FilterChip were designed in the same Chip exploration file, they are in separate specs representing that they are different components from the same Chip family.

If you all agree we can do this and separate InfoChip and FilterChip in different component demos. As Anne commented, it could be confusing to users if all of these features are available in a single component.

In T323524#8573394, @bmartinezcalvo wrote:

If you all agree we can do this and separate InfoChip and FilterChip in different component demos. As Anne commented, it could be confusing to users if all of these features are available in a single component.

We went ahead and did this yesterday to get it into today's release: https://doc.wikimedia.org/codex/main/components/demos/info-chip.html. Filterchip will get its own page when we introduce it.

In T323524#8575222, @egardner wrote:

In T323524#8573394, @bmartinezcalvo wrote:

If you all agree we can do this and separate InfoChip and FilterChip in different component demos. As Anne commented, it could be confusing to users if all of these features are available in a single component.

We went ahead and did this yesterday to get it into today's release: https://doc.wikimedia.org/codex/main/components/demos/info-chip.html. Filterchip will get its own page when we introduce it.

@egardner great, thank you! It LGTM.

Change 869852 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Update Codex from v0.4.3 to v0.5.0

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

Change 885450 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] Update Codex from v0.4.3 to v0.5.0

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

Change 885450 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.4.3 to v0.5.0

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