Last year my team was hired to build a software product. A large educational technology corporation wanted to enhance financial literacy among the pre-college and college students. We were hired to build a product around this idea. Using our unique outcome-driven product design methodology, we came up with a content-based progressive app design. The content is the protagonist of this act. We partnered with Jean Chatzky — a leading financial journalist and CEO of the hugely popular media company HerMoney. Jean and her team produced the content for the product.
There were multiple product requirements around the content strategy. SEO played a major part of those requirements, so did easy but structured navigation and quick access among many others. In this article, I will only focus on the content management side of the project.
- Content for the product were of three types:
1. Textual — written text
2. Binary — audio, video, images
3. Mixed — Text with embedded images, videos and audio
- The content will be semi-structured.
- There will be an advised sequence of consumption of content. Content A will lead to content B to Content C etc.
- The authoring environment must be easy enough to use for non-technical people.
- Authoring binary content will happen outside this tool. They will be uploaded to the system.
- There will be ways to consume content in different form factors and channels.
- Low-latency is a requirement
- SEO friendliness is a requirement
- The product needs to support a huge number of users, in spikes.
One possible solution was to roll-your-own. But that means we have to build a full-featured CMS with an authoring system, a repository, an API layer and the presentation layer. It became obvious almost from the get-go that we need to use some off-the-shelf CMS.
We reviewed a few matured solutions, e.g. Wordpress, Drupal, Sitecore etc. They are very successful products with years of existence, large install-base and strong reputation. They are also well maintained. They are great in what they do, however it could not check all the boxes that we needed.
We needed a solution where the presentation layer is not closely tied to the content authoring and content management layer. If we consider the presentation layer of a product as a head, then we need a headless CMS. (Here the word headless is of different meaning from what the IT people use in the context of ‘headless account’.) You can find more about headless CMS here, but I found this short description quite apt: A headless CMS is a content management system that provides a way to author content, but instead of having your content coupled to a particular output (like web page rendering), it provides your content as data over an API.
The solutions we reviewed were designed to be used as a monolith CMS, not headless. When these products were built, this was the norm of all CMSes. These successful products owe their successes, to some extent, to this design choice. Even though they, under-the-hood, maintain a level of separation between the content-layer and the presentation layer, and started offering headless versions of their product, they were not designed to be headless. Becoming headless had some cost. Hence, we looked for a true headless solution.
We came across Contentful during our research for a headless CMS. It was then a 5-year old company. We heard good things about it from our industry colleagues. It is designed to be a headless CMS. It provides Rest as well as GraphQL API’s to access the content in JSON format.
The content authors and editors use the authoring interface (accessed through a regular browser) to author content. The contents are, by default, created in “Draft” state and stored in the Contentful repository.
Before a content is authored in Contentful, a Content Model is created. A content model can be thought of as a template for a group of content which share the same or similar structure. Note, a Content Model is a composite object, i.e. a content model can contain other objects or even other content models. Creating your own content model provides a lot of flexibility to tie authoring with the rendering content.
Once the content is published by click of a button in the interface, the content is pushed to its multiple edge caches (CDN) for low-latency fetching by the clients.
Contentful manages authentication and some level of authorization via API keys.
We can also create a Preview site for the content, or even better, your frontend can act as a preview just by using the Preview API key, before publishing the content to the production.
We found that even though the Contentful needs some improvements around the authoring tool and content modeling, and even though it’s not completely bug free (e.g. importing needs work), it is a production-level matured product as a headless CMS that can withstand some serious traffic.
We also found that involving content modelers when the product’s UI/UX design and content strategy are being developed is of immense value. This saves a ton of rework and heartburn later.
The full-service CMSes still have their place in the ecosystem, but if I am building another consumer product which has significant content load, complex UI/UX and multiple form-factor distribution channels, I will go for a headless CMS. And that’s exactly what we did in another project where the content part of the product was built on Contentful.
I don’t have a reason to look beyond a headless CMS yet.
Mandatory disclaimer: I do not have any financial interest in Contentful nor do I work there.