Week 1
Debriefing, kennismaking en onderzoek naar CMS'en
Deze week ging het veelal over kennis maken met de opdrachtgever. Voorafgaand hadden we vanuit de briefing al een debriefing geschreven. Deze legden we tijdens het gesprek voor aan de opdrachtgever. Ook hebben we in overleg de opdracht nog wat duidelijker gekregen voor ons. Daaruit is de volgende design challenge gekomen:
"Hoe maken we een co-created visueel en technisch herontwerp van de publieke website van Communication and Multimedia Design (CMD) die voldoet aan de standaarden betreft vormgeving, interactie & techniek?"
Tijdens het gesprek kwam eveneens naar voren dat designbureau GRRR as we speak al werkte aan een visueel herontwerp. Vanuit de opdrachtgever dan ook het verzoek ons daar niet zo zeer op vast te bijten en vooral bezig te gaan met een concept dat zich vooral focust op dat co-creatie gedeelte en waaruit een website voort komt die voldoet aan de CMD standaarden, iets wat binnen het huidige Wordpress thema niet mogelijk is.
Vanuit de briefing kwamen we er al gauw achter dat er vanuit de opdrachtgever de wens is om iets met een headless/JAMStack opzet te doen. Echter, om te valideren of dit inderdaad de juiste weg is die ingeslagen moest worden heb ik nog wat onderzoek gedaan naar wat headless/JAMStack precies inhoudt en wat de voor- en nadelen zijn.
Headless (of JAMStack)
Allereerst was het aan mij om uit te zoeken wat headless of JAMStack nou precies inhoudt en of dat wel aansluit bij de CMD standaarden van creativiteit, accessability en performance.
Een ander punt wat we als team belangrijk vonden is of we ook een headless opzet kunnen bouwen zonder gebruik te maken van een JavaScript framework als Next (React) of Nuxt (Vue) omdat dit haaks staat tegenover de 'CMD-gedachte' van alles zo dicht mogelijk bij Vanilla JavaScript houden.
Daarnaast zou het gebruiken van een framework de co-creatie niet ten goede komen omdat nieuwe developers dan eerst moeten begrijpen hoe dat bepaalde JavaScript framework in elkaar steekt.
Wat is headless?
Headless (of JAMStack) houdt in dat je een website zo bouwt dat er uiteindelijk alleen maar statische markup wordt geserveerd aan een eindgebruiker. JAM staat uiteindelijk dan ook voor JavaScript, API's en Markup (jamstack.wtf, 2020).
Je gebruikt JavaScript om als het nodig is dynamische functionaliteit toe te voegen aan je pagina's. Daarnaast gebruik je (externe) API's om backend functionaliteit in te bouwen. Die API's kunnen zelfgeschreven serverless functions zijn of een volledige externe service van een externe partij.
Uiteindelijk serveer je dus statische markup aan de eindgebruiker omdat je alle data tijdens het build process ophaalt.
"The good thing about this pre-generated markup: We are able to serve content in any scenario. Our APIs might malfunction, our JavaScript might break. As long as we send some pure, old HTML over the wire we have something to show! Then we add dynamic features – if necessary – via JavaScript.
This is progressive enhancement in its purest form. That’s why so many people love it." (S. Baumgartner, 2019)
Bottom line stuur je dus statische markup over de lijn naar de gebruiker in plaats van dat je een dedicated server gebruikt om je pagina's te genereren. Dit maakt het ook een stuk sneller dan het gebruiken van een server omdat je statische bestanden kan serveren via een Content Delivery Network.
Dit maakt het voor een gebruiker in Nederland mogelijk maakt om de bestanden op te halen uit bijvoorbeeld een CDN in Amsterdam en voor een gebruiker in Duitsland om de bestanden op te halen bij een CDN bij hen in de buurt.
Met een serverless opzet kunnen we dus sowieso twee van de drie punten van CMD checken, namelijk accessability en performance. Wat nog rest is het kijken naar de mogelijkheid tot creativiteit.
Uiteraard hebben we zelf de macht over de volledige codebase dus daar kunnen we qua creativiteit helemaal los gaan op de CSS etc. Echter, een website als deze playground valt of staat bij het gebruik van het juiste CMS, ook die moet de creativiteit kunnen waarborgen, vandaar dat we onderzoek hebben gedaan naar headless CMS'en.
Onderzoek naar Headless CMS'en
Toen duidelijk was dat we inderdaad voor de headless opzet wouden gaan hebben we besloten om met z'n drieën alle drie een headless CMS te onderzoeken en te kijken of deze aansluit bij de wensen van de opdrachtgever. Een aantal criteria die we opstelden waren als volgt:
Het CMS moet een preview omgeving bevatten zodat de gebruiker zijn wijzigingen kan bijhouden (dit is een grote wens vanuit de opdrachtgever)
Het CMS moet de mogelijkheid hebben om plugins te bouwen om zo eventueel in de toekomst de functionaliteit zelf uit te kunnen breiden
De UX van het CMS is zoveel mogelijk gefocust op de eindgebruiker
Aan mij de taak om Storyblok CMS uit te pluizen op de bovenstaande drie criteria. Om dit te onderzoeken heb ik een account aangemaakt op Storyblok en een testomgeving geprobeerd in te richten.
De preview omgeving
Storyblok noemt zichzelf al "The only Headless CMS with a Visual Editor", dit impliceerde naar mij direct dat Storyblok dus vooral gericht is op de preview omgeving, dit is een groot pluspunt en een sterk argument naar de opdrachtgever om voor Storyblok te gaan. Echter, het moest natuurlijk nog wel even onderzocht worden of het daadwerkelijk wat was.
Het eerste wat ik te zien kreeg was dat het dus vooral goed werkt als je een JavaScript framework gebruikt... Dit maakte mij een beetje huiverig in eerste instantie. Echter, later bleek dat de rest van de CMS'en geen preview omgeving hadden en dit dus überhaupt het enige CMS is met een full-blown preview omgeving.
Het bouwen van plugins
Het bouwen van een plugin voor Storyblok is net zo eenvoudig als het maken van een single page applicatie. Je kan dus eigenlijk een aparte plugin bouwen die precies dat doet wat het moet doen, volgens de documentatie van Storyblok zelf kan je 'm vervolgens middels een API van Storyblok koppelen aan de Storyblok omgeving waarin je werkt.
Wel blijkt het bouwen van een plugin vooral gebaseerd op Vue, iemand die dus een plugin gaat bouwen zou verstand moeten hebben van het Vue ecosysteem...
UX zoveel mogelijk gefocust op de eindgebruiker
De UX van Storyblok ligt mijns inziens nog steeds erg dicht bij de data, hoewel de live preview omgeving daarin veel goed maakt. Echter, dit blijkt eveneens het geval bij de andere onderzochte CMS'en.
Echter, aan de andere kant denk ik wel dat, mits we de namen van velden de juiste namen geven dat de overstap van Wordpress naar Storyblok nog best te doen is aangezien Wordpress dan ook weer redelijk dicht op de data ligt qua UX alleen zijn gebruikers daar vaak meer aan gewend.
Last updated
