Why did content writers lose trust in CMSs and how to gain it back

Content writers' experience with Content Management Systems has mostly varied from crossing their fingers any time they edit or publish content, to avoiding and minimizing the use of the CMS at any price, replacing it with more trustworthy tools, like word processors and even plain paper!

This is clearly because content writers have lost trust in any of those systems, there are several reasons that can explain it. It is obvious that we can offer a better editing experience than, at least, plain paper. But before thinking of the new experience, we need to restore content writers' confidence in a content management tool. At least this is how we think about it at prismic.io.

prismic.io is a different approach to content management, called "Writing Room and Content Query API". It features a Writing Room where content writers author, manage and publish content, and an API which developers can use to pull that content and integrate it into any website or application design or technology.

Restoring content writers' confidence in the Writing Room should not be taken lightly, we first need to deeply analyze what got the industry into this unfortunate situation. Why do content writers fear and avoid using a Content Management System?

Fear of losing changes

Being continuously worried about losing your changes can kill inspiration and creativity. Honestly, a writer shouldn't use a tool that doesn't guarantee, not only the current state of the document, but also the previous and every single state of that document. In prismic.io we chose to save and keep every version ever written of a document, not temporarily but forever.

This makes experimenting with content ideas a no-risk operation: you are only making a draft of a new version of the document. Drafts in prismic.io are working copies of your documents, and can never affect production. You can have as many different drafts as you want, whenever you think you've got something you're happy with, you can then plan it for production. If you change your opinion, you still have all versions at your diposal.

Fear of overriding someone else's changes

Keeping every version of a document also means that you are never going to overwrite someone else's changes. What they wrote is a different version than yours. Both exist, you can choose one or the other, or even deliberately merge them into a new resuting version!

What am I publishing exactly: losing track of who did what

In systems where pushing the publish button is a risky operation, how does a writer know what exactly is he is pushing into production? He could have worked on these changes for a week, probably with a team. We need a mechanism with which we can visually see what has changed compared previous versions of involved documents, and more importantly what exactly we are changing in what is live now.

Visually comparing document versions

At any moment, a content writer should be able to compare any two versions of a document. This allows not only to remember changes one did, but also makes it much easier to proof-read changes done by others:

Releases as a bucket for related changes

In prismic.io we introduced what we call a release. A release is simply a place were we can push different changes of different documents. In our Les Bonnes Choses pastry shop example, we have a release for the "New San Francisco Shop Announcement". Different changes related to this announcement go into this release. Any time, we can have a look at a detailed view of changes which have been planned for this announcement:

Lack of a real preview: the panic of the blind publish moment

This can be resumed in the simple question: "what if my changes completely broke the website or app design?". Actually there are plenty of what ifs appearing whenever you have push the publish release. Some systems try to solve this by having two deployments of the system, but that can be pretty cumbersome to say the least.

The release concept solves this very cleanly. You can have as many releases as you want, and at any point, you can preview these changes in your actual app or website, securely, and without publishing. This can be very simply done by precising from which release content should be pulled.

Building on solid foundations

Before we even think about experimenting with features to improve the authoring experience in the Writing Room, we had to setup the fundamentals for an environment that restores content writers' confidence in the tool. On top of that, now it is about time for innovation.