Headless and the Headless Accelerator Explained for Marketers
A Look Behind Dev Tech for the Curious Marketer
A Look Behind Dev Tech for the Curious Marketer
‘Headless’ is a term that marketers come across more and more often nowadays, but what does it really mean and how can Magnolia accelerate it?
When developers speak about a headless architecture they refer to the separation of IT systems, namely the separation of the head from the body, also known as ‘decoupling’.
Separating The Head From The Body
The head is the digital touchpoint that end-users interact with, for example, a website or a phone app. Developers call this the ‘frontend’.
The body is made up of various systems in the ‘backend’, like your CMS, DAM, ecommerce, or marketing automation system. The term ‘backend’ refers to the systems behind the frontend, systems that the frontend uses but that are not directly accessible by the user.
The head is responsible for the presentation of content and data to the user. It does not own it. Instead, the head communicates with the backend systems via APIs to consume their data.
API stands for Application Programming Interface and is a means to trigger specific actions across IT systems, for example, exchanging data. A website can, for example, request content from a headless CMS via an API. Or a CMS can request images from a DAM.
Traditionally some of these backend systems had a frontend built in. For example, the CMS would host and present the website. Or the ecommerce system would host and present the shop.
In a headless environment, the head has been chopped off and built as a separate system. Now, content and data are presentation-independent. Developers also call this ‘raw’ or ‘clean’ content because their frontends take care of how it is presented.
The Headless Accelerator by Magnolia
Speed up the development of your digital experiences with a unified workflow and a library of UI patterns. Check out the Headless Accelerator by Magnolia.
Why Headless?
As we’ve seen, there is a head in headless. But why would anyone want to remove the head from the body?
Decoupling the frontend from the backend has 3 major benefits:
Flexibility To Build Any Frontend You Like
Developing a frontend independently from the CMS and ecommerce system allows developers to use a development framework of their choice. For example, you could build a smartphone app with React that consumes raw content from the headless CMS and headless ecommerce system through their APIs. This frees you from any limitations imposed by these systems and how they intend to present their content.
The sky is the limit.Easy Content Reuse Across Multiple Frontends
If content is stored independently and made available via an API, it can be consumed by multiple frontends. For example, as a retailer, you could use the same promotional content on your website, in your mobile app, and on your digital signage in store. This means you can create content once and re-use it many times.
You could call this idea “multi-head”–a modern and friendlier version of the Hydra, a many-headed serpent in the legendary mythos of Herakles.A Unified Customer Experience
In a headless architecture, the frontend is the unifying element of the experience, bringing together content and data from various backend systems. That’s not to say that a head-on architecture cannot deliver a unified experience, but it is easier to implement in a headless architecture.
Let me give you an example: If you have an ecommerce website that is hosted by your CMS and a shop that is hosted by your ecommerce system, will your customers notice the difference between browsing your website and browsing your shop?
Potentially, yes. We call this the “two-system-syndrome” that presents itself as losing the shopping cart when you go from the shop to the website, different navigation menus, and a siloed search that either searches the website or the shop, but not both.
Magnolia can solve these problems even in head-on architectures, but if one system is responsible for the presentation, your customers are likely to have a more consistent experience.
Why Not Headless?
A commonly discussed drawback of a headless architecture is its lack of authoring and optimization tools for marketers. While traditional content management systems come with their own challenges, most offered a decent graphical interface for content authors to manage digital experiences.
Because frontends are built separately, they do not come with a graphical interface or visual editor out of the box.
Magnolia’s headless CMS that sits at the heart of our digital experience platform (DXP) overcomes this obstacle by integrating with any frontend. We give marketers and authors tools to manage experiences in a headless environment as if they were working in a traditional CMS including features like a visual editor, experience preview, and personalization.
The Magnolia Headless Accelerator and What’s in it for Marketing?
So, now, that a headless CMS is no longer a blocker for marketers, you might wonder:
How can Magnolia accelerate headless development?
Why would this matter to you?
Let me try to answer these questions in 2 different ways:
Answer 1: Magnolia developed the Headless Accelerator as a productivity tool for developers and I like to compare it to a ride-on lawnmower.
Imagine you have a big garden and your partner wants to buy a ride-on mower. Now, you could ask yourself why they want one. Or, you could look for how it’s benefiting you. In my opinion, it’s important to understand that they like the mower, so riding it makes them happy, and they finish mowing the lawn much faster. So, they are generally more pleasant to be around and can spend more time doing other things in the house.
You might argue that you could hire a gardener instead, but you would still benefit from the ride-on mower because the gardener could mow faster.
What’s my point?
Answer 2: The Headless Accelerator is cool tech, your developers like it, and it makes them happier and faster so that they can get more work done in less time. For marketing, that means that new landing pages, features, and promotions don’t take up as many dev resources and can be developed faster.
So, let’s get mowing.
Challenge the Status Quo
Are you already using a headless CMS and have not been able to launch experiences as quickly as you would like? Is this because you’re waiting on your developers or because you can’t visually create content and designs? If you answered yes to one of these questions, we’d love to talk to you and your developers to discuss if and how Magnolia could help you overcome these issues.
Bonus: Making Headless Faster
If you are a technically-minded marketer and want to understand the modern web technology behind the Headless Accelerator, keep on reading.
Magnolia’s Headless Accelerator provides developers with a library of UI patterns based on Web Components. Web Components are templates that can be used with various frontend development platforms, also known as JavaScript frameworks. Our library includes templates for buttons, cards, carousels, spinners, and many more. Working with templates gives developers a head start compared to creating components from scratch and ultimately ensures brand consistency across your web properties.
The Headless Accelerator also has a command-line interface (CLI). A CLI is a text-based user interface that allows developers to run programs. These programs are developer tools that help developers adapt templates to their requirements, change Magnolia configurations, and create content types automatically. These tools automate several steps of the development process and also make it easier to use templates across multiple frontend frameworks, which is a common need in large companies because of different product requirements and developer skillsets.
Lastly, the Headless Accelerator creates an integration between Magnolia and the developers’ IDE. IDE stands for Integrated Development Environment and it is used for programming and configuration. The integration with Magnolia makes the IDE smart by offering the user auto-completion for Magnolia-specific code, so that they can focus on developing the frontend rather than learning the inner workings of the CMS. It also reduces the room for human error to nearly zero.
If this sounds good, tell your developers to check it out.