Research
Last updated
Last updated
In de beginfase van deze case, nadat de keuze was gevallen op de huidige techstack, deden alle teamleden onderzoek naar een CMS: ik onderzocht hierbij Storyblok. Hiervoor heb ik een soort snelle Proof of Concept opgezet, wat een goed uitgangspunt bleek aangezien m'n teamgenoten dat uiteindelijk ook een fijne onderzoeksaanpak bleken te vinden voor deze case.
Daarnaast hielp die simpele proof of concept hen om gewend te raken aan hoe Storyblok en het ophalen van data in Eleventy met Storyblok werkte. Al met al is dit mijns inziens dus een goede zet geweest.
Misschien was het wel handig(er) geweest om hierin van tevoren wat meer afspraken/richtlijnen af te spreken betreft 'oplevering' om wat meer op één lijn te komen betreft verwachtingen van de testen. Als we ons van tevoren met z'n drieën hadden gefocust op het aan elkaar presenteren van een 'volwaardig genoeg' prototype hadden we misschien zelfs op meer mogelijkheden op CMS-gebied kunnen verkennen.
Daarnaast denk ik ook dat het achteraf gezien beter was geweest als we de drie CMS'en volwaardig parallel aan elkaar hadden ingericht en ze één voor één hadden getest met gebruikers zodat we op dat gebied een nog beter onderbouwde beslissing hebben kunnen maken.
Verder heb ik uiteraard wel meer onderzoek gedaan dan alleen naar CMS'en, maar ik ben wat praktischer ingesteld en ga het liefst direct aan de slag ermee.
Toen duidelijk was dat we inderdaad voor de headless opzet wilden 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.
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 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...
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.