How to manage content for single-page applications
Rich web front-ends and headless CMS might be the next big thing, but how do editors manage content for this kind of solution?
Single-page applications, or SPAs for short, are web applications or websites that can interact with the user dynamically by rewriting the current page, rather than loading new pages from a server. The purpose is to avoid interruptions and secure a smooth user experience between successive pages, making the website act more like a desktop application.
Simultaneously with the influx of SPAs in the world of digital experiences there is a parallel newcomer, namely headless CMS. A headless CMS is essentially a database with APIs to deliver content to any channel. It’s not difficult to see how single-page apps and headless CMS fit neatly together: a great user experience, clean architecture, and flexible framework of SPAs, coupled with the content/presentation separation of headless.
However, not everything is a bed of roses with single-page apps and headless—especially where the content editors are concerned. Let’s take a look at the challenges and the proposed solutions.
Challenges with SPAs
Inherent in any pure headless CMS is the lack of preview, and conversely, the single-page applications that are built with headless face the very same challenge. Content editors are used to work in platforms showing them the end result immediately, either in a separate preview or in the editor tool itself. Also, a traditional CMS makes it easy for editors to see the content structure of their given website or app, while a headless CMS is just a “free floating” database of contents, where the editors fill in forms that are used to populate content fields. The same principle goes for page editing and structure management.
SPAs and headless are primarily developer driven. The decoupling between the content layer and the presentation layer makes for more fun and agility for developers, but poses a challenge for content editors. This is due to headless limits what editors can do and customise within the platform.
See also: 7 signs Enonic is powering a website »
The developer’s first approach actually leads to more hard coding from the developers, and editors are more dependent than ever on what the devs have taken into account beforehand. There are possibilities for a lot of hard coded custom switches and complex configuration, but this makes the platform more advanced and cumbersome than necessary.
One final challenge to mention with the SPA/headless architecture is image handling. Whereas another type of CMS can automatise several image editing functions, this is not as easy in a headless environment, due to the separation of content and presentation (not to mention that the content may be presented in wildly different channels). This leads to the editors constantly managing different image sizes and cropping, which can be a headache.
Overcoming the challenges
Now that we know of some of the challenges with a combined single-page application and headless CMS solution, do we have solutions to offer? Of course we do.
As for previews, a best practice is for the developers to set up a standard preview, even though it might not take into account what the presentation will look like on every channel you operate. Choose exactly how the content will appear in a preview, be aware of the differences with other channels, and build a template for how you would like it to look—essentially what makes the most sense to you. Again, remember that this preview isn’t necessarily identical to how it will look in a SPA.
When it comes to page editing, the best solution for you will most likely be hybrid CMS—the mixture between a traditional CMS and a headless CMS. With a hybrid model you can deliver data that tells your developers where the placement of content is supposed to be. This approach will usually be form based with a headless CMS, but a hybrid CMS will be able to deliver data directly from your visual page editor. Simple and easy.
Don’t miss: WordPress vs. Enonic XP »
Is it possible to combine a SPA with a traditional CMS in the hybrid approach? If some part of the app needs a landing page or traditional content, you can simply combine the app with server side rendered content.
While SPAs and headless certainly is a developer driven framework, you should in any case facilitate cooperation between editor and developer. This ensures flexibility in the CMS: together you should make ground rules for structuring the content, thus making it easier for a content editor to get the job done.
As an example, if the solution supports adding switches, add them where it makes sense, without overloading the amount of possibilities. Similarly, establish relations between content and content types—ensuring a tidy and logical system.
Finally, whether you choose headless, hybrid, or a traditional CMS, one thing is unavoidable: your CMS should in any case support image handling. Image handling support includes focal point and the ability for the developer to define what version of an image that goes where.
As a final remark, and to summarise the red thread in this article: Make sure you have a flexible platform to deliver an editor friendly platform for delivering single-page applications.
Headless goes as hand in glove with SPAs, but as a hybrid CMS supports both headless (delighting your developers) and traditional CMS (delighting your editors), it might be the right solution for you.