Bij Pixelpillow zijn we altijd op zoek naar verbeteringen in ons werkproces. Hier besteden we dan ook veel tijd aan, en deze kennis delen we graag met iedereen. In deze blogpost gaan we in op een nieuw onderdeel is ons technisch werkproces: Component based werken met Storybook.
Wij ontwerpen geweldige gebruikservaringen. En wij zijn systeemdenkers. Hoewel het creatieve proces ogenschijnlijk chaotisch verloopt, ontwerpen wij uiteindelijk wel een design systeem. Dit systeem bestaat uit alle “losse” onderdelen van een website- of applicatie. Deze onderdelen noemen we componenten. Waarom deze aanpak? Aan de ene kant om ervoor te zorgen dat we een consistente gebruikerservaring creëren. Aan de andere kant om het aantal varianten te beperken. Elke variant zorgt voor meer werk. Het levert dus tijdswinst op. En die tijd stoppen we liever in een aantal key features die de website of applicatie echt onderscheidend maken.
Deze werkwijze vroeg om een andere aanpak in ons proces. Was er een tool die als basis van componenten uitgaat? Toevallig wel: Storybook.
Storybook is een open source tool voor het ontwikkelen van user interface componenten in isolatie voor onder andere Ember, React, en Vue[^1]. Het is zowel een ontwikkeling-omgeving als een bibliotheek van componenten voor een webapplicatie of -site. Anders gezegd: een programma om de visuele onderdelen van een website of -applicatie mee te bouwen. Storybook wordt gebruikt door onder andere Airbnb, Dropbox, Github en Pixelpillow.
Om ervoor te zorgen dat deze geweldige gebruikservaringen ook technisch vertaald worden zoals ontworpen, ontwikkelen we het visuele gedeelte altijd in eigen huis. We werken tegenwoordig met een losse voorkant en achterkant. In jargon: de voorkant bestaat uit een SPA[^2] en de achterkant uit een headless API. Aan de voorkant werken we met JavaScript framework EmberJS. Waarom Ember? Veel zaken zoals de structuur zijn van tevoren al goed uitgedacht. Dat is erg comfortabel aangezien de meeste developers er een handje van hebben om zaken naar hun eigen smaak in te richten. Toch? Binnenkort meer over Ember in een ander blog. Aan de achterkant werken we met verschillende systemen waaronder ook “gewoon” WordPress. We bouwen tegen de standaard WordPress REST API aan met minimale toevoegingen. We proberen zo dicht mogelijk bij de standaard te blijven.
Het grote voordeel van deze aanpak is dat je meerdere kanalen aan kan sluiten op de headless API, zoals een extra mobile app. Een bijkomend voordeel is dat we eerder beginnen met bouwen ook al zijn nog niet alle templates ontworpen. Dit zorgt voor korte doorlooptijden. Ook kunnen we prettig samenwerken met klanten die al een eigen development-afdeling hebben of een eigen leverancier voor data. Juist door die strikte scheiding is het duidelijk wie waar verantwoordelijk voor is.
Deze principes hebben we het afgelopen half jaar al een aantal keer succesvol toegepast. Onder andere bij het ontwerpen en bouwen van een webapplicatie voor een start-up in de ticketing branche. De start-up zelf had een ontwikkelaar voor de achterkant. Wij leverden een bibliotheek op met componenten waarbij de eigen developer deze kon implementeren in de business logica. Ook helpen we bij de ontwikkeling van een webapplicatie voor een leverancier in de binnenklimaatbranche. Deze partij heeft een eigen leverancier voor de achterkant. Pixelpillow regelt de voorkant (zowel ontwerp als techniek) en de leverancier van de klant regelt de business logica. Deze principes passen we ook toe voor onze eigen projecten. We hielpen een autobedrijf met een moderne website waarbij wij de autodata uit een separaat systeem komt.
Documentatie schrijven is saai. Sorry, maar dat is eenmaal zo. Door te ontwikkelen in Storybook pak je direct een groot voordeel mee: je schrijft automatisch documentatie. En dat zorgt voor een geweldige interne gebruikerservaring. Welke data gaat er in je component? Welke states heeft je component? Willen we animaties terwijl de data geladen wordt? Of is er juist veel interactie? Vaak werken we met meerdere developers aan een project. Als de ene developer een component klaar heeft, kan het zijn dat een andere developer deze koppelt aan de achterkant. Door in Storybook te checken kan de developer zien hoe het component werkt. Scheelt toch weer een mini-overleg. En toevallig past dat goed bij onze manier van asynchroon werken.
Wanneer we geen grip op onze aandacht hebben, waaien we met alle winden mee, kost het meer tijd om ons werk te doen en neemt de stress toe. Dit klinkt als een mooie zin en dat is het ook. Ik heb hem helaas niet zelf verzonnen [^3]. Het klinkt paradoxaal: door een extra ontwikkelomgeving toe te voegen creëer je meer focus. Ik geloof dat discipline vooral werkt als je systemen je helpen. Een traditionele aanpak van webdevelopment is om per template te werken. Het risico is dat je met andere zaken bezig gaat dan de taak die voor je ligt. Door specifiek met één component bezig te gaan wordt je gedwongen om op dit specifieke component gefocust te blijven. Grappig: onze andere developers gaven dit ook direct aan als grootste voordeel.
Over het algemeen ben ik trots op de geleverde kwaliteit van ons werk. Voorheen kostte dit de nodige inspanning. In onze oude werkwijze reviewde de designer de templates. Dit gebeurde vaak laat in het proces, waardoor het lastig was om dit werk te plannen. Doordat we direct starten in Storybook kunnen we veel eerder reviewen. Elk component staat als een issue in Gitlab. We reviewen als developers eerst elkaars werk en daarna reviewed de designer. Storybook is te bekijken in de browser. Iets met een systeem.
Helaas niet. We ondervonden dat het lastig is om Storybook up to date te houden. Soms dwingt de data of voortschrijdend inzicht om bepaalde zaken in het component aan te passen. Het vergt discipline om deze aanpassingen in Storybook te verwerken. Vaak is de realiteit dat je deadlines en een planning hebt. We onderzoeken momenteel een aantal oplossingen hiervoor. Komt vast goed.
Storybook kent nog veel handige features en uitbreidingen. Binnenkort gaan we verder uitdiepen over hoe wij Storybook in een project inzetten. Dan lees je meer over hoe wij andere tools integreren in Storybook en over hoe wij samenwerken in een project.
Zoals de Joël al aangaf in het artikel over asynchroon werken is het toepassen hiervan een stuk moeilijker dan een knopje omzetten. Door een tool als Storybook toe te voegen aan ons werkproces voegen we meer daad bij het woord. En wat mij betreft is dat iets meer dan een baby step.
Voetnoten
