Contentful...Headless CMS & AEM
The traditional CMS approach to managing content puts everything into one big bucket — content, images, HTML, CSS, you name it. This made it impossible to reuse content because it was complex and not suitable for all digital platforms.
As digital channels and devices have evolved, the need for more flexible solutions has emerged. Now, enterprises are developing websites, mobile apps, digital displays, conversational interfaces, and more. Meanwhile, the traditional CMS has failed to full fill the requirement of modern digital channels. Why? Because a CMS organizes content in webpage-oriented frameworks, making it impossible for the same content to fit other digital platforms or software.
In headless CMS, the “content,” is separated or decoupled from the presentation layer, the “head.” What this really means is that a headless CMS allows you to manage content in one place and still be able to deploy that content across any frontend of your choice. This is key to omnichannel strategies because it lets you integrate content into any system, software, or website just by calling the APIs the headless CMS exposes.
What are APIs and how do they work with headless?technology?
An API connects two applications so they can exchange data. Content that is housed in a headless CMS is delivered via APIs for seamless display across any site, device or other digital touchpoint. This makes content in a headless CMS endlessly reusable
The main job of a headless CMS is to store and manage your content without caring about what you want to do with that content. Similarly, the main job of display platforms like a website or mobile app is to present content to people without worrying about how that content is stored or managed. APIs are the magical connection points that allow these back-end systems (e.g., headless CMSes) and front-end systems (e.g., websites) to communicate the ways we want them to.
Coming back to AEM…While we were hearing a lot about new publishing concept called ‘headless CMS’, Adobe/AEM introduced Content Fragments and Experience Fragments to fulfil the needs of the headless communication.
In AEM, Traditionally, most editing of content happens directly in Adobe Experience Manager (AEM) on a so-called page that relates more or less 1:1 to a page on a website: you drag and drop images from the DAM onto a page, add components and type (or copy/paste) text and then publish it.
But in the last few years, more and more digital channels appeared, such as mobile apps, social media, email newsletters and so on, so the ways content is moved also needs to be changed.
Contentful…
Of course, Content will not be reused 1:1, but it has to be adapted to fit the need of each channel. After all you can not publish a detailed content with huge text and multiple images, which is possible on website to twitter due to limitation of character.
领英推荐
Adobe/AEM did not directly adapt headless?way of publishing content but provided means to separate?content from the page-oriented management. Adobe allowed users to store texts and entire components in the DAM as has been possible for images for many years. So basically, now you can store two different kinds of content containers in the DAM: Content Fragments and Experience Fragments.
Let’s see Experience Fragment first and try to understand by an example website of a travel magazine which features different variants of teasers that promote an interesting article containing same elements (or components) – a title, an image, a short text and the link to the article page. We can have different teasers with different look and feel depending on different digital channels example the front page, in a sidebar, or even as part of an email newsletter or in a mobile application etc.
These teaser can be stored as an Experience Fragments to be used in many places throughout the web pages or in different digital channels by creating different variation of the teaser as an Experience Fragment to serve the requirement of the different channels. For example, in some digital channel you will need smaller image and less text and with separate look and feel for other channel.
“An Experience Fragment is a structured content that packed together and has a specific look and feel defending on digital channel. It’s some components packaged together, that can be reused anywhere on your site and in different channels.”
Content fragments...as name implies, it’s just fragment of content without the look and feel. You can say content fragments are structured content based on a content model created using the Content Model Editor by defining the different parts (attributes) of the content model. It basically decides what type of content is allowed in the Content Fragment.
Let’s try understanding this relationship by an example. An employee biodata on a website could be modeled as a content Fragment. It contains the first name, last name, email address, a headshot and a small intro text. This is the content model definition of the Content Fragment.
Once this content fragment model is defined, an AEM author can create many content fragments as for requirement. Like, first name is Harish, last name is Burman, and so on.?
So we can say that Content fragments store data, but no information about the look and feel. For different use cases, we can create variations of Content Fragments but with same structure. For example, the intro text or headshot might be longer or shorter, depending on the channel it is used in.