Content management door de ogen van een vrolijke front-end fröbelaar
"Dat kan beter." Zo dacht ik in 2004 ook toen ik het zoveelste op maat gemaakte BeheerDing in elkaar geknutseld had en ontevreden was met het resultaat.
Na het klooien met een Enterprise Content Management System (Magnolia 2.0) tijdens een stage begin 2005 en het klagen over de markup die mijn toenmalige blog (WordPress 1.5) uitkakte, had ik het door: "Dit moet beter." Niet omdat het Web het nodig had, niet omdat klanten er om vroegen en niet omdat ik een gat in de markt zag, maar gewoon omdat ik het nodig vond. Ik was klaar met steeds opnieuw het wiel uitvinden en uitvinden dat ik aan het eind van de rit eigenlijk maar een klein rondje gemaakt had. Ik had een missie: het bouwen van een CMS dat ik steeds opnieuw weer in kon zetten en dat toch met me mee kon groeien door de jaren heen. En iets wat perfect ingesprongen HTML uitspuwde natuurlijk, als ik dan toch bezig was. Wat volgt, is een vrij samengeraapt en toch onsamenhangend verhaal over mijn zoektocht naar het ideaal dat ik voor ogen had, en nog steeds heb, gecombineerd met de afsluiting van een in mijn ogen geslaagd idee van Arjan.
Het allereerste probleem bij een CMS is natuurlijk de vraag: wat is content? Volgens Van Dale heeft het iets te maken met tevredenheid, maar als je eens rondvraagt bij een willekeurig aantal inhoudsbestuurders om je heen, merk je dat het eigenlijk niet echt heel leuk werk is, dat content managen. Vreemd, als je bedenkt dat de bijbel voor content management qua diepgang en dikte de bijbel voor ringheren benadert. Vanzelfsprekend, als je bedenkt dat een groot deel (van dat eerste boek) over XML gaat. En verontrustend, als je bedenkt dat de bijbel voor validatienazi's eenzelfde hoeveelheid pagina's telt. Ruim drieduizend bladzijden, waarvan slechts 33% filmmateriaal bleek. Nee, al vrij snel wordt duidelijk dat je, met oog op het verlangen naar een vrolijkheidsfactor, de beerput die content heet fijn dicht moet laten.
Overigens heeft de werkversie van het laatste deel van The Lord of the Rings een tijdje 'Return of the Content 1.0' geheten, maar is in de jaren daarna door een werkgroep voor een andere naam gekozen; 'The Return of the King', afgekort tot LOTR5. Tegenwoordig spreekt men gewoon van 'The Living Hobbit', omdat in de praktijk blijkt dat deze hele ringzoekexercitie maar om één persoon gaat. Afijn, naast op het grote doek zien we deze geschiedenis in ons vege en vage vakgebied vandaag de dag mooi samengevat terug als het welbekende 'Content is King'. Als je je dus afvroeg waar dat vandaan kwam; je las het hier voor het eerst.
Iedere stinkende hoop kan een hoop lekkerder gemaakt worden door het te prefixen met 'Web'. Developers zijn doorgaans door wereldvreemdheid opvallende mensen, maar zodra je er Web voor zet, zijn ze opeens mondig (kijk naar de rellen rondom 24 ways op Twitter de afgelopen weken). Zet daar nog eens Front-end voor en je hebt een heel nieuw vakgebied gecreëerd (met succes overigens, hulde aan alle vrijwilligers die hier aan hebben meegeholpen!). Ooit gehoord van Cd-video? Maak er Web-video van en je hebt een hit. Met sommige workers communiceer je helemaal niet, terwijl je met Web workers wel moet praten. Zelfs bij het Semantic Web werkt dit fixeren op een pre: Web 3.0 is zoveel sexyer… Hmm, nee, inderdaad, bij deze strontvlieg gaat die vlieger niet op, naar mijn idee. Een mening die niet uit de lucht gegrepen is trouwens; wij HTML'ers snappen gewoon niet wat hidden metadata is, wat je er mee moet, en hoe je het behapbaar moet houden. Google heeft dit voor een groot deel door, anderen hebben andere dingen door. Wellicht dat een Web Semantics 5 specificatie dit probleem ooit op gaat lossen. Of misschien lost het zichzelf wel op, zoals een acidic reactie op een post (die hieronder overigens gewoon welkom zijn).
De term content beperken tot het Web lijkt dus een keuze die leidt tot goud en bling-bling. Zelfs Wikipedia heeft hier een pagina over, dus dan is het waar—een gedrochtreden, ik weet het. Maar om het nog simpeler te maken: met Web content bedoel ik tastbare 'dingen' op een website, zoals bijvoorbeeld pagina's, nieuwsberichten, reacties, alinea's, tabellen, afbeeldingen, kaarten en video's. En dan heb ik het dus niet over onze-voorpagina-met-achtergrondinformatie.html, Nieuws%20brief%20%28september%202011%29.doc, <li>First! LOL</li>, <p>ee<p>ee, <table><tr><td><table>..., <img src="please-4.gif" alt="Please forgive!">, <iframe src="http://maps.yahoo.com/embed#q=Amsterdam&conf=1&start=1&lat=52.373089&lon=4.8933&zoom=12&mvt=m&trf=0&tt="></iframe> of <embed type="application/x-shockwave-flash" src="https://www.youtube.com/v/XSGBVzeBUbk" width="425" height="350" pluginspage="http://www.macromedia.com/go/getflashplayer">. Dat is het idee dat wij nerds van content hebben, maar waar je verder (bijna) niemand mee moet vermoeien. Die implementatiedetails (de tagkoek die voor ons gesneden soep is) zijn niet wat die dingen uniek en bruikbaar maken. Over een jaar wil je misschien de achtergrondinformatie ook op een andere pagina gebruiken, nieuwsberichten of reacties in een feed terug laten komen, tabulaire data als taartdiagram weergeven, bepaalde plaatjes voor iets anders gebruiken, overstappen naar Google Maps (omdat die fijn met 3D aan het pielen zijn), of in één tik de iPad ondersteunen. Sla de dingen dus zo klein en specifiek mogelijk op; je gaat hier later pret mee hebben. Dit lijkt logisch, maar de eerste grote fout bij de meeste CMS'en is dat ze content en HTML als hetzelfde ding zien.
Het woord 'management' belooft niet veel goeds. Hierbij denk ik, vrijblijvende knutselaar die ik ben, aan een keurslijf, regeltjes naleven en een pedante stropdas dragen. Hoe erg ik ook gruwel van die ideeën; als ik als HTML-freak graag wil dat mijn open- en sluit-tags inspringen als perfecte pendanten en niet de spuigaten uit spuiten qua hoeveelheid en nesteldrang, zal er ergens een bepaalde vorm van structuur geforceerd moeten worden. Een web developer is geen magiër en je kunt maar tot op zekere hoogte bijsturen. Volgens mij ligt een groot deel van het beheersbaar maken, voor zowel de developer(s) als degene(n) die met het CMS moet(en) gaan werken, bij de basis.
Je hebt vast wel eens te maken gehad met een gammele WYSIWYG-editor, die een hoop details wegpoetst en een website zogenaamd beheersbaar maakt. Het lijkt aan de oppervlakte een perfect concept en het verkoopt makkelijk. De structuur die wij kennen (HTML) wordt vertaald naar een structuur die de gebruiker kent (een visuele representatie van die HTML), en andersom. Voordat we ook maar een front-end hebben waar we trots op kunnen zijn, is er dus al een vertaalslag geweest. En met een beetje ongeluk zit je je in allerlei bochten te wringen om twee compleet verschillende omgevingen (de publieke website én het CMS) van misschien wel dezelfde CSS te voorzien. Respect voor iedereen die daar overdag mee bezig is!
Met WYSIWYG-editor hierboven bedoel ik trouwens een HTML-editor. Een editor als Xopus is wat mij betreft iets totaal anders, aangezien die tot op het laagste niveau iets van de structuur weet, en dus de echte content beheert. Helaas zijn er maar weinig goden op de wereld, moeten de meeste baksels het gewoon met HTML doen en gaat er nog steeds een hoop fout.
Tuurlijk, er zijn tegenwoordig perfecte editors die schone HTML teruggeven, maar ik heb ooit voor het meeste simpele model gekozen, waar ik geen spijt van heb. Een WYSIWYG-editor is niet eens mogelijk, aangezien bij de content geen HTML wordt opgeslagen en het CMS niet weet hoe bepaalde dingen verrijkt worden. Het uitleggen van deze kluif aan klanten lijkt misschien een grote, maar in de praktijk blijkt dit één van de makkelijkste punten te zijn. Het belang van een WYSIWYG-editor wordt volgens mij enorm overschat, terwijl het één van de grootste pijnpunten voor vrolijke front-enders is. Ik hoop dat de mobiele tsunami en misschien de nieuwe Webrichtlijnen dit de komende jaren duidelijk gaan maken, maar we moeten loslaten en met betere oplossingen komen. Het beheersbaar maken van verschillende formaten afbeeldingen op dezelfde pagina is een goed voorbeeld dat het WYSIWYG-probleem meteen al op de proef gaat stellen.
Eén van de grote voordelen van het hebben van aparte stukjes inhoud, is dat je per inhoudstype een specifieke user interface kunt aanbieden. Wat je inlevert aan What You See Is What You Get, krijg je ruimschoots terug bij What You Want Is What You'll Get. Een lijst met uitslagen? Gewoon een begin- en einddatum vragen. Een speelschema voor een team? Een seizoen, afdeling en team vragen. Een Google Map? Een adres, zoals je die ook invoert op maps.google.nl. Het beheren van dit soort content kan niet veel makkelijker voor de gebruiker. En het later aankleden van die content ligt helemaal in handen van de front-end developer, die zo door de jaren heen met steeds minder markup uit de voeten kan. Voor beide partijen is 'managen' opeens een leuk woord geworden.
Natuurlijk zijn er ook andere voorbeelden te bedenken, die lastiger zijn. Complexe tabellen onderhouden is nog steeds een ramp, niet alleen in een online editor, maar eigenlijk ook in Excel. Aan de andere kant kun je stellen dat als een tabel te complex is om te onderhouden, deze waarschijnlijk ook te complex is om aan de voorkant te begrijpen. Dezelfde uitleg wordt ook gegeven als de discussie over het via extra markup (headers="", scope="", summary="", etc.) toegankelijk maken van tabellen weer eens oplaait binnen de HTML Working Group. De informatie opsplitsen lijkt dus sowieso geen gek idee, en ik steek mijn tijd liever in het maken van een begrijpelijke front-end, dan in het maken van de perfecte tabel-editor.
De vertaling naar ons favoriete formaat (HTML, voor de duidelijkheid) is makkelijk; ieder type content krijgt van de server een stukje logica mee wat 'm in een kaal jasje steekt. Alle alinea's krijgen een <p>- en </p>-paartje. Iedere lijst wordt verpakt in een <ul> en iedere regel van die lijst krijgt een <li>-omhulsel voor z'n kiezen. Een notitie krijgt een <p class="note">, een blok code krijgt <pre><code>…</code></pre>, enz. Grootste voordeel hiervan: dit maakt de belofte die CSS ooit maakte beter mogelijk. Bij een redesign van een site kun je bepaalde inhoud net even wat andere HTML laten genereren. En dat is nodig, want HTML en CSS zijn niet los van elkaar te zien, ondanks dat we onszelf continu voorhouden dat dit wel zo is. "Ja, maar, heiden! Als ik m'n stylesheet weggooi in Firebug, kan ik nog steeds een duidelijke structuur zien. En dat is omdat ik semantische HTML gebruik. You suck." Nee, dat is omdat je browser dan eindelijk 'ns haar eigen schitterende stylesheet mag laten zien.
Ja, ik heb wel eens van XSLT gehoord. En nee, ik ken het niet goed genoeg om het een fijne techniek te vinden. Van de extra complexiteit die deze laag introduceert, blijf ik zo ver mogelijk vandaan. Vooral omdat ik met XML en XSLT geen enkel probleem oplos, maar alleen maar voor buzzword compliance zou gaan. In de korte tijd die we hebben op deze aardkloot wil ik de dingen zo simpel mogelijk houden. Daarnaast, stel dat we ooit Hixie op ons congres krijgen, dan wil ik hem zonder schaamte aan kunnen kijken.
Om al die kleine vertaalblokjes overzichtelijk te houden, heb ik ooit gekozen om mijn CMS op één server te laten draaien, met een gedeelde codebase voor al mijn klanten. Aangezien elk van de ongeveer 100 sites die er nu op draaien het concept 'Alinea' implementeert, is het logisch om de drie regels code die een <p> genereert te delen. En vindt een bepaalde klant het nodig om zich groter voor te doen dan 'ie is, dan is het mogelijk om specifiek voor diegene een nieuwe vertaling te maken, die voor <div class="paragraph"> zorgt ;) Zonder flauwekul: ook deze keuze heeft me veel vrolijkheid opgeleverd, naast het feit dat het lekker schaalt. Ja, je kunt waarschijnlijk meer geld verdienen door klanten een SLA aan te smeren en de zoveelste security update tegen betaling door hun strot te duwen. Genoeg Joomla-boeren die hier hun brood mee verdienen. Niets mis mee natuurlijk, maar ik doe er niet aan mee. Niet omdat ik denk dat Vespasianus gelijk had toen 'ie tijdens het zeiken een goed idee kreeg, maar omdat ik niet Caligula achterna wil qua krankzinnigheid; ik wil leuk werk doen. Wat dat betreft zijn wij developers wel magiërs; we kunnen ons eigen werk beïnvloeden.
Los van de kleine blokjes content waar wij tags voor kennen, zijn er ook grotere concepten, zoals pagina's, secties, nieuwsberichten en producten. Deze moeten ook allemaal zonder moeite uitgelegd kunnen worden aan iemand, dus het is het handigst om zo dicht mogelijk bij het tastbare ding te blijven en zoveel mogelijk structuur af te dwingen. Zo hangt een pagina bij mij altijd onder een andere pagina, en komt deze altijd voor of na een andere pagina. Een regel die het makkelijk maakt om menu's te genereren en URLs netjes leesbaar en gestructureerd te houden. Bij nieuwsberichten is er bijvoorbeeld altijd een auteur en datum, bij producten altijd een naam en prijs. Probeer per concept een stramien te bedenken waarin je net genoeg vrijheid biedt en al het andere dichttimmert. En hou daarbij rekening met het veranderlijke karakter van het web; er gaat sowieso ooit nog wat overhoop gehaald worden. Paginastructuren worden omgegooid, producten krijgen nieuwe eigenschappen, etc. Een CMS dat hier niet flexibel op kan inspelen, is niet gemaakt voor het Web. Iets wat niet betekent dat een CMS alles moet kunnen.
Een belangrijk deel van veel CMS'en is workflow management en gebruikersrechten. Ik ben zelf van mening dat deze vooral in het leven zijn geroepen om bepaalde mensen zich niet verantwoordelijk te hoeven laten voelen voor het werk dat ze doen, of om een organisatie een gevoel van veiligheid te geven. Ik hoop de komende jaren wat milder te worden, maar voorlopig zit het er niet in. Ook hier geldt voor mij de complexiteit die het oplevert, maar ook het vertrouwen in het goede van de mens. Geef iemand de controle over iets en de kans is vrij groot dat diegene zijn of haar best daar ook voor gaat doen. In de afgelopen maand hebben een paar schrijvers bijvoorbeeld gevraagd of ze toegang mochten krijgen tot het CMS achter deze site, zodat ze zelf nog hun post konden aanpassen, wat perfect werkt.
Een hoop ontwikkelaars zijn nog steeds gillend op zoek naar het ideale CMS, en een hoop CMS'en proberen alles te doen, tot aan koffie zetten toe. Volgens mij bestaat die combinatie niet, en moeten we ons gaan beperken tot plezier hebben in het werk dat we doen. Ik weet dat ik met mijn geknutsel nooit de grote massa ga bereiken (een prototype daargelaten), maar ik weet ook dat ik het heerlijk vind om te neuzelen in de marge die HTML-indenting heet. De realiteit is toch dat alles wat we online doen over een paar jaar weer compleet vernieuwd wordt.
Het enige nadeel van werken op het Web? Het kan altijd beter. En dat is ook meteen het voordeel.
Aan iedereen die deze maand heeft meegelezen: bedankt voor je overlevend overlezend vermogen. Beleef de komende dagen feestelijk en het nieuwe jaar vooral gelukkig!
Over Krijn Hoetmer 
Krijgt door dit soort stukjes alweer zin om kronkels.net nieuw leven in te blazen, maar gaat er waarschijnlijk niet aan toekomen door tijdgebrek. Iets wat in 2012 gaat veranderen.
Donatie: Wikipedia
Omdat deze site het bewijs is dat je nooit uitgeleerd kunt zijn.