Letting type move

16 June 2026

5 min

We treat type as something that sits still — fixed in place, headings always the biggest thing, motion bolted on at the end. For one Creative Spark we dropped those rules and asked what type could do once it started moving.

Creative Spark is our in-house R&D session: ninety minutes, a single theme, and a room full of people building prototypes with no client to please and nothing due at the end. This time the theme was type in motion. We wanted type to feel less like a fixed shape that carries information one way and more like a material with some give in it. But the afternoon turned out to be about something bigger than typography: how cheap and fast exploring an idea has become, and what that does to the way a studio spends its time.

What we questioned

A few of our assumptions went early. Weight can change mid-word. A heading needn’t be the biggest thing on the page. Motion has to do a job rather than decorate, without sliding back into the hyperactive web of 2002. Most of these aren’t rules anyone chose on purpose; they’re hangovers from how web type is built, all CSS axes and classes, and that machinery sands the creativity out of it. The tooling has moved on, though. The new AI font editors make a bespoke cut of a typeface cheap enough to try on a whim, so the cost of asking “what if the type did this?” has more or less collapsed.

Whiteboard reading "Type in Motion — challenge these assumptions", ringed with notes on fixed shape, one-way communication and scale as hierarchy The framing board: every assumption about type we wanted to push on.

What we made

Six prototypes came out of it, all over the map. One was a 3D dial you turn instead of scrolling a list. Another tied typography to scroll speed, so the text frays the faster you go. A few used the camera, with hand and face tracking that shoves the letters around — very Minority Report. There were soft-body letters that behave like balloons, bouncing on gravity and anti-gravity. Someone rebuilt the dial from scratch in plain JavaScript and CSS in about ten minutes, from a JSON spec and a reference URL, just to see how close standard web tech could get. None of them were precious, and that was the idea: enough range, fast enough, that binning most of it still leaves you ahead.

Green jittery type on a pink field reading "the web has genuine capabilities for type that almost nobody is using", with radius, jitter and strength sliders Typography wired to scroll speed: the faster you go, the more it frays.

The dial rebuilt in plain JS and CSS: a radial nav that drifts with scroll momentum.

What we took away

The making turned out to be the cheap part. We settled on a cheap, fast model to churn out the bulk and a slower, pricier one to tidy up after it; the whole multi-model run came to about £1.40. For the price of a coffee we had a spread of directions that would normally take days to work up. When making the thing is nearly free, the hard part isn’t the making any more — it’s knowing which of the six is worth pursuing, and why.

A couple of things caught us out. You can do proper hand and camera tracking in the browser now with no extra software, which none of us knew. And the move off loose “vibe coding” onto structured prompts and JSON build specs mattered more than any clever wording. The boundaries kept the models from wandering and handed back code we could actually use.

A particle-dust rendering of the word "MAGIC" with a "hand detected" badge, driven by webcam hand-tracking “Magic”, revealed by hand-tracking through the webcam — no plugins, just the browser.

The speed stuck with me most. We started with a vague theme and, ninety minutes later, had a handful of working, clickable prototypes. That’s the kind of session I’d put a client in the room for: not to show them finished work, but to let them watch an idea become six things they can click before lunch.

A four-panel grid of more prototypes from the session: glowing "type is alive" variable-font text, a radial 3D navigation dial, a split-flap departures board, and ghosted type set over a landscape photo A few more from the room: a variable-font study, the 3D dial, a split-flap departures board, and type set into a landscape.

Magic and logic

There’s a split underneath all of this. The balloon letters showed it. Motion looks right when it obeys physics — mass, gravity, the way a soft body overshoots and settles. That’s the logic. A model holds it without effort: the easing curves, the equations, the maths of how things move. You can hand all of that over. None of it has to live in your head.

What’s left is the magic, and the magic is taste. Should the letter bounce at all? Is this the moment for it? A model can make motion look natural. It can’t tell you it’s good. I don’t think that part can be written down. Make a list of everything we like and it’s out of date before you finish. Taste keeps moving. That’s the part no model took off us.

These models are really just a store of human memory. Fallible, unpredictable, sometimes astonishing. But it’s more personal than that. What comes back is shaped by you — your words, your tone, the way you ask. No two conversations are the same.

We hand over the logic and keep the magic. Maybe that’s what these tools are really for: they show us what’s human in us. Not a record of where we’ve been. The taste for where to go next.

Putting video back where it belongs

Andy Purbrick

Field Notes

11 June 2026

4 min

The problem with putting video in a git repo

The repo kept getting heavier, sprint after sprint. We were committing big MP4s next to the code, builds were slowing down, and deploys with them. Case studies lead with video, so every new client made it worse. We needed the media to live somewhere else, and to turn up in a size that suited whatever screen it landed on.

But where? The CMS was out: most aren’t built for video, so the first byte takes too long and the bandwidth bills mount up. The repo was out too, and we knew the downsides first-hand: files the content team can’t touch without a commit, and a history that keeps growing. A proper video CDN would handle the delivery, but they’re a pain to set up and never really talk to the CMS. That’s the awkward thing about web video: there’s nowhere good to put it.

The authoring side

Writing a case study, you drop a short asset ID into the MDX, something like ![hero](eA1XzRaWsAB), and the pipeline takes it from there. No encoding flags to remember, no breakpoints to define, and nobody exporting poster frames by hand.

📷 Split-screen: the short MDX asset ID on the top, the rendered html on the bottom showing six responsive sources One ID in the markdown, six responsive sources on the page.

The point of all this is that the asset ID is the stable interface. Everything behind it was free to evolve, and it did, without a single case study needing an edit.

Under the hood

The video component looks at what it’s been handed and decides how to deliver it. A short asset ID turns into fully responsive video, several formats and breakpoints. A streaming URL goes to adaptive bitrate. A plain file just plays. None of that is the author’s call. The component works it out from whatever it’s given.

The same principle for images

Images work the same way. Five layout presets, each with its own responsive widths and loading behaviour, and AVIF output by default, built at compile time. You pick the layout you want, and the component sorts out the format, the sizes and how it loads.

The infrastructure underneath

It started small: the Air.inc API wired up so assets could be referenced by a short ID, first just in Labs. From there it grew. Full Air.inc integration, then HLS streaming, then that same delivery across every case study. Next came mobile, with streaming that adapts to the device it’s playing on. The last move put SpeedyClip into the delivery layer.

Through all of it, the people writing case studies carried on exactly as before, same markdown, while the rendering quietly improved at every step.

Air is still the asset library and source of truth. The team manages the files, versions and metadata there; the site references those assets by stable IDs. SpeedyClip takes over at the delivery point, turning the Air source into the responsive streams we serve on the site.

That means SpeedyClip handles every video embed on the site without replacing Air in the workflow. It serves optimised streams off the same kind of global edge network the big streaming services run on, the sort of setup you’d normally have to stitch together yourself on every project. All of it is built around load speed and time-to-first-byte. The clever part is how it starts. It streams over HLS, but the opening segment is only two or three seconds long, so the video starts playing almost as soon as the poster appears, instead of waiting for a bigger file to land. Not many people bother going that far.

There’s a lot more to say about SpeedyClip, what it actually is and why a studio ends up this deep in video delivery. That’s a post of its own.

On the visitor’s end

A poster image holds the layout while the video loads, so nothing jumps around as it arrives. The video fades in instead of popping into place. On a slow connection the smaller breakpoint files turn up faster than one big high-res file would, so even on patchy mobile the page stays together.

The poster holds the space, the video fades in over it, and there’s no jump or empty box while it loads.

Twenty-eight case studies now open with video that doesn’t shift the layout, doesn’t drag a history of MP4s behind it, and adapts to whatever connection it loads on. None of which changed how a single case study gets written.