As buzzwords and methodologies, “content-as-a-service” and single page application models are quickly becoming popular across enterprise IT organizations. However, a fundamental problem exists in the design of virtually every content management system (CMS) solution that offers “content-as-a-service”—there’s more to an actual experience than just content.
The problem begins with an understanding of what content-as-service actually means. When people discuss “content as a service,” they are referring to the reading or querying of content from a web service that the CMS is exposing. In general, web services are typically implemented in a CRUD (Create, Read, Update and Delete) model, but most of the time, we are not creating, updating, or deleting content from a web app. Rather, in most instances, we are reading content from a web app, which requires multiple queries, as well as individual retrievals.
If this seems both technical and overly-complex, it’s because it is. One major flaw with these solution models is that your application (what most of us would simply call a webpage) needs to call the CMS, request content that meets pre-described criteria, pull it back into the system, and then complete the rendering process. And this process is required for each and every webpage!
To overcome these inherent challenges, the application really needs to know what it should be querying before content is created. Unfortunately, this means increased developer involvement for minor site changes and decreased ability to control the experience using CMS tools like inline editing and full-feature previews.
Location + Content = Experience
The pattern for content-as-a-service is broken, as it only takes into account the interests of developers. To deliver the types of experiences that consumers now expect, content contributors and marketers cannot simply hand off content to development teams. Rather, they require the ability to easily build, manage, and optimize each component of the experience without developer intervention. But what are the core components of a digital experience? In nearly every system, we begin by relating content to a page. Whether you are leveraging a component-based or page-based contribution model, a page represents the blank canvas on which the experience authoring process begins. When we strip away functionality, templates, content, and every other page parameter, we are left with nothing more than a location. Location, when combined with content, results in an experience.
If we apply this formula to our content-as-a-service pattern, the first thing we see is that the locations, or “routes,” are typically built into the application. This means that developers are in control of the locations and, barring a custom process, developer intervention is required to maintain and update locations. But what about the content that appears in those locations? If an application is consuming content-as-a-service from a CMS, content is queried in a CRUD model with developers (again) controlling the rules for what content gets displayed where and when.
In the current form, these patterns and frameworks require developers to take on jobs that are currently held by contributors and marketers. Since locations are managed in the code, the addition of new pages into the application, as well as the selection of content appearing on different interfaces, needs to be handled by the application. That selection, or “pull” pattern, requires developer changes and negates many of the experience management features found in the leading content management systems. Additionally, certain content editing features become much harder to leverage, leaving contributors without the drag-and-drop page construction, in-context preview, and personalization functions they were promised (and need).
Where To Go From Here
Single page applications have too much value to be ignored. If we address the contribution concerns that have been outlined above, the marriage of content management and content-as-a-service suddenly make quite a bit of sense. This is precisely the solution that what we have been working on solving for our clients.
We started with a tool that we are quite fond of, BloomReach Experience (formerly Hippo), which is a Java-based web content management system. It provides all of the usual content management features along with a pretty robust and easy-to-use personalization engine. We then focused on building a contributor-friendly single page application integration. In designing these solutions, we focused on the following priorities:
2. Preserve all contribution features: this includes drag-and-drop page creation and editing, inline preview, page creation, and even personalization. All features are supported and function as they would in a server-side implementation.
3. Agnostic and portable communication: one of the biggest reasons businesses are interested in SPA and content-as-a-service solutions is that it allows them to create an application that doesn’t rely on a specific content management system. Additionally, many customers have, or want, various content data to live in intermediary repositories. Our integration relies on JSON-based communication with the CMS, which is a format designed around both abstraction and portability.
With those in mind, our newest product, editConnect, was born. Installation is simple, requiring only a new Maven module on the BloomReach Experience side, and a simple NPM install on the angular side. Locations (or routes), pages, and content are then serialized into a consumable format that our node module can understand, allowing contributors to once again create and manage experiences within the single page application environment.