Backend live preview

Feb 16, 2018

Structured content is central to the content strategy for our new Drupal-based Mass.gov. So is the idea of a platform-agnostic design that can be reused across our diverse ecosystem of web applications, to encourage a consistent look, feel, and user experience. We’re not the only ones with these priorities for our new digital platform. So we can’t be the only ones wrestling with the unsolved authoring experience implications either. This blog post is an attempt to articulate the basic problem and share our best, latest idea for one possible solution. As the saying goes, ‘If you want to go fast, go alone. If you want to go far, go together.’ We want to go far. If you like our idea, or if you have other possible solutions or insights, please share them with us in comments below, or by tweeting at us @massgov, or contact me at @bryanhirsch. Let’s go together.

Problems:

Drupal has made major strides toward improving the content authoring experience in recent years: Acquia’s Spark project in Drupal 7, Quick Edit in Drupal 8, and Edward Faulkner’s integrations with Ember. But (1) our vendors for Mass.gov have unanimously dissuaded us from leveraging these innovations in our new authoring experience because with complex data models it’s costly and highly customized to make in-place editing through the front end work. (2) This challenge is compounded by the desire to keep our design portable across diverse web properties, which means we want to keep Drupal’s Quick Edit markup out of our Pattern Lab-based component library. Additionally, (3) if we get structured content right, our Mass.gov content will be reused in applications we don’t control (like Google’s knowledge graph) and in an increasing number of government website via APIs. It’s both cost prohibitive and practically impossible to create frontend authoring UIs for each of these applications. That said, if we move authoring away from the front end in-place editing experience, (4) authors still need detailed context to visualize how different pieces of content will be used to write good content.

Here’s one possible solution we’re interested to explore that seems like it should address the four issues outlined above: Move high-fidelity live previews to the backend authoring experience, displayed alongside the content editing form as visualized in the designs below.

By showing authors examples of how different pieces of content might be used and reused, we can give writers enough context to write meaningful structured content. But maybe we only need to give authors enough examples to have reasonable interactions with all the different content form fields. If this works, then we don’t have to try and keep up with an infinitely growing and changing landscape of possible new frontends. Pattern Kit (here) and Netlify CMS (here) both offer working, open-source, examples of how this authoring experience could work.

Mass.gov is not a “decoupled Drupal” ecosystem yet. Our API strategy is in its infancy. We know other people with much more experience are thinking about the same issues. Maybe some are even writing code and actively working to develop solutions. If this is you, we’d love to hear from you, to know how you’re approaching these problems, and to learn from anything you’ve tried here.