CMS for SPAs (2 of 4): Save the Content Authors

In Part 1 of the series CMS for SPAs: Are Single Page Applications and Headless CMS a Slam Dunk?  we looked at the trend toward Single Page Applications (SPA) and Headless Content Management Systems (CMS) in general. SPA applications are becoming the de facto way to build web-based applications and sites. Headless CMS is a decoupled, API-first approach to content management that aligns neatly with SPA architecture. Further, the decoupled nature of the architecture makes content more reusable (multi-channel) and completely divorces development from the CMS allowing for greater freedom and agility for developers. While these can be seen as major wins, several developer and DevOps issues remain while others have been created. Further, most of the headless CMS solutions available today set content authors back nearly 20 years in terms of content editing and workflow tooling and practices.

In this installment, we’ll focus on the various ways content authors have been impacted by headless CMS and how CrafterCMS addresses these issues to provide authors with true headless CMS support for SPA applications.

Authors Forced into the Wayback Machine

Clumsy tools and processes for editing, reviewing and testing content offered by headless CMS platforms have content authors, the primary stakeholder of CMS platforms, wondering if they fell asleep and woke up back in the early 2000’s. Let’s take a look at some of the issues facing authors in the Headless CMS space.

Preview and In-Context Editing

Authors are accustomed to easy-to-use tools that enable them to visually locate, edit and publish content in websites or applications. Many headless CMS platforms provide no way for authors to preview their work prior to publishing it. Authors are forced to change content via content entry forms that are completely disconnected from the presentation.  In order to see what the content will look like on the website or in the application, they must publish the content. No author should be forced to work with slow and clumsy deployment iterations just to ensure their content fits and looks good on destination channels. That’s a major step backward.

Some CMS vendors and practitioners argue that by completely obscuring the presentation from the authors, content gets created in a fashion that is naturally more reusable. That’s not necessarily accurate. Content is more reusable when stored and transmitted in a fashion that is divorced from presentation — but that does not mean authors should be forced to ignore how their content will be presented on key channels. As the saying goes: “the medium is the message.” To most authors, the layout is just as important as the content itself. Authors need tools in their headless CMS that are on the level of the tooling they have become accustomed to with more traditional CMS platforms.

DELIVERING EDITING AND PREVIEW TOOLS FOR SPAS

CrafterCMS gives authors a full, interactive in-context preview and editing experience within SPAs. Authors have exactly the same tooling they have become accustomed to with traditional CMS.

Crafter’s preview capability can sit in front of any web-based application. The specific technology does not matter. Crafter’s preview and editing tools are front-end agnostic. One of the key reasons Crafter is able to do this is that CrafterCMS has always separated authoring and delivery into distinct but integrated components. We’ve been assuming a decoupled architecture for years.

Authors are the main users of any CMS and their needs must be properly addressed. A solid authoring experience with true in-context editing and preview is table-stakes for any headless CMS.

Personalization of Headless / API based Content

Another area that Headless CMS platforms have impacted authors is support for targeted/personalized content. Content authors need to be in control of the rules that drive the right content to the right people at the right place and time.

To support personalization your headless CMS must support the following two capabilities:

  • The ability to design, configure or code business rules behind the services.
  • The ability to preview content and functionality driven by personalization rules prior to publishing.

To date, most headless CMS platforms are simple repositories of content that are retrievable by API call. These systems offer no ability to create rules that can be executed based on the request parameter variations and characteristics of the requester.

Further, based on the previous section, we already know that most Headless CMS platforms don’t support pre-publishing preview of content — let alone the ability to preview content and experience as it would appear in different scenarios. There is little point in writing rules or variations of content without the means to properly test them prior to publishing.

DELIVERING PERSONALIZATION FOR SPAS

CrafterCMS provides excellent support for targeted and personalized content even when content is delivered in a headless environment. Authors can configure scenarios and simple rules via the UI or leverage sophisticated rules built-in scripting languages by the development staff. Further, CrafterCMS provides rich preview tools that allow authors to impersonate different users and other types of content consumers within the authoring tools so that content and scenarios can be properly tested well before they are published.

The Need for Real Versioning and Branching

Most CMS platforms (traditional and headless) support some kind of basic versioning.  For the most part that support extends only to a single content item. Each item has its own history.  There is no way to look at the entire content collection at it existed at a specific point in time. That can be a major challenge for authors if they need to reference a previous campaign or support an audit.  The ability to maintain a version history is paramount and rudimentary versioning is typically not enough.

Another key feature that is missing from CMS platforms is the ability to support branches.  Branches allow us to work on different variants of the content at the same time. A branch not only allows concurrent work but it also enables us to sync up variants when it’s appropriate.  This extraordinarily important to authors who are supporting a re-branding or a major content overhaul. Most CMS systems can’t support that without content freezes and manual “double publishes”

DELIVERING REAL VERSIONING AND BRANCHES

CrafterCMS’ repository is based on Git. Git provides authors using Crafter with a versioning system that is multi-file — meaning that an author can see the entire content collection at any moment in time in its history.  Git also provides support for branches which means that authors using Crafter can support difficult operational scenarios like re-brands without any content freezes or extra publishing.

Content freezes and Other Business Interruptions

New features, design refreshes, and integrations are a way of life for today’s customer-focused market. Agility and innovation at scale and speed are key to winning in this competitive landscape. Wherever you have innovation you will find developers and development process along with its procedures, tools, and environments. Businesses want innovation without disruption. Unfortunately with most CMS platforms, due to their architecture, business disruptions are exactly what content authors and other business users end up with. Outages and complicated deployment processes along with content freezes are realities for most innovative organizations use CMS.

When we look at the reason for the disruptions to the business activity we find that the development and testing process requires that we maintain independent testing environments and that we do code deployments. It’s during this maintenance activity that authors are often told to “hold off” or “stay out of the system.” Content freezes waste time and money and they hurt the business. SPAs and Headless CMS platforms do nothing to solve this problem.

In order to get content to lower environments like Dev, QA, and Test we have to take an export of Production. Authors need to stop working during exports. Imports on the lower environments are no fun either. Every environment needs to be painstakingly and individually updated. When coding is complete it has to be rolled out. Once again authors need to refrain from using the system. Complicated deployment procedures and models can take hours, days and in some cases even weeks. More valuable time and money are wasted.

Uninterrupted Business Activities with SPAs

CrafterCMS has an architecture that is different from other CMS platforms. Crafter is designed and implemented with repository technology specifically designed to handle these processes with minimal effort and friction. CrafterCMS leverages Git at its repository layer. In contrast to CMS platforms that rely on databases or JCR repositories that rely on exports and imports that require outages to sync data between environments, Crafter’s repository is meant to be distributed and as such it natively supports syncing between related stores. We call this push button process “Code Forward, Content Back”™ CrafterCMS allows developers along with their tools and process to live and work in harmony with content authors. This enables collaboration together without interruption and with much less friction so that a greater level of innovation and ongoing operations can all take place at the same time.

Conclusion

The net-net of it is simple. Regardless of any improvement in content reusability or ease of development, authors need to be able to do their jobs easily and efficiently without interruption. New tools and approaches need to move the ball forward, not back. Unfortunately for authors, headless CMS has lost major ground.

Some of these shortcomings can be overcome with time but all of the shortcomings we looked at here are architectural in nature. Architecture changes are the most difficult and time-consuming to make. You don’t have to wait for your current headless CMS to correct course. CrafterCMS is an open source headless CMS with the right architecture to take full advantage of the benefits of SPA applications provided to end users and developers while giving authors the tools, process and uninterrupted service they need to succeed.

What has your experience been working with SPAs and your CMS?