Visualization, etc.

Voting in the MLB Hall of Fame

Wed, 23 Jan 2013 17:43:45 -0500

Here’s a visualization of the MLB Hall of Fame trajectories my friend Kenny Shirley and I created using D3, R and a bunch of elbow grease.

This was a whole lot of fun to create (the whole thing from zero to published happened in under two weeks), and was a great way to teach myself some d3. The source code is on Github.

Window Seat

Wed, 16 Jan 2013 00:05:00 -0500

What does it look like when you turn a video of a 5-hour flight into a single image?

I finally put together a web page showing the results of a fun hack Bill Cheswick and I worked on in 2011. Bill pointed a GoPro camera out the window of a jetliner, packed a bunch of extra batteries and high-capacity memory cards, and recorded the whole thing. By stitching together a single row of pixels from every frame of the video (the moral equivalent of slit scan photography), you get a view of the whole continental US. We got lucky it was a mostly sunny day.

A trivial Python hack to tweet from the command line

Wed, 14 Nov 2012 23:14:08 -0500

One of the annoying things about Twitter is that sometimes I want to tweet something, but I don’t want to actually read anything from my feed (because I’ll surely get distracted). So I wrote this trivial, minimal piece of python code to tweet from the command line.

#!/usr/bin/env python

import tweepy

import sys

# Get these at dev.twitter.com

consumer_key="your consumer_key goes here"

consumer_secret="your consumer_key goes here"

access_token="your access_token goes here"

access_token_secret="your access_token_secret goes here"

auth = tweepy.OAuthHandler(consumer_key, consumer_secret)

auth.set_access_token(access_token, access_token_secret)

api = tweepy.API(auth)

tweet_content = " ".join(sys.argv[1:])

api.update_status(tweet_content)

You’ll need tweepy, which you can get with

$ pip install tweepy

$ tweet This is mostly useless.

VisWeek 2012, Monday and Tuesday

Thu, 18 Oct 2012 13:13:09 -0400

This continues the set of notes I started on the previous post.

Monday

It turns out I spent most of Monday hanging out on hallways and chatting with people, so I did not really see much of the sessions. But I will highlight one bit about the BioVis sessions which I thought was pretty great (Robert mentioned this as well on his post). BioVis was run as a traditional symposium, with a set of closely-related papers on a specific area (in this case, biological data visualization). The brilliant idea by the organizers was to start each session with a short presentation by the session chairs. This presentation briefly mentioned all the papers in the session, and put them in context of the wider area. The session chair, having had access to the work and typically more experience in the area than the presenter, can give the wider context. This way the audience can connect dots between the individual papers much more easily. VisWeek should seriously consider doing something like this instead of fast forwards. As much as I enjoyed Gordon’s “Tiny Particles” banjo masterpiece, or (shame on me, I forget their name) “The devil came down to Baltimore”, I think I would be more likely to get something out of a short presentation by the session chairs before each set of papers.

Tuesday

I started the day with the Infovis session on evaluation, and with Steve Haroz’s presentation of this year’s best Infovis paper. Haroz and Whitney designed a set of simple experiments that show very clearly how information displays are fundamentally bounded by our limited capacity for attention, and discuss how to optimize visualizations to avoid squandering this limited resource. The paper includes all the relevant details, and you should read it. But what really caught my attention was Haroz’s presentation. I don’t know if VGTC is recording these, but if you have the opportunity to see one of his talks, I urge you to do so: he was clear, persuasive, only explained as much as needed in a talk (because, really, you should read the paper!), and, above all, he used the projector to show, not tell. Really great job. There has been some discussion on how to interpret the results, and Haroz has written a response. How crazy is it that these written discussions can now happen during the course of a conference? We truly live in the future. Also, and I’ll try to put it mildly, dropbox user 14753707: don’t act like a spineless coward, and let us know who you are! This is not how scholarly discourse happens.

The other work I want to highlight of the morning session is Hofmann, Follett, Majumder and Cook’s paper on evaluating visualization designs by appealing to the notion of statistical power. This is a followup and a direct application of the techniques in Graphical Inference for Infovis, which if you’re at all a reader of this blog, you’re probably sick of hearing. But bear with me some more, because this is great stuff. The original paper presented the groundbreaking techniques for turning visual tasks into formal statistical tests. This paper shows how this idea can be used to compare different visualization designs. The basic idea is this: a visualization design is good if it is hard to hide the true data among “impostors” which are created by sampling bogus data with similar distributions to the true dataset. This is almost unbelievably simple, but it turns out to unlock many powerful (and widely studied!) tools from statistical inference theory directly so then can be used in visualization evaluation. As this is an area that in my opinion is in sore lacking of techniques which generalize effectively, this development by Hofmann and co-authors is hugely exciting.

Other cool papers I saw today included (but were not limited to!) the work from Ahmed, Zheng and Mueller in leveraging human computation to design better compositing operators, Wu, Yuan and Ma’s paper on non-independence and interaction modeling for uncertainty displays, and Sedlmair, Meyer and Munzner’s work on collecting best practices for design studies, which are a powerful, popular, and monstrously hard way to do applied visualization work.

Finally, the day ended with a phenomenal party, organized by Noah Illinsky in connection with the Seattle Data Visualization Meetup and graciously sponsored by Tableau Software (if I’m missing anyone else, please let me know!). This was, as Noah put it, an attempt to bring together two groups of people with very similar interests that would otherwise probably not overlap very much. There were five or six talks ranging from things like “why you should do pro bono visualization work and make the world a better place” to the intersection of art and visualization (by Francesca Samsel, who is actually organizing an intriguingly named workshop on Thursday, to our own Robert Kosara talking about story telling in visualization. This was possibly the best party I’ve ever attended at VisWeek, and I would love for something like it to become a tradition.

VisWeek 2012, Sunday

Wed, 17 Oct 2012 04:31:33 -0400

At this point, VisWeek 2012 is just about halfway done, and there’s tons to write about, but I’ll try to keep these short by sticking to one day at a time. VisWeek now runs four parallel tracks for the best part of a week, so there’s no way I can tell you about everything that is happening out here in (today, surprisingly sunny!) Seattle. But I will tell you about what I think is cool. The usual caveats follow: omissions and mischaracterizations are all my fault.

Sunday

VisWeek started on Sunday, and I saw Pat Hanrahan’s LDAV keynote on “Divide and Recombine: an approach for analyzing large datasets”. This was a nice tour through recent work (some from Hanrahan and his students, and much from other folks) happening on the big data community. Pat gave a nice overview of the reasons surrounding all the buzz around NoSQL databases (performance! flexibility! distributed computation!), and the challenges for visualization and data analyst researchers and practitioners: mostly, the toolchain is slow and clunky. And computer scientists are toolsmiths, so we should make better tools.

It was fun to realize that his talk was really about “satellite issues” surrounding the topics which we traditionally consider visualization, such as: how can we get to the big data sources? How do we wrangle all that data into something usable for visualization, and how do we manage (computationally, and organizationally) all the analyses which we need to use to get meaningful visualizations? Much of his talk focused on R, the current darling language of data analysts. Interestingly, across the hall to this talk, a tutorial on ggplot2 and ggobi was being presented by Di Cook, Heike Hofmann (of whom I’ll have more to say soon). ggplot2 has been described as the hipster plotting library for R. But it really does kick ass. Of course, I’m partial to R since I work in the same building as some good folks who are deeply involved with it. Nevertheless, it’s nice to see the VisWeek community warming up to it, warts and all.

The other interesting observation Pat Hanrahan made was that problems which the (for lack of a better term) “industrial big data community” tackle have a lot of overlap with the ones which we tackle at VisWeek. Somewhat inexplicably, there is minimal overlap of the communities: how many of us hang out at Strata, or the many great visualization and statistical computing meetups? It’s something to think about.

At the same time, someone mentioned to me tonight that in the user interface community, there is an analogous situation with UX vs. CHI. So is this simply an indication that visualization is now actually mainstream? In other words, is this fragmentation a symptom of success or an admission of defeat? I don’t know.

Plug: come see our panel!

I have a lot more to say about VisWeek 2012, but the bigger the wall of text, the more likely you are to go look at cute cats. So before you leave, let me plug a panel in which (because unfortunately Juliana Freire can’t make the trip) I will be presenting, about reproducible visualization research. This is a topic near and dear to my heart, so I am really honored (and more than a little scared) to be sharing the stage with Tim Dwyer, Tamara Munzner and Gordon Kindlmann. There’s few things I like better than a good argument, so this should be great fun.

So you want to look at a graph, part 3

Sun, 22 Jul 2012 19:15:12 -0400

This series of posts is a tour of the design space of graph visualization. I’ve written about graphs and their properties, and how the encoding of data into a visual representation is crucial. In this post, I will use those ideas to justify the choices behind a classic algorithm for laying out directed, mostly-acyclic graphs.

Putting what we know to work

In a way, this sequence of posts is an attempt to understand how we turn the process of designing visualizations from mostly art with some craft, to mostly craft with some art. We do know a few rules which work, but we don’t really know how we know them.

In part 1, I asked: “what is in a graph?”. In part 2, I asked “what is in a sheet of paper?”. It is my view that every visualization design should start answering those two questions: what are the structures which we care about in our data? what can we work with?

These questions have little to do with the actual design of a visualization, but they lead right away to what in my mind is the fundamental axiom of visualization design: A visualization design must match structures in data to structures in visual encodings. From here on out, I will call this The Axiom (tongue possibly in cheek).

Following The Axiom means we identify important structures about the data domain, study the medium in which we are going to encode them, and create an encoding in which these match: the graph properties should be represented by the closest matching properties in a sheet of paper.

This notion is of course central in Cleveland and McGill’s classic paper, and you can also see something like it driving much of what Bertin wrote about in his seminal book. For example, Cleveland and McGill famously showed that positions along a common scale are a very effective way to portray a set of real numbers. So if you have a single set of numbers you want your users to understand, following The Axiom means using a dot plot.

Big whoop, right?

But there are other types of structures we would like to portray in our visualizations. In this post, we will see some of them.

Looking at a DAG

To make this exercise simpler, assume that our visualizations will be node-link diagrams. So your mission is simply to specify positions of the nodes on a cartesian plane, and edges will be drawn as straight lines (directed edges will use traditional arrowheads).

You’re given a graph $G$ which happens to have a “mostly acyclic structure”. That is, there are either no cycles, or relatively few of them, such that you expect that the majority of the interesting properties of $G$ come from its acyclicity. If your mission were to portray this graph faithfully on paper, what would you do? As the simplest possible “null plot”, this is a graph whose coordinates are just positions on the unit square chosen uniformly at random. Aside from (maybe) being able to tell which vertices appear to have more edges than others, we cannot see much. But we didn’t really expect much to begin with.

Following The Axiom, we already identified one property we want to preserve, namely the “directionality” of the graph. This is good, but it is not very actionable: how do we design a visualization around that? Going back to part 1, remember that we learned that the vertices of acyclic graphs can be ranked: we can give every vertex $v$ an integer $r(v)$ such that if there is a path from vertex $v_1$ to $v_2$, then $r(v_1) < r(v_2)$.

Let’s set aside the fact that there are many such possible rankings, and accept for now that a rank ordering is a good representation of the notion of acyclicity. The question is then: can we design a visualization that uses it? One possibility is to use the rank as one of the coordinates of the node positions. As a direct consequence, all graph edges will point in the same direction. We’re still using random numbers for the horizontal position of the vertices, but it’s clear that the ranks are encoding some decent amount of structure in the graph (of course, if we wanted to know for sure, we should be using formal inference methods, but that’s another story).

To decide the horizontal positions of the nodes, there are many possible solutions. To begin with, we are going to use the Axiom to state that positions should be unique (“every node is different” becomes “different nodes should be drawn in different places”).

In addition, we will need a new postulate that sounds a little like the contrapositive of The Axiom. Let’s call it The Other Axiom: Everything shown by a visualization should exist in the data. That is, if something “looks like a feature”, then it had better exist in the data. Of course, what is a feature and what is not a feature can only be determined by psychological experiments, but let’s ignore that important point for now.

This notion is obviously close to Tufte’s principle of maximizing data ink. From my reading, Tufte advocates maximizing data ink as economy in service of aesthetics. I, however, want to use the Other Axiom to try and keep a bijective mapping between data and visual representation: if the Axiom is violated, then two different datasets will look the same, and that’s a problem. But if the Other Axiom is violated, then even if the visual mapping is unique, inspecting the resulting visualization might make you think the data is different from what it actually is. The Axiom tries to prevent blurred vision; the Other Axiom, hallucinations.

Since we are using one of the coordinates for the node ranks, the plot naturally grows an axis perpendicular to the rank coordinate. We need to assign this remaining coordinate, but we want to be careful to avoid giving the impression that our visualization is encoding information in how the edges point one way or another (when ranks are drawn vertically, edges will generally point left or right; we want to avoid implying that this direction is meaningful). In addition, edge crossings are an obvious visual feature, and since adjacent edges meet at a node, we don’t want to give the impression of “ghost nodes” by introducing unnecessary edge crossings. Preferring vertical edges seems to be a sensible way to convey “no additional information”, so we will try to position nodes so that edges are “mostly vertical”. It also prevents edge crossings.

There are two main problems in this solution. First, the goal of vertical edges clashes directly with the goal of unique node positions. So we need to compromise somehow (and the devil is in the algorithmic details). But just as importantly, what constitutes a “natural arrangement” with “no additional information” is a mix of cultural and innate characteristics about which we know very little (but there has been recent work in the area).

Leaving aside all those important details, this is what an algorithm which (roughly) encodes the above principles generates. Aside from one important step, this is a result from graphviz’s classic “dot” algorithm. Visually, the main problem with this approach is in the edges. For simplicity, I have completely ignored the problem of edge occlusion, but that has led to a violation of The Axiom: in a subgraph of the kind $a \to b, b \to c, a \to c$, the principles I set above mean that the edge $a \to c$ will necessarily be obscured. One can explicitly route edges around nodes, and this is precisely what “dot” does; I left that out in my crude drawing.

The paper describing “dot” is worth, at the very least, skimming over; I like that it sets forth a few visual principles and then the algorithm itself (which is, alas, fairly complicated) is designed around those simple principles. The same kinds of statements can be found in the classic Reingold-Tilford tree drawing algorithm. I don’t think I see this structure in more recent visualization papers. Should we be asking ourselves why?

So there you have it, a very basic graph drawing algorithm distilled to its very basics: Find some structure you care about (in this case, acyclicity); find a way to encode it visually, and make sure your encoding is effective (the Axiom) and faithful (the Other Axiom).

Next, undirected graphs

Of course, defining the entirety of graph visualization as choosing node positions in the plane is a gross simplification, and one which lets us apply the Axioms straightforwardly. It will not always be this simple, and in this series we will get to more delicate cases. But before we go there, the next post will discuss (albeit in less detail) a few popular graph drawing algorithms for undirected graphs.

A Javascript question on performance vs. convenience

Tue, 26 Jun 2012 17:19:40 -0400

Here’s a Javascript-specific software engineering problem I’m considering within Facet. I’m trying to decide how (or even whether) to approach type-checking in the API, and I’m looking for input.

Since Javascript is dynamically checked, if a user passes a bad value into a function, the error might only manifest itself much further down the code. Tracking this error down is a slow and opaque problem: the error message will typically come from the innards of Facet, which will confuse users that are not intimately familiar with the library (at present, anyone but me).

The easy way to solve this problem is to add a strict layer of type-checking into every function. This works, but carries a runtime penalty, and good code pays the cost of debugging over and over again. This is not a problem if the API call is not on the application hot path, but some calls are unavoidable: anything that happens per-frame on WebGL should be considered on the hotpath, since spare cycles can be used for more features. The canonical example of this type of thing is in Shade.parameter.

I’m leaning towards creating two sets of methods, the slow, type-checked method, and the fast, you be careful with dat non-type-checked version. But what’s the best way to expose this in an API? Is this even hopeful to do robustly and effectively? I have created an issue on github. If you’ve run into this type of issue in the past, want to voice an opinion or simply help out, I’d love to hear from you.

So you want to look at a graph, part 2

Wed, 29 Feb 2012 10:25:46 -0500

This series of posts is a thorough examination of the design space of graph visualization (Intro, part 1). In the previous post, we talked about graphs and their properties. We will now talk about constraints arising from the process of transforming our data into a visualization.

What is in a sheet of paper? Marks

Paper is like external memory. We can make marks on it, and later we can read marks that we made on a particular spots. We will say then that visualizations are encodings of data as particular configurations of marks on paper. The process of “reading a visualization”, of getting the dataset back into our heads, is simply the decoding of the marks of paper into what they mean. I will refrain from defining a mark precisely: it is only important that the writer and the reader both agree as to what constitutes one, and that they’re both capable of reading and writing marks. Let’s see how far this notion takes us.

We can draw marks of different shapes, and we use the difference between the shapes to encode aspects of our data. Using this idea, we could just write down a description of a graph in english prose. If we wanted to “visualize” the data, we would then literally read the prose, reconstruct the graph in our heads, and be done. But this is not a visualization!

If we went ahead with this boneheaded idea, we would clearly be employing our visual system to read the prose describing the graph, even though no one in their right minds would describe that encoding as “visual”. One reason for this is we know that the process of reading prose feels fundamentally different than the process of looking at a scatterplot, or other abstract graphical depictions. So let’s constrain our encodings to be “graphical” in nature. I’ll keep this notion underspecified, but for now think of it as requiring encodings to only be configurations of dots, lines, circles and their shapes and positions. This makes the encoding more “visual”, and that should be enough.

... or should it?

Even the simplest possible abstract encoding can go boink

When there are two dot marks on a piece of paper, it turns out that we immediately see that these two marks have some distance between them. Given two marks written on paper, I can then read a real number, in principle to arbitrarily large precision. Since we know how to read and write this configuration, we know how to encode a number as distance between two points.

This two-mark encoding appears to be completely innocent and boring, but it turns out that we can already get ourselves in deep trouble if we’re not careful! If you’ve ever read about Godel encodings, you should have started feeling uneasy around where I said “arbitrarily large precision”. With arbitrarily large precision, I can encode a number with as many decimal places as I want, and I can define the encoding of my graph to be, roughly, the ASCII string representing the graph vertices, edges and properties. Furthermore, this encoding is lossless.

Although encoding an entire graph as a single distance between two points is valid. it’s clearly ludicrous. What went wrong? Remember that we decided the prose encoding was bad because “it wasn’t visual”. Now this new encoding of ours is (superficially) visual, but it feels similarly bad to the prose encoding. One thing the two encodings have in common is that the part of the decoding process that confers “graphitude” to the data does not seem to come from our vision system, but from some other part of the brain. We are using arbitrarily small differences in distances to distinguish potentially arbitrarily large differences in graphs, this encoding needs “additional decoding”. Somehow, there are these visual bits (in this case, a distance) which get sent to other parts of the brain for further interpretation. And this indirectness is precisely what is bad about the encoding.

A good visual encoding is “direct”. Such encodings get their “meaning” straight from the vision system, without requiring an explicit “reading”. This notion should be familiar to you, if you read Bertin before: it is related to his ideas of “perception of correspondences” and “retinal legibility” in Semiology of Graphics.

How is any of this at all relevant?

At this point, you may be thinking that this entire discussion is a gigantic waste of time, a treatise in picking nits. But the fact of the matter is that arguing about the effectiveness of different visualization techniques is exactly arguing about encoding choices. And if we ever hope our theoretical arguments to be valid regardless of which encoding we use to examine, we need to be able to articulate why stupid encodings like the above are, in fact, stupid.

And even armed with the simplest of the observations above, we can already make some nontrivial statements. If you’ve ever heard about Chernoff faces and wondered why they’re a terrible idea, worry no more. Remember that the idea behind Chernoff faces is that since we’re incredibly good at face recognition, then we should encode different attributes of our data as different aspects of a face. (If you’ve never heard about them before: yes, they are hilariously bad. But I assure you they were proposed completely seriously.)

So why are Chernoff faces bad? It’s simple: although recognizing different faces and telling them apart is something we do thousands of times a day, we almost never think “yes, George Clooney’s face is different from Julia Roberts’s face because his eyes are obviously 12.3% larger, his ears are 15.7% smaller, and his nose is half as hooked.” In fact, Chris Morris, David Ebert and Penny Rheingans have experimentally confirmed this: Chernoff faces are not pre-attentive. The important point is that even though we can, given enough time, make precise judgements of face proportions, the values don’t jump at us: we have to read faces in the same way we would read numbers from a spreadsheet. And, if the encoding forces me to read, then it’s not a visual encoding at all. If they were visual, we’d just stick with spreadsheet rows in the first place!

The above argument means that, right now, settling almost every question of which visual encodings are good and which are bad (and at what) needs the heavy lifting of experiments in perceptual psychology. Morris, Ebert and Rheingans’s study is important, and appears to answer that one question definitively. But we would like to have a theory which would explain, ahead of time, why Chernoff faces are bad, and many other ideas we might have, without needing to recruit 500 people on Mechanical Turk. I might come back to this later on in the series, when we have enough theory under our belts to actually say something about Chernoff faces. Still, a lot of work has been done in evaluating visual encodings in isolation, and we will have to recap the most important ones.

Next: what do we know about good visual encodings, and can we use these encodings directly for graph visualization? If not, why not?

HCL color space blues

Thu, 16 Feb 2012 01:20:06 -0500

I’ve been playing around with the HCL color space. HCL, if you’ve never heard of it before, is a color space that tries to combine the advantages of perceptual uniformity of Luv, and the simplicity of specification of HSV and HSL. HCL is an improvement over HSV and HSL, but it is not exactly ideal: there is a nasty discontinuity at some bits of the transformation! I have been trying to find a way around this, but I’m stumped. Let me explain, and maybe you can help me.

The transformation from RGB to HCL is somewhat complicated, and involves two intermediate color spaces, CIEXYZ and CIELUV. Going from RGB to XYZ is a simple matrix transformation: $(x,y,z) = M . (r,g,b)$. For arcane reasons, there are many possible matrices: the one most relevant nowadays is the sRGB/D65 matrix. This is a linear transformation designed to make a “brightness” coordinate, Y, while encoding the rest of the space in the other coordinates by roughly mapping them to “red” and “blue” stimuli.

To go from XYZ to CIELUV, things are a bit more complicated: this is the bit that tries to match the physiology of a typical human vision system, which is much better at telling shades of yellow and green apart than it is at telling shades of blue apart. The full transformation behaves nonlinearly, and tries to make the euclidean distance in CIELUV correspond roughly to perceptual differences. In this space, L encodes the lightness of the color, or how bright it is, and uv encodes the chromaticity portion: the particular tint or shade of the color.

Finally, HCL is then obtained by simply transforming the UV coordinates of Luv to polar coordinates. The phase is interpreted as hue, and the length of the vector as “saturation” (specifically, it’s then called chroma).

The goal of HCL is to be perceptually uniform along its axis, and so the thing to notice is how the apparent brightness of the colors all appear roughly the same for any given slider setting; and while moving along the horizontal axis changes the hue of the color, it doesn’t change the perceived lightness or saturation. Compare this with the HSV colorspace.

So you can play with these color spaces, I’ve written a few little demos of the color spaces using Facet. The sliders control the axes which resemble brightness, and the image then shows a slice of the resulting parameter space. You will need WebGL and Chrome for these to work (sorry!). Pay attention to the boundary of the gamut.

One of the great conveniences of HSV is that no matter what you do in HSV, you will end up somewhere inside the (0,0,0)-(1,1,1) cube of valid RGB colors. That means nothing too strange happens.

On the other hand, if you play a bit with the LUV and HCL colorspaces in low luminances, you will see a discontinuity in the conversion. Although it happens outside the RGB gamut, it is still quite annoying: some paths through HCL are cut off in RGB. The issue happens when clamping the values from outside of the gamut back into (0,0,0)-(1,1,1). This is what I would like to solve: is there a simple way to create a (clamped) conversion from HCL to RGB that is continuous and reasonable?

The procedure that is used in the R package for colorspace management is the one I’m currently using in the demo above: after converting from HCL to a value, we find the closest point to the raw conversion that is inside the RGB cube.

Here’s a different approach that is continuous: instead of converting the color $c$, we instead search for the closest color in HCL space $c’$, which converts to a value inside the RGB gamut. Now the problem is: how do we actually find such a transformation efficiently? It’s easy to see that if $c$ goes outside the RGB gamut, then $c’$ will be on the boundary of the gamut. So this is “merely” a two-dimensional search problem. Except that the boundary of HCL or CIELUV in RGB space is complicated. So we’re looking for the minimum of a function constrained to a complicated 2D surface, and I don’t think there’s any simple algorithm to do this.

Or is there?

Acknowledgements

Thanks to Hadley Wickham for teaching me about HCL, whose ggplot library uses that color space extensively. This post grew out of trying to make continuous HCL scales easier to specify.

So you want to look at a graph, part 1

Wed, 25 Jan 2012 08:34:01 -0500

This series of posts is a tour through of the design space of graph visualization. As I promised, I will do my best to objectively justify as many visualization decisions as I can. This means we will have to go slow; I won’t even draw anything today! In this post, I will only take the very first step: all we will do is think about graphs, and what might be interesting about them.

What is in a graph?

A graph $G$ has two things: a set of vertices $V$, and a set of edges $E$, where each edge is represented by an ordered pair of distinct vertices (so in this definition we will not have multiple edges and “self-edges”). To denote that $(a, b)$ is in $E$, I will use $a \to b$.

Usually, we also have a mapping $v_\textrm{attr}$ from $V$ to some other space $V_A$. This gives us attributes of these vertices (names of the people in your social network, names of the computers in your intranet, etc.). A similar mapping $e_\textrm{attr}$ from $E$ to $E_A$ does the same for edges (is $b$ married to $c$ or does $b$ work for $c$? How far is $h$ from $j$?, etc.).

These define a graph, but they don’t say much of what is interesting about them. So let’s list some properties of (these very general) graphs. By explicitly thinking about them, we can see the impact they will have on our choices of pictures.

Graphs are directed or undirected

One important characteristic of graphs is whether they are directed or undirected. When we say that a graph is undirected, we mean that whenever $(a,b) \in E$, it is implied that $(b,a) \in E$: in other words, the has-edge relation is symmetric, and $e_\textrm{attr}((a,b)) = e_\textrm{attr}((b,a))$. (For undirected graphs, I will write $a – b$ to mean that both $(a, b) \in E$ and $(b, a) \in E$ are true). Otherwise, we say that $G$ is directed.

This distinction is important because, remember, the first rule of visualization is “draw all there is, but no more”. If our graph is such that $a \to b$ does not imply $b \to a$, our visualization of it better not imply that the relationship between $a$ and $b$ look symmetric. Of course, “making the relationship look symmetric” is not a formal statement, and we might argue about what it really says. But this is what I meant about the difference between a formal systematization and an “informal” one: we should not disconsider the notion simply because we don’t know how to formalize it! And, as we will see, I believe this distinction does guide the visualization choice.

Graphs have paths

An edge $a \to b$ in a graph implies some sort of connection between $a$ and $b$, and we typically think of these connections being transitive. So if $a \to b$ and $b \to c$ encode some relationship, we tend to think of there existing some relationship between $a$ and $c$ as well (we will say $a \leadsto b$ to say that there exists some path $a \to \ldots \to b$).

This reveals another interesting property of graphs. Let’s say you send the elements of $V$ into new sets, such that whenever $a \leadsto b$ and $b \leadsto a$, $a$ and $b$ must go into the same set. Then, every element of $V$ ends up in exactly one new set. These sets form a partition (into “strongly connected components”, SCCs). Natural partitions like this are your data’s way of telling you to consider divide-and-conquer. If you think paths are important (implying that SCCs are important as well), then your resulting visualization should be “partition-preserving” too: 1) your visualization should have the ability to visually represent a partition of vertices (call it a “visual partition”) and 2) iff $a$ and $b$ are in the same partition, then the visualization of $G$ should put $a$ and $b$ in the same “visual partition”.

Paths have cycles

We will call a path $a \leadsto a$ which does not repeat internal vertices a cycle (and we will require that cycles in undirected graphs have at least three two internal vertices). A directed graph with no cycles is a dag (“directed acyclic graph”) and an undirected graph with no cycles is a tree.

Vertices of a dag can be assigned natural numbers such that for every pair of vertices $a$ and $b$ such that $a \leadsto b$, $f(a) < f(b)$. If your paths encode dependencies, this assignment of numbers ranks the dependencies, and is good information to have around.

Many undirected graphs have a metric structure

The final structure I want to mention is the metric structure. For some undirected graphs, there is a very natural way to come up with a distance function between two vertices such it resembles the familiar distances in plain old two- and three-dimensional space. Our eyes are reasonably good at distance judgements (yes, that’s somewhat controversial because of optical illusions and such. But if we are sensitive to these issues, I believe we can use Cleveland to back the statement.)

Anyway, a function $d: V \times V \to R$ is a metric if:

$d(a, b) \ge 0$, with equality iff $a = b$.
$d(a, b) = d(b, a)$
$d(a, c) \le d(a, b) + d(b, c)$, for all $b$

(Assume that the graph is connected for now; any pair of vertices (a,b) is such that $a \leadsto b$ or $b \leadsto a$.) If one of the attributes of undirected graph edges is a positive weight associated with each edge, then the standard metric to assign to a graph is the shortest-path metric, where we say that the distance $d(a, b)$ is given by the smallest cost of a path, this cost being the sum of the edge weights along the path.

“But what if my graph has negative edge attributes?”, you ask. Good question! Then you simply can’t use a metric to describe that particular attribute of your graph. And slightly less trivially, if your visualization technique implies that your graph obeys some metric, then it is telling a lie. As a preview of the next few posts, this “metric-friendliness” will be a crucial distinction between network diagrams and matrix diagrams.

Next up, I will talk about 2D space; a sheet of blank paper where we get to write. Then we will put those things together, and bam, visualization.

Series introduction