[EPIC] Allow users to be able to edit palette and default color theme in existing design system

[aaronreed708]

Suggestion/Concern

Currently it isn't possible in Theme Builder to change a color in a color palette. Only new colors can be added. One of the reasons for the current limitation is the challenge of handling the fallout that could happen due to such a change. It is also likely that the fallout may not be completely managed without human intervention.

For example, if a user changes a color, what happens to all of the molecules that were already using the original color? What if the original color was the primary, secondary or tertiary color defined in the default color theme? Which other default color theme values would be impacted? Which atoms depend on the affected color theme? Which "on" colors would need to be recalculated?

The goal of this issue is to design how a color change could be made by the user, how the application would communicate to the user the impending issues that might arise from the change, what default values could be used until the user makes the manual updates, how is the user made aware of what manual updates need to be made, etc and then implement those designs.

Proposed Solution

When this work is complete, an end user should be able to load an existing design system, add or delete a color from their color palette and modify the primary, secondary and tertiary values in the design system's default color palette. As such changes happen, the user should receive information relevant to the changes that they have made so that they are well aware of what issues that such a change can have on the design system, what default values Theme Builder will use in an effort to keep the design system accessible and what, if any, manual changes/decisions the user may need to make in order to ensure that the updated design system remains accessible

The tasks that we need to complete to get the functionality that we desire:

• Ability to manage the color palette, even after design system has been established
  • [TB] Implement Core Settings page for building themes #914
    • allows user to provide core settings required when creating a new design system
  • [TB] Implement Build Color Palette page for building themes #916
    • allows user to add colors to the palette
  • [TB] Implement shade editing dialog for building themes #917
    • allows user to edit shades in the palette
  • [TB] Implement Required Changes Review page #918
    • provides user with insight on what changes the proposed shade editing will result in
  • [TB] Implement color deletion capability #919
    • allows user to delete colors from the color palette
  • [TB] Create Stepper component #977
    • introduces a stepper component, allows user to preview the component in the Components tab
• Ability to edit the Color Theme of the design system, even after the design system has been established
  • [TB] Implement Light and Dark Modes page for primary color #920
    • allows user to specify the primary color when creating a design system
  • [TB] Implement the Default Colors panel #970
    • allows user to affect the White, Black and Information color palette for Light and Dark modes
  • [TB] Implement color dependency identification logic for a design system #971
    • allows Theme Builder to determine what downstream components will be affected by a color change
• [TB] Change default design system, atom defaults to match wireframes #968
  • Update default design system theme to match wireframes?

For post MVP, we need to provide the user the ability to:

• [TB] Implement the Adjust Hue dialog #973
  • allows Theme Builder to determine adjust the hue on a set of shades for a given color
• [TB] Implement Dark Mode color editing #976
  • allows user to modify each of the colors in the dark mode color theme

[aaronreed708]

Dependencies
The thought, guidance and designs arising from the following issues will be the basis for this epic.

• [REQUEST] Design UX for changing a color #529
• [TB] Do Design Thinking around color updating #738
• [REQUEST] Correctly handle upstream changes that cause conflicts #664

TODO: we need to create the tasks (and corresponding issues) that will comprise this epic and define the implementation that we are looking to achieve.

[lwnoble]

Figma File: https://www.figma.com/file/Co8gYdDmE64Wv90eWy9FwE/Mentorship---Edit-Theme-Builder-Colors-and-Themes?type=design&node-id=0%3A1&mode=design&t=mVcIZra821J3XrUe-1

[PaulaPaul]

Questions / comments from 'dry run':

• Set the overall context for what we expect from the mentee (writing code in the SDK? creating Figma designs?)
• Include 'what is Hue/Chroma/Luminance'
• What would prevent a mentee/developer/user from creating colors
• Can we create / refine issues for the mentee to get started on?
  • Rendering the AA and AAA
  • Adding the chroma piece
• Can we schedule a session with Paula/Cody/Keith on navigating the SDK
• Work with Keith - is there a video we can use as an overview of the SDK (@aaronreed708?)
• In the Figma, can we note what exists, can or can not edit, and what is new/needed?
  • In the flow for Adding Theme Colors, is there a simplified flow or overview before the complex frames? Toggle for showing light mode/dark mode?
  • What do each of the individual Add buttons do for each section on Light/Dark mode (there are Figma diagrams for these)

[aaronreed708]

@lwnoble is there any way to give us dev access to the Figma file for [EPIC] Allow users to be able to edit palette and default color theme in existing design system? So that we can see the CSS? Or can you generate a TB design system that @omesh-omg can use for the new changes?

[lwnoble]

@aaronreed708 and @omesh-omg This is the V2 Figma File I have been working on that uses the latest Figma collections/mode features. https://www.figma.com/community/file/1370860352426050797/v2-theme-builder. There are several complexities - 1.) I can only share my personal Figma file with @omesh-omg but you need an organization or enterprise license to access Dev Mode. 2.) Discover will not allow me to share files with external folks (even myself with my personal figma account) 3.) Next, the Figma file does not render the css - Cody and I are using Style Dictionary to render the css. I will work on proving the css architecture for the team and sample files. 5.) I need to map out the new format for exporting the JSON as we will not export both moving forward.

[aaronreed708]

I found this which seems to explain what hue, chroma and luminance is in words that I can kinda understand: https://sites.harding.edu/gclayton/Color/Topics/001_HueValueChroma.html. Many other were even worse to understand. We should see if @Chessel or @lwnoble have a better suggestion.

[aaronreed708]

Per @lwnoble in today's Theme Builder call: the color differences between the current Theme Builder default theme and the wireframes being used for the new UI changes are unintentional. The color changes in the wireframe are because the mockups were done using Figma Enterprise with the default Discover theme and palette. We should continue to use the default design system in Theme Builder to implement these wireframes.

[toni-sharpe]

HSL Definition:

Hue: is a wheel of colour that rolls round from red, through orange, to yellow, then green, blue, purple and finally back to red. Typically it runs through 360 degrees, like a compass. Note that there is no pink. Pink is really light red, you'll notice on some artists paints that the pinks are in the red range.

Saturation: is the amount of hue in the result. Usually a %. Set to 100 it's as much colour as possible, set to 0 it's greyscale.

Lightness / Luminence: Two words that mean roughly the same and start with L. Again, usually a % with 0 being absolue darkness, the absence of light. Technically this hasn't been acheievd by humans although there are paints that absorb 99.9% of light. 100 is the opposite. The result is a scale from black to white, which goes through all levels of the selected hue, at the selected saturation.

HSL is usually much simpler for people to understand, whereas mixtures of RGB are more computer focused. Monitors use a mixture of R, G and B to produce the range of colours, which we know from hex codes in CSS, whereas HSL puts the colour into one place which we understand because it is closer to what we see then uses saturation and lightness, again, a closer match to our experience with eyes, assuming signtedness.

It's also much easier to do arithemtic with.

In CSS

I'll let the excellent CSS Tricks site explain how it works in CSS style sheets.

And the MDN docs, just because they're great.

CSS also has an alpha property is HSLA, that defines opaqueness.

An example

In these examples look at the bottom left for "Current" colour.

A hue change

You can see how the S and L portions are the same but the Hue selection is moved.

Greyscale

Here we see the exact same Hue and Lightness as the previous example, but the removal of all saturation results in grey. This grey would be the same regardless of hue.

Black

Here's rthe same hue again, this time with no lightness, resulting in black. The same applies where this occurs with any hue.

Final note

HSL is really syntactic sugar for referring to light from a luminent source, in a computer it's convered into RGB for display; this is different from light reflected off an object (like something painted) which is why RGB are primary on screens, and Red, Blue and Yellow are primary in paints.

I'll leave colour there for now, hope this explanation helps. The topic can take a life's work and I'm no expert by any means.

Please tag me with comments, let's keep the knowledge in one place (I'll move this if there's somewhere better, just let me know)