Skip to content

Lab note

Graph visualisation alternatives

What to reach for when the original Ubigraph viewer is not available and you want to keep working. The shortlist is small and the trade-offs are clear.

A shelf of graph viewer options with short labels

The question this note answers

You have a workflow that used to run on the original Ubigraph viewer. The viewer is not available to you, for whatever reason. What do you reach for now?

The list below is short on purpose. The categories matter more than any specific tool.

What to keep in mind

A useful substitute needs three things to match the streaming model the original viewer uses:

  • A continuous layout. Static layouts cannot animate gracefully.
  • An incremental API. The viewer has to accept changes one at a time without redrawing from scratch.
  • A 3D or 2D mode that fits the data you are trying to read. 3D is more visually striking. 2D is often more legible.

If a tool only does whole-graph rendering, it is not a substitute for this kind of workflow. It can produce nice pictures but it cannot do animation.

The shortlist by category

Force-directed 3D viewers

This is the category that fits the original viewer most closely. A force-directed 3D viewer runs a continuous simulation and lets you nudge the graph as it runs.

Things to look for when choosing one:

  • Does it expose an API that accepts vertex and edge changes one at a time?
  • Can you set per-vertex attributes (colour, shape, size, label) from the API?
  • Does it handle several thousand vertices without becoming unreadable?
  • Can the viewer run headless for screenshots, or only as a window?

A wrapper that exposes the original Ubigraph call shape over your chosen viewer is small work - perhaps a few hundred lines of code. The XML-RPC graph control note covers the call shape.

Force-directed 2D viewers

A 2D viewer is often more legible for the same data. Three dimensions are striking but they ask the reader to mentally rotate the picture.

For most analytical work, a 2D force-directed viewer with a continuous simulation is the better default. You give up the 3D visual but you gain readability. The animation demo works just as well in 2D.

Layered viewers

A layered viewer is what you reach for when the data is a tree or a near-tree. The random binary tree demo would benefit from a layered viewer for the same reason hierarchical data benefits from a layered viewer in general - the picture matches the structure.

A layered viewer is not a drop-in substitute for the Ubigraph viewer. It does not handle animation as well. It does handle hierarchy much better.

Notebook-embedded viewers

If your workflow is exploratory rather than continuous, a viewer that lives in a Python notebook is often the path of least resistance. You give up the streaming model entirely. You gain a tight feedback loop.

This is the right category when you are reading a graph rather than animating one. It is the wrong category when the graph is supposed to be in motion.

Where the original viewer still wins

Three things the original viewer does that current substitutes often do not.

  1. The API is small. Six calls cover most of what you want to do. Current viewers tend to expose larger APIs with more configuration knobs.
  2. The viewer is its own process. That sounds like a minor detail. It makes the viewer easy to share between languages and easy to keep running while you change the client.
  3. The viewer is honest about being a viewer. It does not try to be an analysis tool, a layout editor, or a dashboard. The narrow scope is a feature.

Substitutes are not always honest about that scope. Many current graph tools try to do everything. That makes them harder to integrate into a streaming workflow.

A small adapter pattern

If you want the original Ubigraph API on top of a current viewer, the pattern is:

class UbigraphAdapter:
    def __init__(self, viewer):
        self.viewer = viewer
        self.next_id = 0

    def new_vertex(self):
        vid = self.next_id
        self.next_id += 1
        self.viewer.add_node(vid)
        return vid

    def new_edge(self, v1, v2):
        eid = self.next_id
        self.next_id += 1
        self.viewer.add_edge(eid, v1, v2)
        return eid

    def set_vertex_attribute(self, vid, key, value):
        self.viewer.set_node_attr(vid, key, value)

    # ...and so on

That is enough to run the demos. It is not enough to claim full API compatibility. For most workflows, the calls above are all that matters.

A note on web-based viewers

A graph viewer that lives in a web page has a different cost model. You can ship it without asking the reader to install anything. You can embed it in documentation. You can show several graphs on the same page.

The trade-off is that browser viewers tend to top out at smaller graph sizes than native viewers, and the layout quality at the larger end is uneven. They are a good fit for showing a graph rather than working with one.

Where this connects in the rest of the site