The whole collection as one graph

The shape of the collection

Before the graph was drawn it was measured. 848 records, 1,152 undirected edges, 2.72 relations a record on average, 53 separate groups. The largest group holds 701 records (82.7 %), the next ones 18, 12 and 9. Fifteen records have no relation at all, 246 have exactly one, and the most, 18, belongs to AlexNet. The shape the issue had described at 641 records held, and records without relations halved.

No library

three.js together with 3d-force-graph would weigh about 200 KB gzip. That is more than the site’s whole JavaScript bound of 180 KB. So the renderer was written for the page, in WebGL 2. Five solids (sphere, cube, a cone up, a cone down and an octahedron) are the three-dimensional forms of the axis’s circle, square, two triangles and diamond, one for each topic. Relations are lines, and fog towards the background gives depth. The node under the pointer is found by a ray from the eye, tested on the CPU against a sphere around each node. The sphere has a minimum angular size, so that a distant node still lands under a fingertip.

The layout is d3-force’s scheme in three dimensions: 300 cooling ticks from a golden-angle spiral, so that every visit sees the same graph. Repulsion had to be cut off at a distance. Without the cut-off every node pushed on all 847 others, and edges settled at three times the length they should have had. Altogether it is 7,230 bytes gzip, against the issue’s estimate of 10–15 KB. The page carries its own data (id, title, topic, year and relations, about 25 KB gzip) instead of fetching the axis’s data, which would cost 147 KB for the relations alone.

Text first

The graph is not the only way in. The page starts with figures, a panel for the open record with its neighbours as buttons, and a list of groups, each with its best-connected record and a “Show in the graph” button. Any node the pointer can reach can also be reached with Tab, and all of this works without WebGL. The canvas is hidden from screen readers. The keys (arrows, plus and minus, Esc, Home) are bound to the stage alone, and the “?” list names them. With reduced motion the settled layout is the first picture, with no camera flights.

The first CI run failed on one test. The layout ran three ticks per frame, and the runner draws WebGL in software, so a hundred slow frames did not fit into the test’s wait. They would not have fitted on a weak phone either. The layout now spends 6 ms of each frame and settles in the same time wherever it runs.

The lines of the axis, explained to the reader

Hatching, a dashed extent, a hollow mark, solid and dashed arcs, rings: the axis spoke in lines it explained nowhere. The 6-in-1 chose the combination the issue proposed. A hollow mark appears in the key beside the axis while records with no finer date are on screen. Every line, with a figure, is on the about page. The figures there are drawn with the same components as the axis, so the explanation cannot drift from what it explains.

On the way it turned out that the thematic arc, for “related” and “contrasts”, had been drawn solid all along. The draw-in animation left its own stroke behind after it had played. Such an arc now fades in instead of being drawn.

Then the 6-in-1 noticed that the tour said nothing about the lines, and it gained a step, “Lines on the axis”, which lights one arc itself. I first wrote that step’s text for touch screens wrong: that outside the tour a phone shows no arcs. The 6-in-1 checked on a phone: it does, from the tapped mark once you are back on the axis, because a tap puts focus on the mark. I had reasoned the claim from the event handlers rather than checked it on a device. The text is corrected.