Waarom een headless CMS niet al je ellende oplost

Geen reacties
Tags: , , , ,
Posted 17 Okt 2016 in nieuws

Headless content management was het afgelopen jaar een relatief grote hype. Een woordje uitleg voor iedereen die erin geslaagd is om de controversie rond ‘headless’ te ontwijken: ‘headless’ houdt in dat je de front-end en back-end van de content delivery loskoppelt.

Mark Polly, strategisch adviseur voor digital solutions bij het in St. Louis (USA) gevestigde Perficient, schreef dat technologieën zoals REST en javascript frameworks een belangrijke rol gespeeld hebben in de groei van de headless content-beweging. De mobiele revolutie, en mobiele apps in het bijzonder, vormden de katalysator van de beweging. Zo ging de voorkeur van front-end developers die een back-end moesten kiezen steeds vaker naar data stores, die toelaten om content en presentatie gescheiden te houden.

Sommige bedrijven achter de hype beweren dat een headless CMS de beste keuze is voor iedereen die zich gelimiteerd voelt door de front-end beperkingen van een standaard CMS. Ik ben eerder van mening dat dergelijke beperkingen niet bestaan voor moderne enterprise CMS’en, terwijl er wel beperkingen zijn aan headless CMS’en.

Waarom headless CMS zo’n hype geworden is

Moderne CMS’en bieden een ongelooflijke flexibiliteit en functionaliteit. Dit gaat bij developers vaak gepaard met een steile leercurve voordat ze er efficiënt mee aan de slag kunnen. Aangezien het vandaag de dag belangrijk is om snel te kunnen schakelen, is dit niet altijd mogelijk. Veel developers houden van headless CMS’en omdat die zogezegd meer vrijheid bieden, wat voor developers gelijk staat aan meer flexibiliteit en snelheid. Zo kunnen front-end developers front-end frameworks, zoals Angular en React, gebruiken.

Met de explosie van multi-channel content is het belang van de bedrijfswebsite (vroeger het belangrijkste content management kanaal) gedaald en zijn mensen op zoek gegaan naar andere manieren voor de bewerking en publicatie van content.

De front-end mogelijkheden van de meeste CMS’en zijn gewoon niet aangepast aan de hedendaagse vaardigheden en praktijken. Vooral de noodzaak van diepgaande kennis gecombineerd met de vele tijd die nodig is om interfaces te ontwerpen maakt het moeilijk om snel te schakelen. Veel developers raakten gefrustreerd omdat ze hun skills niet konden gebruiken en bovendien niet snel genoeg konden werken. Daarom zochten ze naar alternatieven voor het traditionele CMS. Daar ben ik het niet mee eens.

Gooi het CMS-kind niet met het badwater weg

De CMS-industrie heeft zoveel vooruitgang geboekt. Zo bestaan er verschillende CMS’en die beheerders de mogelijkheid bieden om meertalige, gepersonaliseerde digitale ervaringen te creëren. Tegelijkertijd ben je als beheerder vrij om te spelen met de front-end en kan je later om het even welke integratie implementeren.

Laten we alsjeblieft het kind niet met het badwater weggooien.

Wanneer het ingewikkeld wordt met headless CMS

Front-end developers mogen dan wel gelukkig zijn met hun nieuw verworven vrijheid, de headless CMS’en geven hen eigenlijk slechts de vrijheid en flexibiliteit van ‘Ik kan doen wat ik wil’ tegen de prijs van ‘Ik moet alles zelf schrijven, debuggen en onderhouden.’ Vaak zal je het grootste deel van je tijd spenderen aan het schrijven en onderhouden van je CMS om steeds geavanceerdere features te bouwen, die eigenlijk standaard ingebouwd zijn in een traditioneel CMS.

Een traditioneel CMS bevat gewoonlijk zaken zoals assetmanagement, navigatie, veiligheid, workflow, access control, caching, categorisatie en linkmanagement, om er slechts enkele te noemen. Deze en vele andere functies zijn niet direct beschikbaar in een headless CMS.

Headless CMS’en zorgen vaak voor veiligheidsproblemen aangezien het moeilijk is om te bepalen welke gebruikers welke toegangsrechten krijgen. Hierdoor bestaat het risico dat vertrouwelijke content in de verkeerde handen valt.

Er kruipt enorm veel ontwikkelingswerk in de publicatie van meertalige content. Bovendien kunnen editors niet langer hun content in voorvertoning zien door de opsplitsing tussen contencreatie en publicatie.

Een ander probleem is personalisering. Wanneer je beslist om de contentcreatie te scheiden van de publicatie, moet je de personaliseringsfuncties volledig herschrijven. Form builders bevinden zich vaak ook op de server waardoor de integratie met marketing automation en andere tools verloren gaat, aangezien je CMS niet langer de mogelijkheid biedt om dynamische formulieren te bouwen.

De oplossing van vandaag kan het probleem van morgen betekenen

Het is altijd verleidelijk om te kiezen voor een magisch product dat je probleem – in dit geval: het gebrek om snel content te kunnen publiceren – volledig lijkt op te lossen. De meesten onder ons weten dat wanneer iets te goed lijkt om waar te zijn, het dat meestal ook is.

Het is zoals bij de lancering van WordPress: velen geloofden dat dit systeem precies was waar ze naar op zoek waren, maar uiteindelijk draaide dat veelal anders uit. Er zijn nu eenmaal beperkingen aan het uitbreiden van simpele oplossingen. ‘Eenvoud’ verandert heel snel in complexiteit wanneer je zaken probeert op te lossen waar het product eigenlijk niet voor gemaakt is.

In veel gevallen zal een headless CMS gewoon meer complexiteit voor developers en marketingteams met zich meebrengen. Probeer verder te kijken dan de meest voor de hand liggende oplossing en te denken aan de toekomst.

Het is niet ‘headless of niks’

Headless content management is goed voor het oplossen van specifieke problemen, die eigenlijk geen content management gerelateerde problemen zijn, maar problemen rond het bewaren en opvragen van form fields en data. Bedrijven kunnen met succes een headless CMS gebruiken. We zien bovendien een toenemende vraag naar een hybride aanpak.

De problemen duiken de kop op wanneer men een headless CMS ziet als het antwoord op alles. Er bestaat geen reden om niet te kiezen voor een CMS dat je toelaat om zowel de headless content, als de publicatie ervan te beheren.

Het belangrijkste is dat je de flexibiliteit hebt om in te spelen op toekomstige veranderingen, die zich niet laten voorspellen.



Lees het volledige bericht op Emerce »


Add Your Comment