How to render a network map, part 3: color

25 min read

In this series of posts, I roam and gauge the design space of network maps. In the two previous posts, I explained how to render a network in black and white and in grayscale. It is now time to explore what color can do for network maps.

One of my goals is to find the best rendering approaches for network tools. This series exposes my rationale so that it can be discussed and criticized, but I will extract do’s and don’ts and takeaways along the way, so that you can also get reusable, practical insights about visualizing networks.

The criteria I will use to assess and discuss each design are the following:

  1. Do the nodes contrast with the background?
  2. Do the edges contrast with the background?
  3. Do the labels contrast with the background?
  4. Do the nodes contrast with many underlying edges?
  5. Do the labels contrast with many underlying edges?
  6. Do the labels contrast with many underlying nodes?
  7. Do we see which edges are connected to a given node?
  8. Does the heterogeneity of the node distribution jump at our face?
  9. Can we identify the edge bridges between clusters?
  10. Context: how many labels can we read?
  11. Colored communities: can we see distinct groups of colored nodes? (typically in a situation of community detection)

Visualizing in color

Color is a vast topic that I won’t try to cover exhaustively. Levels of gray imposed such constraints that we had pretty limited options to produce readable designs. With color, there are so many possibilities that one cannot inventory the good design strategies. In short, with a clever use of color, one can almost always “fix” the “bad” designs we have seen earlier. Therefore my goal here is just to provide safe choices for a common use case.

I will contain the scope of this post to using color to visualize a categorical node attribute. In this particular case, I will visualize the airport country. There are too many countries to use that many perceptively distinct colors. For strategic reasons, I will use only 7 distinct colors with a luminance of about 55% and a chroma of at least 50% in the HCL color space. Only the 7 countries with the most nodes (i.e., airports) are therefore colored (USA, Canada, China, Brazil, Australia, Russia and India) while the other countries (including all of Europe and Africa) are colored in gray (also with about 55% luminance). These numbers are in part arbitrary, but my choices have a specific purpose that will appear progressively.

Color science is complicated. To discuss what is at stake in the choice of colors, we need to draw on a body of knowledge and know-how from graphic design. As I would like this piece to be accessible to non graphic designers, I will not discuss my use of color in details. I am afraid that arguments about color get too technical too quickly, contrary to what our intuition suggest (the feeling that color is just empirical information put in our brain through the eyes, which is not at all how it works). I will instead prioritize the overall rationale, and I will make visual arguments instead of theoretical ones.

In short, I selected colors that have the same perceived lightness, so that I could use grayscale visualizations as a baseline. If you pick completely random colors, some will be dark and others will be light, and unsolvable contrast issues will arise.

Colored dots

We have seen that black dots already give a pretty good representation of the layout, which is the most important thing. Let us naively start from the same point, and just color the dots: each node’s color visualizes the country of the airport it represents.

Compared to just black dots, two problems arise. First, the lesser contrast makes the layout harder to read. Second, the color is not easy to perceive. Indeed, the color requires enough space to be perceived properly. Contained in separated small nodes, it is barely readable.

DO: Give room for color to breathe.
DON'T: Colorize just the nodes, as they do not occupy enough space.

Colored edges

Let me discuss upfront the practice of displaying edges and coloring them, because that is what I have seen many people do (and it’s Gephi’s default behavior). In the image below, the edges are colored as their source nodes. In other words, the airlines are colored by the take-off airport.

Assessment: The contrast of nodes and edges with the background is good, but not that of nodes with edges, as they have the exact same color. For the same reason, the layout is not prominent enough. The bridging edges are visible enough, though. Finally, the communities can be identified, but in an imprecise way, as it is the edges and not the nodes that carry the color.

There is a non-obvious issue with drawing colored edges. The edge drawing order matters. Indeed, the edges drawn last end up on top, and their color dominates. It matters more often than you might think. Here is a real-world example. It comes from Lada Adamic and Natalie Glance’s famous paper Divided they Blog, but is also featured in other papers, notably Lazer et al.’s Computational Social Science. We have two clusters, one of which is blue (nodes are liberal blogs) and the other, red (nodes are conservative blogs). The edges are hyperlinks. Within each cluster, the edges are colored like the nodes. But between the clusters, it looks like the edges are yellow or orange, but that is incorrect. The authors have colored the 781 edges from liberal to conservative in orange, and the 902 edges from conservative to liberal in purple. Those edges are the bridges between the clusters, and occupy the same space. If a color had to dominate, it should be purple, as it is more represented. But for contingent reasons, the orange edges ended up drawn last (on top) more often, hiding most of the purple ones. As a result, it looks like there are more hyperlinks from liberal to conservative blogs than the other way around, while the opposite is true.

Image from Divided they Blog.
Adamic, L. A., & Glance, N. (2005, August). The political blogosphere and the 2004 US election: divided they blog. In Proceedings of the 3rd international workshop on Link discovery (pp. 36-43).
DO: Randomize the order of the edges if your visualization process depends on it while the order is expected to be arbitrary.

Edges give more space to color, and it makes the color more visible, which is a good thing. The effect is dramatic. Coloring the edges makes the communities (i.e., clusters) more visible, even though it also makes the layout less readable. To make it work, we have to address two issues: the fact that the edge drawing order matters, and the fact that edge color is really just a (quite poor) proxy for node color.

Before we look at ways to preserve the readability of the layout, let us address an arbitrary choice: coloring the edges by source node. Here is, for instance, the same visualization but with edges colored like the target node.

The image is not significantly different, but that depends on the network. The difference can sometimes be striking. Here is a compromise: edges colored using the mix between the source and target node colors.

Depending on the network, one of these three choices may be the right thing to do. For instance, for a network of web pages connected by hyperlinks, like Divided they Blog, coloring by source node manifests the fact that hyperlinks are materially situated in the source page. With airlines, we do not have such a solid rationale. We also have a problem with the overlap of mutual edges: if there is an airline from A to B, there is one from B to A (people need to come back!). We could use strategies to avoid this overlap (ex: curved edges), but that is beyond the scope of this post. Let us just mention that a mixed color solves the issue in our case. Using a color mix for edges is the safest choice for us.

DO: If you color edges using a node attribute, think of what makes most sense in your situation: the color of the source node, of the target node, or a mix of both.

From there, with this design, the most important thing is to notice the conflict between the necessity to give room to colors, which requires loud edges, and the necessity to manifest the layout, which requires muted edges. The best solution is to avoid relying on edges to give room to color, to use a different solution; but that requires a sophisticated process. Before we get there, let us see how we can make the visualization work better by just coloring the usual graphical elements (nodes, edges, and if available, hulls). My starting point will be the grayscale visualizations from the previous post.

Flat style with hulls, colored nodes, white edges

For the sake of the argument, let us reuse the grayscale visualization with gray nodes, but coloring them instead. I use the same luminance. In that version, the edges were white, which prevents us from coloring them.

Assessment: The contrast between the different elements is good (except for labels with nodes, which is mediocre), and the layout is visible enough. However, as we have seen before when edges are not colored, the color lacks room and is hard to read. The communities are hard to see, except for the highlighted one (but hulls do not scale unless you use small multiples).

DO: Color the edges to give room for colors to breathe (unless you have access to a better technique, like color spreads).
DON'T: Color only the nodes, as they do not provide enough space for color to allow identifying the communities easily.

Flat style with hulls, colored nodes and edges

If we use colored edges, we obtain this result (also reusing the corresponding settings from visualization in grayscale):

Assessment: The contrast of the different elements with each other and the background is good, bridges are well visible but the emphasis on the layout is mediocre, one cannot afford that many labels, and the communities are visible but not with a good precision.

Important remark: we have modified the colors to control precisely their luminance (perceived lightness). This is why nodes and edges do not have the exact same color. That color theory trick can be done automatically, with libraries like D3 for instance. The visualization works well enough thanks to this. However, it comes with a drawback. As the original colors are modified, it is possible that two distinct colors get changed into the same resulting color (or two very similar colors). Typically, a dark green and a light green may result in the same green. The differences in lightness will get erased while the differences in hue will remain. So this strategy works only if you pick colors the right way (i.e., with distinct hues).

DO: As a tool maker, if you use advanced color tricks, pick the colors algorithmically to prevent color conflicts.
DON'T: Let the user pick colors freely if it may lead to conflicts between the modified colors of the visualization.

Simple style with colors

We can also draw the network with color in even simpler ways, while still retaining the idea of controling color lightness. In the example below, nodes, edges, and labels are colored with curated levels of lightness. No hulls, just a straightforward rendering with controlled colors.

Assessment: The contrast between the elements is decent to good, the layout is decently emphasized even though the bridges are not that visible, we cannot afford too many labels because they compete visually with the layout, and the communities are visible but imprecise (since mediated by the edges).

The main drawbacks are the same as before: colors can only be differentiated by their hue, which requires picking them carefully; the drawing order of edges matters for arbitrary reasons; and the edges mediate an information that actually refers to the nodes, which is imprecise. However, I find the result more readable than with the hulls. The layout is easier to read, even though the bridges are highlighted less.

Takeaway: a simple rendering is relatively efficient and can be implemented easily, but it still requires controlling the colors to ensure appropriate contrasts. Mind randomizing the order of the edges to remove an arbitrary dependency to how the data was produced.

Color changes how we think of contrast

Comparing the last two rendering helps understanding how, when it comes to contrast, color is beneficial and detrimental at the same time. It is beneficial because it can bring some contrast. Typically, a colored node will be pop more over a gray background than its gray equivalent of same lightness. But using color also forces us to use a narrower lightness range, as neither black nor white can be colored. And color can also be distracting, and can quicky draw attention away from the layout.

One cannot simply take grayscale designs and color them; it gives some results but they require adapting. Indeed, new tradeoffs appear. In particular, we have less room for differentiating the layers by their lightness, but we can compensate this constraint by gaining contrast when color is over gray. And we have to emphasize the layout even more, because color draws attention away from it.

This last point deserves unpacking. One may think that color makes the layout more readable, as it emphasizes groups or other structures, depending on which node attribute it maps. True enough; but even so, it acts like a shortcut to the network structure. And like any shortcut, it makes you miss part of the journey. The structures emphasized by color are more readable, yes, but then all the other ones become less visible. It interferes with the balance of the graphics, shifts the reader’s attention, and impacts their interpretation. In the examples above for instance, we differentiate well between airports from the USA (green) and Canada (purple, both on the right), even though they basically belong to the same North-American cluster. But on the contrary, and that is the problem, it draws attention away from the fact that this cluster has subclusters for the West coast (on top of the cluster) and the East coast (bottom-left of the cluster). The color steals attention from the distribution of nodes. It provides ready-made groups, but it makes density-based groups (topological clusters) less visible; and those are the reason why we make a network map in the first place.


I retain three. First, simpler designs are more efficient, because color tends to complicate everything. Second, do not repurpose colored network maps as grayscale by removing color. If a journal requires a colorless illustration, instead of removing color in a picture editor, render a new grayscale visualization. Design for grayscale if you need to. Third, ensuring that the layout pops out is even more difficult when using color, so you need to care even more about preserving the topological affordances.

Color spreads

I believe that the simple colored design just above is a good compromise between ease of implementation and readability, despite a few flaws. For a really high quality result, we need something sensibly more sophisticated. In this section I explain a technique that I call “color spreads”, for a lack of a better term.

Color spreads: proof of concept

Here is a proof of concept (POC). In short, it is not the job of edges to spread the color of nodes, so we should use a dedicated technique to do that.

This POC has been assembled manually in Photoshop, using images already generated. It is also far from perfect, which hints at the fact that doing this well is not straightforward. But it gives a practical idea of my goal. I aim at compromising between the following features:

  • Colored clusters are visible at a large scale, because color spreads around the nodes (color needs space, as we have seen).
  • But the color spreads do not compete with the details at a smaller scale. They should be as unintrusive as possible.
  • The color spreads should be as true to the nodes as possible (the POC is bad at that).

My strategy is to draw a very smooth colored area around each node, and composite it with the rest of the image. It is not as simple as it looks.

Color spreads: naïve implementation

The most naïve strategy is to draw the nodes and then apply some massive blur. As a starting point, let us draw color spreads as bigger, lighter nodes. We will omit the blurring for now.

An obvious issue arises: the drawing order of the nodes matters. The nodes drawn last (on top) spread their color too much, around nodes that are not of the same color. Blurring the image would not solve that issue. The natural solution to this problem is to use a Voronoï partition of space, which would guarantee that each pixel gets colored like the closest node.

Color spread: Voronoï

Each node is guaranteed to bathe in its own color. Two things are distracting, though: the borders between cells, and the circular outer border with the background. In both cases, the contrast creates lines that draw attention to them. We will address each issue one after the other.

Let us address the outer border first by using a gradient.

Color spread: Voronoï + gradient

The gradient here is simply the distance to the closest node (the node that gives the cell its color). It is similar to what we have seen previously with node halos.

The gradient still “falls” quite abruptly into the background, which can be improved. Indeed, the gradient is currently linear. We can use a smoother curve, so that the transition feels more natural:

We used the linear version so far, but we will now use the smooth version for the gradient (see below)

The curve now makes the cells look smaller, which we can compensate by augmenting the radius of the Voronoï cells. We can also add a touch of blur to address the issue of sharp borders between the cells. We obtain a color spread that gives room to the color of nodes, remains (quite) true to the color of the closest node, but without adding distracting details, as it remains smooth and blurry.

If we simply composite this color spread over a detail-rich rendering from before, we see that it does not compete with the details. The result is also better than our proof-of-concept tinkered in Photoshop.

Assessment: The contrast of the different elements (nodes, edges, labels) with each other and the background is good. We can see which edges connect to which nodes (to some extent). The layout is well emphasized. The bridges are visible. We can read many labels. Communities are readable via colors, even though we could do it even better.

This result shows that this strategy works. However, as we have seen, the presence of color requires rethinking the question of contrast. For instance, we want to color the dots too. We can do better than just repurposing the grayscale rendering. Now that we have a color spread that works, we can rethink how the image compositing for color, using all the techniques at our disposal.

Rethinking the compositing for color

As the raison d’être of the network map is the layout, I want to compare my result to a baseline where the layout readability is maximal. As a starting point, one can render a simple visualization with just three layers: hillshading (in gray), color spread (composited as “multiply”), and nodes (in color, with a controlled lightness, that is pretty dark).

Compositing the color spreads as “multiply” is the simplest thing to do, as it basically works as if white were transparency. However, it also means that the color spreads make the background darker around the nodes (as it adds their darkness). It also means that dark areas make the color less saturated, more dull. The effect is subtle in this map because it is very light and does not have much details, but it would add up as we stack other elements. For that reason, I think we should do better. We can afford a better baseline.

We can have more control over the homogeneity of lightness and preserve saturation by using another mode of composition: “color”. That mode applies the hue and the saturation but keeps the lightness unchanged, offering a better control over contrast. This is what we obtain by just compositing with “color” instead of “multiply”:

The contrast is better controlled, but a new problem arises. As white areas cannot be colored (white and black have no hue), the color spread is inconsistent. We see white (and therefore colorless) areas on the north face of the hills (metaphorically). The solution is simple: we can add a very light gray to the background, so that the color can spread everywhere.

This result is smoother and we can then control lightness as much as we want. The result may not look too different for now, but it will matter increasingly as we add details.

This visualization is our baseline. The layout is well emphasized, the color has enough room to be breathe, and we have full control over the contrast. Our goal from there is to add details while preserving the readability of the layout. We want to allow following edges and reading labels from close, while keeping a good legibility of the topological structure from a distance.

Once again, we will be compositing layers one after the other. To make it clear how the compositing works, I will present each major layer one by one, and show how they stack. I write “major” because most of those layers are also composited from sub-layers, as you will shortly see.

Background layer

Our starting point is just a gray background with hillshading, with twist for the nodes. First, we paint the background in light gray, keeping the space for nodes white.

We then composite the hillshading on top (mode “multiply”).

We paint the nodes in white over the background to be able to composite them in “multiply” later on without loosing some lightness due to the non-white background. However, we want to keep the hillshading on top of those white spaces because else, the final result feels unnatural. Indeed, the hillshading acts like a shadow that we intuitively expect to apply to the colored nodes too.

Edges layer

The second major layer we compose is dedicated to the edges. It is itself composed of sub-layers. In short, we draw the edges in a relatively light gray, but with some space for the labels and the nodes in white. The goal is to composite this layer using “multiply”, so the level of darkness matters (white acts as transparency).

We composite this layer on top of the background layer:

And we then composite the color spreads in “color” mode, to obtain a background where edges are not too prominent:

As you can see, the hillshading emphasizes the layout well despite the edges.

Nodes layer

The nodes layer will be composited in “multiply”, as we once again want to use white for transparency. We draw the nodes using their color but controlling lightness so that it is dark enough (so that the layout is well emphasized). On top of the nodes, we paint labels in the background color (that will matter later on). The labels must not be painted outside of the nodes, which can be achieved by painting the non-node space in white afterwards.

Once composited in “multiply” mode on the precedent image, we obtain this result:

The clear dots we had left in the background layer ensure that we can control the nodes’ darkness independently of the background shade, with the exception of the hillshading, that applies in addition to that.

Labels layer

The labels are drawn on a white background for “multiply” compositing. To avoid distracting from the layout, we control both the lightness and the saturation of the labels. Each label has the color of its node, but with a limited saturation and a lightness barely above that of edges.

The expected result is to have the labels be seen as a gray texture from a distance, similarly to the edges, so that the layout remains clearly readable. The labels are therefore not expected to be as clear as they could. Yet from close, thanks to the white border cut from the edges layer, they remain readable.

Fully composited image

With the labels added, the image is fully composited.

Assessment: The contrast of elements with each other and the background is decent to good. We can track which edges connect to which nodes to some extent, the layout is well emphasized, bridges are visible, and we can read many labels. We can easily read the communities from colors.

Here is a side-by-side comparison with the baseline:

And here is a side-by-side comparison of the POC (Photoshop mockup), the simple compositing with a grayscale rendering, and our final result:


Color spreads keeps a distribution of color that is more true to the nodes, as it does not depend on the edges. An appropriate compositing allows controlling color (hue) independently of lightness, in order to find an optimal compromise between the readability of each element and the highlighting of communities with color.

If your rendering environment does not allow you this level of sophistication, a simple rendering style with colored nodes and edges works well enough, at the condition to control the lightness to support appropriate contrasts.

Either ways, the constraints are too strong to allow picking colors freely. Because controlling contrast forces us to rely on the sole hue to differentiate colors, this basically gives us about 6 to 8 different colors maximum, if we want to be able to differentiate them reliably.

DO: Limit the number of different colors to 10 or less, preferably 6 or less. One cannot distinguish more in this context.
DON'T: Try to colorize everything at the same time, because it is not readable anyway, so there is no point.

Cite this blog post
Mathieu Jacomy (2023, May 9). How to render a network map, part 3: color. Reticular. Retrieved April 24, 2024, from

One thought on “How to render a network map, part 3: color”

  1. Things I have not addressed so far:
    * Label orientation (and more generally, isotropic constraints)
    * Hypsometric gradient
    * Small networks (important for presets)
    * Curved edges (arrows? Edge direction)
    * Edge weights (thickness)
    * Edge color
    * Annotations, heat maps (additional layers)
    * Metadata (legend, title, author…)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search OpenEdition Search

You will be redirected to OpenEdition Search