🎨 Color System

[brandonhaslegs]

Hey y’all, so I’m working on creating a more systematic way of designing in Figma (Essentially a design system). We’re only two designers but having a well-made modular system in place makes things much easier to design and is much more realistic when it comes to achieving parity between Figma and our front end.

One thing I love from well-made apps is color theming. Most commonly this theming manifests itself as Dark Mode and Light Mode but it can manifest itself in more exciting ways. Look at how the Pocketcasts and Apollo apps do themes (below). Both apps also allow the user to change the app icon theme too. So fun!

---

So the first thing I’ve built out is a levels-based system of greys.

It was important not to use words like “dark” or “light” since those ideas go out the window when you switch to another theme. Here’s the naming I chose:

Background
The color that the interface sits on. In light mode, it’s normally white, or off-white.

Foreground
The color with the highest contrast against the background. (in light mode, it’s normally black or near-black).

Levels 1-6
Shades of grey connecting the Foreground and Background. This is not a purely mathematically interpolation between the background and foreground. I chose the values specifically for their use in interfaces.

---

Help!

One thing I’m still kinda struggling with at the moment is deciding whether we adopt this full on 6-level system in the color set too. So far I just have the core colors (which don’t change between the two themes) and a Dark, Light, and ExtraLight variant of the core colors. Breaking my own rules here by calling them Dark Light and ExtraLight… Should probably just rename to Level 1, 2, and 3…

Anyway, do you think we need a full level system for the colors?

In my experience, I’ve only ever used one tint when designing interfaces. I think it’s not necessary to build in the full range of six levels that you have with greys. Mostly I just need a “faded” version of the color and the core color. For example:

Would love to know if, in your experience, you’ve come across the need to build in a full 6-level system for colors, or if that’s overkill.

---

One final note: If we build our Figma design system like this, and also build our front end on this system, then turning on Dark Mode, or app theming in general, will be much easier. I can imagine theming also existing on an org level similar to how Slack lets you change color themes from workspace to workspace. So not just app-level theming, but allowing the user to choose different themes for their different organizations.

---

Here’s my Figma file if you want to look at it a bit closer.

[fintohaps]

Not sure how relevant this is, but more variety in colours is useful when it comes to workflows like adding labels for issues. For example, in GitHub you can choose the colour for your label (or randomise it), so that they can be distinct and recognisable.

Maybe if we identify more artifacts like that, it’ll answer your question?

[cloudhead]

Super interesting! From the perspective of having a design system that can be used by people outside of the core team to build applications in the radicle ecosystem, I would err on the side of simplicity.

[brandonhaslegs]

I thought about this a bit with @Julien. We figured we could do this outside of the standard UI color set, and the label colors just wouldn’t change between themes. But… I suppose label colors should adjust between themes. I wonder if there should just be a finite amount of colors to choose from for labels… would that be bad? Do organizations typically use a ton of labels? I know we only use 9 on our GitHub.

[fintohaps]

Ya, I’d like having some colour theme to choose from. Would make the workflow v pretty But how many labels people use, I’m not sure Paging community rep @abbey

[Julien]

So some of the other code collaboration platforms allow you to edit the label colors yourself. This means that they can have consistent if they have complex labels systems, like having multiple types of “bug reports”. I don’t know what we’re gonna do there ourselves as in a first version I’d go for either all labels being the same color or the label text defining the color or the label (this would mean that “bug” is the same color in the entire app, which is nice). In the long run I would either have custom label colors which allows a user to pick any color or we have specific colors for specific labels.

To the larger question of having 6 levels of colors is in my opinion not necessary. We risk having tons of inconsistency in what level we use for what as we design more and more features. I think we might even be able to get away with having 1 set of core colors with just a lighter version and darker version and that’s it. And then if we need more colors, maybe we can just expand the core colors (with the coinciding darker and lighter version).

[abbey]

@fintohaps: I think it depends on the project! You can see the differences between react, rust-lang, and go-ethereum.

Seems the most customization you allow, the more complex the labeling can become. Ultimately I think it’s the text of the label that truly matters and the label colors are mainly for aesthetic differentiation UNLESS they are signalling a simpler, global communication pattern (i.e. critical = red). This is really valuable!

@Julien: I think that starting with the label text defining the color of the label and having a consistency across the product is a great idea. We can always introduce more customization in later versions.

[NunoAlexandre]

@Julien

I don’t know what we’re gonna do there ourselves as in a first version I’d go for either all labels being the same color or the label text defining the color or the label (this would mean that “bug” is the same color in the entire app, which is nice)

I like the idea of having a pre-defined set of labels that are consistent across the whole app. It should be a ‘small effort, good value’ piece of work. Should that pre-set be theme-dependent? I can imagine that a red label in a dark theme won’t work well.

As for future further customisation, it’d be cool that the set of colours we provide the user to choose from are categorised by some well established meaning. For instance, “Serious” with have red, orange, black, “Informative” with blue, green, etc. That would guide users into choices that have some science behind and thus create more intuitive and consistent colouring across projects, as well as reduce or ease the cognitive load of choosing.

[rudolfs]

@brandonhaslegs

Anyway, do you think we need a full level system for the colors?

I really like the proposed color system change, especially the new more abstract naming!

Looking at what we have in the app right now, it seems like having the core color plus a maximum of one shade and one tint has covered most of our needs, so in that regard, I think we don’t need the full 6 levels.

However note, that the tints and shades that we used were quite specific to the use-case, like in the alerts component (border vs background):

Also buttons might be tricky to get to look good with a limited color palette given: normal, hover and active states as well as borders.

For reference, here are all colors used in the app at the moment:

I also noticed that we have one exception - the sidebar, which has a color not from the style guide: sidebar - background-color: #eeeeef;. And we had to define an opacity for shadows --color-lightgray-opacity-08: rgba(51, 51, 51, 0.08);, but opacities might be a different topic altogether.

One edge-case that we have to keep in mind is multiple layered hover states: when an already hovered element has another element on top that is also being hovered.

Here’s an example in notion:

It might be a non-issue, as we have more than 3 gray levels. And perhaps this edge-case can be solved better with opacities (see #3 in Improve dropdown component · Issue #246 · radicle-dev/radicle-upstream · GitHub).

[efstajas]

Hey I was working with Brandon on Grover’s design system previously.

Slightly off-topic: I like to call these “atomic design constants” tokens. I think Salesforce (of all places) initially coined this term, and it works pretty well IMO. It’s not just for colors — a “typography token” is a description of a specific typography style, for example. A while back I built a little proof of concept tool that can generate tokens for typography, colors and even spacers in JSON format from a structured Figma file using their API. Try it with file ID GY9M9XrStShrij6AJyzVtUrW for an example!

We didn’t yet get to actually using this in production, but the idea is to consume these values at build time and essentially make our Figma design system definition the ultimate source of truth.

Anyway, coming back to the actual discussion. We started doing the background-foreground-levels thing very early on, and it’s always served us well. In the past few days, coincidentally, I’ve also been working on the color palette questions. Just to confirm the idea of having levels per color: we ended up with the same conclusion.

I basically saw 3 approaches, and made a little experiment with only a single color & two variations to illustrate.

• Left: Have a number of variants per color with decreasing intensity as full colors on white, and don’t adjust between themes. It should usually work fine and everything will be visible, but it won’t look totally amazing, because in dark themes, colored elements are very bright and look a bit out of place
• Middle: Don’t theme color variations — just use opacities of your 100% colors! I thought this would work well, but duh — on dark backgrounds, a whole lot of color variants are just impossible to see and it just looks like a muddy mess. This definitely doesn’t work
• Have a number of variants per color with decreasing intensity as full colors on the theme’s background color. Adjust variations per theme. This means maintaining a LOT more color values obviously, but I think it’s the only way to ensure visibility of colors in all possible scenarios. It also means full flexibility especially when considering offering more than just dark / light themes.

On the question of how many levels you need — I think 2 or 3 should be fine. For hover on hover, we decided we’re going to just be using those grey levels (which do have transparency) on top of colors. I think the only reason you would want to have more than 3 is if you want to theme SVG illustrations and you use a bunch of variations of the full color.

[kim]

Not trying to beat a dead horse, but: I just ended up with 17 label colors, mainly because I just take what the label creation flow offers me, and I’m too lazy to even think about a colour climate. I could do entirely with grayscale in exchange for being able to reorder labels in reading order (most important - least important).

[Julien]

Yeah I tend to agree with this. The more choice you have, the more choices you’ll make. I tend to want to create sensible (albeit maybe limited) defaults and see where people complain and then expand.

What do you mean with being able to “reorder labels in reading order”?

[Julien]

Hey @efstajas, thanks for your contribution.
It’s nice to see other people wanting to give their 5 cents.

You’re talking about something I’ve been thinking a lot about, the bridge between design and development. I’m always so frustrated that if we want to make a change in the design system, like colors or anything, we need to take time away from developers building features, since they need to implement this. I like the little tool you built, would be so cool if this would automatically open a pull request with the update. Maybe a radicle x figma plugin in the making…

[kim]

@Julien

What do you mean with being able to “reorder labels in reading order”?

On most-popular-forge-platform, the labels are assigned to an issue in the order you pick them (or I don’t know, some order), and there doesn’t seem to be a way to change that order later. Since I’m reading left-to-right, I’d like to order them in the list view according to my preferences. For example:

“subsystem” - “severity” -" priority" - “interest group”
(“ci” - “bug” - “prio:1” - “security”)

Or whatever makes sense. I guess I’m just having difficulties to assign colours to (visual) importance.