When the subject of headless comes up, it’s usually within the context of ecommerce. Specifically, it’s usually around how headless solutions (e.g. products with decoupled front- and backends) are the longer term of omnichannel experiences.
But there’s another side to headless: content.
Today, we’re getting to talk through headless CMSs, and the way they will power web and mobile applications.
The Problem
The problem with web and mobile apps for an extended time has been that they’re disconnected. The rationale you disconnect them is because the functionality and content you would like for each is exclusive, so to deliver the simplest experience, you would like to take care of two, disparate solutions.
For example, on an internet application selling shoes, you would possibly have high res photos of your products, alongside 360° 3D product views. These are cool, but require an outsized screen and a robust internet connection to figure.
In contrast, an equivalent store selling equivalent shoes on your mobile app may need much smaller photos (since it’s a smaller screen) and no 360° 3D product view, since it’s a compromised experience on mobile.
But this easy reality results in an entire mess of inconvenience:
- You have to take care of two points of integration for each backend system
- Your systems will inevitably fall out of sync
- Coding and programming takes twice as long
- Marketing and frontend execution takes twice as many resources
The standard solution was to easily maintain two systems and two teams — all liable for wiring and building the proper content for the proper experience at the proper time, in line with the unique aspects of their mobile or web application.
And while this works, it’s not an excellent fix.
The Headless Solution
Enter the headless CMS. A Headless CMS takes an equivalent general approach as headless ecommerce — you’ve got one content management system, an API layer, then all of your web and mobile applications.
Your various application developers build whatever frontend experience they need, then fire API calls to programmatically usher in the content they need.
It means there’s a real single source of truth for content, which then finishes up filtered through all of your various channels in a way that suits each individual one.
And this design comes with tons of perks.
Streamlined content management
For starters this technique massively streamlines content management because there’s only ever one thing to update.
Let’s return to our shoe example. Let’s say that you simply want to market a selected sort of shoe across all of your channels during a flash 48 hour sale.
A traditional approach would have every single promo panel updated manually on every device.
A headless CMS solution would mean you’d simply build and tag your front promo slots as “promo” then, once you want to run a campaign, you only tag the corresponding content ONCE within the backend.
The API calls will register that it’s a special campaign, and distribute your content instantly across every device.
Now, let’s say there was an error . Let’s say the 48 hour sale is merely on the blue shoe, not all colours. instead of again updating everything manually, you’d just enter the CMS, the only source of truth, make your change there to be always blue, instead of all colours, and watch than change cascade out across your various applications as API calls fire.
Reduced content reproduction / easier version control
By maintaining all of your content during a single location, it’s far easier to reuse your content across different campaigns, channels, or applications, which successively reduces content creation costs and creates a more cohesive brand experience.
At an equivalent time, because all of your content is stored during a single location, it’s far easier to version control it as time goes on.
For example, say you sell a variety of technical products, like washing machines. Keeping PDF manuals and user guides up so far is exhausting if they sleep in multiple places. At the time, if you don’t, you risk offering customers conflicting troubleshooting advice (which is bad).
With a headless CMS, there’s only ever one copy of a bit of content, so updating the core version must happen once, then that change is reflected everywhere, instantly.
Wrap Up
A headless CMS solves tons of problems. Yes, it’s more complex to create, and may require buy-in from the organization to rethink their approach to content production and distribution.
