A guided tour of the ITP 30 show's technical infrastructure

Most visitors to the ITP 30 Show see a calm grid of projects, an elegant journal, and a few RSVP links. Underneath is a deliberately lean infrastructure shaped by the same experimental spirit that drives the work on display.

The site is read by curious audiences worldwide, including a steady stream of visitors from Sydney and Melbourne who tune in after hours. For them, the back end is the difference between a smooth experience and a frustrating one.

The show runs as a small, mostly static web project with a handful of dynamic services bolted on. That hybrid shape is the result of tradeoffs between cost, contributor access, archival longevity, and streaming from a New York gallery to any browser.

A static-first front end with just enough dynamism

The public pages are generated ahead of time and served as flat files, which keeps load times low on the patchy NBN connections still common in regional Australia. Project descriptions and event dates are written in Markdown and committed to a repository, so a contributor can ship a new entry without touching a database.

Static generation also keeps the show resilient under traffic spikes. When a journal piece gets shared on Australian social feeds or in a Monash University newsletter, the origin does not buckle. Anything truly interactive is wired in separately, and that is where a small layer of server-side endpoints quietly does its work.

Media delivery for videos and illustrated catalogs

Each project ships with visual documentation, often shot on the NYU Brooklyn floor. Clips are transcoded into adaptive bitrate variants and streamed through an HLS pipeline, so a viewer on flaky hotel Wi-Fi in Surry Hills gets the same experience as someone on a fibre-to-the-premises link in Perth.

Subtitles and transcripts live in the metadata layer rather than inside the video file, which makes the show friendlier for screen readers. Illustrated catalogs are exported as lightweight PDFs and inline carousels, and keeping that layer separate means a single broken embed will not take down a project page.

Project metadata and the editorial pipeline

Every project carries structured fields: title, contributors, year, category, hardware list, and code repository. Those fields live in a small managed database that the static site generator queries at build time, so editors work through a friendly form while the public site reads only the compiled output.

This split keeps the editorial workflow forgiving for non-technical contributors. A student can log in, fill in fields about their Arduino build or their weather-based experience, and walk away knowing the front page will be regenerated within the hour.

RSVPs, ticketing, and the live event layer

The show is part exhibition and part social event, and the RSVP flow reflects that. A lightweight serverless endpoint accepts sign-ups, deduplicates submissions, and writes them into a managed table, then computes remaining capacity on the fly and pushes it back to the page.

For a community spread across many time zones, including AEST and AEDT watchers in Australia, that flow has to feel instant. Serverless functions keep cold starts short, and a small queue handles the rush when invitations go out.

The journal and participatory data work

Some of the most technically interesting pieces are the journal entries themselves. The journal writeup documents how visitor input is collected, anonymised, and folded into a live rendering, with small JavaScript snippets posting anonymous interactions to an endpoint and the results written back to a public dataset anyone can fork.

The architecture treats each visitor as a temporary co-author of the piece rather than a passive viewer. The implementation stays well within Australia's Privacy Act thresholds, and the team is deliberate about not collecting more than the work actually needs.

The digital archive and long-term preservation

Past editions live in a dedicated project archive, intentionally separated from the live site. Older pages, assets, and project files are frozen in their original form so a 2024 viewer in Adelaide can still see the show as it was, not a redesigned rewrite.

That separation matters because university gallery sites are often reshuffled within a few academic years. Treating the archive as a read-only sister site gives the work a much longer half-life than the live presentation alone could promise.

Performance, accessibility, and reach

The front-end stack is deliberately small: a few hundred kilobytes of JavaScript, system fonts as a fallback, and a single style sheet. That restraint lets the show load quickly on older laptops, Chromebooks handed out by Australian schools, and underpowered devices still in circulation across the country.

Accessibility audits run before each launch. Colour contrast is checked against WCAG thresholds, keyboard navigation is tested by hand, and captions are mandatory for any project that includes speech. None of this is glamorous, but it is the difference between a showcase that welcomes everyone and one that quietly excludes part of its audience.

Practical notes for anyone rebuilding something similar

• Treat the public site as immutable output. Generate it from data, never hand-edit HTML in production.
• Put video, transcripts, and catalogs in separate layers so a single failure does not cascade.
• For participatory pieces, anonymise at the edge and document the schema you are collecting.
• Keep an offline archive copy of every edition, frozen and addressable on its own URL.
• Audit accessibility before launch, not after, and treat captions as part of the deliverable.
• Lean on a CDN for the public surface and reserve the dynamic layer for RSVPs and live data.
• Pick a content format contributors can actually edit, even if they are not engineers.

The next show goes live soon, and the team is looking for feedback, contributors, and curious attendees. RSVP early, dig into the journal, and explore the archive to see how earlier editions were wired together. If you want to build something similar, the archive is the most honest place to start, and the maintainers welcome pull requests from anyone willing to learn in public.