Quarter Life Crisis

The world according to Sven-S. Porst

« Hamburg SauseMainGraphViz & OmniGraffle »


717 words on

GraphViz file icon GraphViz is an interesting visualisation tool. It lets you write a simple text file describing the nodes and the connections between them of a graph and then algorithmically creates the layout of the graph, apparently by trying to minimise the ‘forces’ between the objects. Depending on the content of your graph there are several different algorithms to choose from, ranging from dot for tree-like graphs, neato and fdp for more force-based freestyle stuff and twopi or circo for more circular arrangements.

Thus, in theory, GraphViz is a fantastic tool to magically create meaningful graphs from simple relations between objects. Being open source and able to export into many file formats from bitmaps to PDF to SVG makes it also score high in buzzword bingo. There’s also a pretty abandoned looking, Design Award winning and not exactly easy to use graphical Mac application for the dot tool as well as a cool looking but presumably useless iPhone version for the same people.

There are, however, problems with GraphViz. One of them is documentation. As is par for the course for open source software, there is a formal specification for the language used and an alphabetical list of all the parameters you can use. Of course that’s pretty close to useless as it totally hides the fact that writing a dot file is quite easy. And once you figured that out, by looking at the pages of examples, it still remains frustrating to use the software because not all of the options work in all of the tools and generally the outcomes seem quite random in the sense that it often seems gratuitously hard to figure out or achieve simple graphical effects.

Particularly so, once you start creating slightly complex graphs. Positioning nodes ‘just right’ in those is pretty hard because the positions one node potentially affects all others. This makes it pretty much impossible to turn a graph which may represent the structure correctly into a graph that represents the structure correctly and looks good. Where ‘looking good’ also means that the graph can become clearer as a consequence of that because you have fewer crossing lines or the order of the nodes is more adequate for your current application. To a certain extent you can tinker with some of these aspects, but in my experience it quickly ends up being a lot of effort while still not giving the results I want.

In addition GraphViz, in true Unix style, is a one-shot-wonder - meaning that it simply processes the file you throw at it without any knowledge of previous runs. Hence even adding a single node to the graph can significantly change the layout the algorithm comes up with. This makes it pretty futile to try and ‘optimise’ the graph in any way unless you are 100% sure its nodes and edges will not change. It also keeps you from doing something like a development of the graph over time as adding a node will quite likely create a discrete jump in the graph rather than lead to a continuous change. As far as I understand the readmes of GraphViz, the way it optimises graphs actually is continuous in nature, so it’s likely that all the necessary algorithms are pretty much in place already and a shame that no interface to them is exposed.

Finally, there is the difficulty of the middle ground. Looking through the GraphViz examples page you will find mostly graphs which are small or structurally simple. Those tend to look all right. There are also a few examples which are very large and complex and in which the graph is seen as a global picture rather than revealing the details of its nodes. Of course the graphs I wanted to create are in the middle ground. They are too big and complex to fit in the first category but I am still interested in the detail information.

An example for many of these issues may be my UTI graph:


Once you start looking at it in detail to learn the exact information it contains, you will start noticing how the layout of the graph is far from perfect in many places. Improving on that seems quite hard. And getting everything ‘just right’ could very much end up being impossible.

December 11, 2009, 11:19

Tagged as graphviz.


Comment by Doug Everly: User icon

Try out Graph::Easy perl module to programmatically make .dot files. I’ve used this to graph a couple hundred network nodes from a text file.

Also, OmniGraffle Pro can read .dot files.

December 11, 2009, 17:31

Comment by ssp: User icon


I’m not normally using perl (it gives me rashes). Superficial googling suggests that the library you recommend merely is a general graphing library with different export options. So I suspect that it probably just supports the basic features of GraphViz rather than its finer (and hard-to-comprehend) options. Please correct me if I’m wrong about this.

For simple files I find the GraphViz syntax easy enough to just write my own scripts for generating the files. Like the python one used in the UTI Graph post linked in the text. I probably shouldn’t admit this but I’ve also used Excel to create GraphViz files (eek).

My next post is supposed to be on Omni Graffle and how it vastly improves the GraphViz experience even though it’s far from perfect. You kind of spoiled the surprise of that now ;)

December 11, 2009, 18:12

Comment by Fred Blasdel: User icon

That’s the same thing I thought immediately — duh, just use OmniGraffle silly!

When using Graphviz I make no attempt to control what it’s output looks like. Even if I managed to tweak it just right, I’d just have to do it again when I changed the nodes. I don’t think it’s possible to build a graph layout hinting system that’s both robust enough to handle change and expressive enough to want to use.

The most I’ll usually do is make dummy invisible nodes to balance a tree as if it were complete (which helps a lot in OmniGraffle too).

December 11, 2009, 19:24

Comment by ssp: User icon


The most I’ll usually do is make dummy invisible nodes to balance a tree as if it were complete (which helps a lot in OmniGraffle too).

Heheh, that’s just what I ended up doing as well. But it seems strange / wrong that one should need such hackish workarounds and that it seems to be common (among my small number of samples) to use them.

December 11, 2009, 19:59

Comment by Fred Blasdel: User icon

I don’t see it as hackish at all — I can’t think of a more declarative way to tell it that a node should be placed as if it has siblings.

December 12, 2009, 4:09

Add your comment

« Hamburg SauseMainGraphViz & OmniGraffle »

Comments on




This page

Out & About

pinboard Links


Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.