Proposed “Preview” terminology

Note: This was originally written up for a client with similar concerns about previewing content when using a decoupled admin interface. We don’t need the same level of end to end decoupling, but the nomenclature might be useful as we figure out which problems are being solved by which parts of the project, and which aspects of the preview problem are out of scope for this initiative.

—

(CLIENT’S) CMS is designed to operate as a "decoupled" content publishing system. Although the first publishing platforms that will use it are web sites, the same system will ultimately supply the content for web content on mobile and desktop, settop devices, mobile and tablet apps, partner content feeds, and more. To accomplish this, the CMS used to manage content will be completely separated from the system that generates public-facing web pages.

That separation presents a challenge: how can editors and producers preview their work before it goes live? Solving it with the new system requires clearly identifying what we mean when we say "preview". In this document, we're going to be covering three specific use cases.

1. Review: Allow editors and producers to examine the copy, assets, relationships, tags, etc. for a piece of content in a presentation-neutral form, to ensure that there are no errors. ("Does this episode have its full cast list," "Is this movie event scheduled for the right day," etc.)
2. Content Preview: Allow editors and producers to see how a particular entity will appear when published on a particular platform. ("How will this show appear on a Roku," "How will this blog post look on mobile web," etc.) (Note: for our purposes this probably means per display mode rather than per platform)
3. Publishing Preview: Allow editors and producers to review how a given platform (Roku, web, app, etc) will appear at a particular time in the future. ("What will the front page look like on Monday," etc.)

Review

Reviewing content in the CMS for accuracy and completeness, without regards to its presentation or appearance, will be baked into the CMS. The "View" state of any given piece of content should be optimized for this task: it should present the data on each entity consistently and clearly, with an eye towards skimming.

Content and Publishing Preview

(Note: this section outlines the solution for a totally decoupled publishing platform; we don’t need this level of separation but the general philosophy may dovetail with the ongoing “workspaces” stuff that’s going on in core)

Both forms of "true preview" will be difficult, if not impossible, to accomplish inside the CMS itself. Since all content will pass through the content API before being shown to the public, the CMS itself doesn't know what the final presentation will be.

Instead, a "Staging Version" of the API should be maintained, with separate security credentials from the standard public content API. It should mirror the standard PubCentral content API in all ways, but requests to it should be able to override the "effective date" used for filtering content, and preview the most recent version of any given piece of content regardless of its published status.

Similarly, "development" or editorial versions of the front end applications for each platform (web, mobile apps, etc) will need to be used when previewing content — they will make requests against the "Staging API" rather than the public API.