Update the color scheme for ethereum.org

[nloureiro]

Is your feature request related to a problem? Please describe.

On the continuous development of the Design system we set a core color scheme that it's works but still needs some improvements

This issue is an exploration of some options to extend and improve the design system, and it's open to anyone that wants to collaborate or give feedback

link to figma file
https://www.figma.com/design/tRjUmvmKl9Ns0wdxBEFOLv/DS-color-explorations?node-id=1%3A47&t=yn0vJzXTAHReMV3R-1

[ddannehh]

After dealing with some design tickets I'd like to explore this!
I'll try to refine the color system based on a global palette and creating relevant design tokens from this. It's more about a straightforward system than the color palette itself.
Let's see where this goes 😅

[TylerAPfledderer]

@nloureiro let me know if I can be of assistance here with the Chakra config!

[ddannehh]

Allright @nloureiro , sorry for the small delay, took a bit longer than expected but wanted to propose a color system that was a bit more expressive, have a wider range, but still easy to scale and maintain.
Creating a palette is one thing, but creating a system that is solid is another. 😅

The palette

I've started with gathering the colors that are currently used in the .org brand and illustrations. Started expanding and iterating from there :)

A lot of tweaking was about making sure the palette is usable in Light- & Darkmode while trying to limit the amount of colors per hue. The original "branding" colors are still there (circular shapes).

Full palette:

Not all of these colors will be used by UI elements but are definitely good to have when creating future artwork/gradients/illustrations or use in graphs and so on.

The full palette would be added to the file as vars (e.g. $palette-neutral-100,-200,-300,..) but should not directly be used by UI elements (you can control this in Figma). However, UI specific color tokens, e.g. $color-background-layer-1 or $color-background-layer-2, will make direct use of these values. This way if someone wants to create a UI layer the DS controls which grays are allowed to be used.

The UI tokens

The goal here was to broaden the set of tokens but keep them easy to apply across different components. It's clear the current system prioritises to have a small token set but in my opinion the options are a bit too restrictive resulting in a harsh look and feel at times.

When the token set is too limited, changing a value from a token is very unpredictable with a website this big. For instance, if I want to change the secondary body text color to slightly darker gray, I'm basically changing every component. I also think there's room to add more nuances that will make for a more visually appealing experience and more relaxed reading.

I propose we categorise color tokens by the most important top-level UI element primitives (text, background, border, icon,..) and add a bit more of the nuance on each level. So, if we want to set a border color we are not restricted to contrast levels of the primary text tokens but rather presets that are better suited for borders/lines.

You can still have a single token like $color-background-purple that can be used for different type of components like background for a button, an active checkbox, radio button, perhaps a banner and so on. If at some point the value changes we'll have a beter idea of the impact.

Note: in figma you can't use a token and change the transparency (while in code you can background-color: rgba(var(--black), 0.9);) so in figma you need to detach it for the raw hex with custom transparency. That's why you currently see #FFFFFF 95% instead of white 95% I'm hoping this is a feature they announce next month on their yearly conference._
Documenting these values in figma helps to keep track as well will make it easier to have an overview for developers too. Figma doesn't make it easy to consult this in devmode (yet).

In figma, when creating a new component that needs a border, you can just type "border" in the styles library and pick the one for the job, like subtle, default, strong or bold. If it's an interactive component, you can swap out the $border-subtle style to a $border-subtle-hover style on hover.
Note, as you know, these decisions are primarily when creating a component, not when using them in a design since they come with the default styles attached.

Since we're dealing with a category based structure we can also limit the uses of each token. For example, we can limit the use of all the $border-... tokens to only show up when adjusting the stroke value on an element in Figma.

When adding new tokens it would always be important to try and make it multi-purpose, avoiding component specific tokens. The hardest part is probably the naming. The overall goal still remains to keep the token set as small as possible.

Use of transparency

As you can see in the token values above I've made use of transparency this allow the components to be more adaptable to their environments.

The current DS only uses solid colors and could result loss of contrast when using the same component on different backgrounds. For example: If you have gray border around an input field and place it on a gray background the border will become much less clear. So you either have to bump up the contrast of the border that it's visible on both (which is the case in the current system) or create an exception for that background. If you use, let's say .24 Black, it's visible on both backgrounds since the underlying color shines through. Another example: When the secondary text color is a solid medium gray and you use it inside a red banner the text will be barely readable. If you use .56 Black, it's not only readable but inherits a bit of the underlying red as a bonus. Not saying this example is apparent on the current site but I feel like some design decisions have been made to counter this.
Quick example:

So with that being said this is where I'm currently at. I've tested all of the above on a couple of components with pretty good results. See below.

I've opted for purple as key color for primary buttons, I like it personally but can easily be changed of course.
While the current proposed system has a bit less contrast in comparison to the current implementation it should be easier on the eyes when the site is read by visitors with decent eyesight. I've personally had some eyestrain while reading the white text in darkmode in the current. If this is a concern we could easily add a high-contrast modes for visitors with poor vision. Basically extra themes where the contrast is turned up a notch for specific tokens and maybe adding the option under the LM/DM Toggle in the navbar or something.

I'm planning to put in some further testing and recreate some existing pages to have better before/after comparisons. So probably still some changes expected. Will update soon!

In the meantime I'm looking forward to any feedback on all of the above and also what you guys think of the approach in general.

Cheers! ✌️✌️

[nloureiro]

@ddannehh, this is awesome! Thank you!!!

I will need some time to go over this in detail.
Do you have some time next week to jump on a call to review all this and the design system stuff?
I think it helps to understand all the details of your great work. Understand if you can't, no worries.

[ddannehh]

YW! We sure can if something isn't clear.
Still want to do some further testing with actual content to see if the theory holds up. I'll post updates here.

[nloureiro]

YW! We sure can if something isn't clear. Still want to do some further testing with actual content to see if the theory holds up. I'll post updates here.

Ok. let's keep the coloration on Figma.
Thank you for the great work.
I did a first overview of your proposal and liked it a lot.

The things that stand out the most are:

Can we use purple as our primary color for both themes? Maybe two shades, but I always wanted to unify the primary color for branding and attention purposes. Can we try this?

• Test adding more colors to the main palette to create dynamic visuals. My idea is to use the brand colors as a base and go from there.
• the red button is been the only pushback until now... if not for a good reason, we should only use a red button for cancel actions, and in our case, I think we don't have a use case for it

I'm in the process of exploring a new design for the homepage based on the wireframes and these colors come in the perfect timing

LFG!

[ddannehh]

Sure, was planning the fiddle around with some actual content anyway, just to battle-test a bit further. I'll keep the purple in mind for important CTA's and more of a branding element.

Totally agree about the red button, these are just tests, will probably be very uncommon and should only be used for negative outcomes. But good to know that the option is there. Just like green, yellow, blue.. ;) They work should we ever need them.

Do you like the token approach and its organization as well? It'll probably get some additions while exploring further. TBC!

[nloureiro]

Sure, was planning the fiddle around with some actual content anyway, just to battle-test a bit further. I'll keep the purple in mind for important CTA's and more of a branding element.

Totally agree about the red button, these are just tests, will probably be very uncommon and should only be used for negative outcomes. But good to know that the option is there. Just like green, yellow, blue.. ;) They work should we ever need them.

Do you like the token approach and its organization as well? It'll probably get some additions while exploring further. TBC!

on the red button, just a radon add-on.... red only if your brand allows, like optimism for example.

On the design token, I would like to keep the same structure as much as possible. @TylerAPfledderer and I worked on it recently, and it made sense from the DS perspective and the Code side.

Do think it's possible?

[ddannehh]

I don't think it's possible without refactoring. Things can evolve right? 🥹
It's just the better way to have better control over component colors.

Quick summary of my earlier points

More functional tokens, but with restrictions.
Separate tokens for backgrounds, borders, text and so on. This way it's super clear what the options are for element styling. You can even limit the visibility of tokens to specific properties (border properties only accessible on the figma stroke menu). Currently you have "base, medium, light". This is used for a lot of different things. So I can't have a subtle stroke around anything since those are the only options. Which are mostly calibrated for text as far as I can see.

Predictably
When you change a functional token like $border-disabled in the proposed system you know exactly what will be changed -> All the borders on elements that are disabled.
In the current DS, lets say you want to change the color of a disabled border because you want it to be slightly less visible, now you'd have to change $disabled, but in doing that you also change all the disabled texts, because they all use that token as well, which have now become unreadable. These two items do not play by the same contrast rules and are preferably not using the same token.

Not component specific but still shared between components
When you add new functional tokens let's say $background-layer-3 & ...4 other components can start using these as well. So you don't have to end up with component specific tokens like the recent new menu, which have their own set of tokens.

What are the downsides you think?

In general, like I said earlier some parts of the website and components have a somewhat brutalism vibe to them, and I think its partially due to the way the tokens are set up. It feels like your only options are white gray or blue highlight. For a website that is mostly about reading, this limits the ability to create a more relaxed, nuanced, not-so-heavy-on-the-eyes experience. If there's a great need for a high contrast version I'd just create 2 additional themes (one for light, one for dark) with the value's a bit higher.
To me this was the nuance I needed for being able start creating pretty components/pages. I probably have some more suggestions when I get to it.. SORRY! Just trying to help out here :)

Anyway, I know this is something that is not done overnight and requires some refactoring but I personally think the DS will benefit from this approach in the long term. I'm certainly not advocating for this to be implemented asap or anything but maybe it's worth considering at some point..

[TylerAPfledderer]

@ddannehh @nloureiro I'll note here that the Chakra team likes to take a similar approach with tokens. Check out this config for semantic tokens in the PandaCSS doc site.

https://github.com/chakra-ui/panda/blob/main/website%2Ftheme%2Fsemantic-tokens.ts

For example, I usually see various token groups like bg-color-token for background colors of various shades, and fg-color-token for foreground colors.

That's to say, I don't have an opinion on this, as Chakra is meant to be flexible with this!