Last year my team was hired to build a software product. A large educational technology corporation wanted to enhance the 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.
Problem Statement
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 other. In this article, I will only focus on the content management side of the project.
Content for the product were of three types:
Textual – written text
Binary – audio, video, images
Mixed – Text with embedded images, videos and audio
The content will be semi-structured.
There will be a lose 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 huge number of the users, in spikes.
Possible Solutions
One possible solution was to roll-your-own. But that actually means we have to build a full-featured CMS with authoring system, repository, API and presentation layer. It became obvious almost from 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 extremely successful products with years of existence, large install-base and strong reputation. They are also well maintained. Once any vulnerability is discovered, they patch their code very quickly. All in all, each one of these are solid products in their own domain. They are great in what they do, however it could not check all the boxes that we needed.
One of the main shortcomings was that all of them were designed to be used as a monolith CMS. That means there was not enough separation between the authoring part of the CMS and the rendering of the content. 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.
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 (primarily, head is the organ through which we interact with the outside world), 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.
Even though most of the CMSes we considered, under-the-hood, maintain level of separation between the content-layer and the presentation layer, and started offering headless version of their product, they were not designed to be headless. Becoming headless had some cost. Hence, we looked for a true headless solution.
Selected 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 as a template for a group of content which share same or similar structure. Note, a Content Model is a composite object, i.e. a content model can contain 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.
Learnings
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 channel, I will go for a headless CMS and Contentful will be my first stop.
