Building your color palette | Hacker News Reader

Building your color palette

refactoringui.com

705 pointstnorthcutt115 comments

Take this one step further and build the color palette into your stylesheets. If you're using Sass you can setup something like:

    $palettes: (
      blue: (
        lightest: hsl(201, 75%, 66%),
        lighter:  hsl(201, 75%, 61%),
        light:    hsl(201, 75%, 56%),
        base:     hsl(201, 75%, 51%),
        dark:     hsl(201, 75%, 46%),
        darker:   hsl(201, 75%, 41%),
        darkest:  hsl(201, 75%, 36%)
      ),
      red: (...),
      gray: (...)
    )

    @function palette($palette, $tone: 'base') {
      @return map-get(map-get($palettes, $palette), $tone);
    }

This ends up looking like: `background-color: palette(blue, "light")` in your codebase.

I typically use hsl instead of hex codes because it is easier to understand and modify. You can quickly build up a palette by just modifying the lightness scale on each color by a constant percentage. (This is where I disagree with the author, all of design is just math)

It is often useful to combine colors for your designs and Sass has you covered with the `mix` function. Using this setup you can call `mix(palette(blue), palette(gray))` to combine colors in your palette. You typically want to do this with text on a colored background to make it look more visually appealing.

This is the only way I've found to stay sane managing your colors in a big project. In my experience, everything else goes off the rails when you introduce multiple people into the picture. Please steal this idea, your projects will be better because of it.

The point of a palette is that if your blue is your accent colour, the grey will already be a bit blueish and work great with it

> I typically use hsl instead of hex codes because it is easier to understand and modify. You can quickly build up a palette by just modifying the lightness scale on each color by a constant percentage. (This is where I disagree with the author, all of design is just math)

Unfortunately, the “math” of color models like HSL is only very loosely related to the science of human color perception. It was a model developed by computer graphics researchers of the 1970s who were not very knowledgeable about 20th century color science and dealing with very limited hardware capabilities compared to today, roughly based on outdated ideas from the 17th–19th century... and frankly not very well designed even within those constraints. As a result, leaning too heavily on HSL (especially for novices) typically leads to garbage results. An experienced artist picking colors visually will do much better than someone largely relying on HSL numbers.

If you want to pick colors based on numbers, look up the Munsell color system (a big lookup table from the early 20th century; the “modern” version was developed by the leading American color scientists of the 1940s), CIELAB (from the 1970s, an inferior but based-on-a-simple-formula Munsell clone), or CIECAM or IPT models (more recent and more complicated formulas).

Can you point me to any resources where I can learn more?

Pick up any color science book from the last 50 years (you should hopefully be able to find a few at any medium-sized public library).

If you want an online resource, try https://www.handprint.com/LS/CVS/color.html

More than you ever wanted to know, in one well-illustrated blog post: http://jamie-wong.com/post/color/

That's awesome. It makes me think, though, that we could do a lot better than RGB given accurate values for actual human cone sensitivity and better subpixel colors. We should be able to get a digital gamut that fully spans the visible spectrum.

Yes we could get much better results with more primaries in our displays. It would take some fancier digital signal processing, and more importantly would only be especially useful for images designed with the wider gamut in mind (or potentially even multispectral images), but is possible using current technology, and probably not impossibly expensive.

Personally I would love to see displays made grids of hexagonal pixels, and maybe 7 primaries. Since almost every image that goes to displays today already needs to be rescaled at runtime, the processing shouldn’t need to be impossibly much more expensive than current square-grid resampling.

I would also love to see digital camera sensors with more primaries in a better pixel arrangement.

7 seems like overkill, but ok. :D Is that helpful for being able to display the full gamut of visible color more than 4 primaries, or even just 3 that are closer aligned to our eyes?

I picked 7 because it works nicely with hexagonal pixels. :-)

But the primaries can be relatively close together in color. It’s fine if we have e.g. 2 reds, 2 blues, and 3 greens instead of 1 of each.

Or for an LCD, some of them could be broader-spectrum primaries which were brighter but less colorful, while others could be more intense narrow-spectrum primaries. This would make the display more color accurate for various observers (more robust against “observer metamerism”), and would make the display overall brighter for the same intensity of backlight.

Or I dunno.. I’m not an expert in display technology, I’m sure the engineers could come up with many ideas.

http://davidjohnstone.net/pages/lch-lab-colour-gradient-pick...

You could learn more, or just use Lch! The colours you can pull out of this tool are amazing.

But let's not throw away the baby with the bath water...

A huge value of HSL is being able to verify that you're keeping hue constant. Or, to change hue everywhere slightly (when you decide you want a 214 blue instead of 217).

The second value of HSL is that it's easy to look at a code and understand its brightness and saturation semantically.

But I agree that you absolutely need to manually pick appropriate lightness and saturation values to match what you want perceptually, and that changing lightness often requires changing saturation as well.

If you want to be able to control hue still, you can use CIE LCH which is comparable to HSL but better matches our colour perception.

Yes, LCH is easier to use for picking colors than other CIELAB color spaces. To try an LCH color picker, you can use http://davidjohnstone.net/pages/lch-lab-colour-gradient-pick... (as linked in another comment).

You can also use the better-implemented color picker for the HSLuv color space at http://www.hsluv.org/. HSLuv is just like LCH except that it stretches the saturated colors for each hue so that any saturation coordinate represents a valid color, unlike LCH’s chroma coordinate. The downside is that the color’s chroma (colorfulness) can change when you drag the hue slider.

> HSLuv is just like LCH

To be clear, HSLuv, is based on CIELCHuv, the cylindrical transformation of CIELUV [0]; the LCH in David Johnstone's colour picker is CIELCHab, the cylindrical transformation of CIELAB [1].

Of course, that doesn't contradict your comment about the pros and cons of HSLuv's "saturation" component.

[0] https://en.wikipedia.org/wiki/CIELUV

[1] https://en.wikipedia.org/wiki/CIELAB_color_space

“LCH” is just the same as CIELAB, but in polar coordinates.

Prefer CIELAB to CIELUV for this type of use.

Having someone on your team that understands and values this stuff is Priceless to anyone building a user friendly product.

I think it still has some value. A few years ago I was building my color palette, and discovered through trial and error that if I keep saturation and luminosity constant, and just change hue to cover the color space, I get a pretty good looking set of colors. I'm not sure if there's science behind it, but it works in practice, at least for me.

If you're using Less, try http://strapless.io/ (my take on organizing colors in a project)

> background-color: palette(blue, "light")

Having never used Sass, this syntax strikes me as odd.

Is there a CSS pre-processor similar to Sass but where you would instead write it as “background-color: palette.blue.light”?

Not really a preprocessor per se, but look into JSS. Since it’s just JavaScript, you could use the object syntax you asked about.

Why is it odd? You're just calling a function with two arguments.

That function call is an alias for: map-get(map-get($palettes, 'blue'), light)

Which, in a language with dot accessors, could be accessed like: $palette.blue.light

I don't think he means that the function call is odd but rather that it's odd that you have to create and call a function to be as concise. Some of the oldest and longest Sass issue threads are about this missing feature.

You can use CSS variables, no preprocessor necessary for newer browsers:

  :root {
    --palette-blue-light: blue;
  }
  background-color: var(--palette-blue-light);

Great suggestion, but due to extremely poor support [0], it might be best to use a polyfill [1]

[0] https://caniuse.com/#feat=css-variables [1] https://github.com/aaronbarker/css-variables-polyfill (or https://github.com/jhildenbiddle/css-vars-ponyfill)

Personally, I don't like forcing JS to make things render properly on the client, but it depends on the project whether it's acceptable or not.

However, it kind of defeats the purpose, because if you're willing to use a polyfill, then you may as well use sass or less as a solution anyway (and get a range of benefits that they provide).

I haven't used it in a number of years, but Stylus apparently lets you access hashes[0] using dots:

  palette = {
    blue: {
      light: hsl(201, 75%, 56%)
      base: hsl(201, 75%, 51%)
      dark: hsl(201, 75%, 46%)
    }
  }
  
  palette.blue.light
  // => hsl(201, 75%, 56%)

It was a fun preprocessor, even if you could go overboard with it (for instance, dropping colons). I used it in a few node projects, but didn't do much beyond that because it never really took off like Sass. Sass is, well, everywhere. Stylus, on the other hand, appears to be either dead or close enough to it. While I've got a list of issues with Sass--mainly because I prefer the SASS syntax over SCSS--none of them are dealbreakers.

0. http://stylus-lang.com/docs/hashes.html

I made something like that for myself before SASS etc. were a thing, and it's been working so great for me that I keep using it, even though it's kinda derpy. First, I have a bunch of vars, such as

    hue9, top_bg_sat, top_bg1_lum, top_bg2_lum

Only those get changed when making new color schemes, and the colors are made up from them like so:

    hsl top bg1: [hsl hue9 [float top_bg_sat] [float top_bg1_lum]]
    hsl top bg2: [hsl hue9 [float top_bg_sat] [float top_bg2_lum]]

Those colors in I use in the CSS so they can get replaced by the final HSLA color:

    background:	<:top bg1>;
    background:	linear-gradient(to bottom, <:top bg1 l/1.125> 0%, <:top bg1> 10%, <:top bg2> 90%, <:top bg2 l*1.125> 100%);

allowing modifiers, such e.g. "use this color, but with luminance divided by 1.125".

I would look into options before rolling my own again, but even rolling my own made my life so much easier, so quickly, I would still recommend it just because it's fun.

This is an interesting idea. Seems like a good practice in larger projects though. I like your choice in words, lightest, lighter, light, base, dark, darker, darkest. Its the same naming convention as tailwinds, minus the word "base".

Is the word "pallete" really necessary? Why not just organize it like this instead?

  // Colors
  $blue-lightest: hsl(201, 75%, 66%);
  $blue-lighter:  hsl(201, 75%, 61%);
  $blue-light:    hsl(201, 75%, 56%);
  $blue           hsl(201, 75%, 51%);
  $blue-dark      hsl(201, 75%, 46%);
  $blue-darker    hsl(201, 75%, 41%);
  $blue-darkest   hsl(201, 75%, 36%);

and

  body {
    background-color: mix($red,$purple-light);
    color: $blue-dark;
  }

I am surprised the author did not mention HSL code anywhere, especially in the section about creating shades. I use HSL for everything, it should be standard practice.

The palette does two jobs. First, it makes sure you don't overwrite yourself somewhere else in the codebase. It also helps you easily see where someone has goofed since they aren't using the palette when defining a color. You could write everything that way, but you have to spend more effort maintaining the project.

Okay good point

If it's a solo project I would probably just stick to what I wrote, but for larger projects I see the benefits. Since someone might define another $color-variable elsewhere

By the way, you can also generate CSS using e.g. Python. No need for yet another domain specific language.

I've picked my fair share of colors for various businesses, and something that annoys me is that you pretty much always end up with green or blue being the main color.

I tried to figure out why, and I think it's a really dumb reason: like this article says, if you don't really know what you're doing with design, you want a spectrum of light-to-dark colors to choose from. Light green -> normal green -> dark green.

For some weird reason, we call light red "pink". And dark orange/yellow is "brown". If you pick one of those as your main color, it becomes much harder to just use lighter or darker shades without it becoming something else entirely. Great designers can make pink or brown work, but if you're a programmer who's just trying to find a "good enough" color scheme, it's way easier to go with green or blue.

I don't really have a good reason why we all think of pink as a different color from red, but we do.

Violet, Indigo and Red are different hues. Pink is not "light red". No adjustment of the saturation of red will ever make it pink. Brown is created with a low saturation of red, orange, yellow or green.

Pink is a "light tint of red", not a different hue. https://en.wikipedia.org/wiki/Shades_of_red

That is a purely semantic argument. It's also a contradictory one. That article says in the first sentence that they are considering adjusted hues as "shades" or "tints" of red. Using terminology beyond HSV only introduces semantic complexities to confuse the topic.

Wikipedia is a terrible source for this type of thing.

“Pink” was until recently a synonym for “light red”.

However, when it became possible and fashionable to produce more bright purple-red colors, these were also called “pink” (“hot pink”, etc.) by marketers, and now our late 20th/early 21st century concept of the denotation of the word “pink” is considerably broader than 50+ years ago.

Then how do monitors work with just 3 basic colors (RGB)?

Adjustment of Value will make a red pink though, not sure why you're talking about Saturation only?

> Pink is not "light red". No adjustment of the saturation of red will ever make it pink.

Can you tell us what you think one has to do with the other?

Pink is the hue between purple and red. You can't just saturate red, you also have to add a slight bit of blue.

This is pink: https://static1.squarespace.com/static/53cdd3f3e4b09b69bef6e...

You can't adjust the saturation of that color to make it red, just a lighter shade of pink. There are pink colors that are closer to red than to purple, but pink is a different part of the color space than red is.

If you see the shade in that link as red or purple, then you're living in a hell of having no rational basis by which to talk about color, or possibly color-blind.

> living in a hell of having no rational basis by which to talk about color

That’s what many people on Hacker News are doing, apparently.

Hm? Did you mean to reply to me? I am not challenging or even talking about the definition of pink. That is happening elsewhere in this thread.

Huh. I always called that color magenta. And called light red pink. TIL.

Up until the last few decades, English speakers would not consider the color in your link to be “pink”. “Pink” was another word for “light red” (not the name of a hue), named after a flower that looks something like https://www.stauden-stade.de/img/artikel/full/823.jpg

“Hot pink” is a creation of the fashion industry / marketers from the 1980s (or maybe 70s?).

If you want to be unambiguous, you should call the hue of your link purplish red or similar. You could also use a word like fuchsia (named after a different flower) or magenta (a purplish red ink used in 4-color CMYK printing).

I think humans can see a wider range of blues and greens than they can yellows and reds. Check out: https://upload.wikimedia.org/wikipedia/commons/thumb/3/3b/CI...

I believe this chart roughly corresponds to the colors humans can perceive for different light combinations. I see greens/blues in most of the chart and the colors I consider to be red, orange, or yellow occupy very small regions of the image.

Since greens/blues have a wider range, maybe that's why designers tend to use them as the main color?

Another factor to consider is our acuity varies across that color gamut (see https://en.wikipedia.org/wiki/MacAdam_ellipse). So we're best at distinguishing subtle differences in blues and worst at seeing variation of greens. The number of shades of blue or green you can see would be the number of MacAdam's ellipses which fit in each region - so it looks like we can see the most shades of blue but green isn't much of an outlier (depending on how you group pinks/purples etc.).

Most folks would disagree and say that blue is actually the least sensitive to changes and green the most, and allocate precision accordingly. See remarks here: https://en.m.wikipedia.org/wiki/High_color

sorry I misspoke by saying shades - the MacAdam's ellipses are measured for the same brightness so only apply to variation in hue/saturation. So I think we can see more shades of green but more hues/saturations of blue?

Speaking of distinguishing subtle differences in blues, there is actually a linguistic component.

English and Russian color terms divide the color spectrum differently. Unlike English, Russian makes an obligatory distinction between lighter blues (“goluboy”) and darker blues (“siniy”). We investigated whether this linguistic difference leads to differences in color discrimination. We tested English and Russian speakers in a speeded color discrimination task using blue stimuli that spanned the siniy/goluboy border. We found that Russian speakers were faster to discriminate two colors when they fell into different linguistic categories in Russian (one siniy and the other goluboy) than when they were from the same linguistic category (both siniy or both goluboy). Moreover, this category advantage was eliminated by a verbal, but not a spatial, dual task. These effects were stronger for difficult discriminations (i.e., when the colors were perceptually close) than for easy discriminations (i.e., when the colors were further apart). English speakers tested on the identical stimuli did not show a category advantage in any of the conditions. These results demonstrate that (i) categories in language affect performance on simple perceptual color tasks and (ii) the effect of language is online (and can be disrupted by verbal interference).

Source: https://doi.org/10.1073/pnas.0701644104

This reminds me of the development of 'color words'. Most languages start off creating words to differentiate light from dark, followed by a word to describe red, then yellow (or green), followed by green (or yellow), then blue, then brown.

One reason is that computer displays are just not very good at reproducing colorful light reds, a limitation of the 3-primary emissive display technology. As a result light reds on typical computer displays are always pale/faded looking. This can make it hard to build a useful range of UI colors of red hue, depending on the needs of the UI.

> For some weird reason, we call light red "pink".

This is partly cultural. In Russian, there's one word for light blue (голубое). It's the color used to describe the sky. I remember wondering why there's not an English equivalent, when there's the pink/red distinction.

The English word for the blue of the sky is "azure". Or sometimes "cerulean".

Thanks! But these words are certainly not part of the everyday vocabulary in English, like my Russian word example.

Native English speaker here (Canada) - I believe I can honestly say that I have never heard anyone refer to the colour of the sky as either of those things. Certainly never "cerulean", and I have strong doubts about "azure". In fact, because Microsoft Azure comes up in conversation relatively frequently, I have noticed that people don't even know how to pronounce it. I often hear people say "ah-zoor".

There actually is a science for this: it's called accessibility. WCAG guidelines would be extremely useful in determining how colors should be combined and applied to meet contrast guidelines.

It would also be useful to create usage contexts to guide additions to the palette. for example: text + background, ui (border, icon) + background, background + background.

These would help identify common situations and ensure that you're adding the colors you need and avoiding future bloat.

Since companies are now being sued over a11y issues, it's definitely something that should be incorporated into the design process from the beginning.

Steve Schoger does a great job of designing with accessibility in mind! The future book that this chapter will be rolled into contains a whole discussion on it. If you check out the Refactoring UI screencasts, he uses an app (called Contrast, if you're curious) to make sure things meet AA minimum requirements.

Yes WCAG guidelines are useful. But, for me as a novice empathic but still a novice, they are not easy to use. At the very least, finding definitive examples and such often eludes me.

That aside, thanks for mentioning accessibility and #A11Y.

Here is a tool that makes it easier to pick foreground and background colors with high enough contrast according to WCAG guidelines: https://webaim.org/resources/contrastchecker/

Kinda ironic that he starts the article by decrying fancy color palette generators that give you 5 hex codes centered around a primary color, and then ends it by choosing a base color and filling in the gaps with 5 (possibly 10) shades from light to dark. That's exactly what color palette generators do!

The mistake most people do is going hog-wild with color palette generators. The vast majority of the time, you want a monochromatic scheme with a complementary accent color. Adjacent, triad, and tetrad schemes are quite special purpose, and you use them differently. Think of Google - it's a tetrad scheme, but the base color for all Google sites is white, and all 4 colors of the logo are used as accents. You want to KISS - if you do have a multicolor palette, use the colors sparingly and pick a neutral white or grey as the primary background color.

No, not ironic, that's precisely what he doesn't do; he says you probably need 5-9 shades of each colour group - Primary, Secondary, Highlight, Greys, etc.

He also says the reason you can't write a generator is because every colour looks different and needs to be judged by your eyes.

Light grey sans-serif body font means you hate your readers' eyes. At least they didn't make it tiny as well.

Also, the color advice is bad. The garish "calculated and scientific" example is more readable than the "What you actually need" example.

- - - -

Edit: The differences between people's eyes and between monitors' color output mean that you probably shouldn't spend more than an hour or two (or a couple of hundred bucks) picking out a dependable conservative color pallet. In fact, the time it took to read that article should be enough to pick a pallet, unless you just want to play with colors, which is fine.

> Ever used one of those fancy color palette generators? You know, the ones where you pick a starting color, tweak some options that probably include some musical jargon like "triad" or "major fourth", and are then bestowed the five perfect color swatches you should use to build your website?

> This calculated and scientific approach to picking the perfect color scheme is extremely seductive, but not very useful.

Just recently I wondered if there is any scientific basis behind these approaches. I skimmed all research papers that I could find but not a single one of them provided serious data based support. All justification for these methods I found were historical, i. e. artists used color wheels and different methods of color selection on the wheels for a long time.

My conclusion so far is: There is no science what so ever behind these color palette generators.

I only spent about a day on this research and I'm not an expert, so if anyone has some pointers to serious research in that direction I'd be happy to know.

Google how the human eye works. The rods and cones. Colour and harmony between colours is rooted in our biology. Your iphone screen looks very unnatural, unattractive, to a dog or a goose. They see very different colours than we.

Our affinity to bright red is tied to how we used it to identify ripe fruit. Notifications, things they want you to click/grab/poke work best in red. You dont see many brown buttons on websites. We dont like touching brown the way we do red.

That might be true but this article basically says you have to rely on your eyes. You might as well get the designer to do everything. We programmers should also publish articles like this: dont even bother with Excel formulas you need a programmer

I didn't want to criticize. My argument was meant to support the thesis that the palette generators are useless. They are not only useless from the designers point of view stated in the article but also from a scientific view.

> You might as well get the designer to do everything. We programmers should also publish articles like this: dont even bother with Excel formulas you need a programmer

I couldn't agree more.

Whether you see it as having science behind it or not really depends on what problem you're considering.

There are some interesting in-depth articles about how people build those palettes and ramps that you might find interesting:

https://uxplanet.org/designing-systematic-colors-b5d2605b15c

https://design.lyft.com/re-approaching-color-9e604ba22c88

Thanks for the links, I skimmed the articles, they are very interesting and I will certainly read them later. They are not what I'm looking for, however.

What I'm looking for are empiric, preferably cross-cultural, studies on color harmony. I'm interested in work similar to what has been done for Unique Hues and Focal Colors but for combinations of two or more colors and for the notion whether people find these combinations pleasing, neutral or displeasing. I wouldn't be surprised too much if we couldn't find universal pleasing combinations but I'm surprised that apparently no one has done these type of studies.

May not be exactly what you want but you could look into the World Color Survey:

http://www1.icsi.berkeley.edu/wcs/

https://youtu.be/gMqZR3pqMjg

I'm happy to give them the benefit of the doubt, and I think many colour pickers wanted to do the right thing.

HSL or HSV was a step up from RGB, so it made sense to use it to derive other colours quickly. Because if you're an underpaid freelance developer, the primary colour is usually set by the client, but they usually son't have a full colour scheme. Using a colour wheel based tool gave good enough results fast.

Not only are perceptual uniform models like CIE Lab*, and the derived CIELCh or CIEHLC mindbending to understand and code, but monitor colour gamuts sucked, and so it was overkill.

So is it scientific? If what you wanted was an easy way to derive a number of colours, sort of. If you need them to "look good", well that's art, not science. So ultimately, IDK what answer you're looking for. Colour wheels have always just been a nice way to visualise hue.

> If you need them to "look good", well that's art, not science.

I'm not so much interested in "look good" but in "look pleasing or harmonious together" and I think that's a question science might have an answer to.

It's no coincidence that the palette generators borrow musical jargon. In music the definitions of minor second and perfect octave are completely uncontroversial. That these two intervals have different musical qualities, we call them dissonance and consonance, is uncontroversial too. Sure, some cultures use dissonant intervals heavily in their music but they still recognize the different qualities. Most importantly there has been a ton of research in this field.

Contrast this with the state of the art in color science: When it comes to color harmony there is not even a single universal definition of opposite or complementary. Look at the Wikipedia article about that topic [1]. It mixes up three completely separate topics:

1. Colors that when mixed together give a neutral hue

2. Colors that are opposite of each other on some wheel

3. Colors that supposedly have a certain effect, like contrast or harmony, when perceived next to each other

Color wheels are a dime a dozen. There is no shortage of claims that this and that color go well together but there doesn't seem to be any serious research.

I wonder if that is just my impression because it's not my field, or if maybe color science really is just not developed enough to tackle these kind of questions.

[1] https://en.wikipedia.org/wiki/Complementary_colors

>I wonder if that is just my impression because it's not my field, or if maybe color science really is just not developed enough to tackle these kind of questions.

I have wondered the same thing ( https://ask.metafilter.com/245014/Help-me-understand-color-t... ) and haven't found anything.

I've had some subsequent thoughts. We know that there is a characteristic of the human perception of scenes called "color constancy". That is that our visual perceptual abilities are surprisingly robust to changes in the character of light sources. We may be aware of the light source color, but we easily "factor it out" of what we see of the objects in the scene. It is as if color constancy takes the distribution of colors and applies some transformation to standardize that distribution.

My guess is that the mechanisms underlying color constancy contribute to the aesthetic feel of the scene. If a scene's colors lie along a single line (e.g. a grayscale image), there is a sort of cramped or confined feeling (at least, I experience this), as if the color constancy mechanism is attempting to make a gaussian sphere* out of the colors but there's not enough variance to make it work.

At the same time, if you make a palette out of the corners of the RGB cube, there's an unusually high amount of variance. The image might be very vivid but it gives me an impression of excessive busy-ness or energy. The sphere has spikes now!

Maybe harmonious color schemes are those in which the color constancy mechanism doesn't have to do too much work to make the color distribution into a standard shape... maybe. I don't have any evidence or anything.

I don't think the "standard" distribution of colors that would feel neutral is actually going to be a sphere, but it's not going to be perfectly flat and it's not going to be a straight line. It is possible to visualize the color histograms of images as 3d point clouds to get some sense of what feeling is evoked by different color distributions (e.g. http://opensource.graphics/visualizing-the-3d-point-cloud-of... )

> we call them dissonance and consonance, is uncontroversial too

haha, right... but only for western music. compare it to e.g. Gamelan or throat/overtone singing. babies to have some concept of pitch, but mostly what sounds good is very much cultural and not "scientific" at all (good post on this: https://blog.nationalgeographic.org/2013/11/12/the-emotional...)

> Not only are perceptual uniform models like CIE Lab*, and the derived CIELCh or CIEHLC mindbending to understand and code

Conversion from srgb to lab and back (through xyz) is a handful of functions, all under a dozen lines of javascript. Lab to lch and back are a pair of functions, about two lines of code each.

If you're implementing a user interface with sliders, you might also want to clamp the values to avoid producing out of gamut colours. The weird shape is probably the hardest thing to understand (user point of view), but the controls remain very intuitive.

I should have phrased it better. Teenage me struggled, but I haven't attempted it since. Having said that, HSL/HSV worked well enough, and monitors now have better colour accuracy and wider colour gamut. Back then, people were still using "web-safe" colours.

I've made one so maybe I can help (http://strapless.io/)

It's only really scientific insofar as it's based on a model. We basically make a big cube with R,G,B on its sides instead of X,Y,Z. Different approaches will then "smush" that cube to try to better match how humans perceive colors. Those different smushes will usually have some scientific thinking behind them (mine is based on... historical justifications, good post here btw). Then we move around the cube to find colors.

When I get a color, I try to match the luma too. Luma is itself a weird value, which tries to work through the relative perceptual brightness differences in colors.

The relative perceptual brightness difference is, as far as I can tell, the thing that really makes a color look "wrong" in a color scheme. I didn't solve that with problem with Strapless, but instead relied on whomever figured out luma. I think if you looked into how luma works you'd find the current best scientific model for whether two colors "fit" together.

I'd agree that color-generating isn't a science (definitely more of an art) but any good approach will have a bunch of underlying science and math.

> Just recently I wondered if there is any scientific basis behind these approaches.

No, not really. It’s mostly 17th–19th century pseudoscience, propagated by generations of uncritical art teachers. (Note: not all art teachers; some are amazing.)

Complementary colors (which mix to neutral when you e.g. paint two sides of a top with them and spin it) are a thing though.

Most of those generators are showing you sets of colors that all compliment each other. When you're designing an interface you have different priorities, you need a more of a fill and accent colors, as well as other colors that give contextual clues (like confirmations or warnings).

I think both concepts are useful, but this article is a way better approach.

And make sure to use LAB color space!

https://en.wikipedia.org/wiki/Lab_color_space

In LAB space, the distance between two colors approximate perceptual distance (how different two colors look). Its not exact---it can't be, because the space isn't actually Euclidean---but it's close.

RGB, on the other hand, isn't close. Here's a visualization of RGB space embedded in LAB space:

https://en.wikipedia.org/wiki/HSL_and_HSV#/media/File:Srgb-i...

If RGB space corresponded to what our eyes saw, that would be a hexagon.

Great article, I especially liked:

> the ones that make you think of Facebook as "blue", even though it's really mostly grey.

which seems obvious in retrospect.

I'm colour-blind (mostly red-green, sometimes blue-green too, never pinned down exactly which type - or types - it is) so I have used those generators before, and I think they do have value for me or others that just think they don't have a good eye for colours that look good together.

The opening example shows a nauseous combination of colours, but actually what the article mainly addresses is the lightness of each - presumably one could get some good results with a 'palette generator', and then following the advice here with the generated palette as the 'base colours'.

After reading this, I created a theme color picker in a single HTML file with no libraries. It's only tested in the latest Chrome.

https://gist.github.com/steve-taylor/40f54b400785258b80d4792...

Tested and working well with the latest Firefox (v63). Nice work, this is handy!

No mention of color blindness or a11y, which seem like important factors in color selection.

This simulates the effects of various types of color blindness on any webpage:

https://www.toptal.com/designers/colorfilter

Something like that could even be part of automated testing for graphical applications and websites -- why not?

> There's no real science

> It's not a science

I preach and preach that to people on certain other forums who insist you need one of those palette generators or palette samplers, and everyone praises them, but it's ART not SCIENCE or MATH! It's why there are artists who design the look of things and not scientists or engineers.

I think a big thing but underrated thing is iteration. Giving things time to "simmer", looking at things with fresh eyes often, i.e. having multiple shorter sessions instead of few long ones, and simply playing around with and comparing various ways how things could look, can get you quite a long way.

Otherwise, you end up with "coder colors".

http://www.pouet.net/prod.php?which=53631

I think it's assumed you would still use grays and whites if you use one of those palette generators.

It's a bunch of variables, so expose them to the users, and let them create and share color schemes. Pick some of those for the off-the-shelf selection, and it'll be better than any single color scheme.

Even better would be a standard way for websites and browsers to negotiate color schemes, and for users to be able to set specific themes for sites, a theme for all sites, themes depending on the URL, enforce legibility with color blindness, and so on. It's 2018, yet we don't even trust people with selecting user stylesheets in the GUI anymore.

To me, how to make neat colors is a discussion normal users should have, that it's so much in the hand of web designers is a failure in and of itself.

While there are no absolutes when it comes to taste.

One design language that I really like is the Atlassian/Bitbucket one.

https://atlassian.design/guidelines/brand/color-1

I've generally really liked the changes to bitbucket over the last few years in terms of UI and UX.

They also have an impressive component archive.

https://atlaskit.atlassian.com/packages

A lot of the packages are under an Apache 2 license, I can't say all as I haven't looked but the master repo is Apache 2.0 as well.

Those colour names in the Atlassian palette are hilarious.

Every design needs more cowbell.

I think the key is to build the palette from a mental model of relationships. You start with a base color, and choose "adjustments" down the line to describe accent colors, etc.

The other perk about this approach is that you can then adjust the base color, and everything referencing it usually looks pretty good or only needs slightly adjusted.

I've been working on a tool for this off and on since 2015 (https://www.colorproducer.com/). The app has some really annoying issues, mainly around UI. I think the main thing I did wrong was to make it work on a per CSS selector/color property basis. Most websites will have 50+ unique selectors with color value, so it becomes a lot of work. I'm trying to address this, and have been thinking of a "mapping" step, where the user picks out what selectors are a primary color, accent color, etc., and then works solely with those groupings.

Hopefully this makes sense, I've been thinking about it a lot and may be a little too stuck in my own head/thoughts.

I actually really love that first example. Wish more sites looked like that.

For people with blue-yellow color blindness that page is a nightmare.

If it makes you feel any better, it's also a nightmare when you can see blue-yellow.

You will love it for the first 30 minutes, after that it will become annoying and heavy on your eyes

Why the yellow background though? It'd look nicer with the light cyan background. Save the yellow and red for some kind of attention colors.

Even with the "right colors" one can go wrong if the colors are not used in a smart way: green over red or blue over yellow is seldom good for something people are expected to look at longer times.

(Yes, I fully understand the first example was a "don't do this", but it was not the best it could be with those colors)

This was really helpful to see how the author thought through the palette's creation. In my experience, I came to similar results, but over a long period of time and rather haphazardly after endless tweaking.

I would add that often times it's helpful to define a "light on dark bg palette" and "dark on light bg palette."

This calculated and scientific approach to picking the perfect color scheme is extremely seductive, but not very useful.

Well, unless you want your site to look like this:

There's a difference between picking maximally distinctive colours (which a lot of palette generators are designed to do) for graphs and such, and picking colours for UI.

Personally, I think less colour and higher contrast is better than the trend of barely-distinguishable shades of grey; and of course, for desktop apps, please use the platform's standard UI colours because the user may have customised them for his/her preference/colour-perception and expect your app to be too.

Let's say I created a suitable color palette. What would be the best way to make sure the colors are used consistently? – Giving it names like primary_700 or accent_1_700 seems a bit too technical.

Use a css preprocessor, and define variables with the technical names but classes that end up in html should have descriptive names. Something like this:

  $accent_1_700: #e60000;
  $accent_2_900: #ff9999;

  @mixin button_border($color) {
    border: 1px solid $color;  
  }
  
  .alert-button {
    background-color: $accent_2_900;
    @include button_border($accent_1_700);  
  }

This makes your color palette defined explicitly and easy to change in one place, and makes which color on the palette you're using in a given context defined explicitly as well.

Strapless, a color library I built, automates a lot of this if you use LessCSS: http://strapless.io/

Just tried it. Impressive. Thanks!

I'm not sure (read: very new tbought) what this would look like in terms of a broader theory, or mixins, but I would imagine it might be helpful, just like with music, to think of colors as having a key; that at the very least there's some way to automatically define the colors __not__ in the key.

Okay. It's a raw idea :) Maybe someone else here can flesh it out?

Cool article, but isn't the point of a palette that you limit your options so it's easier to pick a color and the colors on your site are more consistent? This article suggests every palette should have 6 colors and 9 shades for each color, which doesn't really narrow things down...

Awesome blog post, providing interesting approaches.

What I always struggle with is not the different shades, but finding suitable other colors which go along with a given one. Let’s say your company already has a hex code for a blue. How do you find appropriate greens and reds to go along with it?

This is where the triads and tetrads that the article dismissed come in. But a good rule of thumb is to pay attention to saturation and brightness more than hue; they have a larger role in the harmoniousness of a pair of colors.

Here are some common techniques:

1. Hue shift your complements towards the primary instead of trying to use the full range. This mimicks what we experience in different lighting conditions: under a red light, everything looks red.

2. Create ramps of saturation within the palette. If you have a dark blue primary, add a grayish transition and pastels to complement.

3. Make a larger palette than you need right now and then trim it down. When making palettes for pixel art(a great way to learn color), there's an iteration between making color ramps and making test images to spot the flexibility of the palette. You can do similarly for the site design: you don't want to have tons of colors, you want colors that can be used in many different roles.

Also, for palette design it can be a good idea to get a good monitor and have it calibrated.

I use https://www.colorhexa.com for colors. It gives you schemes based on your chosen color, previews, and more. It even has a color blindness simulator.

For years, I've been using http://www.0to255.com to come up my scales. For each hex, you're shown a monochromatic scale of 32 colors. I love that site!

This is a great article. Anyone know of any articles that explain how to use a tool(say Sketch) to pick the different shades of colors that the article mentions?

http://colormind.io/bootstrap/

I fear that this is exactly the kind of advice that makes websites all look the same.

And books all look the same. White background with black text. Even print magazines mostly all look the same. There is only so much variation you can introduce before the design starts to draw attention away from your content. Most websites designs should be comforting and ignorable.

Reply on news.ycombinator.com