Considering the RBG color space
At NYC Planning Labs, we’ve worked on quite a few projects which visualize a ton of data. Lately, in preparation for creating design guidelines, I’ve been exploring how we might standardize the use of color across our applications.
For example, it’d be great if all of our apps used the exact same color to represent the same data — the same green to represent parks, the same blue to represent the floodplain, and the same red to represent commercial overlays.
But herein lies the challenge: just one of our apps (ZoLa) uses over 50 different colors to visualize its data.
(ZoLa uses 11 Land Use colors, 5 Zoning District colors, 1 Commercial Overlay color, 2 Zoning Map Amendment colors, 2 Special Purpose District colors, 1 Limited Height District color, 22 Supporting Layer colors, 5 Administrative Boundary colors, and more colors for the basemap, building footprints, subways…)
Of course, it’d be a rare occurrence for someone to turn on every single map layer at once and have to differentiate between over 50 colors. But even if they only turn on two layers, we can’t know which two. So, ideally, all map layers should be visually distinct from each other.
Cataloging our use of color
ZoLa alone doesn’t contain all the data used in Planning Labs’ applications. On top of its 50+, we have dozens of other data points being visualized. This makes me want to take inventory of all our visualizations and map them to the RGB color space in an attempt to better understand their breadth, resolve conflicting visualizations, and identify how our use of color might be standardized and optimized.
Caveats: There are existing color standards in planning realm — such as the Land-Based Classification Standards — that should be considered while establishing our own standards. *See notes & considerations at end
But first, let’s consider the RGB color space, and ultimately why computers are bad at color theory.
Every possible RGB color can be represented by plotting red, green, and blue values in a 3D graph as a cube. The corners are pure red, green, blue, cyan, magenta, yellow, black, and white. The exact center is gray.
Simplifying the cube
We’re not interested in every possible RBG color. Instead, we want a subset of visually distinct colors that can be used for data visualization.
We can divide each axis of the cube into 16 possible values by using shorthand hexadecimal (e.g. the R axis would go from #000 to #F00), which would limit our palette to a cube of 4,096 colors. But that’s still too many colors. And besides, #F00 and #E00 are practically the same color red.
Programmatically-generated color palettes
Let’s further limit our palette by only using a subset of shorthand hex colors.
This CodePen shows every possible permutation of every fifth hex value:
↓----↓----↓----↓
0123456789ABCDEFOnly using the 0, 5, A, and F hex values will limit our palette to 64 colors. But you as can see, there are still quite a few colors that aren’t visually distinct.
We could use a smaller subset:
↓-------↓------↓
0123456789ABCDEFThis CodePen gets us closer to a 100% distinct color palette. But there are still a few issues to consider. First, there are only 27 colors (way fewer than needed for ZoLa alone). And Some colors (greens, cyans) still aren’t very distinct. And what about grays (there’s only #888)?
Let’s rethink our cube
We don’t need to programmatically generate black or white — we can easily come up with a grayscale palette that includes more than #888. It’s also apparent that the 100% pure colors (#F00, #0F0, #00F,#0FF, #F0F, #FF0) are hideous. So, instead of using the entire range of hexadecimal values, let’s avoid the extremes.
This CodePen shows every possible permutation of every sixth hex value from 2 to E:
--↓-----↓-----↓-
0123456789ABCDEFThis skews closer to white than black, as it’s more difficult to discern differences between darker colors. And avoiding the extremes makes the bright colors more visually pleasing.
Still not good enough
This programmatically-generated color palette might be getting prettier, but the visual difference of specific colors could still be improved.
This CodePen shows the same [2,8,e] permutations as the previous one, but some colors have been manually adjusted — darkened, brightened, or desaturated — to make them more visually distinct.
Computers are bad at color theory
We’re beginning to see the challenges of color theory, and why computers can’t (easily) resolve all the issues related to human perception. The palette above has lots of nice blues and greens, but only two reds and one orange. And we’re still well below the number of colors we’d need to standardize the visualization of data in our apps.
But why’s it so complicated?
A map of the RGB color space — or even an alternative representation such as HSV (hue, saturation, value) — is really great at helping you choose a specific color. But it’s really bad at dealing with the complexities of relative color appearance. Since the symmetries of the RGB cube are based purely on math, the distance between two colors is completely unrelated to human perception. In a perceptually-uniform color space, hues wouldn’t be evenly spaced or have the same scale of lightness or chroma (colorfulness relative to brightness).
So where do we go from here?
When it comes to color theory, not much can improve the good ol’ fashioned technique of rolling up your sleeves and trying out different combinations. Our next step in creating a standardized color palette will be just that: brute force. Beginning with an audit of colors currently being used, we’ll compile a palette by hand and iterate.
Other notes & considerations:
- Aging Standards
Many standards in the planning realm are decades old, created at a time when printed maps reigned. Much has changed in web mapping, and Planning Labs is pushing the boundaries of what’s possible. How applicable are these standards to modern web maps? Is there an opportunity to establish more modern web map standards in planning? - Color combinations
When colors are used together they influence each other. Changing just one color can affect the whole palette. A color can be perceived differently when combined with other specific colors. - Color blindness
4.5% of the population is color-blind (8% in males). Designing an a11y-compliant color palette makes this even more challenging. - Opacity
Often in our mapping applications, we make map layers transparent so that they can be stacked and remain visible. When a specific color from a standardized palette is made transparent, is it still the same color? - Color psychology
What are the cultural connotations of using certain colors in our visualizations? Red often implies excitement, danger, impact; green implies nature, growth, success. We must also consider the differences and limitations in using color for data vs UI. Does a color has a different meaning when used for a button than when used for a map layer?
