Colors - PF colors for severity levels

[jamestalton]

Several products need colors to indicate severity levels. Instead of the products each defining these separately PF should provide those colors. That way that can be used for icons, text, and charts consistently. In addition, PF can adjust the colors for the PF dark theme.

Different use cases might have a different number of severity levels, usually 3, 4 or 5.

Examples: Lowest, Low, MediumLow, Medium, MediumHigh, High, Highest, Critical

[mcoker]

To add to this, I think we should consider all of the types of states we want to be able to support and theme, as well as simple uses of colors that may overlap with states. For example, for "red" things, we have:

• "red" as a literal variation - labels and banners
• "invalid" - an invalid value for a form element
• "error" - something bad happened, an error alert for example
• "attention" - nothing's wrong or invalid, it's more of a severity - like the notification badge or a banner

These may all be the same red, but should they have separate tokens that can be customized, and inherit intentionally? For example - this is just an example of that type of customization/inheritance, and is likely wildly inaccurate for how we would want it to end up behaving:

• "error" sets the base color - it's value is a red palette color - red-[number]
  • "invalid"'s value is whatever the "error" color is (if error is updated to `red-[different-number], invalid also updates)
    • "attention" is set to whatever "invalid" is
  • "red" inherits whatever the "error" color is

This produces:

• Update red-[number] to something else - error, invalid, attention, and red are all updated
• Update "error" and all are updated, except red-[number] remains the same
• Update "invalid" it also updates "attention"
• Update "attention" and only attention is updated

This goes for all statuses potentially

• "green," "valid," "success," low priority severity
• "blue," "primary," "unread," "info"
• and so on

Also I think it would be great to get away from using literal color names as the multi-color variation name for things like labels - ie, change "red," "blue," "green," etc to "multi-color-100," "multi-color-200," "multi-color-300". That way we can make updates to those palettes and they aren't tied to literal color names. This is essential for theming, and also allows us to define them in a logical order in which they can be used. In charts, we have both palette color scale vars/tokens and multi-color scale vars/tokens (also unordered multi-color)

[mcarrano]

@mcoker @mceledonia Should we be considering this as part of our global variable refresh?

[andrew-ronaldson]

@smckinno is picking this up. Wanted to share the progress with a link to the Sketch file

I started testing a wider range of severities but the colour accessibility plays a factor in these decisions.

[smckinno]

@andrew-ronaldson Wrapping up this effort - Here is the documentation and the Sketch Link. Feel free to check it out! Sketch Link: https://www.sketch.com/s/6cd8d222-b3cd-461d-b15d-d1d4ee331b48 Documentation: https://docs.google.com/document/d/1-4ocLt9Ijcu5amiX7u_U6au17N4wCqDTYGh8ZiPu7mQ/edit?usp=sharing