De gevolgen van headless voor je content organisatie
Gepubliceerd op 14 augustus 2019
Auteur: Tim Hanse
Contentmanagement consultant bij Crossphase
Opeens heb je het. Een headless cms. En je komt er niet zo makkelijk van af vrees ik.
Maar wat doe ik hier nu mee als contentmanager?
Het klinkt zo ideaal. Een cms waarmee ik door middel van een API alle kanalen van content kan bedienen. Omnichannel. Waar ik ooit, in de toekomst, een AI op kan koppelen, die dan zelf de juiste content inlaadt. Waarmee ik elke klant over het gewenste kanaal van de juiste content kan voorzien.
Mooi toch?
Een headless cms is een systeem waarbij de front-end code losgekoppeld is van de database met content.
En hier ontstaat dan direct de verwarring. Want wat is dan nog het cms?
Is het de front-end module, waarbij we de content inrichten voor het juiste kanaal? (App, website, mailing) Of is het de database met informatie en data?
Mijn antwoord: beide kunnen we het cms noemen. Want we managen content in de database, waar we het beheren en opslaan. En we managen de content in de front-end module, waar we het koppelen en functie geven.
Om verwarring te voorkomen, zal ik in het verloop van dit stuk de database gewoon de database noemen. En dit brengt me bij mijn eerste punt.
Om de content optimaal te kunnen gebruiken, moeten we af van het concept waarbij we content opslaan als volledige “eindproducten”. Met eindproducten bedoel ik webpagina’s, nieuwsbrieven en applicaties. Content moet niet alleen herbruikbaar zijn binnen het communicatie kanaal, maar ook daarbuiten. En het zou ook herbruikbaar moeten zijn met een ander doel. Een simpel voorbeeld is een afbeelding, die we op een pagina gebruiken als header, ook op een andere pagina, maar ook als achtergrond van een nieuwsbrief. Ook teksten zouden multi herbruikbaar moeten kunnen zijn. Dit maakt dat we content niet meer als complete pagina’s kunnen opslaan, maar in steeds kleiner wordende onderdelen of componenten. Hoewel ik componenten hier wil vermijden. Vaak hebben die al een functie meegekregen, zoals header block of intro field. Feitelijk moet de content in kleine gebruiksklare stukken zijn opgebroken. Een beetje als een bak losse Lego blokken. We hebben het soms ook wel over de granularisatie van de content. Al deze blokjes moeten dus oproepbaar zijn. En beheerd worden in de database. En dat vereist ook weer zijn eigen werkwijze.
Om al deze kleine fragmenten content op te slaan, volstaan we niet meer met een mappenstructuur. Het kan, maar zelfs met een mappenstructuur moet een zoekmachine de juiste content kunnen oproepen. Daarnaast creëer je met mappen een soort grenzen en bakken voor je content. Dus eigenlijk wil je alles in een hele grote contentbak. Uit die bak kan content dan worden opgeroepen.
Dit kan worden gedaan door elk stukje content metadata mee te geven. Om het niet te verwarren met metadata voor SEO, kun je het ook micro metadata noemen.
Het gaat hierbij om metadata die details geeft over het kleine stukje content.
Denk hierbij aan naam, inhoud, mogelijke kanalen voor gebruik en aan mogelijke functies.
Net als de indeling van het dieren- plantenrijk, creëren we voor ons bedrijf een eigen contentrijk.
Maar is dit nog genoeg? Ooit wilde we een AI koppelen aan de data. En hoe moet die de juiste content samenvoegen? Hoe moet content überhaupt als relevant voor elkaar worden vastgelegd? Kunnen we content metadata meegeven die de relatie van content tot elkaar kan meegeven?
Het antwoord is ja. Dit kan door ontologie toe te passen op onze content. Ontologie?
Ontologie, ook wel de zijnsleer binnen de filosofie, kan worden toegepast door gebruik van RDF en OWL2.
RDF is een manier om de linkstructuur tussen items te verrijken met de relatie tussen beiden items. Deze verrijking wordt geschreven in OWL (Web Ontology Language). Dit is dus letterlijk de relatie die twee items tot elkaar hebben. Kort samengevat kan de link tussen twee items zelf als metadata worden meegenomen.
Al met al wordt het managen van de data in de database dus een stuk pittiger als we voor de ultieme variant gaan. In de praktijk zullen we veel minder granulaire content zien.
Door bovenstaande ontwikkelingen, zie ik op korte termijn nieuwe specialismen ontstaan binnen het content vakgebied. De taken van een contentmanager worden een beetje verdeeld over de twee instanties waarin gewerkt kan worden: De front-end module en de database.
Voor de front-end module blijven we marketeers en schrijvers nodig hebben. Mensen die campagnes kunnen opzetten, volgens en beheren. Dit is de creatieve kant van het content managen. Deze zullen echter wel het conceptuele denken wat men nu heeft, denken in eindproducten, moeten aanpassen naar denken in modules of fragmenten.
Voor de database hebben we mensen nodig die erg goed zijn in het beheren van grote hoeveelheden data. Een echte databeheerder dus. En ik denk dat er, met de opkomst van headless systemen, ook meer vraag gaat zijn naar goede taxonomen, die content van de juiste metadata kunnen voorzien.
In the end moeten alle partijen nog steeds samenwerken, maar je team zal weer meer expertise moeten hebben om de alle vernieuwingen het hoofd te kunnen bieden. Daarnaast zijn veel organisaties in de basis nog niet flexibel genoeg ingericht, waardoor we veel silo’s binnen bedrijven zien die gezamenlijk meerdere kanalen bedienen. Ik begrijp dat het nog niet altijd nodig is, maar er is steeds meer behoefte aan centrale content teams, die de content, of data, goed kunnen beheren. En als laatste wil ik graag meegeven dat het allemaal nog toekomstmuziek is. Misschien nabije toekomstmuziek, maar morgenochtend kun je gewoon door met de daily business.
Je vindt het artikel hier op LinkedIn.