Effective use of colour for categorical data

Colour choices can have a profound impact on the interpretation of the results

In module 2 we discussed how changing the colour scheme drastically improved a clinical outcome by almost doubling physician’s detection rate of blood vessels regions indicative of potential future heart disease (from 40% to 70%).

In this slide deck, we will discuss some of the consideration that goes into evaluating if a colour scheme (also called a colourmap) is suitable for the data you are visualizing.

Colour can be broken down into hue, lightness, and saturation

There are several different ways to represent colours. You might already have heard of RGB (red, green, blue) or CMYK (cyan, magenta, yellow, black) where different amounts of a set of base colours are combined to create all possible colours.

When discussing colours in the context of data visualization, We will be describing them with the parameters “hue”, “saturation” and “lightness”.

The left schematic in this slide is a 2D circular representation including only hue and saturation. When we add lightness, this circle grows into a cylinder with lightness as the height.

On the next slide, we will break down exactly what each of these three parameters represents.

Hue, lightness, and saturation describes different properties of colours

We could verbalize the changes we saw in the previous slide in the following manner:

Hue is what we traditionally think of as the “colour”, is it red, blue, etc?

Each hue can have a varying saturation, which ranges from a dull, greyish appearance to a vibrant fully saturated hue.

Lightness is how bright the colour is. For every hue, it starts at black (no lightness) and ends at white (full lightness).

Hue and lightness are the most important from a data visualization perspective, and we use them for categorical and quantitative data, respectively.

Saturation is often used more as a stylistic choice to decide whether the colours we use should be muted/desaturated or vivid/saturated.

Hues are used to distinguish categorical values

Hue is useful to distinguish between categories because it is often relatively easy for us to say that different hues are distinct. We can see that blue, orange, red, etc are different and don’t easily mix them up.

The leftmost plot uses different hues to separate the points belonging to different categories. We can quickly identify that there is a total of three distinct colours being used here even without looking at the legend.

In the plot to the right we used lightness within a single hue (blue) to label the different categories. Here it is much harder to say how many different categories there are, and even when we have the legend, it is difficult to tell which points are which shade of blue.

It is often better to use established colour schemes instead of making your own

There are many different hues we could use to represent our colours and some might not go as well together as others, so how do we decide which ones to use?

Fortunately, we don’t have to design our own combination of colours to use, but can pick from combinations designed by experts to be easy to tell apart and in most cases also suitable for people with colour vision deficiencies.

These colour combinations are referred to as colour schemes in Altair, but you might also hear them being called colourmaps or colour palettes.

In this slide, you can see some of the colour schemes for categorical values that are built into Altair.

The default one is “tableau10” and it was named this way because it was originally designed by the company Tableau but is now one of the most common categorical colour schemes used in data visualization. All Altair colour schemes can be viewed here.

Specifying colour schemes in Altair

alt.Chart(cars).mark_point(size=70, filled=True).encode(
    alt.X('Horsepower', title='Engine power (hp)'),
    alt.Y('Miles_per_Gallon', title='Fuel efficiency (miles/gallon)'),
    color=alt.Color('Origin', title=None, scale=alt.Scale(scheme='set1')))

You can change the colour scheme of a plot by specifying its name as a string to the scheme parameter inside alt.Scale.

To more easily see the changes we are making to the colours, we also increase the size of all points via the size parameter of the mark.

Redundant coding can make charts easier to interpret

alt.Chart(cars).mark_point(size=70, filled=True).encode(
    alt.X('Horsepower', title='Engine power (hp)'),
    alt.Y('Miles_per_Gallon', title='Fuel efficiency (miles/gallon)'),
    color=alt.Color('Origin', title=None, scale=alt.Scale(scheme='set1')),
    shape='Origin')

Although many of the colour schemes in Altair are designed according to the guidelines for effective colour uses, they can sometimes be difficult to interpret for people with colour vision deficiencies.

Especially colour schemes that mix red and green as the one in the previous slide.

In addition to using a more suitable colour scheme (such as the default), we could also change the shape of the points for each category.

Although this is technically redundant since the colour is already used for the categorical groups, it can make your visualization more effective since it makes the points more distinct from each other.

Note that shape= is only available to use with mark_point, not mark_circle, mark_square, etc.

For line plots, we could achieve a similar effect by using the strokeDash encoding instead of shape, which together with direct labelling from the previous slide deck can facilitate interpretation of these plots.

Specifying custom colours

colors = ['coral', '#4682b4', 'rebeccapurple']
alt.Chart(cars).mark_point(size=70, filled=True).encode(
    alt.X('Horsepower', title='Engine power (hp)'),
    alt.Y('Miles_per_Gallon', title='Fuel efficiency (miles/gallon)'),
    color=alt.Color('Origin', title=None, scale=alt.Scale(range=colors)),
    shape='Origin')

Most of the time it is a good idea to stick to the predefined colour scheme because of the advantages mentioned in the previous slide.

However, sometimes the categories we are representing might have a colour already associated with them, such as political parties or sports teams.

In these cases, it is often better to design a custom colour scheme using the colours naturally associated with each category.

In Altair we can create a custom colour scheme by passing a list of colours to the range parameter of alt.Scale.

You can specify colours either by their HTML/CSS name (such as ‘coral’) or their hex code (such as ‘#4682b4’). All HTML/CSS colour names can be found in the image in this post.

Hex codes are defines over the range #000000 for black (“zero colour”) to #ffffff for white (“full colour”) and are easiest chosen via colour pickers such as this one.

Don’t use more than 5-8 distinct hues for categories

Although many of the categorical colour schemes contain ten or more hues, if is often not a good idea to use all that many because it becomes near impossible to distinguish the different hues from each other.

The guidelines on what is too many hues differ between different sources and also depends on your use case. A good rule of thumb is that when you get to around five different hues, you should really consider if this is the best way to represent your data or if you could split it up into multiple visualizations instead.

If the data is neatly organized in well-separated clusters, it is possible that you could visualize more than five colours (maybe even ten) effectively, but in data where the datapoints are more mixed, you will rarely if ever, be able to go this high.

Too many hues are impossible to distinguish

alt.Chart(cars).mark_point(size=70, filled=True).encode(
    alt.X('Horsepower', title='Engine power (hp)'),
    alt.Y('Miles_per_Gallon', title='Fuel efficiency (miles/gallon)'),
    color=alt.Color('Name', title=None))

This is an example of what happens when too many categorical hues are used. In this plot, we can not separate the colours even if we spent a considerable amount of effort studying the chart.

As we saw on the last slide, categorical colour schemes have a limited amount of hues so in addition to it being hard to differentiate this many hues in general, it becomes practically impossible in cases where there are more categories than colour hues, since the colour scheme starts repeating as in the chart.

A better approach here would have been to label specific points of interest directly and keeping the rest as either a single colour or using a categorical variable with fewer values, e.g. by grouping the cars into brands rather than their full model name.

Since Altair allows for interactive elements, we could also have used the tooltip here as we saw in a previous module.

Redundant coding of bar charts can be disorienting

cars['Brand'] = cars['Name'].str.split().str[0]  # Extract brand from the name column
chart = alt.Chart(cars).mark_bar().encode(
    alt.Y('Brand', title=None, sort='x'),
    alt.X('mean(Horsepower)')).properties(width=200, height=350)
chart | chart.encode(alt.Color('Brand', legend=None, scale=alt.Scale(scheme='tableau20')))

A few slides ago we saw how encoding the same variable as both shape and colour could make our figures more effective although it is technically redundant.

Similarly, you might come across bar charts where the author of the visualization has added a distinct colour for each bar.

This can work when there are relatively few bars, but it usually does not add anything and can become directly disorienting when there are many bars as in this slide.

It is usually preferable to colour all the bars in the same colour (or after another categorical variable, such as “Origin” in this data), and let the axis labels alone identify which category the bar belongs to.

One exception to this is if each axis label is broken down into subcategories where each location has multiple bars based on another categorical variable, then colour can help.

You can also see that the car brands are not systematically named and we would need to clean this data to unify e.g. ‘vw’, ‘vokswagen’, and ‘volkswagen’. The reason we’re setting the height is just to fit the plot on the slide.

Use consistent colouring between subplots even when it is redundant

chart = alt.Chart(cars).mark_bar().encode(
    alt.X('Origin', title=None),
    alt.Y('mean(Horsepower)'),
    alt.Color('Origin', title=None))
(chart | chart.mark_line().encode(alt.X('Year', title=None), alt.StrokeDash('Origin', title=None)))

When creating a figure that contains several subplots, it is important to be consistent in the colouring between these even if the colouring is redundant in one of the subplots.

Here we have coloured the bars to match the lines although we could tell the categories only from reading the axis labels.

It is important to not use different colours for the same categories between subplots. For example, if we made an additional subplot that only contained Japan and the USA, then we should make sure that these are still coloured in orange and red. Since the default Altair colour scheme will always start with blue, we would need to manually specify the colours in this case.

Let’s apply what we learned!