Storyblok editing experience

What makes Storyblok unique?

In the current market there are a lot of headless CMS systems you can choose from. One of the most promising headless CMS systems we at Iquality believe in is Storyblok. What makes Storyblok distinctive then other headless CMS systems? As for most headless CMS systems, Storyblok has certain elements which makes it the best fit in a specific business case or for a specific customer. From a technical marketing point of view the visual editor is the most appealing feature. In this blog post we take a deeper look into the Storyblok visual editor.

Preview and inline editing within a Headless CMS

In the world of CMS systems and content management we often talk about two features; preview and inline editor. Both features are intended for content editors, they will help doing their job and will help them deal with content before it is published to the live environment.

A preview is basically a visual presentation of your website or application. The goal is to “preview” content before publishing it. Content is requested from a headless CMS via an API. All headless CMS systems offer 2 different APIs: the content delivery API and the content management API. For the “normal” website you use the content delivery API and for the “preview” you use the content management API: this API returns both published and unpublished content to the frontend.

An inline editor is also a visual presentation of your website or application but with the ability to change the content within this visual presentation. This is often called a WYSIWYG (what-you-see-is-what-you-get) editor. This feature is not present in any headless CMS to this date.

Composable vs Monolith

Enterprise monolithic digital experience platforms often contain both a preview and inline editor. This makes sense: the presentation layer is part of those systems, which makes it possible to use this layer also for the preview and inline editor function. Headless CMS systems, part of a composable stack, present themselves traditionally as a centralised content hub. Within composable architectures the frontend layer is not part of another component, e.g. the headless CMS. This means in theory headless CMS systems can’t facilitate a preview or inline editing experience.

The evolution of headless CMS systems

In the very beginning a headless CMS system was an application which was perfect for managing content in all its aspects. Over time it became more and more clear that content editors lack the ability to create pages and preview them before publishing. While Storyblok is relatively new, in comparison with f.e. Contentful, you see that they took those requirements into practice when developing their product.

Preview integration

Most headless CMS systems have something you can call a preview “integration”. For example, Contentful and DatoCMS have the ability to configure a button on specific content types which opens your self hosted preview environment. Storyblok is the only headless CMS on the market that offers an integration of a preview, the so called visual editor. Storyblok has chosen to integrate the preview more into the CMS. This preview is still a self-hosted environment and becomes a real part of the UI via an iframe. As far as I'm concerned, these are interesting differences and mean that there is something to choose from. I think that the business case in particular determines which choice is the best. For example, if you want to facilitate the management of generic, omnichannel content, you are not managing pages and an inline editing experience has no added value.

More than a preview

The big advantage from Storyblok is that the preview is directly available within your content editing experience. But there is more: in Storyblok you have the opportunity to make the preview interactive. To explain this further, it is important to be a little bit more specific about terminology. Often the visual editor is referred as the preview but actually we should be more specific, we have two areas within the Storyblok UI:

• Visual editor preview;
• Visual editor content.

On the left side you see the visual editor preview and on the right side you see the visual editor content. To make those areas connected, Storyblok has leveraged a toolkit, called the Storyblok bridge. This bridge helps you enable two things:

• Enabling clicks on the preview and open the related content area on the right
• Update the preview based on specific events in the Storyblok UI

You can guess the big advantage: content editing becomes very visual in this way. Digital products where the design and content are really tightly connected have the most advantages. Without leaving the content management area you can immediately see how your content fits.

Implementation from this toolkit should be done in your self hosted preview site, more information can be found in the Storyblok documentation over here.

Conclusion

The visual editor preview is an essential and prominent part of the Storyblok UI. It makes editing content more convenient because you can see the changes immediately visually during the editing process. Especially when your Storyblok space is connected to a website, it makes sense to have this editing experience. One important thing to take into account is that not all content is page driven. For example in situations where your content is not connected to a specific website or application, it doesn’t make sense to have a visual editor preview. Another point is that not all content on a page is edited in the context from a page, the footer on a page for example is not something you will edit on every page. This footer data will be stored in another location within your Storyblok project and is not connected to the visual editor preview.

Would you like to know more about the visual editor or its implementation? Let's get acquainted!