Skip to content

Demo index

Demos index

The original demo index, kept at its historical path and revised so it stands on its own as a guide to what each example is meant to teach.

A demo index panel listing three graph experiments with small previews

The point of a demo set

A demo set for a graph viewer is most useful when each example is built around one idea about how the viewer should behave. The three demos here cover the cases that come up most often in practice: density, structure, and change.

The exact historical paths for each demo are preserved. Modern landing pages exist on top under /demos/, but the original URLs continue to resolve.

How to read a graph demo

A graph viewer is a slow camera pointed at a layout that is still computing. A good demo reads better in motion than in a still picture. The point is not the picture; the point is the response.

Four things to watch for, no matter which demo you are looking at:

  • The centre. Does the layout keep a recognisable centre as the graph changes, or does it drift?
  • New structure. When a new node joins, does the layout slot it near related nodes, or does it shove the whole graph aside?
  • Edge crossings. Do crossings accumulate over time, or does the layout reduce them when it can?
  • Settling. After a change, does the picture come to rest, or does it keep ringing?

Most of the differences between a useful and a frustrating graph viewer come down to those four behaviours.

Random graph

The random graph demo builds a graph from a fixed set of vertices and adds edges with a probability you can adjust. As probability climbs from sparse to dense, three behaviours appear in sequence:

  1. Sparse graphs look almost like rings or chains. The layout has enough room to separate the nodes.
  2. As edges accumulate, the picture becomes a recognisable graph with clusters and bridges.
  3. Past a certain point, the layout gives up on separation and produces a tight cluster.

The transition is the interesting bit. Different viewers handle the dense end of the spectrum differently, and the demo is useful precisely because it shows you the transition rather than only the endpoints.

The longer write-up is on the random graph page.

Random binary tree

The random binary tree demo grows a tree by repeatedly choosing a random existing leaf and giving it a new child. The result is a tree, but not a balanced one.

That is what makes it useful. A balanced tree is a tidy thing. An unbalanced tree exposes how a layout handles structures where the depth is uneven and the branching factor varies.

A few things to look for:

  • How does the layout handle deep branches versus shallow ones?
  • Does the layout reward the tree structure with vertical separation, or does it treat the tree like a general graph?
  • What happens when a leaf with no siblings suddenly gets a child?

Force-directed layouts and layered layouts both have failure modes here. The random binary tree page goes into the trade-offs.

Animation

The animation demo adds and removes nodes and edges in motion. The viewer has to keep up with all of it without losing the picture.

That is a harder problem than it sounds. A viewer that reacts strongly to every change makes the picture unreadable. A viewer that reacts too softly hides the changes. A good viewer sits between those two failure modes.

Worth watching specifically:

  • When a node is removed, does the layout collapse the gap gracefully or does it shove the whole graph?
  • When an edge is added, does the layout pull the endpoints together too aggressively?
  • When changes come in bursts, does the picture stay stable enough to read between bursts?

The animation page is the longer write-up.

Layout mistakes the demos make visible

A handful of layout mistakes are easy to see in the demos:

  • Over-jitter. The picture moves more than the changes warrant. Often a sign that the layout dampening is too weak.
  • Over-settle. The picture barely moves. Meaningful structural changes look like small wobbles.
  • Cluster collapse. The layout cannot maintain readable separation as density climbs.
  • Tree fatigue. The layout treats a tree as a general graph and loses the hierarchy.
  • Bursty resets. The layout keeps re-arranging the whole graph in response to small local changes.

These are not flaws unique to any one viewer. They are the kinds of behaviours every graph viewer has to handle, and the demos surface them quickly.

How the demos render technically

Most modern technical documentation that wants to draw a graph in the browser does it through SVG. If you ever want to follow what current technical pages are doing under the hood, the SVG 2 working specification is the right document to consult. The Ubigraph viewer is not an SVG renderer - it is a 3D viewer - but the underlying questions about how to lay out a graph on a flat screen are the same.

Where to go from here

If you came to this page from an old link, nothing has been moved. The demos are at the same paths they have always been.