Aims

By the end of this tutorial, you should be able to:

•   Graph any compatible network with graphr() and read what the defaults show you
•   Choose which nodes to label, and add titles that help others read your graph
•   Map node and tie attributes to colour, shape, size, and groups, and title the legends that explain them
•   Set a consistent theme across all your plots, and tailor palettes for accessibility or print
•   Choose an appropriate layout, and know when the positions of nodes can be interpreted
•   Check how legible a drawing is, and how faithful it is to the network it draws
•   Tame dense or disconnected networks with backbones, bundling, and isolate handling
•   Arrange multiple graphs together with graphs() and animate change over time with grapht()
•   Plot degree and other results with consistent plot() methods
•   Export publication-ready figures with ggsave()

Choose your own data: The worked examples below mostly use fict_lotr, a fictional network of affinities among Lord of the Rings characters bundled with {manynet}, plus a couple of classical datasets. But wherever there is an exercise box, you are encouraged to swap in a network that interests you. Remember the three flavours of bundled data as a rough difficulty ladder — Classic (ison_*, small & tidy), Fiction (fict_*, mid-sized & fun), Real-world (irps_*, larger & realistic) — and that you can browse the full list with table_data().

Plotting approaches

To understand graph and network visualisation with {autograph}, it is useful to review the different approaches already taken in R. Plotting in R is typically based around two main approaches:

• the ‘base’ approach in R by default, and
• the ‘grid’ approach made popular by the famous and very flexible {ggplot2} package.¹

In the case of base R graphics, plots are essentially written straight to the plotting device. This means that they are not easily modified after the fact: you would need to replot the whole thing to change something. Moreover, while there is an admirably clean aesthetic to base R graphics, it can be difficult to modify or extend them to your needs.

In the case of grid graphics, plots are built up in layers, and thus can be modified after the fact. That is, you can initialise a plot using ggplot2::ggplot(), specifying the data and mapping variables to various aesthetic features, and then add layers to it using + to add further points and lines, but also titles, legends, etc.

The following figure illustrates the difference between these two approaches.² Run the code to compare the two plots. (There are buttons to run the code you have entered, to start over, and — where available — to receive hints and solutions. You will use these throughout the tutorial.)

plot(mtcars$hp, mtcars$mpg,
     main = "Base R: MPG vs Horsepower",
     xlab = "Horsepower",
     ylab = "Miles per Gallon",
     pch = 19,
     col = "blue")
ggplot(mtcars, aes(x = hp, y = mpg)) +
  geom_point(color = "blue") +
  labs(title = "ggplot2: MPG vs Horsepower",
       x = "Horsepower",
       y = "Miles per Gallon")

Graphing approaches

Approaches to plotting graphs or networks in R can be similarly divided:

• two classic packages, {igraph} and {sna}, both build upon the ‘base’ R graphics engine,
• newer packages {ggnetwork} and {ggraph} build upon a ‘grid’ approach.³

Let’s see how the fict_lotr network would be plotted using {igraph} and {ggraph}, adding a title to each to facilitate comparison, but otherwise relying on default behaviour.

plot(as_igraph(fict_lotr),
     main = "igraph: fict_lotr")
ggraph::ggraph(as_tidygraph(fict_lotr)) +
  ggraph::geom_edge_link() +
  ggraph::geom_node_point() +
  ggtitle("ggraph: fict_lotr")

We can see here that {igraph} plots the network in a fairly basic way, straight to the plotting device (window). By default, it uses a force-directed layout (see the Layouts section below),⁴ colours the nodes orange, and prints node labels if they have them. However, the layout is not optimised for the size of the plotting window, the node labels are regularly overlapping, and the orange colour with black borders is not particularly appealing or helpful for label legibility. It only works with ‘igraph’ objects.

In contrast, {ggraph} offers the trademark flexibility of the grammar of graphics approach. However, it requires the user to build up a plot from the ground up, which can be daunting for new users and fiddly even for experienced ones. Four lines are required to get even a basic plot, with an additional line required if a grey background is not desired. No labels or other information are added by default, and would also require additional lines. It works with ‘tidygraph’ objects, which are an additional layer on top of ‘igraph’ objects.

Your first graph

{autograph} builds upon these packages, but takes a somewhat different approach. It builds upon the ‘grid’ approach of {ggplot2} and {ggraph}, lending itself to the additional layering and flexibility of those packages. Because it depends on the coercion routines available in {manynet}, it can be used with network-related objects from most common network analysis packages — igraph, network, tidygraph, matrices, edgelists, and more — without you needing to convert anything first. Unlike those packages, though, it offers concise and easy-to-use functions with sensible defaults for most common use cases, using the information that is available in the network object.

The first thing you will want to do when you import or create a new network dataset is draw it. Compared to the {igraph} and {ggraph} examples above, autograph::graphr() offers a much more concise way to draw the network. Try it now.

graphr(fict_lotr)

Note everything that happened without being asked: graphr() recognised that the network is labelled and printed node labels — but only for the most central characters, since 36 labels at once would hide the network behind them (the next page shows how to choose differently), chose a deterministic layout (so you get the same picture every time), sized and spaced the labels to minimise overlap, and dropped the axes and grey background that mean nothing for networks. Because the network is undirected , there are no arrowheads; for a directed network, graphr() would draw them automatically.

The package also offers methods for plotting statistics related to networks (e.g. degree distributions ) and models of them (e.g. goodness-of-fit plots). We will get to some of these later in this tutorial, and others are demonstrated in the tutorials of other {stocnet} packages. {autograph} also offers consistent theming across graphs and plots, so that you do not need to keep specifying the same options over and over again.

Free play

Your turn: before going any further, graph a network of your own choosing. Any of the networks bundled with {manynet} will do — here is one suggestion per flavour:

Then note what graphr() decided without being asked. Were all the nodes labelled, some of them, or none? Are there arrowheads? More than one node shape? A legend? Each of those decisions was read off the data, and each is one you will learn to take over in the pages that follow.

In the following pages, we’re going to go through a number of different ways of taking control of the graphing process. Click ‘Next Topic’ to continue.

Labels

With our fict_lotr example above, because the network is itself labelled, graphr() adds node labels. If you do not want any labels, you can remove the names from the network before passing it on to graphr(), or more simply use the argument labels = FALSE.

graphr(fict_lotr, labels = FALSE)

Without the labels, the structure of the network is clearer and easier to interpret, though we lose the information about which node is which character. Which you prefer depends on what the graph is for: exploring who-is-who, or communicating overall structure.

But this is not really a choice between all and nothing. fict_lotr has 36 nodes, and 36 labels would cover the very network they describe, so graphr() labelled only the handful of most central characters and told you so. Ask for all of them with labels = TRUE and compare.

graphr(fict_lotr, labels = TRUE)

You can decide how many to label by passing a number. This is a depth of ranks rather than a count of nodes, so characters tied at the cut are labelled together — ask for the top three and you may get four names.

graphr(fict_lotr, labels = 3)

By default the nodes are ranked by their degree , the number of ties each node has, so the names you see are those of the best-connected characters. You can say so explicitly, and combine it with a number, by naming the number: labels = c(degree = 5).

graphr(fict_lotr, labels = c(degree = 5))

And when you know exactly who matters to your argument, you can just say so — by name, or with any logical vector of the nodes. Here node_attribute() pulls the Race attribute out of the network as a vector, so that we can ask which characters are hobbits.

graphr(fict_lotr, labels = c("Frodo", "Gandalf")) +
  ggtitle("Named outright") |
  graphr(fict_lotr, labels = node_attribute(fict_lotr, "Race") == "Hobbit") +
  ggtitle("Every hobbit")

Titles

{autograph} works well with both {ggplot2} and {ggraph} functions that can be appended to create more tailored visualisations. Let’s try this by adding a title to a plot. Append (with a +) labs(title = ) to add a title to a plot, say “My graph”, and then add also a subtitle (an argument to that function), say “I did this”.

# Fill in the blanks (this is a template, not runnable code):
# graphr(fict_lotr) +
#   labs(title = _____, subtitle = _____)

graphr(fict_lotr) +
  labs(title = "My visualisation",
       subtitle = "I did this")

Note that you can also use ggtitle() to do the same thing, but if you just remember labs() you can also use it to add labels for x and y axes, and for some legends (see Legends on the next page).

Shaping nodes

One of the first things we might be interested in doing is understanding better the distribution of some categorical variable. Our fict_lotr dataset contains a variable called Race, so let’s try and change the shape of the nodes by this variable. Following the syntax shown in the table above, we just need to reference the variable name in the node_shape argument. Print the network first to check the attribute’s (case-sensitive) name, then graph it.

fict_lotr
graphr(fict_lotr, node_shape = "Race")

We can see here that there are six different races present.⁵ Unfortunately, this is a few too many different categories to be effectively distinguished by shape: at a glance, can you quickly find the triangles among the squares? Shape works best for two or three categories at most.

One place where shape excels, though, is distinguishing the node sets of a multimodal network — and there graphr() does it for you. For a two-mode network, nodes in the first mode are drawn as circles and nodes in the second mode as squares, with a “Mode” legend added automatically; were a third node set mapped to shape, it would be drawn as triangles. Graph the ison_southern_women network, where the women (first mode) appear as circles and the events they attended (second mode) as squares.

graphr(ison_southern_women)

Colouring nodes

Let’s try instead colouring the nodes by this “Race” variable. It is very similar to the shape example above. Can you complete the code yourself?

# Use the same syntax as with node_shape, but with the node_colour argument.
# Remember to name the attribute in quotation marks.

graphr(fict_lotr, node_colour = "Race")

That’s much easier to read. Note how a legend has been added automatically, using the colours of whatever theme is currently set (more on themes soon).

How should we interpret this graph? Since the same colours seem to be clustered together, with the humans and hobbits each clustered together in the centre of the graph, and the elves clustered towards the left, we might infer that there is some homophily going on here — that characters tend to be connected to others of the same race — a hypothesis to test properly in another tutorial. Interpreting an attribute-coloured graph like this is often the first, informal step toward a more formal analysis.

An alternative to colouring the nodes is to use the node_group argument to highlight groups in a network. This puts a shaded area around nodes of the same group. For rather spatially clustered distributions, this can be a very effective way to show groupings, but it is sensitive to the layout used: if nodes of the same group are not close together, the shaded areas can overlap and make the graph harder to read.

graphr(fict_lotr, node_group = "Race")

Note that node_colour and node_group can be used together, either to highlight different groupings, or to emphasise group assignment where the groups interpenetrate, as described above.

fict_lotr |>
  mutate(Degree = node_by_deg(fict_lotr)) |>
  graphr(node_colour = "Degree")

graphr(ison_lawfirm, node_colour = "age")

Sizing nodes

Colour is not the only way to show a number, and it is rarely the most precise. Our eyes compare sizes more readily than they compare shades, which makes node_size the usual home for a continuous variable. Size the characters by the degree we calculated above.

fict_lotr |>
  mutate(Degree = node_by_deg(fict_lotr)) |>
  graphr(node_size = "Degree")

Larger nodes are now the better-connected characters, and a size legend has been added. Who turns out to be the most connected character in the fellowship?

Nothing stops you mapping the same attribute to both aesthetics at once. This costs nothing, and helps a reader who is looking at a small figure, a greyscale printout, or with a colour vision deficiency. Compare the three encodings of the same variable.

lotr <- mutate(fict_lotr, Degree = node_by_deg(fict_lotr))
(graphr(lotr, labels = FALSE, node_size = "Degree") + ggtitle("Size") |
    graphr(lotr, labels = FALSE, node_colour = "Degree") + ggtitle("Colour") |
    graphr(lotr, labels = FALSE, node_size = "Degree", node_colour = "Degree") +
    ggtitle("Both")) &
  theme(legend.position = "none")

Tying up loose ends

All this works similarly with ties/edges. Just replace node_ with edge_ in the arguments above, and you can control edges’ size and colour. The following example uses two classic networks that come with tie attributes: ison_florentine, where each tie among the families of Renaissance Florence belongs to a layer (marriage or business), and ison_karateka, where each tie among the members of a karate club has a weight (the number of contexts in which the two members met). Run the code, then try colouring the karate club’s ties by "weight" instead of sizing them.

(graphr(ison_florentine, edge_colour = "layer") |
   graphr(ison_karateka, edge_size = "weight"))

Now delete the two edge_ arguments and run the code again: nothing changes. That is because some tie attributes are recognised automatically: if a network contains a tie attribute called weight, ties will be sized by weight without you asking, and a tie attribute called layer (or type) will be used to distinguish the ties of a multiplex network. Naming your attributes accordingly can save you some typing; for an attribute under any other name, the edge_ arguments are how you ask.

Pointing arrows

So far our example network has been undirected. For directed networks, graphr() adds arrowheads automatically, pointing from the sender to the receiver of each tie, and trims them back so they are not swallowed by the receiving node. Arrowheads are also scaled automatically with the width of the ties: thin ties get small arrowheads, thick ties get larger (but capped) ones, and ties of width zero lose their arrowheads entirely. This means arrowheads stay proportionate even when tie width is mapped from a weight attribute, as in the ison_networkers network of messages exchanged among early network researchers. Because the arrowheads follow the tie width, setting edge_size yourself resizes both together. Compare the automatic sizing with a manually thickened version.

(graphr(ison_networkers) + ggtitle("Automatic") |
   graphr(ison_networkers, edge_size = 1) + ggtitle("Manual (edge_size = 1)"))

To change the arrowheads without changing the ties, use edge_arrows. It is a switch that can also carry a value: left alone, graphr() decides from the network; edge_arrows = FALSE draws none, which suits a network where the direction is already plain from the layout; edge_arrows = TRUE insists on them; and a number gives their length in millimetres, whatever the tie width. Draw the same network with larger arrowheads, and with none.

(graphr(ison_networkers, edge_arrows = 4) + ggtitle("edge_arrows = 4") |
   graphr(ison_networkers, edge_arrows = FALSE) + ggtitle("edge_arrows = FALSE"))

Legends

Every mapping on this page has come with a legend, because a mapping is unreadable without one. But a legend asks a reader to hold a colour in mind while they hunt for it in the graph, and people are poor at that: colour is not recalled reliably, even over a couple of seconds. Labelling nodes directly asks less of them, which is why graphr() labels nodes where it can, and why, above thirty nodes, it labels the most central ones rather than none at all (see Labels on the previous page). Keep a legend for what cannot be written onto the graph itself, and keep it short.

While {autograph} adds legends where necessary, it can only title them with what it knows: the name of the attribute. Take the following figure, where we highlight the character with the highest degree . Top is a logical attribute, TRUE for one node and FALSE for the rest, so by the rule above it is drawn as two categories rather than a gradient.

fict_lotr |>
  mutate(Degree = node_by_deg(fict_lotr)) |>
  mutate(Top = Degree == max(Degree)) |>
  graphr(node_colour = "Top")

Which node is highlighted here, and why might that be? A legend that says only “Top: FALSE, TRUE” does not tell a reader, who cannot see the code that made it. Because the graph is a {ggplot2} object, its legends can be revised after the graph has been drawn, using guides() and naming the aesthetic concerned. Nodes are drawn as filled shapes, so the aesthetic to name is fill. Note that we can use "\n" within the legend title to make the title span multiple lines.

fict_lotr |>
  mutate(Degree = node_by_deg(fict_lotr)) |>
  mutate(Top = Degree == max(Degree)) |>
  graphr(node_colour = "Top") +
  guides(fill = ggplot2::guide_legend(title = "Most\nconnected"))

guides(fill = "none") removes a legend altogether, which is worth doing where the title or caption already says what it would. To change the position of the legends, add the theme() function from {ggplot2}, e.g. theme(legend.position = "bottom"). The legends can be positioned at the top, bottom, left, or right, or all removed using “none”.

Free play

Your turn: choose another network and illustrate something about it. Pick a dataset with interesting node attributes — here is one suggestion per flavour:

Print the network first to see which attributes are available, then map one or two of them to colour, shape, size, or groups.

Setting a theme

Perhaps you are preparing a presentation, representing your institution, department, or research centre at home or abroad. In this case, you may wish to theme the whole network with institutional colours and fonts. Indeed, you may even want to set a theme that is then reused across all your graphs and plots. {autograph} offers a number of themes that can be set using the stocnet_theme() function. Once set, the theme applies to every subsequent graph and plot in your session — no need to repeat yourself.

stocnet_theme("default")
graphr(fict_lotr, node_colour = "Race")
stocnet_theme("iheid")
graphr(fict_lotr, node_colour = "Race")
stocnet_theme("default")

Currently available themes include a number of institutional themes ("iheid", "ethz", "uzh", "rug", "unibe", "oxf", "unige", "cmu", "iast", "hwu") as well as stylistic ones ("default", "bw", "crisp", "neon", "clay", "rainbow"). Run stocnet_theme() without arguments to see which theme is currently set. More institutional scales and themes can be implemented upon pull request.

A theme lasts for the session in which you set it, and a new session starts on the default again. Where a theme is your usual one, persist = TRUE remembers it, by writing the name to your user configuration directory:

# stocnet_theme("iheid", persist = TRUE)   # remembered next session too
stocnet_theme()

Nothing is written to disk unless you ask for it. Setting any theme with persist = FALSE, the default, forgets a choice you persisted earlier, so stocnet_theme("default", persist = FALSE) puts you back where you began.

A theme sets a typeface as well as a palette, but only where that typeface is installed and R can see it. list_fonts() lists the families R can see, and ag_font() reports the one the current theme settled on.

ag_font()
head(list_fonts("sans"))

If ag_font() returns "sans", the theme found none of the fonts it prefers, and your graphs will look more generic than they should. Install the missing family — many are free from Google Fonts — then install the {systemfonts} package so that R can see the fonts on your system, and set the theme again. ?stocnet_theme sets out the steps for each operating system.

Who’s hue?

By default, graphr() will use a colour palette that offers fairly good contrast and better accessibility. However, a different hue might offer a better aesthetic or identifiability for some nodes. Because the graphr() function is based on the grammar of graphics, it’s easy to extend or alter aesthetic aspects. Here let’s try and change the colours assigned to the different races in the fict_lotr dataset. Note that despite the argument being node_colour, when overwriting the colours please use functions of the type ggplot2::scale_fill_*(), as it is the “fill” aesthetic that is being mapped to the variable in this case.

graphr(fict_lotr,
           node_colour = "Race")

graphr(fict_lotr,
           node_colour = "Race") +
  ggplot2::scale_fill_hue()

At this stage, it is worth noting that not everyone experiences colours in the same way. Some people are colour-blind, whether by deuteranomaly, deuteranopia, protanomaly, or protanopia, and so it is worth checking that your visualisations are accessible to them.⁶ Others are less sensitive to colour distinctions. The old trope is that males are less sensitive to colour distinctions:⁷

Seeing what others see

About one man in twelve, and one woman in two hundred, sees colour differently from the palette designer. The most common form, deuteranopia, confuses reds with greens — which is precisely the pairing a “stop/go” palette relies on.

{autograph} gives you two functions for checking this. simulate_colorblind() shows you a set of colours as such a viewer sees them, and check_separation() scores how far apart colours are, taking the worst case across normal vision and each type of colour blindness. A score below 10 means two colours are easily confused, 10 to 25 that they are separable but close, and above 25 that they are comfortably distinct.

# A red and a green that look quite different to most viewers
check_separation(c("#B7352D", "#627313"))
# But not to everyone
simulate_colorblind(c("#B7352D", "#627313"), "deutan")

Run the code, then try "protan" or "tritan" instead of "deutan".

How far the simulation goes is set by severity. Full severity, the default, is dichromacy: deuteranopia, protanopia, tritanopia. A lower severity is anomalous trichromacy — deuteranomaly, protanomaly — which is the more common condition, and which the paragraph above named without being able to show you.

simulate_colorblind(c("#B7352D", "#627313"), "deutan", severity = 1)
simulate_colorblind(c("#B7352D", "#627313"), "deutan", severity = 0.4)

You can also look at a whole graph the way another viewer would, by mapping the simulated colours back onto it.

graphr(fict_lotr, node_colour = "Race")
graphr(fict_lotr, node_colour = "Race") +
  ggplot2::scale_fill_manual(values = simulate_colorblind(ag_qualitative(6), "deutan"))

Much of this work is already done for you. Each theme’s palette is reordered when the theme is set, so that the colours a graph uses first are the ones that stay distinct for every viewer, and each divergent palette pairs a warm pole with a cool one rather than a red with a green.

stocnet_theme("iheid")
round(check_separation(ag_qualitative(4)))
# The closest pair among those four colours
min(check_separation(ag_qualitative(4)), na.rm = TRUE)
stocnet_theme("default")

Greyscale

Other times colour may not be desired. Some publications require greyscale images, and a figure may be photocopied whether or not you meant it to be. A greyscale device keeps the luminance of a colour and throws the rest away, so two colours of the same lightness merge, however different their hues. This is why ColorBrewer marks a palette print-safe and photocopy-safe separately from marking it colour-blind safe: they are different questions, and a palette can pass one and fail the other.

simulate_colorblind() answers the second with type = "grey", and check_separation() reports the greyscale distances beside its own score.

check_separation(ag_qualitative(4))

The matrix is what every viewer can see. The line beneath it is what survives a photocopier. Most institutional palettes separate their categories by hue, so most of them collapse in greyscale.

To draw in greyscale from the start, replace _hue from above with _grey (note the ‘e’ spelling):

graphr(fict_lotr,
           node_colour = "Race") +
  ggplot2::scale_fill_grey()

As you can see, greyscale is more effective for continuous variables or for very few discrete categories than for the six categories used here. If you need to distinguish several categories in print, consider combining greyscale with node_shape, or use the "bw" theme, which is designed for this purpose. stocnet_medium("print") is the companion to this; see Where will it be seen? below.

Manual override

Or we may want to choose particular colours for each category. This is pretty straightforward to do with ggplot2::scale_fill_manual(). Some common colour names are available, but otherwise hex colour codes can be used for more specific colours. Unspecified categories are coloured (dark) grey.

graphr(fict_lotr,
           node_colour = "Race") +
  ggplot2::scale_fill_manual(
    values = c("Dwarf" = "red",
               "Hobbit" = "orange",
               "Maiar" = "#DEC20B",
               "Human" = "lightblue",
               "Elf" = "lightgreen",
               "Ent" = "darkgreen")) +
  labs(fill = "Colour")

Where will it be seen?

A theme says how a plot should look. Where it will be seen is a separate question, and the answer changes more often than the theme does. The same institutional theme has to serve a figure worked on at a desk, projected in a lecture theatre, printed in an article, and read on a phone in a narrow column. Each of those wants a different size of text, and one of them wants a different background.

stocnet_medium() sets this, and leaves the theme alone.

stocnet_medium()
stocnet_medium("presentation")
graphr(fict_lotr, node_colour = "Race")
stocnet_medium("screen")

The media are "screen" (the default), "presentation", "mobile", and "print". The first three differ in the size of their text; ag_size() reports the multiplier in force. "print" leaves the text alone and draws on white, whatever ground the theme prefers, since a dark or tinted ground costs ink and is often not reproduced. As with stocnet_theme(), persist = TRUE remembers your choice.

The medium scales text, not marks. A node’s size is relative to the layout it sits in, so enlarging the nodes without enlarging the layout would only crowd it. Use node_size in graphr() where a figure needs larger nodes too.

Nor does the medium set the size of the file you write. Give ggsave() the width, height, and resolution to match; see Exporting plots below.

Spectral layouts

Spectral layouts are the nearest a network graph comes to a scatterplot. Both axes are calculated from the network, and a node’s coordinates are its scores on them, so that nodes drawn together are similar in some measured sense. {autograph} offers three, which differ in what they take ‘similar’ to mean:

• the eigenvector layout draws together nodes that are tied to the same others;
• multidimensional scaling draws together nodes that are few steps apart;
• correspondence analysis draws together nodes whose rows in a table of ties look alike.

All three are careful about position and careless about legibility: nodes pile up on top of each other, and ties run long and cross often. The rest of this page gradually reverses that trade.

graphr(ison_southern_women, layout = "eigen") + ggtitle("Eigenvector")

graphr(ison_southern_women, layout = "scaling") + ggtitle("Multidimensional Scaling")

graphr(ison_southern_women, layout = "correspondence") + ggtitle("Correspondence Analysis")

Layered layouts

Layered layouts give up one of the two axes. One axis is still data — it says which layer a node belongs to — while the other is used only to arrange the nodes within each layer so that their ties cross as little as possible. These layouts are best suited for directed acyclic graphs, two-mode networks, or other data with a natural ordering.

{autograph} offers four, and they are one layout drawn four ways. Two things vary: which axis the layers run along, and whether the nodes line up across them. The names say which is which — a railway lies flat, a ladder stands up:

graphr(ison_southern_women, layout = "bipartite") + ggtitle("Bipartite")
graphr(ison_southern_women, layout = "layered") + ggtitle("Layered")
graphr(ison_southern_women, layout = "railway") + ggtitle("Railway")

Note that "layered" and "railway" use a different algorithm to {igraph}’s "bipartite", and generally perform better, especially where there are multiple layers. Whereas "layered" tries to position nodes to minimise overlaps, "railway" sequences the nodes in each layer to a grid so that nodes are matched as far as possible. For the "layered" layout you can also steer which set sits where by passing a center argument — "events" or "actors" for a two-mode network, or the name of a particular node — which helps when the default places the less interesting set on top.

graphr(ison_southern_women, layout = "layered", center = "events")

If you want to flip the horizontal and vertical, you could flip the coordinates, or use "lineage", which is the same layout with the axes exchanged.

graphr(ison_southern_women, layout = "lineage") + ggtitle("Lineage")

These layouts serve both multimodal and directed acyclic networks. A genealogical network offers the clearest case: every tie points from an earlier generation to a later one. Where a force-directed layout obscures this ordering, graphr() uses the "layered" layout to make it clear. Draw the parent ties among the characters of Westeros.

thrones <- to_uniplex(fict_thrones, "parent")
graphr(thrones)

This layout tries to minimise two costs. The first is which layer each node goes in. Ranking each node by its distance from a root sounds right — a row is then a generation — but it pins a parent whose only child is born several generations later to the top row, and manufactures a long tie to reach them. The ranks argument chooses the rule, and check_span() reports how many rows each tie crosses, so you can measure the difference.

thrones <- to_uniplex(fict_thrones, "parent")
spans <- sapply(c("generation", "compact", "tight"), function(r) {
  span <- check_span(graphr(thrones, ranks = r))
  c(total = attr(span, "total"), `over one row` = mean(span > 1), max = max(span))
})
round(t(spans), 3)

"generation" is the distance-from-a-root rule and "compact" is the one {igraph} uses in its Sugiyama layout. "tight", the default, minimises total tie length while still pointing every tie down at least one row. Note that the longest tie is the same under all three.

The second cost is where each node sits within its row. check_offset() reports how far each tie travels sideways, as a share of the width of the drawing, so a tie that drops straight down scores zero. Again, you are wanting to minimise this, and the alignment argument chooses the rule. Compare the two alignments.

thrones <- to_uniplex(fict_thrones, "parent")
c(straight = attr(check_offset(graphr(thrones)), "mean"),
  rungs = attr(check_offset(graphr(thrones, alignment = "rungs")), "mean"))

alignment = "rungs" gives every row the same spacing, which is what "railway" and "ladder" are for. The default, "straight", pulls each node towards its parents and children instead, which is what makes the families read as families.

ranks also accepts a node attribute, instead of one of those three rules. Then the layers are that attribute’s values, and nodes are placed along the axis in proportion to them rather than at even steps, so a network of dated nodes is drawn as a timeline. Rank the adolescents by a year of your choosing.

ison_adolescents |> as_stocnet() |> 
  mutate_nodes(year = rep(c(1985, 1990, 1995, 2000), times = 2),
               label = paste0(label, " (", year, ")")) |>
  graphr(layout = "lineage", ranks = "year")

Other layered layouts include:

• Tree: "tree"
• Dominance layouts

Circular layouts

Circular layouts give up Cartesian axes altogether and arrange nodes around (potentially concentric) circles, such that crossings are minimised and adjacent nodes are located close together. What is left that can be data is the ring a node is on: in some cases, the ring can be specified by attribute or mode.

graphr(ison_southern_women, layout = "concentric") + ggtitle("Concentric")

The "concentric" layout can also place nodes on rings by a grouping you choose: pass a membership argument (a node attribute name, or a vector the same length as the number of nodes). Ring the Lord of the Rings characters by their race.

graphr(fict_lotr, layout = "concentric", membership = "Race")

Other such layouts include:

• circular: "circle"
• sphere: "sphere"
• star: "star"
• arc or linear layouts: "linear"

Grid layouts

Grid layouts arrange nodes at regular Cartesian coordinates. Here the positions are no longer data at all: they are evenly spaced because even spacing is tidy. These can be useful for making sure all nodes’ labels are visible, but horizontal and vertical lines can overlap, making it difficult to distinguish whether some nodes are tied or not.

graphr(ison_southern_women, layout = "grid") + ggtitle("Grid")

Other grid layouts include:

• orthogonal layouts for e.g. printed circuit boards
• grid snapping for other layouts

That last point deserves a demonstration. Rather than committing to a full grid, graphr()’s snap = TRUE argument keeps whatever layout you asked for but snaps its coordinates onto a grid — trading a little positional accuracy for the label legibility of a grid. Compare the stress layout with its snapped version.

(graphr(fict_lotr) + ggtitle("stress") |
   graphr(fict_lotr, snap = TRUE) + ggtitle("stress + snap"))

Force-directed layouts

Force-directed layouts complete the trade this page has been making. They give up position as data entirely, in exchange for a drawing in which tied nodes sit near each other, untied nodes keep apart, and the ties are of a similar and readable length. This is why one of them is the default layout for most networks, and why you have been looking at them since your first graph.

Force-directed layouts update some initial placement of vertices through the operation of some system of metaphorically-physical forces. These might include attractive and repulsive forces.

(graphr(ison_southern_women, layout = "kk") + ggtitle("Kamada-Kawai") |
   graphr(ison_southern_women, layout = "fr") + ggtitle("Fruchterman-Reingold") |
   graphr(ison_southern_women, layout = "stress") + ggtitle("Stress Minimisation"))

The Kamada-Kawai (KK) method inserts a spring between all pairs of vertices that is the length of the graph distance between them. This means that edges with a large weight will be longer. KK offers a good layout for lattice -like networks, because it will try to space the network out evenly.

The Fruchterman-Reingold (FR) method uses an attractive force between directly connected vertices, and a repulsive force between all vertex pairs. The attractive force is proportional to the edge’s weight, thus edges with a large weight will be shorter. FR offers a good baseline for most types of networks.

The Stress Minimisation (stress) method is related to the KK algorithm, but offers better runtime, quality, and stability and so is generally preferred. Indeed, {autograph} uses it as the default for most networks. It has the advantage of returning the same layout each time it is run on the same network.

Other force-directed layouts available include:

• Simulated annealing (Davidson and Harel 1993): "dh"
• Graph embedder (Frick et al. 1995): "gem"
• Graphopt (Schmuhl): "graphopt"
• Distributed recursive graph layout (Martin et al. 2008): "drl"

Manual layouts

Whatever their differences, all these layout algorithms do the same job: they return a table of node coordinates. Nothing stops you computing that table yourself, inspecting it, adjusting a coordinate or two, and handing the result back to graphr() via its x and y arguments. This is handy when a layout is almost right — say one label sits awkwardly, or you want a particular node set apart — or when you need the same hand-tuned positions across several figures. Compute a stress layout for fict_lotr, inspect the coordinate table, banish Gollum to the top-right corner, and re-graph.

lo <- ggraph::create_layout(as_tidygraph(fict_lotr), layout = "stress")
head(lo[, c("name", "x", "y")])
lo$x[lo$name == "Gollum"] <- max(lo$x) + 1
lo$y[lo$name == "Gollum"] <- max(lo$y) + 1
graphr(fict_lotr, x = lo$x, y = lo$y)

The same trick lets you reuse a layout across plots (compute once, pass the same x/y to each call), which keeps node positions identical between figures — useful when readers need to compare them.

Legibility

Researchers who study graph drawing have identified a number of features that make a drawing easier or harder to read. Each of the following four comes with a pair of drawings of one small network: the same nodes and the same ties, only placed differently. The score in each title is calculated from the drawing beneath it.

sw_stress <- graphr(ison_southern_women, layout = "stress")
sw_circle <- graphr(ison_southern_women, layout = "circle")
rbind(stress = check_drawing(sw_stress), circle = check_drawing(sw_circle))

Layers

Layered layouts have two legibility checks of their own, which you met with the family tree of Westeros in Layered layouts: check_span() counts how many rows each tie crosses, and check_offset() measures how far each tie travels sideways. Both are costs. A tie that runs to the next row is easy to follow; one that passes over a row has to find its way between the nodes on it. Each of the six ties in a small tree runs to the next row. Move one leaf down a row, and its tie crosses two rows instead of one, so that the total over all the ties rises from six rows to seven.

Faithfulness

A legible drawing is not necessarily a faithful one. Where a layout claims that its distances are data, as the spectral layouts on the last page did, we should ask how far to believe it.

sapply(c("scaling", "stress", "fr", "circle"),
       function(x) check_stress(graphr(ison_southern_women, layout = x)))

##               ison_southern_women ison_adolescents ison_networkers
## dimensions                  12.00              7.0           31.00
## inertia_drawn                0.57              0.6            0.36
## vs_even                      3.40              2.1            5.60
## vs_random                    1.30              0.9            1.60

fit <- attr(layout_correspondence(ison_southern_women), "fit")
round(sort(fit$cos2), 2)

Free play

Your turn: the create_*() functions from {manynet} make networks with one very regular structure each, which makes them ideal for finding out what each check rewards. The code below draws a ring, a star, a lattice, and a tree with one layout, and checks each drawing. Change the layout to "stress", "grid", "star", or "tree". Which network and layout together give the fewest slopes? The most even ties? The widest smallest angle? And can you find a layout that draws the lattice without any crossings?

nets <- list(ring = create_ring(12), star = create_star(12),
             lattice = create_lattice(12), tree = create_tree(12))
do.call(rbind, lapply(nets, function(net) {
  check_drawing(graphr(net, layout = "circle"))
}))

Isolates

First, it is possible that the hairball is not a hairball at all, but a network with many disconnected components or, especially, isolates , that each need to be drawn. As each component is drawn under a force-directed layout, the components will repel each other and the giant component will be squeezed into a clump.

The isolates argument in graphr() provides some options for what to do with them instead: "legend" (the default) drops them from the drawing but records how many there were in the legend, "caption" notes them in a caption instead, and "keep" leaves them in place. Add ten unconnected characters to fict_lotr and compare keeping them with noting them in the legend.

lotr_iso <- to_unlabelled(fict_lotr) |>
  add_nodes(10)
(graphr(lotr_iso, isolates = "keep") + ggtitle("keep") |
   graphr(lotr_iso, isolates = "legend") + ggtitle("legend"))

Bundling ties

The second option is to draw all of the ties ‘bundled’ together, which can reveal where the most common paths through the network are. edge_bundle pulls ties that travel in similar directions into shared paths — like cabling them together — so that the main ‘highways’ of the network stand out. It is off by default; set edge_bundle = TRUE (or name a specific algorithm: "force", "path", or "minimal") to switch it on. ison_lawfirm records 71 lawyers and 2571 ties between them, which is about as thick a hairball as a network this small can be. Compare it drawn with and without bundling (turn backbone off too for clearest comparison results).

graphr(ison_lawfirm, backbone = FALSE) + ggtitle("Unbundled") | 
  graphr(ison_lawfirm, backbone = FALSE, edge_bundle = "path") + ggtitle("Bundled")

I find this works best with networks that are at least moderately dense, and sometimes requires a little bit of playing around to get a good result.

Backbones

By contrast, backbone changes which ties the picture is built around. Ties that carry more weight/structure than expected by a null model local to their endpoints are in essence what the network would be if it were stripped back to its skeleton. graphr() then draws the layout according to this skeleton and fades other ties into the background to further emphasise the main structure.

Most of the time you will not have to ask for this. Networks of 50+ nodes with 8 ties each on average is drawn this way by default. But you can specify backbone = FALSE to turns it off, backbone = TRUE to force it on, or you can name a filter — "disparity", "lans", "noise", "mlf", or "simmelian" — or threshold. Compare ison_lawfirm drawn with and without its backbone.

(graphr(ison_lawfirm, node_colour = "office", backbone = FALSE) +
   ggtitle("Every tie alike") |
   graphr(ison_lawfirm, node_colour = "office", backbone = TRUE) +
   ggtitle("Backbone"))

The offices are hardly visible on the left. On the right they separate, because the ties that hold each office together are the ties the filter keeps.

Only the layouts that read tie lengths are laid out this way: "stress" (the default), "fr", "drl" and "kk". Every other layout, including those whose coordinates already mean something such as "layered" or "scaling", keeps its coordinates and only fades its ties. Signed networks have no backbone, since these null models have no place for a negative weight, and are drawn as they were.

Bundling and backbones answer the same problem from different ends, so try one before reaching for both. A bundled tie cannot carry a fading of its own — bundling merges ties into shared paths — so where both are asked for, the backbone still shapes the layout but every tie is drawn alike.

For very large real-world networks such as irps_blogs, these work well together: a backbone picks out the ties that hold the connected core together (or edge_bundle = TRUE, if you would rather see the paths the ties take than which of them matter most), while isolates = "legend" keeps its several hundred unconnected blogs from crowding that core out.

Arrangements

{autograph} uses the {patchwork} package for arranging graphs together, e.g. side-by-side or above one another. The syntax is quite straightforward and is used throughout these vignettes/tutorials. Basically, you just use + or | to put graphs side-by-side, and / to put them above one another. Parentheses can be used to group graphs together. Try graphing fict_lotr and ison_algebra side-by-side, and then one above the other.

# Fill in the blanks (this is a template, not runnable code):
# graphr(_____) + graphr(_____)
# graphr(_____) / graphr(_____)

graphr(fict_lotr) + graphr(ison_algebra)
graphr(fict_lotr) / graphr(ison_algebra)

Sets

graphr() is not the only graphing function included in {autograph}. To graph sets of networks together, graphs() makes sure that two or more networks are plotted together, using a consistent layout and theme across the panels so that they can be compared. This might be a set of ego networks, subgraphs , or waves of a longitudinal network.

graphs(to_subgraphs(fict_lotr, "Race"),
       waves = c(1,2,3,4))

What is happening here is that to_subgraphs() is creating a list of subgraphs — one per race — and then graphs() is plotting them together at once with the same set of aesthetic parameters. The waves argument selects which networks in the list to plot — here the first four of the six race subgraphs. Left to its own devices, graphs() plots just the first and last networks of longer lists, which suits before-and-after comparisons of longitudinal networks.

When the panels share the same nodes, graphs() computes a single layout and reuses it across panels so that positions line up and can be compared; by default it uses the "first" network’s layout, but based_on = "last" or "both" are available. Sharing a layout means every panel has to draw every node, so in that case isolates are kept in place.

Dynamics

grapht() is another alternative to graphr(), this time rendering network changes over time as an animated gif. Longitudinal networks (with discrete waves) and dynamic networks (with dated changes) are both supported. Nodes appear, move, and fade as they enter and exit the network, and node positions transition smoothly between waves. Run the following to animate a randomly-evolving version of our Lord of the Rings network. (Be patient — rendering an animation takes considerably longer than drawing a static graph, and requires the suggested {gganimate} and {gifski} packages.)

fict_lotr |>
  mutate_ties(wave = sample(2001:2012, manynet::net_ties(fict_lotr), replace = TRUE)) |>
  to_waves(cumulative = TRUE) |>
  grapht()

Note that here, as with weight and type in the previous section, attribute naming matters a little: a time attribute called wave marks the network as longitudinal for {manynet}, so to_waves() (and grapht() itself, passed such a network directly) will split it without being told which attribute to use. Any other name (say, year) works just as well — it only needs declaring via to_waves()’s attribute argument.

Glossary

Here are some of the terms that we have covered in this tutorial:

Backbone

The backbone of a network comprises the ties that carry more weight, or hold more structure, than a null model local to their endpoints expects.

Community

A community is a set of nodes more densely connected to one another than to other nodes in the network.

Complex

A complex network is one that includes or can include loops or self-ties.

Component

A component is a connected subgraph not part of a larger connected subgraph.

Degree

The degree of a node is the number of connections it has.

Directed

A directed network is a network where the ties have a direction, from a sender to a receiver.

Distribution

A degree distribution is the frequency distribution of the degrees of the nodes in a network.

Giant

The giant component is the component that includes the most nodes in the network.

Homophily

A tendency for nodes to connect to similar nodes.

Isolate

An isolate is a node with degree equal to zero.

Label

A labelled network includes unique labels for each node (or ties) in the network.

Lattice

A network that can be drawn as a regular tiling.

Longitudinal

A longitudinal network is one observed in two or more discrete waves or panels over time.

Multiplex

A network that includes multiple types of tie.

Network

A network comprises one or more sets of nodes, one or more sets of ties among them, and potentially some node, tie, or network-level attributes.

Node

A node or vertex is an entity or actor within a network.

Reciprocity

A measure of how often nodes in a directed network are mutually linked.

Signed

A signed network is one where ties are marked as positive or negative, such as friendship and enmity or alliance and conflict.

Subgraph

A subgraph comprises a subset of the nodes and ties in a network.

Tie

A tie, edge, or link is a connection or relationship between two nodes.

Twomode

A two-mode (or bipartite) network is a network with two different sets of nodes, where ties connect only nodes from different sets, such as people and the events they attend.

Undirected

An undirected or line network is one in which tie direction is undefined.

Weighted

A weighted network is where the ties have been assigned weights.