Rebuilding without interrupting the exhibition

Black Wall Street Journey · shipped 2021–2026

Role: Platform Architect / Sole Engineer
Timeframe: During the V2 build, in the 2022 site engagement.
Technologies: Strapi
MongoDB Atlas
PostgreSQL
Skills: API design
Data modeling
Data migration

Stood V1 back up and left it executing for the duration of the V2 design, deriving the V2 themes from what the running material grouped into and sorting every slide against them, rather than working from a data dump or from notes

About the project

Black Wall Street Journey is Rick Lowe's public-history initiative on Black wealth-building in Chicago. I was the sole software engineer, from the first system in 2021 through the public site that followed. Two versions: a timed installation across three Chicago venues, and a public website built from the same research.

Timeframe: Software involvement: 2021–2026; primary commissioned engineering: 2021–2022

Overview

Designing the next model with the old one running

When I began adapting Black Wall Street Journey for the public website, I needed to decide how to organize the exhibition's research. The installation presented chapters and slides on a schedule. The website would let people choose a theme and read its stories at their own pace.

I had the original data and had built the installation software. I also brought V1 back up and kept it running while I designed V2. I wanted to check the material in the presentation it had been written and arranged for before deciding what the new model should retain.

What the export could tell me

V1 used Strapi v3 and MongoDB Atlas. Its chapters held ordered slide references, and each slide carried a duration. Presentation-specific slide types determined how text, images, statistics, and maps appeared. The frontend used those records to advance through the exhibition.

The export preserved the records, including ordering and timing values. I could inspect those fields and use them to reconstruct the sequence. What I could not judge as readily from a collection of documents was the experience of that sequence: a photograph held on screen, the passage before it, and what followed.

V2 used Strapi v4 and PostgreSQL. Its reading model had no slide-duration field to receive the old values. I needed to understand what a pause or grouping contributed before deciding how that material belonged on the website. Inspecting the data remained useful, but it did not replace watching the presentation.

Solution

Keeping the material available to inspect

I stood V1 back up against the retained Atlas dataset and left it available during the V2 design. That gave me a way to check a particular chapter instead of relying on my memory of the code or reconstructing its behavior each time.

An Oscar Micheaux slide in the preserved V1 player, with a portrait, quotation, biography, and marquee. — The preserved player shows how the research was arranged for the installation. It is not a recording of the V2 design period. Portrait credit: Homestead National Monument of America / National Park Service.

Reading through the original CMS material and watching it play helped me identify recurring subjects across chapters. Those subjects became the themes for V2. I then reviewed the slides against the themes, grouping related stories and leaving material out where it did not fit.

I was responsible for that recataloging and the new API and model. The research and curatorial material came from the contributors, Abigail Winograd, and Rick Lowe's studio. Keeping their presentation available helped me work from what they had made while changing how someone would encounter it.

Database export
Records, ordering and duration
are stored and available.
Playback is not observed.
Evidence informs the decision
Review and reassign the material
Decide which stories belong
together in the website.
Authored mapping
V2 thematic content model
Retain research and media.
Do not carry over playback duration.

The export already contains order and duration. Running V1 adds the ability to watch those values produce an experience while designing V2. It does not automate the editorial mapping.

Giving the themes a different structure

The old system was a reference I could inspect, but it could also pull the new design toward a familiar shape. I had to keep asking whether a relationship belonged to the research or to the installation's playback.

The website still needed an order for browsing themes. It did not need a timed progression through slides. Related stories could appear together inside a reading panel, where the user decided how long to spend with them. That distinction guided the new model more usefully than reproducing V1's timeline.

The V2 Retail reading panel groups business stories and quotations under a single theme. — Retail shows the grouped reading format, including map controls added later. It illustrates the destination structure; the stories shown here are not a matched before-and-after set with the Oscar Micheaux slide above.

An exhibition at the user's pace explains the reading interaction. Keeping V1 available supported the earlier work of deciding what that interaction would contain.

Reflection

What a running reference added to the export

Maintaining two environments took time on a contract with an end date. Working from the export would have avoided some setup, and documentation could have answered structural questions. I accepted the additional work because I needed to examine particular chapters while making decisions about their content.

The running system did not make those decisions for me. I still had to interpret the material, choose the themes, and check that I was not carrying the installation's timing into a website that no longer needed it.

This approach also depended on being able to start V1 again. Retaining a database and repository helped, but the old runtime and its dependencies were part of that access. The preserved system is easier to examine now; it does not establish exactly what I saw during the original design work.