Black Wall Street Journey

Black Wall Street Journey was an interdisciplinary public-history initiative exploring the history and legacy of Black wealth through public art, research, and community engagement. Its digital presence needed to do more than document an exhibition: it had to organize evolving scholarship and turn it into public experiences.

Rick Lowe’s studio led the initiative alongside an exhibition curator, researchers, University of Chicago partners, and a data scientist. Together, they contributed the historical, curatorial, and geographic material behind the experience.

I was hired directly by Rick Lowe and served as the sole software engineer. My responsibility was to translate those contributions into working software without a conventional product team or predefined technical specification.

I designed the information architecture and Strapi content models, built the editorial CMS and public-facing applications, and integrated the geospatial data. The original exhibition slideshow included a ticker presenting quotes and statistics about Black wealth and the Black Wall Street Journey. I later redesigned that experience for a mobile-friendly public website.

The result was a set of connected publishing experiences built from the same body of research. The original system supported the collaborative exhibition workflow; the later redesign adapted that material to a new public context.

I was initially hired to build a website and an exhibition application, but neither arrived with a conventional software brief. There was no product team, backlog, or settled specification. Instead, the project took shape through meetings, documents, research, designs, informal conversations, and geospatial datasets. Each collaborator understood a different part of the work, but those needs had not yet been expressed as a software system.

Rick Lowe’s studio carried the artistic vision for the initiative. The curator shaped how the work would be encountered and interpreted. Researchers supplied historical narratives and archival context. A University of Chicago liaison helped connect the project’s institutional and academic work, while a data scientist provided the neighborhood boundaries and points of interest that would anchor its geographic dimension.

My first engineering task was to understand what each discipline needed, find the requirements connecting them, and decide which concerns belonged in the content system rather than a specific interface.

Several requirements emerged. Researchers and curatorial collaborators needed to enter and revise material without routing every change through a code deployment. Historical narratives needed relationships among entries, sources, media, and geography rather than being flattened into static pages. GeoJSON needed to work with the editorial material instead of appearing as an isolated visualization. The exhibition also needed explicit sequencing and timing.

Together, these needs pointed beyond standalone interfaces. The original project required a structured editorial system that collaborators could maintain and the exhibition frontend could execute.

A later request introduced the project’s only new constraint: adapt the exhibition slideshow and its ticker into a mobile-friendly website experience. The first schema had successfully served a timed, directed installation, but its presentation-specific records were not flexible enough to carry forward unchanged. I reused its themes and source material while independently redesigning the ERD and API, then manually recataloged the research in a separately built Strapi v4 system.

Each generation therefore needed a clear model of the project’s knowledge: the concepts that should become content types, the relationships and order that had to be preserved, and the editorial controls its context required.

It also established an important boundary between disciplines. My role was not to author the scholarship, define the curatorial vision, or produce the GeoJSON. My role was to design the product and technical structures through which those contributions could work together—without reducing one discipline’s material to the assumptions of another.

The resulting requirements centered on editorial ownership, relational content, integrated geospatial data, explicit exhibition behavior, and room for the research to change. They became the basis for the information architecture and content models that followed.

The material behind Black Wall Street Journey did not arrive as application-ready records or a stable API contract. It arrived as historical research, prose, archival context, curatorial priorities, designs, media, and geographic files. Each form carried meaning within its discipline, but none prescribed its representation in software.

I had to turn that domain knowledge into information that could be entered, related, revised, and retrieved.

The central challenge was distinguishing the research from its presentation. A narrative needed to retain meaning when placed in an ordered exhibition chapter. Neighborhood boundaries and points of interest were part of how visitors understood the history, not decorative layers. Media, sources, and timing also needed explicit roles rather than being buried inside page copy.

I identified the concepts the software needed to preserve—narratives, chapters, media, geography, order, and duration—then determined where an interface required a more specific structure. The resulting model had to remain recognizable to collaborators in the CMS while giving the frontend explicit behavior.

In V1, direct collaborator use made that vocabulary operational. The content model shaped how researchers and curatorial collaborators grouped, entered, and revised material—not only what the application could query. A clear concept could be maintained without translating every revision through code; an ambiguous one would create confusion in the CMS and compensating frontend logic.

The supplied GeoJSON introduced a parallel concern. Its points of interest and neighborhood boundaries were already structured, but their format alone did not make them part of the product. I integrated those features into the application’s behavior and presentation so geographic context could work alongside the editorial narrative.

The work transformed interdisciplinary material into explicit software inputs without treating every input the same. Research remained editable content, timing became application behavior, and GeoJSON became geographic context. The next question was architectural: which concepts should become first-class content types, which relationships the systems needed to preserve, and where flexibility should live.

Once the project’s goals had been translated into product requirements, the next challenge was deciding how its knowledge should be organized. The system needed more than a collection of finished pages. It had to represent historical narratives, support exhibition sequences, connect material to place, and remain understandable to the collaborators maintaining it.

I treated the research itself as the source of the architecture. Rather than allowing a screen to dictate the model, I looked for concepts that remained meaningful across presentation contexts. This changed the central question from “What belongs on this page?” to “What is this material, and how does it relate to the rest of the project?” The answer evolved through implementation as new material and presentation requirements exposed where the model needed more flexibility.

That distinction became especially important when material cataloged for a directed, timed exhibition needed to support a mobile-friendly website and ticker. The new context exposed where the first model’s screen-specific structures could not simply be carried forward.

The new architecture had to preserve the research while changing how it could be used. Sequenced material still needed an explicit order without remaining inseparable from an exhibition slide. Media and geographic context needed to stay connected to the narratives they supported. The challenge was to distinguish enduring concepts from structures that belonged to one interface.

This was also an editorial design problem. In V1, researchers and curatorial collaborators worked directly in Strapi, so collection names, fields, relationships, and grouping choices had to communicate the project’s logic. The architecture served two audiences at once: editors deciding where knowledge belonged and applications deciding how to retrieve it.

These principles established the foundation for the revised Strapi schema. The next step was turning them into concrete collections, fields, and relationships.

The information architecture became concrete in Strapi. The first schema was designed around the immediate needs of the exhibition: a Timeline assembled Chapters; chapters grouped ordered Slides; and each slide selected from a dynamic zone of presentation-specific formats, including biographies, map flyovers, stories with maps, and video. The frontend used each slide's duration to determine how long it remained onscreen before advancing. In the backend, those slide durations accumulated into the chapter's total duration, making pacing both executable by the application and legible in the CMS.

That model also contained reusable domain concepts. Neighborhoods stored names and coordinates and could be associated with both chapters and slides. Contributors, Programs, and Sponsors existed independently of the exhibition sequence. A separate ticker single type accepted quote and statistic components, while the public-site and application home screens each had their own single type. The schema therefore combined two kinds of structure: enduring project entities and models shaped by a particular interface.

Encoding slide types made the exhibition predictable to render and gave editors a bounded set of layouts. Explicit steps and durations made sequencing legible in the CMS and controlled playback in the frontend. The tradeoff was coupling: a component named for a visual arrangement described both the research it contained and how one application should display it.

For the later mobile-friendly website and ticker, I redesigned the ERD and API around a more modular publishing vocabulary. A general Page collection introduced a slug, SEO data, and a dynamic zone of reusable blocks. Programs used blocks for descriptions, events, headings, heroes, links, reading lists, galleries, images, and video. Site-wide navigation and footer content moved into a Global single type, while program, contributor, and ticker pages received focused configuration.

Chapters remained first-class entries, but their content became a dynamic sequence of media and ticker components rather than relations to a separate Slide collection. A chapter could contain images, video, headlines, quotations, statistics, or title-and-text entries, with a color field providing presentation context. Block-level links opened citation or source information in a new tab. Alongside location data, they added annotations and geographic context without a separate citation entity.

The redesign did not produce a perfectly normalized database; it shifted where flexibility lived. V1 gave the exhibition strongly shaped records that matched its screens. V2 gave the website and ticker reusable content primitives that the frontend could assemble in context. The comparison shows the product learning between them: presentation-specific records made the first experience reliable, while modular blocks made the research more adaptable.

A content model only becomes useful when people can work through it. In V1, researchers and curatorial collaborators entered and revised material directly in Strapi. The CMS therefore had to guide editorial decisions without requiring them to understand the frontend code.

Editors organized the exhibition through timelines, chapters, and ordered slides. For each slide, they selected a presentation format, attached narrative, media, and geographic material, and set its duration. Slide order determined the visitor sequence, while duration values drove the frontend intervals. The CMS made structure and pacing editable without embedding either in application code.

That specificity made the exhibition straightforward to compose, but it offered less freedom when the material needed to appear elsewhere. The request for a mobile-friendly website and ticker forced a choice: keep pushing the research through exhibition-shaped records or redesign the system around the new use.

I chose to redesign it. Using the themes and research cataloged in V1, I manually rebuilt the catalog in Strapi v4 and selectively reused material that still fit. The new editorial vocabulary separated the meaning and order of the material from the screen that first presented it.

This moved more presentation responsibility to the frontend. A chapter could remain a coherent narrative unit without reproducing the exhibition screen that originally shaped it. The schema still provided guardrails, but no longer treated the V1 slide layout as the research’s only valid expression.

Direct researcher and curator editing belonged primarily to V1; V2 was my reconstruction of that material for the later requirement. I preserved the research and themes that mattered, discarded constraints tied to the first interface, and created a more reusable structure.

V1 made the CMS a collaborator-facing working environment. V2 demonstrated a different kind of product judgment: learning from that system and reconstructing its material for a new context. The research and themes came from the original project. The redesigned ERD and API, the Strapi v4 implementation, and the manual recataloging that made the material work in a new context were mine.

The exhibition application had to play a curatorial sequence without manual control: introduce a chapter, move through its slides at the intended pace, render several kinds of media, and advance to the next chapter.

I built that behavior as two coordinated levels of progression. At the chapter level, the application selected the current chapter and used its cumulative duration to determine when the next one should begin. Within that chapter, a second timer read the current slide's duration and advanced the slide index when the interval elapsed. Redux held the active chapter and slide steps so the interface, content, and playback state remained synchronized.

This turned Strapi's timing fields into playback behavior. Changing a slide's duration changed how long it remained onscreen, while each chapter's total duration determined when the next chapter began.

A dispatcher mapped each slide record to its React component: a biography with a quotation and image, video, credits, or a map. Each format owned its visual behavior while participating in the same playback system.

Geography was one of those fixed exhibition formats. When a chapter needed to show a location or neighborhood, a dedicated map slide rendered the project's GeoJSON points of interest and neighborhood boundaries. The data was not separate from the narrative; it appeared within the same timed sequence as text and media. The tradeoff was that every geographic story passed through one predetermined map presentation—an appropriate constraint for the installation, but one the later website would revisit.

Outside the slide sequence, a stock-market-style ticker tape remained visible across the top of the page. It continuously displayed quotations and statistics about Black wealth and the Black Wall Street Journey while the chapters advanced beneath it. The ticker was a persistent layer of the installed experience, not a slide type or standalone application; I later redesigned the idea for the public website.

The system was deliberately built around a finite set of formats. Coordinating interval-driven state at chapter boundaries introduced complexity, but the tradeoff suited an installation that prioritized reliable, directed playback over open-ended composition.

The public website changed the project from a directed installation into something people could explore on their own devices. It needed to make the research navigable outside the exhibition, support smaller screens, and let editorial structure determine the page without reproducing the slideshow's fixed sequence.

I built the V2 site around a catch-all Next.js route that resolved a requested slug, fetched the matching page from Strapi on the server, and passed its ordered blocks into the interface. Programs and contributors kept focused routes of their own, while global navigation and footer content came from shared CMS settings. This separated route responsibilities without hardcoding the site's editorial hierarchy into the frontend.

A BlockManager translated Strapi's component identifiers into React components for headings, text, headers, events, video, reading lists, links, and galleries. The pattern resembled the exhibition's slide dispatcher, but the responsibility had changed. Exhibition renderers filled a timed slot; website blocks composed responsive pages whose length and order could vary with the material.

The website reused the same supplied GeoJSON points of interest and neighborhood boundaries as the exhibition, but redesigned their presentation for a public, self-directed context. A reusable map block was planned so editors could place geography alongside research, media, programs, and contributors; that work was not completed before my contract ended.

Responsive behavior extended beyond rearranging content blocks. The site included a full-screen mobile navigation treatment and layouts that adapted galleries, reading lists, links, and other editorial modules to narrower viewports. Server-side page resolution also gave each CMS-authored slug a direct public URL rather than burying the material inside application state.

The result was responsive public access to the research: CMS-authored pages could change without recasting the frontend’s route structure, while the site left room for future editorial modules.

The exhibition’s ticker was designed as a continuous ambient layer: a persistent marquee across the top of the screen, carrying Black-wealth quotes and statistics while the timed slideshow advanced beneath it. Its implementation reflected that fixed presentation role. It read ticker items from the application state, moved them through a marquee at a constant speed, and alternated the visual treatment as the exhibition played.

For the mobile-friendly website, I rebuilt the ticker as a public-facing editorial experience rather than carrying the exhibition marquee forward unchanged. The goal was to preserve its core function—putting Black wealth, place, and historical context into active circulation—while giving visitors a format they could read at their own pace.

The V2 CMS model supported that shift. A dedicated ticker-page configuration supplied the page-level frame, including its logo, return link, credits, and calls to action. Within each ticker chapter, editors could sequence several content types: quotes with attribution; statistics with an optional link; headlines with article links; and titled text entries with one or more locations. Images and video could appear in the same ordered chapter content.

That structure turned what had been a single, always-moving interface element into an extensible editorial surface. The ticker could still be visually distinct from the rest of the site, but its content was no longer constrained to one repeating line or one presentation rhythm. Research could be expanded with source links, fuller context, related media, and geographically specific entries—without requiring a code change for each new piece of material.

The rebuild carried a successful exhibition device into the web experience without treating the website as a smaller exhibition.