Storyblok content editing ervaring

Wat maakt Storyblok uniek?

In de huidige markt zijn er tegenwoordig heel veel headless content management systemen (CMS) waar je uit kunt kiezen. Eén van de CMS systemen waar we bij Iquality veelvuldig mee werken is Storyblok. Wat maakt Storyblok nu zo uniek en anders dan andere headless CMS systemen? Zoals veel CMS-en heeft Storyblok een aantal unieke kenmerken waardoor het het beste past voor een bepaalde klant of specifieke business situatie. Wanneer je leest over Storyblok of kijkt op hun website wordt vooral de visual editor veelvuldig genoemd als hun “unique selling point”. In deze blog gaan we wat dieper in op deze visual editor.

Preview en inline editing in een Headless CMS

Binnen content management systemen en qua ervaringen voor content managers hebben we het vaak over 2 belangrijke features; preview en inline editor. Beide features geven content managers een rijke ervaring bij het beheren van content en het helpt hen om content aanpassingen te bekijken voordat ze daadwerkelijk gepubliceerd worden.

Een preview is een visuele weergave van een website of applicatie. Het doel is om content te “previewen” voordat je deze publiceert. Content wordt via een API opgevraagd uit een headless CMS. Alle headless CMS systemen bieden 2 verschillende API’s: de content delivery API en de content management API. Voor de “normale” website gebruik je de content delivery API en voor de “preview” gebruik je de content management API: deze API geeft zowel gepubliceerde als niet-gepubliceerde content terug naar de frontend.

Een inline editor lijkt op een preview, maar biedt als extra optie om content in een visuele context aan te passen. Vaak wordt dit ook wel een WYSIWYG (what-you-see-is-what-you-get) editor genoemd. Deze feature is tot op heden bij geen enkel headless CMS aanwezig.

Composable vs monoliet

Veel traditionele monolithische all-in-one content management systemen bieden standaard een preview en inline editor ervaring. Op zich is dat logisch: een all-in-one content management systeem is verantwoordelijk voor de complete afhandeling van een website of applicatie. Dit betekent dat de “frontend” laag binnen het CMS bekend is. Wanneer een CMS op de hoogte is van de “frontend” kan dit systeem deze ook gebruiken om een preview en inline editor aan te bieden. Headless CMS systemen zijn headless oftewel de “head” is niet bekend. Dit betekent zoiets als dat de “frontend” niet de verantwoordelijkheid is van het CMS. In theorie betekent dit dus ook dat een preview of inline editor niet mogelijk is.

De evolutie van headless CMS systemen

In de begintijd van headless CMS systemen was de focus puur gericht op een applicatie waarmee content op een optimale manier beheerd kan worden. Langzaam werden steeds meer functionaliteiten toegevoegd aan deze systemen, maar vooral nog steeds gericht op het beheren van content. Het verhaal was vooral om content te beheren en via een goede API beschikbaar te stellen voor 1 of meerdere kanalen (omnichannel). Later kwam er steeds meer behoefte aan het beheren van content in de context van een pagina of website.

Preview integratie vs. de visual editor van Storyblok

De meeste headless CMS systemen hebben een soort van preview integratie. Zo bieden bijvoorbeeld Contentful en DatoCMS een mogelijkheid om een button te configureren per content type. Dit zorgt ervoor dat een externe website geopend wordt op het moment dat de content editor op deze button klikt. Deze externe website kan een zelf gehoste preview website zijn. Storyblok biedt als enige headless CMS op de markt een integratie van een preview, de zogenaamde visual editor. Storyblok heeft ervoor gekozen om de preview meer te integreren in het CMS. Deze preview is nog steeds een zelf gehoste omgeving en wordt via een iframe écht onderdeel van de UI. Wat mij betreft zijn dit interessante verschillen en maakt dat er wat te kiezen valt. Ik denk dat vooral de business case bepaalt welke keuze de beste is. Wanneer je bijvoorbeeld puur het beheer van generieke, omnichannel content wil faciliteren ben je niet bezig met het beheren van pagina’s en heeft een inline editing experience geen toegevoegde waarde.

Meer dan een preview

Zoals gezegd is de preview een onderdeel van de Storyblok UI, maar er is meer! Storyblok biedt de mogelijkheid om deze preview interactief te maken. Allereerst is het belangrijk om wat specifieker te zijn over de visual editor. De visual editor is namelijk de complete editing experience binnen Storyblok, maar deze is opgesplitst in 2 delen:

• Visual editor preview;
• Visual editor content.

Aan de linkerkant in bovenstaande weergave is de visual editor preview te zien en aan de rechterkant de visual editor content. Deze 2 UI onderdelen kunnen met elkaar samenwerken, hiervoor heeft Storyblok een toolkit beschikbaar. Deze toolkit, genaamd de Storyblok bridge, heeft 2 functies:

• Wanneer je ergens binnen de preview klikt zal binnen content het betreffende deel geopend worden.
• Bijwerken van de preview aan de hand van gebeurtenissen binnen de UI van Storyblok, bijvoorbeeld het bijwerken van content zorgt ervoor dat dit direct zichtbaar is in de preview.

Het grote voordeel laat zich raden: content editing wordt op deze manier heel visueel. Digitale producten waarbij de content heel bepalend is voor de presentatie kan direct vanuit de Storyblok applicatie gevalideerd worden of de content past en zorgt voor de goede uitstraling.

Meer informatie over de toolkit en hoe je deze kunt gebruiken in je website is te vinden in de Storyblok documentatie.

Conclusie

De visual editor preview is een belangrijk en prominent onderdeel van de Storyblok UI. Het zorgt ervoor dat het bewerken van content erg intuïtief is, vooral wanneer het gaat om pagina gerelateerde content. Als onderdeel van de implementatie is het dan ook belangrijk om dit mee te nemen en de Storyblok bridge op de juiste manier te implementeren. Een implementatie waarbij een belangrijk deel van de UI niet werkt omdat het niet geïmplementeerd is, is onlogisch. Wel is het belangrijk te realiseren dat het bij de visual editor preview gaat om pagina’s en niet alle content is pagina gedreven, bijvoorbeeld een productcatalogus wiens dat op diverse plaatsen en zelfs kanalen gebruikt wordt. Ook binnen een pagina wil je niet alle content in de context van de pagina editable maken. Een goed voorbeeld is een footer, deze geldt voor je hele website. Hier dient rekening mee gehouden en daarmee is lang niet alle content via een preview aan te passen.

Wil je meer weten over de visual editor of de implementatie hiervan? Laten we kennismaken!