Time as a circle: designing TimeRadar
Why I wrapped a timeline into a ring — and what a radial layout reveals that a straight line hides.
The first version of TimeRadar was a straight line. It worked, in the way a spreadsheet works — technically correct and quietly unreadable. The problem with a linear timeline of community structure is that the interesting events are comparisons: is this cluster bigger than last month? did these two merge? A line makes you scrub back and forth to answer that. A ring puts the whole story in one glance.
Three encodings, one rule
Every visual channel has to earn its place. In TimeRadar: angle is time, radius is the ring (each step outward is the next snapshot), width of a wedge is community size, and color is identity held constant across rings so the eye can follow one community outward. The rule I kept repeating to myself: if a channel does not answer a question someone actually asks, cut it.
What the circle reveals
- →Rhythm — periodic swelling and shrinking becomes a visible pulse around the ring.
- →Splits and merges — a wedge forking into two, or two folding into one, reads instantly.
- →Stability — the communities that simply hold their shape while everything else churns.
What it costs
Radial layouts are not free. Area near the center is scarce, so early time steps get cramped; comparing exact magnitudes across different radii is harder than reading bar heights on a shared baseline. I am honest about this in the paper: TimeRadar is for seeing the shape of change, not for reading precise counts. When you need the number, a sorted bar chart still wins.
A visualization is an argument about what matters. The radial form argues that change matters more than the exact count.
