@ldelench_wmf @DAbad moving to Need Refinement since we should add these new decision tokens as soon as possible since they are part of our color palette T296995

Change 848595 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] tokens: Update 'Error' and 'Warning' color decision tokens

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

@RHo deleted the illustration color requirements from the task description since in illustrations we don't need to use decision tokens but we can use any color from the color palette defined in the DSG. So you can simply use the hex of the color in your illustrations.

I've updated the color decisions Figma spec with the following proposal:

Instead adding new color decisions for these Growth use cases, we can update our current color decisions used in feedback. So we will use the following token names and some of the option tokens that they are using:

Content colors:

• color-error-dark (update option color with color-red700)
• color-warning-dark (update option color with color-warning700)
• color-success-dark
• color-notice-dark @RHo we could use this color #202122 for mixed-level elements in order to unify them with notice ones. What do you think?

Border colors:

• border-color-error-dark (update option color with color-red700)
• border-color-success-dark
• border-color-warning-dark (update option color with color-warning700)
• border-color-notice-dark

With this solution we will be able to use the same color decision for feedback (messages) and level elements (growth). Also, we will have more accessible warning and error message since these tokens will be updated with a darker color.

Following a conversation during design review, I would like to challenge the current proposal of using color-warning700 uniquely on different components as the only viable solution that we could consider for this problem space. The proposed color leans more towards a brownish hue rather than a yellow hue. I'm wondering if this color is a good candidate as the only color for "warning" scenarios. A couple of ideas worth considering:

• What if we opt for bi– or tri–color icons? Eg. a warning icon with a dark yellow border, a light yellow background, and a black exclamation mark?
• What if we opt for a light yellow background color, and a black histogram?

Moreover, even if we would go forward with this decision, I'm wondering if it's necessary to update the message bar color combinations at all. If we want to improve the accessibility of said component, what if we opt for a similar approach as the one used by GitHub Primer?

On the accessibility of this component, I also would like to consider the multiple semantic layers to question if changing the warning icon background color to a brownish shade is a good solution. The layers are: color (light yellow background), icon (brownish warning symbol), and the text (eg. “This is taking a bit longer than expected. Please check back later.”). Are all of those necessary? Or could we keep the warning icon set to the lighter yellow shade?

In T321202#8351857, @AAlhazwani-WMF wrote:

Following a conversation during design review, I would like to challenge the current proposal of using color-warning700 uniquely on different components as the only viable solution that we could consider for this problem space. The proposed color leans more towards a brownish hue rather than a yellow hue. I'm wondering if this color is a good candidate as the only color for "warning" scenarios. A couple of ideas worth considering:

• What if we opt for bi– or tri–color icons? Eg. a warning icon with a dark yellow border, a light yellow background, and a black exclamation mark?
• What if we opt for a light yellow background color, and a black histogram?

Hi @AAlhazwani-WMF, relating to the levels icon specifically, I was really using the dark green, dark yellow (brown), and dark red to represent editing task difficulty levels as easy/medium/hard respectively, so it is a semantically different application of success/warning/error colour decision tokens. @bmartinezcalvo did have option 1 in her different proposals to add a separate set of "Level" colour tokens, but since it is only being used by Growth at this point I thought it would be simpler to not go forward with this option. I would have no objection if this is the approach instead to be less disruptive for a short term solution that re-incorporates the colours we need.

Moreover, even if we would go forward with this decision, I'm wondering if it's necessary to update the message bar color combinations at all. If we want to improve the accessibility of said component, what if we opt for a similar approach as the one used by GitHub Primer?

On the accessibility of this component, I also would like to consider the multiple semantic layers to question if changing the warning icon background color to a brownish shade is a good solution. The layers are: color (light yellow background), icon (brownish warning symbol), and the text (eg. “This is taking a bit longer than expected. Please check back later.”). Are all of those necessary? Or could we keep the warning icon set to the lighter yellow shade?

This was also discussed. I personally think the lighter shade yellow icon doesn't work as it is too light, and we are bending over backwards and twisting the warning message colour application differently to success, error, and notice for the sake of using the current yellow tones available (I pasted all the current message variants below together which I hope illustrates the point). IMO it would make sense to review a different yellow that works systematically and visually, which includes considering some of the explorations you have here around how message could be different. Having said that, it seems that greater reconsideration of colours for Codex components that are 'upgraded' from OOUI seems to be out of scope right now.

In T321202#8351857, @AAlhazwani-WMF wrote:

Moreover, even if we would go forward with this decision, I'm wondering if it's necessary to update the message bar color combinations at all. If we want to improve the accessibility of said component, what if we opt for a similar approach as the one used by GitHub Primer?

@AAlhazwani-WMF thank you for your explorations, I think they will be useful if we want to redesign in some moment the Message component and the Level elements used in Growth. In this case we should create a separate task to evaluate the design of these system elements. If you feel these elements can be redesigned you can create a separate task and add all these explorations in the task description. We can evaluate our system components if needed. But if we decide to do it, we should keep in mind the following questions:

1. This new design proposal follows the principles documented in our Design Style Guide?
2. This new proposal fits with the rest of the components currently designed in our system?
3. Also we should keep evaluate this new design in the components/variants/properties currently designed in our system. E.g. we need to understand this component on mobile device and close icon, and also compare it with the rest of our system elements as the levels designed for Growth where the dark yellow is needed.
   

• What if we opt for bi– or tri–color icons? Eg. a warning icon with a dark yellow border, a light yellow background, and a black exclamation mark?
• What if we opt for a light yellow background color, and a black histogram?

@AAlhazwani-WMF regarding these proposal for feedback and level elements, I would say these icons with different color on background and border can't be implemented. They would be illustrations.

Regarding this task, it was created to add some Growth colors in our system. As @RHo comments the best approach decided was to simplify our color tokens using the same tokens for both feedbacks and level elements. In this way both elements were visually unified since currently were using different color solutions and it was inconsistent. Review this example bellow where the warning message is totally different from the level tag. I think it makes sense to use the same tone in both cases, right?

Before	After

Since this task is to find a solution that currently fits with our system components and tokens, I think this proposal is the best solution now unless we decide to update our warning yellow (it's not easy to find a good contrast with yellow tones) or redesign our message component.

@bmartinezcalvo did have option 1 in her different proposals to add a separate set of "Level" colour tokens, but since it is only being used by Growth at this point I thought it would be simpler to not go forward with this option. I would have no objection if this is the approach instead to be less disruptive for a short term solution that re-incorporates the colours we need.

100%, thanks for the extra explanation @RHo 🙏🏼

IMO it would make sense to review a different yellow that works systematically and visually, which includes considering some of the explorations you have here around how message could be different. Having said that, it seems that greater reconsideration of colours for Codex components that are 'upgraded' from OOUI seems to be out of scope right now.

+1, maybe—reconsidering the scope of this task—this is a good reminder to just add those missing colors, and not touch the message bar for the time being? And open a separate task instead?

Review this example bellow where the warning message is totally different from the level tag. I think it makes sense to use the same tone in both cases, right?

@bmartinezcalvo I'm reflecting on what Rita shared above "relating to the levels icon specifically, I was really using the dark green, dark yellow (brown), and dark red to represent editing task difficulty levels as easy/medium/hard respectively, so it is a semantically different application of success/warning/error colour decision tokens.", and since the two scenarios rely on two different semantic layers, maybe it's not necessary to change the message bar colors?

I also wanted to build on top of yours and Rita's great reminder to keep the scope of this task in mind, maybe let's open a separate task for the message bar?

@AAlhazwani-WMF we have to options to add the level colors for Growth:

Option 1

Add the level colors as different and separate colors from feedback messages. In this case we would use different color tones for warning message and medium level.

Option 2

Unify both feedback message and level elements in one single token per color. In this case warning and medium-level would use the same dark yellow (brown) color.

I think option 2 is the right option in terms of unification and also to improve our warning message contrast. But if you all are against changing the message color we can go with option 1 now and evaluate our warning message contrast in other task. cc: @Volker_E

Thanks for the extra context @bmartinezcalvo!

Just for my own understanding, is it always necessary to create semantic tokens, or could the Growth team simply use the color-yellow700 token?

I favor option 1 as it provides more flexibility in the long run, and a stronger separation of concerns BUT I also want to trust you and the design system team, hence feel free to go forward with the option that you all feel is the most appropriate all things considered. My initial intent was to to challenge this decision, and I feel that my concerns were more than adequately heard and addressed!

hi @bmartinezcalvo - posting my two cents expressed in our offline chat that option 1 would be my preference out of the two to keep to the scope of the task to have decision tokens that match defined use cases right now, without opening up the larger discussion about updating the colour palette overall if it is not as ideally fit for purpose like in the message component use-case.

However, to @AAlhazwani-WMF's point, we are fine to continue using the 'option' tokens for Growth features and leave the need to add this new "levels/difficulty" set of semantic tokens until we move these elements to Codex, since probably there are a couple of other cases where new colour decision tokens would need to be created across all products.

Another use case for a Warning feedback element:

In this Wikifunctions table the "Proposed" is a warning feedback element since it's giving a warning alert to the user. "Available" belongs to Success and "Proposed" belongs to Warning.

"Proposed" tag should use the same warning tokens as the Warning message component since it's a warning feedback element. If we decide to use the normal yellow #FFCC33 the tag in the table wouldn't be enough contrasted on the table.

This is another reason why we should use the dark yellow for warning tokens.

After a catch up with @Volker_E and a conversation with @RHo we've decided to finally don't use our system decision tokens to represent the growth levels for the following reasons:

1. It doesn't make sense at the moment to create specific color decision tokens for levels since they are only being used at the moment in the Growth project. So they can use their own tokens to represent those level colors.
2. In case we would like to use the system tokens, level colors should use the feedback color tokens (error, warning, success, notice) to represent each level. At the moment, those feedback colors are different from the ones that are being used in Growth so they can use their own tokens (unless we decide to update our message colors in this other task commented above).

@Volker_E since we finally won't use the system tokens to represent the growth levels I think we could decline this task.

In T321202#8356597, @AAlhazwani-WMF wrote:

Thanks for the extra context @bmartinezcalvo!

Just for my own understanding, is it always necessary to create semantic tokens, or could the Growth team simply use the color-yellow700 token?

Very important point. Designers and devs could refer to the option tokens, but are advised to turn them into one-off decision tokens. The option tokens like 'color-yellow700' should never be referred to in code applications.
So you would end up with `@color-growth-level-medium:
@color-yellow700`

That's emphasizing the design decision and also make tokens application more flexible and maintainable in the long run.

In T321202#8370957, @bmartinezcalvo wrote:

1. It doesn't make sense at the moment to create specific color decision tokens for levels since they are only being used at the moment in the Growth project. So they can use their own tokens to represent those level colors.
2. In case we would like to use the system tokens, level colors should use the feedback color tokens (error, warning, success, notice) to represent each level. At the moment, those feedback colors are different from the ones that are being used in Growth so they can use their own tokens (unless we decide to update our message colors in this other task commented above).

@Volker_E since we finally won't use the system tokens to represent the growth levels I think we could decline this task.

Agreed. Let's discuss amending and improving (warning) color token and warning message further in T322428 with your good explorations, @bmartinezcalvo!

In T321202#8376679, @Volker_E wrote:

In T321202#8356597, @AAlhazwani-WMF wrote:

Thanks for the extra context @bmartinezcalvo!

Just for my own understanding, is it always necessary to create semantic tokens, or could the Growth team simply use the color-yellow700 token?

Very important point. Designers and devs could refer to the option tokens, but are advised to turn them into one-off decision tokens. The option tokens like 'color-yellow700' should never be referred to in code applications.
So you would end up with `@color-growth-level-medium:
@color-yellow700`

That's emphasizing the design decision and also make tokens application more flexible and maintainable in the long run.

I agree, but specifically for Figma the option-token named colour style for Yellow30/Yellow700 was removed (as were the other colours mentioned in the task), so I want to confirm that we can just use the Primitive-colour-tokens-as-styles (being re-introduced in Figma files per T321908) instead on projects where Codex is not yet in use.

In T321202#8376968, @RHo wrote:

I agree, but specifically for Figma the option-token named colour style for Yellow30/Yellow700 was removed (as were the other colours mentioned in the task), so I want to confirm that we can just use the Primitive-colour-tokens-as-styles (being re-introduced in Figma files per T321908) instead on projects where Codex is not yet in use.

@RHo Primitive colors have been addd in our Design Tokens library as Figma styles (T321908 done) so you can now use them in your designs.

In T321202#8378703, @bmartinezcalvo wrote:

In T321202#8376968, @RHo wrote:

I agree, but specifically for Figma the option-token named colour style for Yellow30/Yellow700 was removed (as were the other colours mentioned in the task), so I want to confirm that we can just use the Primitive-colour-tokens-as-styles (being re-introduced in Figma files per T321908) instead on projects where Codex is not yet in use.

@RHo Primitive colors have been addd in our Design Tokens library as Figma styles (T321908 done) so you can now use them in your designs.

Great, thanks for confirming.