Theme Builder Looking ahead

[aaronreed708]

In Progress

Updates to color calculations.

Dark mode text contrast calculations
Presviously we were calculating dark mode text contrast to the background by gettting the contrast of pure white (#fffff) to the background and multiplying that contrast by .6. This leads to inaccurate results. Now we calculate the contrast of the text by mixing the background with white with an opacity of .6, rendering this to get the resulting hex value and then getting the contrast of that hex value to the background.

Color scales
Previously we generated color scales by only increasing and decreasing the light and darkness of a color. In my research I discovered that the chroma of a color should increase up to the 700 shade and then go down. More about that here: https://colorspace.r-forge.r-project.org/articles/hcl_palettes.html We are now calculating color scale adjusting the chroma using the triangle approach outlined. In addition, we allow users to set a max chroma to prevent colors from becoming too saturated.

New logic for dark mode
In dark modes for both WCAG AA and AAA calculations there is a huge jump between the last shade to have a dark on-color and the first shade to have light on-color. To minimize this we find the darkest shade possible of the color with the dark on color and the lightest possible shade to have a light on color. We then scale the colors between the lighest shade 050 and the last color with a dark on-color and then scale the colors between the first color with light text and the darkest shade the 900 color. This creates a smoother color scale in dark mode.

New adjust hue functionalty for the 050 and 900 shades
When you adjust colors with chroma sometimes you can get results that you don't quite expect. Yellow may shift to a more green hue, for example. We have introduced the ability for users to adjust the hue of the scales at either end of the color scale, 050 and 900. Colors then are scaled in between the 050 and the base color (the orginal color the user entered) and then between the base color and the 900 shade.

Color and Theme Adjustment
Previously, the color and theme generation user experience was linear and changes could not be made to the new theme after you declared it complete.

Now we allow users to update color and theme settings. When changes are made, the logic to maintain accessibility across the design system is re-run in both light and dark modes in WCAG AA and AAA. Any downstream updates that are required to maintain accessibility are presented to the user before their changes are committed. Some updates may be suggested rather than required. The user may then choose to make those changes or opt out.

Code Generation

Currently, Theme Builder can generate both CSS and JSON design tokens that represent the design system created by the user. The user can copy the JSON design tokens and paste them into Figma as Figma Tokens in order to see a Figma file re-render using their design tokens.

Moving forward, we want to connect Theme Builder to a GitHub repository provided by the user. Generated JSON would be pushed to the GitHub repo whenever the user hits save in Theme Builder. GitHub actions would trigger Style Dictionary script that would convert the JSON to CSS (XCode, Android, etc). The user could also have the repo connected to Tokens Studio or Storybook. The updates would be pushed to those tools and render updates reflecting their brand styling.

Elevation Calculations

We have added new logic to assure accessibility when elevations are applied in dark mode. In dark mode the background colors get lighter as elevation increases. This can cause contrast issues that make components and styles non-accessible. Hence we will apply the following logic.

For every background color we calculate what the new color will be when lightened for each level. We will make sure that the button color works on all elevations, for consitency, and then will update the following at each elevation to reflect the elevation change and stay compliant: background color, on-color, border color, quiet text (which is typically the on-color with some level of opacity to de-emphize the important of the text). These are contrast pitfalls in dark UIs.

Future Vision

Bring your own code

We are proposing a new feature that allows users to bring their own code for each component.

They can cut and paste the code for a button into the UI.

Because the naming conventions may differ from the Design File UI and the Coded component UI, we allow the user to provide the names of the components and variants, in order to generate the proper output.

In addition Theme Builder creates a parent container around all clickable UI components (checkboxes, radio buttons, slider handles, swicthes, etc.) so as to adjust for varying target areas. We will provide the user the opportunity to identify clickable elments so that we may add a parent container.

Accessibility Audit

Once Theme Builder is connected to GitHub, updates could be pushed from Tokens Studio or Storybook to that repo. Such an update could trigger an accessibility audit to see if the incoming changes break any WCAG requirements in the design system in light or dark modes or in WCAG AA or AAA modes. In the Theme Builder UI a notifcation would alert the user of an exteral update. If Theme Builder identifies required or suggested edits, these would be outlined for the user. If no edits are required, that would also be indicated to the user.

Adding Components

The goal of Theme Builder is to streamline the design-to-development lifecycle and keep everything accessiblity compliant. In furthering our efforts to provide this functionality, users will be able to add new components to Theme Builder. We envision that code could be generated by Figma or a Figma plugin from new components built in Figma using Theme Builder components, styles and variables (which are connected to Theme Builder tokens). The code exported from Figma could then be pasted into Theme Builder to add a new component.

Removing Components

Users will be able to remove components that they do not want in their libraries.

Adding new variants

Users can add new variant or new values to existing varient to a component.
Adding new variant requires the user to provide a name and values for the varient, then providing the design tokens for each value. And example of a varient and values would be a varient called Icon: with values of none, left and right.

Renaming Components, Variants and Values

amzn/style-dictionary#395
To overcome the differences in naming conventions from Figma design components to the user code components we could provide a UI for the user to update the names of components and any children frames/divs as well as the variant and value names. They could have an input field to add any new library code (react, angular, node, ect) and a window to add any new css. The JSON code and the style dictionary generated CSS would be updated to reflect any name changes provide for the component, children, variants and values.