In today’s nerdy tweetstorm, we’re going to talk about the problem of retrofitting the ever-popular CMS “Preview” button in multichannel publishing — especially decoupled systems where the CMS is just used for editorial work.
In a monolithic full-stack CMS it’s pretty easy; the system you use to manage things is the same one that publishes/renders, so there’s almost always a bult-in way to preview, even if it’s just saving and “viewing the unpublished page” while logged in as an editor/admin.
But! In a multichannel publishing scenario that isn’t necessarily accurate. It’s just a view of things on the platform and device you happen to be using at the moment. Decoupling the editorial and publishing tools from each other exacerbates that.
(It’s not that decoupling makes the problem of ‘It works on MY device!’ worse, it’s that you often sacrifice the basic built-in preview button that serves as a lowest common denominator, so it’s where some orgs first encounter the problem.)
The two worst case scenarios are 1) Laziness: Editors stop previewing and shrug when stuff breaks, spend 3 years complaining about the CMS. 2) Overkill: Your dev team spends months cloning your publishing system inside your editorial system, so it can “preview.”
Before diving into the TECHNICAL problems with multichannel and decoupled content preview, figure out what you actually mean by “preview.”
If preview means “Writers, editors, legal, etc need to double-check accuracy and ensure all the right data has been entered before content moves on in the process”, you’re in luck. It’s copy/content review, not design proofing, and your editorial CMS can probably do it easily.
If preview means “I need to see what this piece of content will look like in our templates,” it’s trickier but not terrible. If you’re only concerned about multi-viewport issues, consider linking “Preview” to a page full of iframes, each of which loads a different size/etc.
It’s not perfect, but golly it’s quick and easy to implement and in 90% of cases it’s good enough.
If you’re doing real decoupled publishing, you probably need to set up a “staging” version of your publishing system or content API, visible only to authorized users. There are shortcuts, but all of them eventually snowball into building and maintaining a parallel “preview” api.
The third and tangliest preview scenario is “I need to see this in context as it will be seen by the public — with all related data, with a simulation of what will appear around it on a particular day, and so on.” That is absolutely, non-negotiably a dedicated staging system.
In particular, a staging environment that allows users to pass along a particular “target date” so that articles going live/unpublishing, layouts being updated for special events, etc, reflect the target date.
Ironically, that full-context preview is where a monolithic CMS can be trickier — you have to graft “time machine” functionality onto almost everything it does, and almost every CMS has gaps (“Oh, you want to preview DOODADS? It only works for articles and widgets…”)
While a decoupled publishing API is already (or should be) a single pipeline for everything that will go live. Adding a query param for the “simulated date” to an API like that is often easier than digging into your monolithic CMS’s guts to hack that feature in.