Content Management Systems seem to be a hot topic at the moment. We have been building varying solutions for several clients with integrated CMS systems, including our very own websites abletech.nz and addressfinder.nz. Our personal experience sees us on a three to five year lifecycle with CMS’s. Abletech went from WordPress, to BlogSpot, to Tumblr, to Medium, and now to Strapi over the course of 16 years! This article outlines some of our learnings, why we keep changing, and what we are really after from our CMS.
Why use a CMS at all?
The general driver seems to be providing the business with the ability to quickly publish content, be it a marketing website, web application, or even a native mobile app. Using a CMS allows us to separate the quickly changing content from the slower changing application. The attractiveness of not requiring an expensive developer to be involved with making changes is also a big drawcard.
Content
We seek a fantastic user experience in creating, reviewing, previewing, and publishing our content. We also generally need the ability to define our own content types. Contact cards, blogs posts, opening hours, locations, and any other types that our publishers need access to and inject into our content rich applications.
Media
A killer feature of the CMS is image and asset management. Traditional mechanisms to handle images within a website by including images in source repositories such as Git is not a great idea (doing so can quickly bloat and slow down your github actions due to increased repository size and bloat.) Cloud storage is a better option (such as AWS S3), but without a management facility wrapped around it you will struggle to find and manage your images in your content.
A good CMS should allow you to not only effectively manage images (upload, categorise, find etc), but also automagically format your images into various sizes to optimise them for delivery across different devices (desktop, mobile etc) and network speeds (rendering small images ahead of higher density refined images in a consistent systemised manner).
Headless CMS or CMS
Headless refers to the CMS just being used to create and manage content. The content is injected into your application by a real time API or via a build process. Full CMS's (sound we call these headfull 😀) which provide the content, and theme builders etc to deliver the content into a rich fully featured site.
If you are creating a brochure website for your business and have little in the way of brand then a fully-featured CMS that can give you a responsive out-of-the-box design is certainly a nice way to go, However, if you want full control in delivering a unique, unconstrained, rich online experience showcasing your brand - with precise control over concerns such as performance, accessibility, availability, and security - then you will likely find that your out-of-the-box CMS will fail. A headless CMS is also required to push/pull information into mobile or web applications (it would be difficult or impossible to do this without an API directly into the content).
OK, so which Headless CMS then?
Googling for Headless CMS sets you on a path of choosing and evaluating many! We took the time to make a comparison of the top ones we found and please feel free to review our own comparison and feedback your experiences as well.
Full Page showing Prismic, Contentful, GraphCMS, DatoCMS, Ghost, Strapi comparison
We settled on Strapi as it provided us with a future-proofed content system with a friendly UX. We had also been burnt by lock-in from other CMS providers. You can read about our (very historic article) of why we shifted from Tumblr to Medium here; and Medium certainly had a lot of advantages (the editing UX is the best we have found and supports commenting). It is however rather opinionated in what it lets you do. Try putting formatted code blocks and using it for other application content. The main reason we had to leave, however, was due to SEO.
SEO Matters
Medium changed its business model and policies since we first started using it. They now don’t support separate domain hosting (although we were grandfathered so technically not a problem for us), and Medium has removed SEO advantages of publishing content on Medium to your external services/product websites (they don’t transfer the google juice to you and prefer to keep it to themselves!). The business model they are working to is luring people into their Medium content.
As a technical example of what they are doing, you can take a look at how links that are published in a Medium article (a hyperlink being an important part of how the internet works!) and notice that they have a no-follow attribute. This means that although you can link off to external websites from your stories, Medium has instructed search engines not to go to (follow) that site and ignore it for SEO purposes. So being hosted on Medium did nothing to boost the SEO of abletech.nz and addressfinder.nz sites! So bye bye Medium from us
<a href="external link" rel=".. nofollow" target="_blank">
There is still no silver bullet in great rich headless content management
As I write this content, I am doing it outside of our CMS. Why? The user experience is not up to scratch for the requirements I have over editing content. I need spell correction, the ability to review, suggest changes, and comment on content, as well as options for simultaneous edits on the same document. We are also tied to MarkDown, this is fine for developers but a hindrance for non-technical authors. We were unable to find a headless CMS that satisfied our requirements around authoring experience (perhaps Abletech should build a new Headless CMS and we certainly have considered this!).
Other things to look for
- Strong UX
- Support for your own content types
- Support for multiple users / roles / permissions
- Support for tables, graphs, rich HTML, code sniplets
- Realistic pricing plans for your business
- Ability to export your data out should you choose to leave
- Rich media support
- Commenting on drafts - resolving comments
- Image resizing, searching, tagging
Additional CMS requirements
Versioned content
Although our goal is for business people to add business content to our dynamic content, we shouldn’t forget about software best practices either. Allowing your publishers to publish straight to a content website is one thing, but when inserting content into an application, giving publishers the ability to publish without putting the content through your development pipeline is a risky business. We have seen too often undesirable side effects of moving content out of control of normal build/QA/pipelined processes and into the hands of content publishers only to break UX, or worse, the application. Problems can arise from: Content that does not fit or changes the layout due to not being tested within the application before publishing to production Content that is subsequently unpublished, breaking a dependency that is required for the execution of the application.
Ensure you have thought through a robust pipeline of testing changes before allowing those changes to hit production. Your content changes should traverse your normal pipeline including testing phases (integration tests, UI device tests, accessibility tests), QA, and then be rolled out to production. To roll out multiple changes (or a change set) may require your CMS to support versioned content - something that seems to be missing from most CMS’s. In some instances, we have needed to devise our own robust pipelines for dealing with these challenging constraints.
Open Source
Choosing a system that is open source provides you with options to extend/enrich any missing features and also give you security over service. Ask yourself if the CMS provider will still be around in five years, will they disappear, merge, discontinue the product? Even with Strapi, however, there are hooks in the code to allow the organisation to further monetise the offering (even though they say they won’t!)
Serverless
If I had my way I would choose a platform that leveraged the FAAS (function as a service such as AWS Lambda). Our CMS’s can be costly to host and run and are often little used except for the publishing and build phases. This would reduce the cost substantially (as well as reduce the environmental impact).
Wrapping up
It is also important to realise that you will have your own specific requirements that need to be addressed. Please share any feedback to hello@abletech.nz and also do get in touch if you need help determining the best fit for your content management needs.
