Creative work typically requires tools, and the best tools provide immediate, high-fidelity feedback — the quicker you see the net result of your effort, the faster you learn from mistakes and advance your design. A tight feedback loop is valuable in even the most basic of creative tasks, e.g. writing prose with a word processor that underlines typos. At the lab, we’ve applied this principle to one of our latest experiments, a tool for publishing a neighborhood-focused email newsletter. As our newsletter editor, Kelly Brennan, drafts a new edition she sees a preview of the entire email that immediately reflects her changes.

Is a realtime preview of an email really necessary? After all, aren’t most emails just text with some interleaved images? Yes — and to that end, most newsletter editing tools offer simple WYSIWYG-style interfaces (“What You See Is What You Get”). Take Substack’s editor, for example:

This works well for simple inputs, like text and images. But there are plenty of resources relevant to your neighborhood — upcoming neighborhood meetings, for example — that take a lot of time to collect the data for, and attempt to present with polish using just a WYSIWYG editor. A design goal of our product is to ease the embedding of complex data by automating its collection and presentation for newsletter editors.

To achieve this our edition-editing UX is essentially a list of “modules,” each tailored to a specific resource. We have modules that embed weather forecasts, local news articles, upcoming neighborhood meetings and events, real estate listings, and so on. Each module is implemented as a pair of components: a form input in an “editing” panel on the left, and its corresponding styled HTML output in a “preview” panel on the right. Separating input and preview components and presenting them side-by-side frees us to use whatever form fields are most appropriate for the module’s data, for example multiple-choice inputs for selecting events from a public calendar:

The editing panel inputs are implemented in conventional frontend javascript, as is the entire admin CMS — we use React, but any well-supported library would work just as well.

Editors’ changes to a module’s inputs (keystrokes, selections, etc.) are immediately resolved to a simple module-specific data configuration, like so:

On every change the module’s config is immediately passed to the module’s corresponding preview component, which is a function that accepts the configuration and transforms it into email-ready HTML. The HTML returned by MJML is then presented in the edition’s preview panel on the right, which gives our newsletter editor fairly snappy feedback:

As with all of the Lab’s code, our neighborhood newsletter CMS is is open-source on Github — feel free to write us with questions.

---

The Lenfest Local Lab is a multidisciplinary product and user experience innovation team within The Philadelphia Inquirer. The Lab was founded within The Lenfest Institute for Journalism in 2018 before joining The Inquirer in 2021. The Lab remains supported by The Lenfest Institute, the Google News Initiative and additional funders.