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!

[nloureiro]

conversation from figma to github to keep the history alive and not in figma comments

Yeah wanted to do a design a real implementation just to make sure everything is looking solid; no contrast issues or color mismatches, etc. I did some tweaking on the colors while building so good I did.

In terms of what the next steps are, not sure, I'm pretty confident the colors will work out for the most part. There's lots of different parts of the website I could iterate on, revise, try to make better, but I'll end up building a whole new version of the components and DS in parallel. 🤡

I wanted to double-check with you up to where you are comfortable to go.
You’ve made an extraordinary contribution already; I don't want to push it too much.
Based on our current progress, I believe the next steps involve breaking down the project into smaller tasks and establishing clear actions for each of them.

1- colors: you are moving in the right direction; love it!!! I want to test some small changes myself but I think you are almost there
1a. - the reds are where we all start > do you think we can isolate this on the main design system and change there based on what you have here
1b. - Purple as the primary color on both themes > something I wanted to push, and you kick start it >>> On this file, we can make a proposal to change the design tokens, and I will open a PR to test this on the code (the best way to see if it works)
1c. - complementary colors to purple >>> We should make a solid proposal on this and see if we can add new design tokens. I think we can add a look at current pages and point out where they change color >>> at the same time, we can incorporate this on the new design for the homepage

2. Gradients: I would love to explore some of the new gradients, radial and so on
   2a. - The new homepage can be great for pushing this and testing.
   2b. - eventually, we can do it on other special pages too
   2c. - look at the DS main file and make the changes to be added to the DS to code pipeline.

3. Components: You made some proposals here that clearly show improvements.
   3a. - isolate some of them and see if we can still use existing colors and make them work. If yes, we can isolate and make an issue so someone in the community can code it

It’s a lot to do. Do you think a call can help? Or should I create independent issues on GitHub for some of these?

(Adding this to GitHub too, easier to have conversations than here)

[ddannehh]

Allright, so quick speedrun through the updates.
Goal was to get the colors on a real life page to see if it holds up.
I've tweaked some of the colors in the process but I think we're at an okay version of for a fuller palette now. Transparency values for b/w are also included.

Small demo from live page
Started from the Staking as Service page as reference
See Lightmode implementation
See darkmode implementation
Note: left out some of the graphics for now to focus on the palette.

In the process I've also set up a Typography Mode with variables heading,body & mono type styles and more props for font-family, -size, line-height, letter-spacing and weights. This way you'd be able to choose on Artboard level what you are designing for. Try changing the font-family in the local variables, it's pretty cool (devs will shrug at this).

Furthermore I've updated the stickersheet (Lightmode + Darkmode) with some ideas more I'd like to try out on some other pages.

Did some further exploring with gradients on specific sections.
Hero light mode
Hero dark mode
Code samples light mode
Code samples dark mode
I've also experimented with some gradient variations for headers in general. Feel free to take a look at those and the other things in the figma file. Note that these are just tests but could perhaps be useful as a base for when revisiting other custom pages.

I wanted to double-check with you up to where you are comfortable to go.

In terms of where I'm comfortable to go. If you feel these things have value I can continue building further on this. In the sense that I'd like to continue to build some more fundamentals and actual components with this system, testing them on pages and so on. Iterating on the current elements and improve where possible. I guess more like a broader side-track project instead of a single issue thing. Ideally I can get it to a state that includes all current components. Basically building a system that I would find a joy to use myself. I'm keen to see what additional DS features Figma will launch in a couple of weeks and get to the bottom of those as well.

If you don't mind me exploring further in this way I'll try to add documentation for each component on separate pages like it is now so IF we want to make a case for dev and implementation we have a good way to link it.

1a. - the reds are where we all start > do you think we can isolate this on the main design system and change there based on what you have here

Since there are almost no components currently using the red color, it'll be pretty straightforward to add to the current DS.

1b. - Purple as the primary color on both themes > something I wanted to push, and you kick start it >>> On this file, we can make a proposal to change the design tokens, and I will open a PR to test this on the code (the best way to see if it works)

Yes, would need to be tested with the if it fits the live palette and surrounding elements. There's a lot of elements that are currently blue (primary color token). I don't think just swapping them with purple would be a good idea (secondary outlined button, links,.. could cause issues imo) > Great example where a more functional tokenset would be beneficial ;-))

1c. - complementary colors to purple >>> We should make a solid proposal on this and see if we can add new design tokens. I think we can add a look at current pages and point out where they change color >>> at the same time, we can incorporate this on the new design for the homepage

This is a big one, basically every component would need to be refactored in the DS and to be assigned new vars, same for the components in code. I think some dev input on how to approach this would probably be advised. Maybe a bit early, not sure, feels like you could end up with a Frankensteinesque website. Although I'm not sure this is completely avoidable. Maybe there's a way to develop iteratively without "publishing" until most things are taken care of?

Gradients: I would love to explore some of the new gradients, radial and so on
2a. - The new homepage can be great for pushing this and testing.
2b. - eventually, we can do it on other special pages too
2c. - look at the DS main file and make the changes to be added to the DS to code pipeline.

Components: You made some proposals here that clearly show improvements.
3a. - isolate some of them and see if we can still use existing colors and make them work. If yes, we can isolate and make an issue so someone in the community can code it

This is the part I'm a bit worried about, refactoring the current figma DS will be a tedious job. Not fun work and a lot of it will break. The clean up is large job. Perhaps this is why I'm inclined to explore further on "happy island" until I've got something to show for and ignore it for now :D Best case scenario, we can just use the new file, but I understand there's a workflow in place that requires a slower transition for stuff like this. Not too familiar with the hand-over process and dev timelines.

Please, let me know if you still see value in me contributing this way @nloureiro
✌️✌️