35 min read
In this series of posts, I roam and gauge the design space of network maps. In the previous post, I explained how to render a network in black and white. It was essentially an occasion to explore the contrast issues inherent to visualizing networks as dots and lines. I will now move closer to a realistic use case: rendering a network map without colors, but with levels of gray (aka grayscale).
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:
- Do the nodes contrast with the background?
- Do the edges contrast with the background?
- Do the labels contrast with the background?
- Do the nodes contrast with many underlying edges?
- Do the labels contrast with many underlying edges?
- Do the labels contrast with many underlying nodes?
- Do we see which edges are connected to a given node?
- Does the heterogeneity of the node distribution jump at our face?
- Can we identify the edge bridges between clusters?
- Context: how many labels can we read?
- Colored communities: can we see distinct groups of colored nodes? (typically in a situation of community detection)
Classic stack of layers
We can think of background, edges, nodes and labels as four different layers stacked on each other, in this order. This is how most network maps are built. We can leverage contrast to overlay each one over the precedent using a darker color, and it will remain separated. This is what it looks like.



Assessment: The contrast of each element with others (nodes, edges, labels, background) is good, except for the labels over the nodes, and the edges over the background, that have room for improvement. The layout is visible enough, and we have sufficient context (labels). The bridging edges are not too visible though, and we still cannot read which edges connect to which nodes.
Note: here I reused the settings from the last post (black-and-white rendering) and just added levels of gray. In particular, I used the strategy I had recommended for the labels: sparse enough, with controlled font weight.
No need for node borders, no need for sophisticated techniques beyond selecting which labels to display. The nodes contrast with edges, and their distribution is visible. The edges are visible but not distracting. The labels are readable. It basically does fine on every aspect except reading which edges connect to which nodes. This is the baseline for my exploration of improved designs.
DO: Stack layers with levels of gray staged from white to black (or vice-versa), especially if your rendering tools don't have complex options, as it can be surprisingly efficient and reliable.
Let me mention three minor flaws, though. First, the levels of gray have to be staged carefully. The edges can be very light, and the nodes have to be dark enough that their distribution pops out. Second, the labels may still compete with the rest if they are too dense, so it is still important to limit their number. Third, as we use the whole spectrum of grays, the picture gets easily damaged in high-contrast situations, such as poor quality printing (dark gray conflated with black) or video projection (light gray conflated with white).
DO: Pick the edges as light as possible (but still visible), and the nodes as dark as possible (but with labels still readable on top). Mind the target medium (screen or print). Keep labels as thin as possible (light font) and as sparse as possible. DON'T: Set the edges so dark that the nodes are hard to spot in dense areas.
Classic stack of layers with emphasis on nodes
The baseline works, but it makes an assumption worth challenging. It assumes that labels prime over nodes. Yet as we have mentioned, they should not. Our top priority is to keep the spatial distribution of nodes emphasized; readable labels are less important. What are our options?
Option 1: nodes over labels
This is for the sake of the argument, as illegible labels are particularly frustrating. The reader will probably conceive this design as a mistake. Yet the result is surprising and interesting.



Assessment: Compared to the baseline (classic stack of layers), we lose some contrast of labels with nodes and, from there, some context (labels are less readable overall), but we sensibly improve the emphasis of the layout.
I find it counterintuitive: the distribution of nodes is emphasized better, and the labels remain largely readable. From a purely functional perspective, it is arguably better than the baseline, except for a major flaw: in situations where nodes are densely packed, the labels are not readable at all (cf. example below).



Because of this flaw, this solution is problematic in general, but may works surprisingly well in situations where the nodes are not too big and not too closely packed.
Option 2: labels on top but lighter
This solution is not the best but it is worth noting why. The distribution of nodes retains some emphasis, the labels are more readable than before, but they are still too hard to read, and some amount of occlusion still occurs.



Assessment: Compared to the option 1 (nodes over labels and darker), this option is essentially the same with a minor improvement of the readability of the labels on top the nodes.
DO: consider displaying the nodes darker than the labels, and possibly over the labels, in particular if the nodes are sparse and/or small. DON'T: do that if the nodes are very dense, as the labels would not be readable.
Finding the right value for the labels is a Catch-22 situation. They cannot be too dark to avoid competing with nodes (it would obfuscate the layout) but they cannot be too light or they will not be visible over the edges. Ultimately, no matter what value you pick, they will tend to compete with nodes over the background and the edges, and yet occlude the nodes when they are on top of them. The settings in the example above work a bit better than having the nodes on top of the labels, because we can at least decipher them, but they remain too hard to read and we cannot really get anything better. The labels are basically as thin and light as we can afford. And if we make them darker or thicker, they will compete with the nodes (see example below).



In this rendering, the labels downplay the layout too much (and they are not even that much more readable).
Option 3: labels on top with opacity
This solution aims at keeping the labels darker when they are on top of the nodes, but not too dark when they are on top of the edges or background. This can be achieved if nodes are not fully dark, by leveraging the opacity (alpha channel) of the labels layer.



Assessment: Compared to options 1 and 2, we have improved the contrast of labels with edges, but we have damaged the contrast of labels with the edges and the background, and of edges with the background.
Some labels are hard to read but it can be done, and we see the node placement well. The gain over option 2 is not indisputable, and it requires a precise tuning. In the example above, the image looks too pale. The strategy (barely) works but remains fragile, as many things could easily go wrong.
We have not completely solved the Catch-22 situation of option 2. Pushing this strategy forward would require controlling two parameters independently. First, when over the edges and background, the labels must be as light as possible to be readable but without competing with the nodes. Second, when over the nodes, the labels must contrast with the nodes, using border, a darker color, or both. This cannot be done with opacity alone.
DO: carefully stage the lightness/darkness of the different elements to provide appropriate contrasts. DON'T: use opacity, as it does not provide sufficient control over the contrast of the different elements, and will often create multiple unwanted side effects.
Takeaways about stacking layers
Stacking layers with staged levels of gray works relatively well for everything except reading which edges are attached to which nodes. The classic approach lacks emphasis on the node placement, and fixing it requires compromising with the readability of labels. I still recommend it: render the labels on top of the nodes, but feel free to set the nodes darker than the labels so that the labels compete less with the layout.
As a tool maker, I find the classic option of having labels in dark over nodes dangerous, because the legitimate desire to display more labels (more context) easily jeopardizes the clarity of the node placement. For that reason, I favor strategies that keep the placement readable no matter what. I acknowledge, however, that those strategies are not great. This is why I think it is worth pushing the sophistication further.
Compositing layers
From this point I will use a more advanced strategy. It will be familiar to graphic designers who use applications like Photoshop or drawing systems like HTML Canvas. Canvas calls it “composite operations” and the idea is to have different ways to stack layers. In a given mode, white on black may produce white, and in another one, black, and so on. We can use different operations to compose the layers; you may think of it as choosing whether you want to add, subtract, multiply, etc. the layers. I will use the Canvas names for reference.
This technology is available in many environments, and from the standpoint of a tool maker, implementing it is not too complicated. But for the user, mastering compositing requires graphic design competences, which cannot be taken for granted. I think that a tool maker using these strategies would have to curate the settings exposed to the user, and/or keep it as presets.
Split rendering of labels
Here we split the rendering of the labels in two distinct graphic situations: (1) over the edges or the background; and (2), over the nodes.
First, we ensure that the labels are readable over the edges and the background, but not too visible. I suggest picking a gray that is just slightly darker than the edges, and using a white border. As the label border ensures visual separability from the edges, we can make the edges darker than previously.



Note: to make composition easier, we render the nodes in white but on top of everything else (i.e., at the end).
DO: for the labels, pick a the level of gray such that once merged with the background color used for the label borders (when we look at the map from a distance) results in about the same gray as the edges.
Second, and separately, we draw just the nodes and labels such that the labels are well separated over the nodes, but without the nodes getting too light, so that they keep contrasting with the background. The label borders should be gray while the nodes and the labels should both be black for maximal contrast.



Then we crop this image around the nodes. In practice, here is what we do: we keep a copy of the image with just the white background and the black dots, and we composite it on top of the image above using the composite operation “screen”, which boils down to adding just the white. We obtain this:



Now, we simply draw this last image (nodes) on top of the previous image (labels) using the composite operation “multiply”, which boils down to just adding the blacks. We obtain the final composited image.



And as the labels do not compete with nodes anymore, we can crank their density up! Here is where we land:



Assessment: This rendering almost nails it! The contrast of each element with each other is good, the prominence of the layout is good, bridges are visible enough, the only issue is that we cannot read which edges are connected to which nodes.
With this strategy, the labels are mostly visible up close (zoomed in) while the structure of the network remains clear from a distance (zoomed out). Compositing is demanding, but it basically allows fine-tuning multiple aspects of the picture simultaneously and independently. This version essentially addresses all of our needs but one: reading which edges are attached to which nodes.
DO: composite your rendering if you can, so that the labels are visible up close but do not obfuscate the layout from a distance. DON'T: obfuscate the layout with the labels, because we do not need to read most labels from a distance (but we need to read the layout).
Hillshading
To emphasize the distribution of edges even more, we can borrow the hillshading technique from traditional geography. In a nutshell, we infer an elevation of the visualization space from the density of nodes. You can think of it as a heat map or a kernel density estimation, which boils down to the same thing. This elevation can then be rendered as shadows, also known as hillshading. You can find an implementation in JavaScript in this notebook.
The hillshading technique emphasizes the node distribution and is a valuable visual help in situations where many graphical elements compete with the nodes. I will not provide technical details here (find them in the notebook mentionned above), but highlight how it can be composited.
Here is the hillshading alone:



In this case, we can simply composite hillshading over the background layer (everything outside of nodes) in “multiply” mode.



Assessment: Compared to the version without hillshading, it slightly improves the readability of the layout.
The hillshading is so smooth that it does not compete much with the nodes even if it makes the overall image darker. At a distance, it emphasizes areas with densely packed nodes without being too intrusive. It helps guide the reader’s attention toward the most important thing, the spatial distribution of nodes.
Node halos
Let us tackle the last issue: how to see which edges attach to which nodes? The technique I propose makes room around each node where we can see only the edges that attach to it. I will describe how it can be done, then show the result, then discuss it.
The idea of the first step is basically to compute a Voronoï diagram. For each pixel or point of an arbitrary grid, we compute which is the closest node and what is the distance to it. We will tweak that in two ways, but let us keep it simple for now. If you just plot the distance to the closest node as a gradient, you get this:



It looks like little balls glued together, and for good reason. Two important remarks. First, we see very well the delimitation between areas that “touch” each other (nodes that are close to each other). Not all the cells (the “balls”) are round, as when they get densely packed, they get flattened by the neighboring cells. This information is key to drawing node halos properly for densely packed nodes. Second, the size of the balls is a parameter that has to be set. It will ultimately determine the size of the node halos. It has to be set by the user, but in a nutshell, it should have the order of magnitude of the smallest nodes’ size, which should also be that of the spacing between nodes.
In practice, we will tune this Voronoï in three ways. First, we will take into account the node sizes, so that the distance is computed to the border of the node instead of its center.



Second remark, we should tune the gradient so that the white is more visible. The white represents the halo, and the lighter it is, the more the edges belonging to that specific node are distinct from the other edges. That is an optional refinement that makes the result more natural in the end. In short, we need to see the edges connecting to each node, which requires very white halos.



Finally, we set the size (spreading) of the Voronoï cells so that for about every node except the most packed ones, the gradient of the cell drop is visible. The cells (white areas) will become the node halos. If they are too big, the pattern will become distracting. If they are too small, it does not serve its purpose (making it clear which edges attach to each node).



The next and final step is to draw the edges using the Voronoï data computed above. The strategy is the following. Each edge is converted into a path consisting of a series of points. If the edge is a line, we must not compute it all at once but bit by bit. The points must be close enough to roughly match the grid size used to compute the Voronoï. For each point of the edge, we compute the opacity from the Voronoï data, using the closest grid point or something more clever like an interpolation of the 4 closest ones. In short, the point should be opaque in black areas and transparent in white areas (in the Voronoï plot above) except when the closest node is the source or the target of that edge (that is why we must also store which is the closest node). Here is the result:



The technique is compatible with simple approaches as well as the most sophisticated ones. Here it is integrated with our baseline (classic stack of layers):



Assessment: Compared to the classic stack of layers without node halos, we sensibly improve the clarity of which edges are connected to which nodes, even though it is not perfect. This also helps following the bridging edges. There are no downsides.
And here is what it looks like with compositing and hillshading:



Assessment: Similarly, node halos make it much easier to understand where edges connect to nodes, with no downsides. Recap: the contrast of nodes, edges, and labels, with each other and the background, is good. The layout pops out very well. We can read many labels. We can see and follow the bridges well, and we can decently understand which edges connect to which nodes. It essentially checks all the boxes (aside from colored groups).
Note: In this case I have displayed many labels, and as they have borders, the node halos are quite often hidden behind the labels. We have added so many details that the visual competition becomes a concern again. This is why I assessed the ability to see which edges connect to which nodes as only decent, but we could get play this tradeoff differently by displaying less labels.
Discussion about node halos
Node halos are not intrusive. If you don’t understand what they are, you can basically ignore them. They will not cause the image to be significantly busier. But I think that they are in fact pretty intuitive, especially in areas where there are not too many nodes and not too many edges.
However, as soon as you want to read node halos, the relevant space of a node is more than just the dot (and label), but also its surroundings (the halo). As a consequence, and even if the image does not get much busier, there are now more parts of the image that one does not want occluded. As a consequence, the competition for space (if not for attention) increases between the graphical elements.
DO: Set the layout algorithm so that close nodes have a constant margin between them, and set the range of the node halos so that it matches about the half of that distance. DON'T: Let nodes overlap, as node halos will not help you there.
Even when they are not occluded, the node halos do not provide a perfect information. Indeed, it remains hard or even impossible to track any given edge. The key insight they provide, however, is to clarify the “reason” why each node has been placed where it has been. Indeed, some nodes are under the influence of many neighbors, which means that their position is determined by the general structure of the network. Those nodes appear as dots with many lines connected to them, and their halo is barely noticeable. On the contrary, some nodes are under the influence of just a few neighbors, and their position is determined at a local level. Such nodes may be placed in the middle of the picture, but only because they are neighbors to nodes that are structurally central. Their situation is that of a small satellite of a big planet. Those nodes will have a clear halo around them, because they do not have many edges, and we will be follow their edges easily. More generally, the halos make the local structures visible, and help make the distinction between large-scale patterns and small-scale patterns.

Note: node halos sometimes create a 3D-like antipattern with big, dense clusters. This comes from the fact that the nodes on the side of the cluster have most of their edges directed towards the inside of the cluster. As a result, node halos get more of the background color turned towards the outside of the cluster. This creates an unwanted illusion of depth. One may find it aesthetically pleasing, but it remains undesirable because it warps the perception of distances. The layout algorithm was applied in two dimensions, not three.

Grayscale, flat design, with hulls
I will now explore a different design direction, and for simplicity I will keep the design flat: no gradients (hillshading), and no advanced compositing. Just layers. So far we have used 4 layers: background, edges, nodes, and labels. We have seen that their order matters, and their contrast also matters. I will consider two new things: using different ways to organize the layers by contrast, and adding new layers to highlight the shape of the network and/or clusters (set of nodes).
Network hull
What I call here a network hull is a shape surrounding all (or most of) the nodes of the network. There are different ways to compute such hulls, and I will just stick to this one here: using a threshold on a heat map of the nodes (the same heat map as for hillshading, which you can also think of as a kernel-density estimation).
Hulls provide a form of highlighting. They are mostly relevant for clusters. They do not work very well if the highlighted nodes are disseminated everywhere. They work best when the highlighting nodes are packed together in one or more places.
The hull of the entire network can be used to highlight its structure with more or less subtlety:



Assessment: Compared to classic layers with black nodes but without the network hull, we just gain a bit of emphasis on the bridges, because the edges are now more visible between the clusters.
With the settings above (based on classic layers with black nodes), I retain three effects on the image.
- The network hull draws attention on the presence of nodes, not edges. Which is a good thing, as edges are baked into node positions.
- It lowers the contrast of edges above the hull (within the hull). As those edges tend to be the short edges, and those are accurately represented by the layout, it is not a big problem. On the contrary, it makes a less busy background to nodes and labels.
- By comparison, it highlights the edges outside of the hull, which are the long ones, and the less accurately represented by the layout. Those edges are bridges, and they have a special role in the structure. Highlighting them is beneficial.
Used this way, the network hull does not improve the visualization by a lot, but it can be useful. It also depends on how the contrast is articulated between the different layers, which we will explore.
As the network hull is much less busy than the full visualization while retaining information about its structure, it can be used by itself or with just the nodes to provide a simpler view on the structure. This can be used for mini-maps or small multiples (an example will follow).



Cluster hulls
Hulls can also be used to highlight groups of nodes (generally, a cluster). Here I will pick a single subset of the nodes to highlight with a hull: the airports situated in the USA (reminder: this is a network of airports connected by airlines). I picked settings that make the cluster hull fit nicely within the entire network’s hull. But of course, depending on the situation, you may want to use hulls differently. You may want to display multiple hulls at once. I will not explore this here as it depends too strongly on the shape and distribution of the clusters. I will stick to this single hull:



Note: although the second zoom is not focused on the hull, I will keep it for consistency.
Possible misinterpretation: this looks like a heat map. One may understand that the highlighted cluster is somehow denser or higher on some unspecified scale, which is not the case.
It is worth noting that the hull shapes can be rendered as lines for a different compromise. Lines are more distracting than flat surfaces, but they obfuscate less.



I recommend to keep the network hull as a surface and the cluster hulls as contours, to emphasize the fact that highlighting a cluster is essentially an annotation. In this case, one draws the network hull at the bottom and the cluster hulls on top. Here is an example as a small multiple, in inverted colors for the sake of variety:









DO: Favor a filled hull for the network and contoured hulls for additional annotations (cluster highlight). DON'T: Stack cluster hulls if it makes the map confusing or cluttered (use small multiples instead).
The design choices worth exploring from here are: in which order to draw the layers, how choose the right darkness to obtain appropriate contrasts, and when to use lines or surfaces for the hulls? There are more possibilities then immediately meets the eye.
Light edges
The priority is still the readability of the layout, therefore the graphical elements that need contrast the most are the dots representing the nodes. Those should be either black or white. I arbitrarily pick black here, but the rationale will also work for inverted images (negatives).
The dots need to be visible above their background, which may now consist of the edges, the network hull, or cluster hulls. As a result, none of those should be too dark.
The background color does not matter anymore in this case, as nodes are never above it. It could even be completely black. Let us put aside labels and edge readability: the layout remains readable even if everything else is in gray, even a relatively dark gray. Here is the proof of concept:



Assessment: The contrast of edges with the background (including the network hull) is very bad, as we do not see the edges over the hull. And when it comes to see which edges connect to which nodes, it is as bad as if we did not even have the edges. Yet we have three good points: a good contrast of the nodes with the edges, with the background, and the layout is decently highlighted. We also have a glimpse of where the bridging edges are. Despite all the flaws and the intentionally too-dark gray, the most key criteria are covered acceptably.
Building on top of this proof of concept, we can make observations that help us organize possible designs:
- As long as the network hull and the edges have not-too-different colors, the layout remains readable.
- Although distinguishing edges over the network hull is useful, the most important is to have contrast outside the hull (where some edges bridge across clusters)
- As the network hull and the edges could get quite dark, we could then go for lighter labels and cluster hulls.
The key factor is the lightness of the edges. The most obvious choice (it will be our baseline) is to keep the edges pretty light. Then the network hull should also be pretty light. The background color should be contrasted enough, which leads us to a darker gray. Labels should be even darker so that we could read them well above edges and the network hull but keep them readable over the background. Here is an example:



Assessment: The contrast of the different elements is decent to good, except that of the labels with the nodes which remains poor. The layout is well emphasized, the bridging edges are readable, and we have a number of labels, although we cannot afford too many. And without node halos, we do not see which edges connect to which edges in general.
Remark: we can afford to draw the edges quite thicker, as in this context we care more about the long edges and the general structure than the small edges and the local structure. In a nutshell, for dense areas, we rely on the layout to convey the key information: within that cluster every node is more or less connected to every other one.
In the same spirit as this visualization, we could have the edges completely white. In that case the network hull should be very light and the background even less light.



Assessment: Like the previous rendering, but with an improved contrast of edges with the background.
This version works better because the lesser contrast between the network hull and the background is less distracting.
Remark: this strategy boils down to the Grandjean trick, but inverted (see previous post). The hulls help warrant that the background color around the nodes is consistent. Like for the black and white version, network borders are beneficial. Here is an inverted version of the same image:



The staging of contrast is that of the Grandjean trick.
Dark edges
Conversely, one could keep the edges quite dark with black nodes. The network hull should then be quite dark too. Light tones can then be used for labels and cluster hulls.



Assessment: The contrast of all the elements with each other and the background is good, except that of the edges over the background, which is disappointing. The layout and the bridges are well emphasized. But we have to keep the number of labels low, and we do not see which edges connect to which nodes.
We lose something on the way: the dots and the labels are no more of a similar color, so we lose the sense of association between them; labels might be misunderstood as annotations. But we also gain contrast between the label and the node, which makes labels more readable.
This works insofar as we can keep a fragile balance between the white (labels), the black (nodes) and the gray (the rest): the layout is manifested through black and gray while the white makes a more homogeneous layer. The reader must somehow accept to forget about the white layer when it comes to reading node densities. The highlight of the structure provided by the network hulk does help in this context.
DON'T: Use a very different color for the nodes and the labels if it makes it look like the labels don't belong to the nodes (it notably depends on your other annotations).
Gray nodes
In anticipation to adding color to the visualization (the next post in this series), it is worth considering gray nodes. Indeed, the lightness of any saturated color can neither be null (black) nor maximal (white). I will then use mid gray (50% lightness), and I will also arbitrarily set labels to black, on the motive that white labels are equally valid but can be derived by just inverting the resulting image.
The main constraint remains to keep the layout readable while the edges are gray. Their background has to provide contrast, therefore the network hull and the edges should be as light as possible. Since edges create a busy background behind the nodes, we should get more contrast in that case. As labels are black, edges have to be white and the network hull light gray, and then the background should be a less light gray.



Assessment: The contrast of all the elements with each other and the background is good, except for the labels with the nodes, which is poor. The layout and the bridges are decently emphasized. But we have to keep the number of labels low, and we do not see which edges connect to which nodes.
The result is quite similar to dark nodes with white edges, but the layout is less readable because the contrast of the nodes is not as good. It is not the best choice for actual grayscale network maps, but provides a baseline for color maps.
Gray nodes and edges
For reasons that I will develop in the next post of this series, we may also want to use color on edges, which means that they cannot be white. With this constraint, nodes have to be dark gray and edges light gray. We can then use white for labels, as long as we avoid very light tones for edges, the network hulls, and to a lesser extent, the background. Here is where we land.



Assessment: The contrast of the different elements with each other is decent to good. The layout is decently emphasized, and the bridges are visible enough. We cannot afford too many labels, and we still do not see which edges connect to which nodes.
Once again, the purpose of this exercise is to calibrate the contrast in anticipation of using color, not to produce an optimal grayscale image.
Takeaways about grayscale network maps
Your expectation should depend on the sophistication of your rendering system. If your environment is simple, then you will not have access to hillshading, node halos, and possibly hulls. You cannot expect to solve certain issues, but you still have multiple options to craft a readable network map. If your system is sophisticated, then you can afford to find the tradeoff that works best for you and craft a network map that conveys more context and a more accurate information.
If your system is simple, you cannot clarify which edges connect to which nodes. You should then aim for a well-staged contrast between the different elements, which is quite easy to obtain in different ways. I still recommend to prioritize the emphasis of the layout over the labels. You could have a stack of white background, light gray edges, black nodes, and dark gray labels; or the inverted version. But you could also stack a gray background, white edges, black nodes and dark gray labels; or the inverted version. If you do not need to display too many labels, you could even stack a light gray background, dark gray edges, black nodes and white labels; or the inverted version.
If you have access to node halos, you should use it as it improves the visualization by a lot with minimal downsides. The part of your audience that is expert at reading networks can get a lot of important information from the details of which edges connect to which nodes, even if it is not perfect.
If you have access to compositing options, I recommend that you tune your visualization so that the labels are visible from up close without drawing attention from a distance, which corresponds to what I see as the typical use case. However, this does not apply to situations where zooming is impossible (ex: small printed image).
Hulls have multiple applications, essentially as different ways to annotate the network. If you do not have access to color (some newspapers and academic articles), making small multiples with hulls is a good replacement to representing clusters with colors.
Finally, the hillshading is not the ultimate solution to emphasizing the layout, but it can help in many situations because it is not too intrusive.
OpenEdition suggests that you cite this post as follows:
Mathieu Jacomy (May 4, 2023). How to render a network map, part 2: grayscale. Reticular. Retrieved February 19, 2025 from https://reticular.hypotheses.org/6761