-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update the color scheme for ethereum.org #12966
Comments
After dealing with some design tickets I'd like to explore this! |
@nloureiro let me know if I can be of assistance here with the Chakra config! |
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. The paletteI've started with gathering the colors that are currently used in the .org brand and illustrations. Started expanding and iterating from there :)
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. The UI tokensThe 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 Note: in figma you can't use a token and change the transparency (while in code you can 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 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 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 transparencyAs 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. 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. 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! ✌️✌️ |
@ddannehh, this is awesome! Thank you!!! I will need some time to go over this in detail. |
YW! We sure can if something isn't clear. |
Ok. let's keep the coloration on Figma. 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?
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! |
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. |
I don't think it's possible without refactoring. Things can evolve right? 🥹 Quick summary of my earlier points More functional tokens, but with restrictions. Predictably Not component specific but still shared between components 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. 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.. |
@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 That's to say, I don't have an opinion on this, as Chakra is meant to be flexible with this! |
conversation from figma to github to keep the history alive and not in figma comments
I wanted to double-check with you up to where you are comfortable to go. 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
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) |
Allright, so quick speedrun through the updates. Small demo from live page 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.
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.
Since there are almost no components currently using the red color, it'll be pretty straightforward to add to the current DS.
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 ;-))
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?
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 |
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
The text was updated successfully, but these errors were encountered: