Coupled content to presentation, then deliberately uncoupled it

The installation followed a timeline of chapters and slides. Each slide had its own duration, and the playback code accumulated those durations to coordinate progression. The persistent ticker ran across the top of the presentation. Map-based formats could use geographic data alongside the stories.

I kept duration with the slide because pacing was something collaborators needed to author. How long a photograph remained visible affected the experience of the exhibition. Putting that value in application configuration would have made a routine editorial adjustment dependent on a code change.

This tied the model closely to its presentation. That was useful for the installation: the player consumed a structure built for a timed sequence, and collaborators could work on the content and its pacing in the same system. It also meant I would need to reconsider the structure if the experience changed.

For the public website, I redesigned the ERD and API in Strapi v4 on PostgreSQL. Chapters grouped material by theme, and their content used components for text, quotations, statistics, images, and video. General pages had their own blocks, while global content held shared site elements.

The thematic chapters did not need a duration. Their content could be read together and revisited independently of the installation's sequence. I retained presentation choices where they were useful, including component types and chapter color; the new model was not completely independent of the website.

The database change required technical work, but it did not decide where an old slide belonged in the new model. A script could move records and preserve their fields. It could not make the editorial choice about which stories should be read together without an authored mapping.

I reviewed the material against the running installation and reassigned it into thematic chapters. That was more work than preserving the old hierarchy, but it let the organization follow the website's purpose. I describe that process in Rebuilding without interrupting the exhibition.

Extending V1 was a reasonable way to preserve the existing presentation. Moving from its MongoDB stack to the chosen PostgreSQL stack also required conversion. Neither constraint made a redesign automatic; I chose it because retaining the timed hierarchy would leave the website organized around a playback job it no longer needed to perform.