Designing the Strapi schema as the editorial interface

Researchers, curators, and Rick Lowe's studio supplied Black Wall Street Journey's material. I was the sole software engineer. If every correction had to pass through me before reaching the exhibition, content work would compete with building and maintaining the application.

I designed the Strapi model for collaborators to use directly. That made the generated admin part of the product I was responsible for: field names, relationships, and the placement of content affected how someone entered and revised their work.

Strapi generated much of the editing interface from the schema. A field's name became a label, its type determined the input, and its relationship to another record influenced where someone had to go to edit it. I had to consider those consequences while choosing the data structure.

A separate collection record could be useful when an item needed its own identity or reuse. An embedded component let someone edit material inside its parent. Neither arrangement was inherently easier in every case. I needed to decide which work belonged together on a screen and which material should be managed separately.

V1 used both. Chapters related to slide records; each slide contained its selected presentation component and duration fields. The schema did not put all of a chapter's slide editing inline. It gave the installation a hierarchy while keeping the details of each slide together.

Collaborators entered and edited content directly in V1. That gave the people responsible for the material a way to revise it without making every change an implementation task. They could still need help, and I remained responsible for the model and application.

I did not measure turnaround time. The benefit I was designing for was access to the work: collaborators could manage the content and its pacing in the system that supplied the exhibition.

An engineer-mediated process could have offered a familiar document-writing environment and centralized review. I chose direct CMS work because the people responsible for the material needed access to its presentation and pacing. That choice moved responsibility into the editing structure I built.

The schema became something people worked through. That changed the cost of maintenance: a field rename could require an explanation, and moving content into a related record could alter an editor's routine even if the API remained correct.

I had to account for that alongside the usual technical reasons to reorganize a model. A cleaner relationship in code would not automatically justify asking collaborators to learn another path through the admin.

The lasting constraint was that I owned the interface without owning the material. I could structure how it entered the system and how the application consumed it, while leaving the research and curatorial decisions with the people responsible for them. The preserved models document that structure; my recollection supplies the account of how we worked with it.