Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared Severity color palette (Borealis Update) #203387

Open
gvnmagni opened this issue Dec 9, 2024 · 4 comments
Open

Shared Severity color palette (Borealis Update) #203387

gvnmagni opened this issue Dec 9, 2024 · 4 comments
Assignees
Labels
Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins.

Comments

@gvnmagni
Copy link

gvnmagni commented Dec 9, 2024

Following the issue raised here (#202985) and given the upcoming release of Borealis, we thought it could be a good idea to take advantage of this transitioning phase to put together a Severity color palette the could be shared across solutions.

Currently there is a little bit of inconsistency when dealing with this kind of data, the lack of clear guidelines resulted in a different use of colors across the product, which is not great for our developers and designers that every time needs to find a solution while at the same time generating a scattered user experienced.

A first mapping of cases can show us exactly this behaviour, the following image shows how different this use can be and it shows perfectly the need for a clear set of shared guidelines

Image

Before introducing our proposal, a few constraints/requirements that need to be specified:

  1. New palette needs to be agnostic in terms of semantic. (Critical in Observability might means a different level of severity than Critical in Security)
  2. Needs to be based on color primitives provided by Borealis, so that it will be automatically updated in case of any future change
  3. Needs additional levels, in case of future cases in which we might need that
  4. This is a separated palette from what we typically call Status, which normally provides Green-Yellow-Red for Success-Warning-Danger. This palette is meant to map levels of dangers, with neutral or negative meaning.

Proposal

A new set of 15 colors divided into severity groups, spanning from Red shades for Danger levels, through yellow for Warning, while providing at the same time a group of colors for neutral categories of data.

Image

Specific color primitives and hex codes:

Severity Color Palette

Level 14		|  Danger 90		|		#C61E25
Level 13		|  Danger 80		|		#DA3737
Level 12		|  Danger 70		|		#EE4C48
Level 11		|  Danger 60		|		#F6726A
Level 10		|  Danger 50		|		#FC9188
Level 9			|  Danger 40		|		#FFB5AD
Level 8			|  Danger 30		|		#FFC9C2
		
Level 7			|  Warning 30		|		#FCD883
Level 6			|  Warning 20		|		#FDE9B5
		
Category 5		|  Blue Grey 30		|		#CAD3E2
Category 4		|  Blue Grey 45		|		#ABB9D0
Category 3		|  Blue Grey 60		|		#8E9FBC
Category 2		|  Blue Grey 75		|		#7186A8
Category 1		|  Blue Grey 90		|		#5A6D8C
		
Category 0		|  Muted Grey 20	|		#E5E9F0

Few notes:

  1. Using Danger 90 as highest level of severity allows us to be consistent with EUI. With this approach, the same color will be used in all contexts
  2. The palette doesn't change according to color mode (light/dark). The colors picked are contrasted enough to provide a 3:1 contrast with dark background, being accessible in dark mode.

Usage

This color palette will be provided as a list of color from which teams can pick according to their needs. Therefore it will be needed, from teams, to be a cautious in how it gets used and to make a couple of choices.

The main principle to follow would be the following, to always use the whole extension of this scale, which means to try to distribute your own levels of severity within proper groups of colors first (yellow for warning, red for danger zones) and to distribute them as much as possible.

This should allow us to get the following results:

  1. Maximise contrast between levels
  2. Always obtain our desired shade of red as most dangerous level. This will make the user experience the same every time, reducing the cognitive load. Main goal here is to be able to create a context in which our users can always associated our desired shade of red to danger that need immediate action.

An example of this use, picking the same scales shown in the first image of this issue:

Image

Which will get us this final result:

Image


Conclusions

This proposal is meant to be a solid base of colors that could be shipped quickly and be ready, if we are lucky, for 9.0. It's not meant to be perfect nor final, the conversation is still open and I would love to hear feedback from anybody who might be interested.
I do think though that, in order to start building a good user experience, the best would be to start having this in our library and eventually adjust it according to needs, rather than wait a long time before having this available for teams.

Please feel free to add anything to think it's relevant, apologies for the long issue! 😊

Use cases

Security - https://www.figma.com/design/jD6AMtmTTOSPKsdRMsqHIX/Severity-colors-Security-use-cases?node-id=1-19

@gvnmagni gvnmagni self-assigned this Dec 9, 2024
@botelastic botelastic bot added the needs-team Issues missing a team label label Dec 9, 2024
@gvnmagni gvnmagni added the Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins. label Dec 9, 2024
@botelastic botelastic bot removed the needs-team Issues missing a team label label Dec 9, 2024
@gvnmagni
Copy link
Author

A little update after a first very initial feedback from teams. Number of available levels and chosen colors have been received positively, while guidelines on how to use this list of colors can be improved.

An important concept that still needs to be investigated is the rigidity of usage, I would slightly reconsider the subdivision of colors into areas (danger, warning, neutral) in favour of a simple list of colors that are entirely available to teams to be used according to their context.

Some teams might need a lot of levels, some might need their severity levels to be as recognizable as possible, some might even want to use the same level color for multiple severity levels. I would probably avoid giving complex guidelines on how to use this, leaving on teams a bigger freedom, the only thing that probably needs to be fixed as a sort of main principle is that we should always use Level 14 (Red 90) to represent the highest level of severity in every context.

This would allow us to achieve consistency across the product, giving the user the possibility to understand the same color is always associated with the most immediate action needed.

I would use the following image, from now on, as a reference for this palette. I'll keep posting updates here so that we will have a reference for the ongoing conversation.

Image

@gvnmagni
Copy link
Author

An additional couple of updates in order to have full information and being able to set up a conversation in early January.

First, two main principles that I would personally introduce as only guidelines for teams to follow:

  • 1️⃣ If the severity levels available in a specific context are somehow associated with some meaning, it would be great to be consistent with overall share concepts. A very simple example would be a severity level called Warning, in this case I would strongly suggest to use yellow shades, which is a common and well known good practice
  • 2️⃣ The highest level of severity should always be associated with the highest level of color intensity. Regardless of the level itself (eg. Critical, Fatal, Alert...), we should try to use Level 14 of this color palette, so that customers will get used to associate that color to the most immediate needed action.

I believe that if we follow these rules, giving full freedom to teams to apply other levels according to their own needs, we will end up with a consistent use of severity colors in the end.

Second, we realised that teams were already experimenting with these colors and we thought it would be better to have control of the process in order to avoid ending up with tons of hard-coded color values.

EUI team has been able to include these variables (as proper tokens) in their latest release. This means that we can already start using them even if, potentially, they might change in the future. This will help us a lot, being able to point something already available to engineers instead of just pointing to design work (PR)

@gvnmagni
Copy link
Author

gvnmagni commented Jan 15, 2025

January 2025 Update.

We had the chance to share, with designers coming from all Solution Teams, the latest concepts and principles behind this color palette. It's worth recapping a little some of the points of this conversation and the feedback received.


01. Requirements

We took the chance to formulate again the requirements we had, briefly:

  • We need a consistent use of colors for severity levels across product (eg. would be great to use the same colors in all solutions)
  • We need a color palette that works both in light and dark mode in similar ways (eg. colors such as Black won’t work since alternatives would be needed)
  • Colors picked should be included into EUI and Borealis in order to be easily updated in the future

02. Colors

The color palette chosen includes 3 tints (Blue Grey, Yellow and Red) in order to cover 3 semantic typology of levels (Low levels, Warnings and Alerts). In addition to these a shade of Neutral Grey has been included in order to have a Neutral color to use in case of need.

The palette provides 15 levels of Severity, all the associated colors passes accessibility contrast (3:1) for visual shapes on Dark Mode. For Light Mode an appropriate solution will be eventually provided with the High Contrast Mode.

FAQ

- Why only Reds for Alerts?
Red is commonly associate in Western countries with alerts and its intensity is a common practice, recognized automatically by people.

- Did we consider other colors? such as Pink? Purple?
Yes, there was an clear preference among Platform designers that a color palette that would stay into the Reds without introducing other colors would be the best but we are not excluding this option. There still might be the case in which introducing a Dark Pink could be useful for very specific edge cases in which that severity level is so severe that needs to be different at all costs. So, this option is still on the table but we suggest to avoid being the default option

- Did we consider using Black?
Yes, but unfortunately it introduces issues with dark mode. In dark mode Black would disappear, this means that we would need to find an alternative that would probably use a counter color, such as White. This unfortunately raises a few points, White is not associated with danger and it is too close to the lighter tones of the other colors included in this palette. In addition to this, if possible, we would prefer to avoid having two palette for dark and light mode, a case that we are thinking about are users working on the same kind of data but in different color mode, the communication would be problematic.


03. Principles

Two main principles, that gives a high level of freedom when using this palette while at the same time trying to give a little bit of guidance.

Image
Image


04. Feedback

A series of very valid points have been provided by designers:

- Stronger guidelines and recommendations would be helpful. What colors should we pick when we have 3 levels of severity? What when we have 4?
A series of recommended set of colors could be very helpful and will be provided.

- Will this number of colors provide too many choices for designers?
In some cases, yes, but this might also be required by other solution or pages (Discover is currently running with 11 levels of severity). Designers should probably make conscious decisions, in case of need we could always help finding the best solution

- If designers are free to pick their own colors from this palette, we will have inconsistencies across the product?
Unfortunately we have to be aware that it is impossible to have everything identical. In order to have that, all areas of Elastic product should be identical in terms of levels of severity and also semantic behind their name or value. This is impossible to reach and we are aware a certain degree of inconsistency will come inevitably. This is why Principle 02 is important, from my perspective we should try to reach uniformity on the most important information which is the highest level of severity

- Levels that are close to each other might not be distinguishable enough
True, but everybody should feel free to adapt this palette to our own context. In some cases having a pure color scale is fine, in other case we need the tell apart colors as much as possible. Both cases are fine.
Always keep in mind that a chart is an abstraction of data and will never be alone on a interface. We have legends, typically a table behind a chart, a label next to the icon, interactivity..)

- Can we reinforce these levels?
Yes, valid point, icons could help identifying these colors even more in the future

- Would it be possible to see these colors in real contexts?
Attaching a few images to show that, we can see these colors used in charts, badges and dot icons. (Colors have been picked quite quickly, needs to be checked with Security Designers)

Image

Image

Thank you for your support and feedback, I'll keep you posted with updates!

@gvnmagni
Copy link
Author

Update, January 20th 2025

After a few conversations, we realised how there is a considerable overlapping between Severity levels and Health/Status levels. Therefore, we would like to restructure a little this activity in a more comprehensive way.

I will keep posting updates as soon as a clear path forward is established.

angorayc added a commit that referenced this issue Jan 25, 2025
## Summary

Apply severity colors for Borealis theme.
#204007 (comment)

Update: ⚠️ As the final decision for severity color is still pending,
the temporary colors are the hard coded color hex:
#203387
`TODO` Borealis migration - move from hardcoded values to severity
palette elastic/security-team#11606

| Color token | Amsterdam|Borealis|
|-------------|------------|------------|
| Critical | euiThemeVars.euiColorDanger |```#E7664C```|
| High | euiThemeVars.euiColorVis9_behindText |```#DA8B45``` |
| Meduiml |euiThemeVars.euiColorVis5_behindText|```#D6BF57``` |
| Low | euiThemeVars.euiColorVis0| ```#54B399``` |

### Running Kibana with the Borealis theme
In order to run Kibana with Borealis, you'll need to do the following:

Set the following in kibana.dev.yml:
uiSettings.experimental.themeSwitcherEnabled: true

Run Kibana with the following environment variable set:
KBN_OPTIMIZER_THEMES="borealislight,borealisdark,v8light,v8dark" yarn
start

This will expose a toggle under Stack Management > Advanced Settings >
Theme version, which you can use to toggle between Amsterdam and
Borealis.



![Image](https://github.com/user-attachments/assets/78d64946-43fc-4400-bbb1-229d900b7f05)


### Checklist


- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

---------

Co-authored-by: kibanamachine <[email protected]>
JoseLuisGJ pushed a commit to JoseLuisGJ/kibana that referenced this issue Jan 27, 2025
…#206276)

## Summary

Apply severity colors for Borealis theme.
elastic#204007 (comment)

Update: ⚠️ As the final decision for severity color is still pending,
the temporary colors are the hard coded color hex:
elastic#203387
`TODO` Borealis migration - move from hardcoded values to severity
palette elastic/security-team#11606

| Color token | Amsterdam|Borealis|
|-------------|------------|------------|
| Critical | euiThemeVars.euiColorDanger |```#E7664C```|
| High | euiThemeVars.euiColorVis9_behindText |```#DA8B45``` |
| Meduiml |euiThemeVars.euiColorVis5_behindText|```#D6BF57``` |
| Low | euiThemeVars.euiColorVis0| ```#54B399``` |

### Running Kibana with the Borealis theme
In order to run Kibana with Borealis, you'll need to do the following:

Set the following in kibana.dev.yml:
uiSettings.experimental.themeSwitcherEnabled: true

Run Kibana with the following environment variable set:
KBN_OPTIMIZER_THEMES="borealislight,borealisdark,v8light,v8dark" yarn
start

This will expose a toggle under Stack Management > Advanced Settings >
Theme version, which you can use to toggle between Amsterdam and
Borealis.



![Image](https://github.com/user-attachments/assets/78d64946-43fc-4400-bbb1-229d900b7f05)


### Checklist


- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios

---------

Co-authored-by: kibanamachine <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Platform-Design Team Label for Kibana Design Team. Support the Analyze group of plugins.
Projects
None yet
Development

No branches or pull requests

1 participant