Revolutie in Web Content Management op komst

27 maart 2012, 11:15

Van WCM naar Content Snippet Management

Web Content Management is voortdurend in beweging. Oorspronkelijk was het op internet gericht. Maar het aantal kanalen dat vanuit technologisch en conceptueel oogpunt slechts deels ‘webgerelateerd’ is, (bijv. Twitter, YouTube, Facebook, mobiele apps) neemt snel toe. Aanbieders van WCM doen daarom verwoede pogingen om alle kanaalspecifieke mogelijkheden in één WCM-systeem te proppen.

Een onmogelijke opgave zou je zeggen. Systemen die oorspronkelijk voor maar één kanaal zijn gebouwd worden nu ingezet in talloze kanalen met totaal verschillende eisen, technologieën, klantenverwachtingen en processen. Op een afstand bekeken, lijkt dit precies wat de klant wil: het grote, bestaande Web Content Management-systeem opnieuw gebruiken, inclusief de kennis, de processen en de gebruikers, om alle bestaande internetkanalen én de nieuwe digitale kanalen (zoals mobiele en sociale media) te kunnen beheren. Uiteindelijk zal dit echter niet werken.

Traditionele WCM-functies

Traditioneel hebben WCM-systemen verschillende functies, zoals bijvoorbeeld:

  • Content creëren: de mogelijkheid om een webpagina te maken en te bewerken.

  • Content leveren: HTML-pagina’s leveren met een hoge omloopsnelheid, cachebaar en met personalisatiefuncties, en afhandelen van (registratie)formulieren.

  • Content indexeren: content indexeren ten behoeve van zoeken en retrieval.

  • Geïntegreerde webanalyse: de effectiviteit van content zichtbaar maken: wordt deze wel of niet gelezen, hoe komen bezoekers bij de content, enz.

  • Opties voor personalisatie: hierbij is de webpagina gedeeltelijk op de klant afgestemd (bijvoorbeeld het verplichte ‘Hallo meneer Van Berkum’).

  • Opties voor maatwerk: bijvoorbeeld een Java-, PHP- of .NET- gestuurde software development kit (SDK) om de basis-WCM met extra functies uit te breiden.

Al deze functies zijn direct op internet gericht en op het technologiemodel dat bij het internetkanaal hoort. Nu zich nieuwe kanalen met andere technologieën en andere gebruiksmogelijkheden aandienen, is dat vragen om problemen.

De uitdaging van multichannel

Met de opkomst van de multi-channelbenadering en de snelle toename van het aantal kanalen, krijgen al deze functies van WCM-systemen in de toekomst met fundamentele problemen te maken. Met name kanalen die andere technologieën gebruiken dan de technologie die op internetgebaseerde kanalen wordt gebruikt, zullen niet langer in het WCM-model passen. Enkele voorbeelden:

  • Wat gebeurt er als een kanaal geen URL-concept gebruikt (denk bijvoorbeeld aan mobiele apps)? Hoe moet je dat indexeren? Hoe kun je personalisatie aanbrengen? Wat te doen als een kanaal niet eens HTML gebruikt (zoals Twitter)? Hoe kun je in zo’n kanaal een HTML-tabel weergeven?

  • Door inline en WYSIWYG-editing (‘What You See Is What You Get’), een functie die klanten bij een WCM verwachten, steekt een fundamenteel probleem opnieuw de kop op dat WCM jaren geleden had moeten verhelpen: het scheiden van content en presentatie. WYSIWYG en de andere heilige graal van WCM-systemen, een Word-achtige interface bieden, doen precies het tegenovergestelde van wat het scheiden van content en presentatie inhoudt. Beide proberen de editor een omgeving te bieden waarin hij of zij direct kan werken in de webpagina waarin de content, inclusief de presentatie, wordt gebruikt. Maar als je in allerlei soorten kanalen en in allerlei soorten presentatie die je nog niet eens kent content opnieuw gebruikt, hoe moet je WYSIWYG dan gebruiken?

  • Webanalyse, de naam geeft zelf het probleem al aan: de aanduiding ‘web’ slaat op de altijd beschikbare URL waar het meestal op gebaseerd is. ‘Click path analysis’ (muisklikken volgen) is een veel voorkomende en erg handige functie van webanalyse, maar hoe doe je dit op een mobiele app die niet met URL’s werkt? Hoe kun je de effectiviteit van een tweet meten? Of zelfs de communicatie in een fysieke winkel?

  • Maatwerk: als andere kanalen dan het internetkanaal op een eigen technologie draaien, is Java of .NET SDK niet genoeg. Als je bijvoorbeeld een app voor iPhone wilt maken, moet je mobiele ontwikkelaar deze app in Objective-C opstellen. Wat heb je in zo’n situatie aan Java of .NET SDK? Je moet de content dan op een andere manier van A naar B krijgen, bijvoorbeeld met een geformaliseerde API (Application Programming Interface) op basis van RSS of overeenkomstige standaarden, waarbij je content naar believen kunt manipuleren.

Tijd om de harde feiten onder ogen te zien

Ik kan nog wel even doorgaan, maar het is de hoogste tijd om de harde feiten onder ogen te zien: de opkomst van de multi-channel uitdaging zou weleens het einde kunnen betekenen van Web Content Management-systemen zoals die de afgelopen tien jaar zijn gebouwd, doordat ze in de wereld van internetkanalen onder hun eigen functionele gewicht bezwijken. We hebben dus een nieuw soort contentmanagementsysteem nodig: een die direct in de cloud werkt, met een leveringsmechanisme dat volledig gescheiden is van het indexeren en creëren van content. En uit te breiden middels API’s in allerlei programmeertalen en niet sterk aan één technologie verbonden. Systemen waarin content niet tot webpagina’s wordt gecombineerd, maar tot kleine stukjes content (snippets), een soort marketingmateriaal dat op alle kanalen (her)gebruikt kan worden om klanten te trekken.

Er is dus een revolutie in de markt WCM op komst, een verschuiving van WCM naar Content Snippet Management! Wat vind jij ervan?

10 Reacties

    Christiaan W. Lustig

    Om nog maar te zwijgen van de uitdagingen die responsive web design stelt voor contentmanagement. 🙂


    27 maart 2012 om 11:35
    Wouter Mellaart

    fraai toekomstbeeld, ben benieuwd wie er als eerste met een dergelijk Content Snippet Management komt!


    27 maart 2012 om 11:47
    Micha Schopman

    Laten we vooral niet weer nieuwe terminologie introduceren, we hebben er al zoveel en de onderliggende problematiek heeft meer te maken met implementatie, architectuur en gebruik van de toegepaste systemen 😉

    Het ontbreken van een” URL concept” staat mijnziens los van het wel of niet kunnen personaliseren van content. Een URL is niets meer dan een verwijzing/transportmiddel. Je kunt prima multichannel personaliseren met een ander transportmiddel. Een simpel voorbeeld van de velen die mogelijk zijn, we personaliseren ook al SMS en E-mail verkeer.

    De WYSIWYG editor problematiek; als je in je basis content, structuur en presentatie strikt van elkaar gescheiden houdt is ook dit geen enkel probleem. Het is discutabel of je in je content HTML toepast om een stuk tekst vetgedrukt te maken, maar ook hier zijn legio alternatieven voor beschikbaar waarbij je de opmaak bij publicatie naar je kanaal vertaald of zelf helemaal weg laat. Dat is de taak die je mag verwachten van een content management oplossing.

    Webanalyse, een andere applicatie vereist soms een andere aanpak. Het juiste gereedschap voor de juiste taak. Als je dus je statistische informatie wilt vergaren uit je app, kun je vanuit je content management oplossing services aanbieden (een API bijv.) die de app kan aanroepen bij een druk of gesture. Niet moeilijker maken dan het is.

    En dat werkt dus ook weer door op maatwerk. Wil je content op een uniforme wijze delen, dan kun je ervoor kiezen dit via een service beschikbaar te maken aan apps, en daar zijn weer legio transportprotocollen voor.

    Ik denk dus niet zozeer dat de oplossing ligt in een geheel nieuwe propositie op het vlak van content management door het snippets te noemen, maar in slimmer en logischer gebruik van bestaande systemen. Scheiden van content, structuur, presentatie. Services gebaseerd op open standaarden om die informatie beschikbaar te maken, en voor de rest gewoon even logisch nadenken en niet met een bazooka op een mug gaan schieten.

    Daar valt in deze branche zo ontzettend veel in te verbeteren en we weten met zijn allen dat we veel en veel beter kunnen 🙂


    27 maart 2012 om 12:23
    Albert Skibinski

    Het klopt dat het systeem van de toekomst naar verschillende kanalen moet kunnen publiceren. Eén ervan kan de traditionele html/css zijn, maar het moet ook mogelijk zijn om naar andere formaten dezelfde content te publiceren (denk aan mobile).

    Daarbij moet het mogelijk zijn elk stukje content afzonderlijk te zien, en niet meer in pagina’s te denken (denk aan responsive design).

    Als ontwikkelaar van Drupal (een open source cms/framework) zie ik de toekomst rooskleurig. Het zijn precies deze punten die momenteel opgepakt worden om in de volgende versie (8) een systeem te presenteren dat dit fundamenteel anders doet dan de traditionele systemen.


    27 maart 2012 om 14:59
    Rob Smulders

    Interessant al deze ontwikkelingen!

    @Wouter: Wij, Mondi, hebben vorig jaar hierover contact gehad met Iqnomy liquid internet. Zij hebben een platform ontwikkeld waar mee je 1 op 1 kunt personaliseren met anonieme bezoekers op je website en je andere online kanalen. Zeker de moeit waard om eens naar te kijken 🙂

    Rob


    27 maart 2012 om 15:05
    Ate van der Meer

    Heerlijk om dit artikel te lezen en dit sterkt ons in de gedachte dat wij met ons Snakeware CMS Enterprise al jaren invulling geven aan wat er in dit artikel staat. Bij ons is content gescheiden van vorm en wij werken met objecten en leveren de browsers slecht xml met verwijzing waar de objecten en de vorm gevonden kan worden. Misschien moeten wij als nuchter Fries internetbureau eens wat meer op de grote trom slaan en een moderne naam bedenken voor onze veelzijdige multichannel software. Dus nogmaals heerlijk om dit verhaal de lezen laat die revolutie maar komen, we blijken er al jaren klaar voor te zijn 🙂


    27 maart 2012 om 20:28
    mvberkum

    Er worden heel wat eigen producten hier geplugged als -de- oplossing 🙂 Maar dat mag natuurlijk.

    De uitdaging ligt hem erin dat WCMS systemen op dit moment zo sterk vanuit het Web kanaal denkt en niet vanuit de karakteristieken en eigenaardigheden van andere kanalen. Daarnaast wordt er vanuit gegaan dat -alle- kanalen aangestuurd moeten worden vanuit 1 CMS. Dat is niet meer de praktijk van vandaag voor veel organisaties. Content wordt ondertussen overal gebruikt, in allerlei vormen. Van PDFs, print, callcenters, Point of Sale tot SMS, twitter en het web. Bovendien worden er per kanaal steeds meer technologien geintroduceerd (denk alleen al voor social en mobile), die zeer effectief zijn, maar een silo werking hebben. Het liefst wil je toch over al die kanalen heen managen, effectiviteit meten, optimaliseren, personaliseren, profiel gegevens verzamelen etc. Vandaar ook in mijn eigen ogen de opkomst van Content Marketing als strategie van marketing organisaties, een aanpak over alle kanalen heen. Zolang CMS leveranciers alleen maar vanuit hun eigen technologie blijven denken worden klanten niet echt geholpen.


    28 maart 2012 om 07:51
    Micha Schopman

    Inhoudelijk op je stelling (het pluggen van eigen producten is imho te makkelijk).

    Er wordt de aanname gemaakt dat WCMS systemen op dit moment geen rekening houden met karakteristieken en eigenaardigheden van andere kanalen, én dat er vanuit technologie wordt gedacht. Ik denk dat die stelling wat kort door de bocht is, want.

    Er zijn best wel wat spelers op de markt die in de basis content kanaal onafhankelijk beheren, dit delen over meerdere kanalen én over al die kanalen heen informatie verzamelen, en hiermee effectief de beleving van de eindgebruiker verbeteren. Van gepersonaliseerde content, geautomatiseerde processen om te informeren of interactie te stimuleren, tot en met acties als a/b testen.

    En, vrijwel elke leverancier biedt mogelijkheden om content te aggregeren vanuit derden en deze ook weer te distribueren, met alle bijbehorende toeters en bellen, over meerdere kanalen.

    Veel organisaties zijn ook gewoon nog niet serieus genoeg bezig met online strategie en maken onvoldoende gebruik van alle hulpmiddelen die we vandaag de dag kunnen bieden omdat de theorie in de praktijk best complex is én het een continue proces betreft waar veel organisaties intern niet op zijn ingericht. Er komt dan nog niet eens techniek aan te pas.

    Het is en blijft lastige materie; van verschillen in tone of voice in je communicatie over meerdere kanalen, tot iets als het bepalen van de persona’s binnen je online strategie.


    28 maart 2012 om 08:51
    Ate van der Meer

    @Martijn van Berkum, blij dat je open staat voor het “pluggen” van eigen software, maar het is gewoon de waarheid. We hoeven ons product niet te pluggen wij werken al jaren echt op een manier over alle systemen heen en ook voor print draaien wij onze hand niet om. Dus nogmaals laat de revolutie die je voorspelt maar komen 🙂


    28 maart 2012 om 09:51
    Tony de Bree

    @Wouter,

    dit is nogal een technische, traditionele software-bouwer, inside-out benadering. Die revolutie is al lang in gang gezet. Met bv platforms als WordPress als open-source basis. Klaar voor mobiel, ipad, gewoon en geintegreerd met bv Fanpages op Facebook (na 30 maart!).

    Of via Google of zoals Microsoft al lang doet. Via de Cloud bv. Voor zowel thuisgebruik als professioneel gebruik.

    Zo hebben bv grote software-leveranciers en adviesbureaus jarenlang veel geld verdiend in o.a. de bancaire sector met allerlei multi-channel benaderingen en “pukkelbouw” op oude systemen.

    En daarnaast ook in de zzpers/webwinkel-sfeer.

    Die tijden zijn voorbij. Game over.

    Tony de Bree

    Twitter: @tonydebree


    1 april 2012 om 10:14

Marketingfacts. Elke dag vers. Mis niks!