Ook toe aan een nieuwe manier van werken met style guides?

Als je visual identies ontwerpt weet je het: ontwerpen is één ding, hier consequent mee omgaan is een andere uitdaging. Daarom krijgen klanten bij hun nieuwe branding ook een manual met uitleg over het gebruik daarvan. De stijlgids, vaker style guide genoemd. Het probleem? Ook die stijlgids is niet handig, want: statisch en bewerkelijk. Vaak is het een pdf dat steeds geüpdatet moet worden. Een goede style guide bevat niet alleen de branding elementen zelf, maar – als het om websites gaat – ook de code van die elementen. En niet iedere gebruiker weet even goed hoe hij daarmee moet omgaan.

Is daar nog niet iets slimmers voor bedacht? Nou, ja ja en nee. Disclaimer: er volgt nu een relatief lange cliffhanger waarin we uitleggen wat style guides precies zijn, wat voor alternatieven er op de markt zijn en wat onze definitie is van een stijlgids. Weet je dit al of ben je net als wij een developer die gelijk wil lezen over onze oplossing? Dat kan.

 

Ja, er bestaan plugins voor bijvoorbeeld Adobe Illustrator die automatisch de specificaties opslaan van nieuwe branding elementen die gemaakt worden.

Dit kan handig zijn maar kent nog een aantal nadelen:

• Het werkt alleen voor Adobe tools. Dus niet voor bijv. Sketch. En laten we eerlijk zijn, wie ontwerpt er nog alleen in Illustrator?
• Het is meer bedoeld voor designers dan voor de web developers die templates maken. En al helemaal niet voor klanten. Met deze setup zou je nog steeds een style guide moeten hebben in bijvoorbeeld een pdf bestand en die steeds moeten updaten.

Daarnaast bestaan er diensten als Bynder en Adobe Experience Manager die, zoals zij het noemen, Digital Asset Management systemen aanbieden. Dit zijn cloudoplossingen voor de opslag van onder meer huisstijlen en andere content. Precies wat je nodig hebt dus. De catch? Deze services zijn bedoeld voor bedrijven met 200+ medewerkers en de prijsopgaven beginnen dan ook vanaf 450 dollar per maand voor het instapmodel. Meer iets voor KLM en Akzo Nobel dan voor De Melkweg en The Ocean Cleanup dus. Toegegeven, Frontify is binnen dit segment nog enigzins betaalbaar (vanaf 29 dollar p/mnd maar dan met veel restricties).

Nee, verder bestaat hiervoor, zover wij weten, nog geen handige oplossing. Er zijn dus wel mensen, zoals bijvoorbeeld Dane Wesolko, die dromen over een style guide die met hulp van Machine Learning, Big Data en Artificial Intelligence volledig geautomatiseerd is.

Maar zo ver zijn we nog niet. Is er dan echt geen hoop? Ja, natuurlijk wel! Bij het Grrr-techteam weten we waar digitale innovatie voor dient: om ons leven makkelijker te maken. Daarom hebben we een eerste aanzet gedaan tot het mogelijk maken van een toekomst zoals Dane die schetst. Ok, een heel stuk minder futuristisch dan een tool die je het werk echt volledig uit handen neemt. Maar ook een heel stuk minder omslachtig dan het handmatig updaten van je style guide in een pdf. Of erger, het laten ontsporen van je huisstijl doordat dit juist niet gebeurt.

 

Nog even resumerend. Waar hebben we het precies over als we het over style guides hebben? Een stijlgids is een essentieel onderdeel bij het ontwikkelen van een huisstijl. De stijlgids dient als het sleuteldocument dat door de communicatieafdeling gebruikt wordt om op een consistente manier met haar publiek te communiceren. Het zorgt ervoor dat het hele doel waarmee de branding ooit gecreëerd is ook daadwerkelijk wordt bereikt: het duidelijk overbrengen van je doel bij het publiek.

Wij zien een style guideals een tool om de daadwerkelijke uitingen te valideren. Klopt de code? En misschien nog belangrijker: maken aanpassingen aan de code niks stuk. Zonder deze tool is dat niet altijd makkelijk te zien in uitgebreide websites waar veel modules samenwerken.

Wat we creëerden is een pagina op je website waar alle modules van een site onder elkaar staan. De modules zijn geen kopie of benadering, maar dezelfde code (HTML + CSS) die we gebruiken om de “echte” pagina’s van de site op te bouwen. Hierdoor kunnen we snel zien of aanpassingen aan CSS elders bugs veroorzaken in een andere module, doordat de style guide pagina fouten zal vertonen. Dit is het grootste voordeel van een dynamische style guide versus bijvoorbeeld een PDF of een kopie van de code.

Echt automated: style guide = code

Voor wie is het? We bouwden dit (https://waarzitwatin.nl/styleguide) vooral voor (front-end). Met name front-enders. Daarnaast ook: voor designers die nu op één pagina alle modules onder elkaar kunnen zien en controleren of deze goed geïmplementeerd zijn. En; Klanten die nu op één pagina alle bouwstenen kunnen reviewen.

Overzicht van illustraties die Grrr maakte voor de automated style guide voor www.waarzitwatin.nl

• De style guide loopt nooit meer achter op de werkelijkheid. Het geeft vertrouwen om aanpassingen te doen aan code: je ziet namelijk makkelijker wanneer je iets breekt, iets waar in CSS en HTML nog niet echt een systeem voor is (in back-end development heb je hiervoor unit tests).
• Je hebt altijd je documentatie voor developers op orde: welke elementen zijn er beschikbaar met welke class, en hoe ze werken.
• Designers hebben altijd een overzicht van componenten zodat er geen componenten worden vergeten en er een button bij wordt gemaakt die voor 90% lijkt op een andere button.
• Voor designers die net aansluiten bij een project wordt het veel makkelijker om een nieuw type pagina te ontwerpen.
• Klanten hebben altijd een up to date documentatie: welke illustratie-naam hoort bij welk icoon?
• Het is altijd makkelijk te zien of bepaalde wijzigingen ongewenste invloed hebben gehad op andere componenten.
• Het dwingt tot modulair bouwen.
• De style guides zijn automated, dus altijd in sync met de ‘echte’ code, want het is echte code.

Vroegah, richtten we een pagina in waar we een soort kopieën van de templates (in code) op zetten. Dat was de style guide, en die moest je telkens bijwerken wanneer je een aanpassing deed. Je voelt op je klompen aan dat die pagina verouderde waar je bijstond. Requirements aan de templates veranderden, input van de templates werd gerefactored, en vroeg of laat toonde je style guide ofwel een 500 server error, of het gaf simpelweg de werkelijkheid niet meer weer.

Daarom gebruiken we nu de daadwerkelijke templates in de style guide. De developer die de templates inricht is verantwoordelijk voor het opnemen van een voorbeeld-implementatie in de code van het template zelf. Je beschrijft dus met de code hoe je wil dat de code gebruikt wordt. Wanneer je verandert hoe het werkt, verander je het voorbeeld mee, en omdat dat allemaal in hetzelfde stukje source code zit is dat heel laagdrempelig te doen.

De style guide pagina hoeft eigenlijk alleen nog maar alle templates onder elkaar te zetten, door de voorbeeld-code eruit te trekken en weer terug te voeren aan zichzelf. Heel meta, heel effectief. Bijkomend voordeel is dat je de details van de implementatie als visuele documentatie erbij kunt zetten in de style guide zodat iedere developer kan zien hoe hij een template precies gebruiken moet.

We houden erg van het delen van kennis. Dus maak vooral gebruik van deze tool! Daarnaast staan we natuurlijk ook open voor feedback. Ook als je zelf dus al iets veel handigers hebt uitgevonden; laat het ons weten!

Natuurlijk valt of staat de bruikbaarheid van deze tool met het framework waarin de website is gebouwd. We hebben nu twee implementaties: in ons eigen Garp3 CMS (gebaseerd op Zend Framework) en in OctoberCMS (gebaseerd op Laravel).

Met name die laatste heeft een grote community en daar is het dus zeker interessant om het als plugin uit te brengen. Naar andere frameworks en CMS’en zal gekeken moeten worden, daarvoor zijn dan wat uitbreidingen nodig. Drupal is het grootste PHP CMS, dus een implementatie in Drupal zou leuk zijn, want daarmee help je een hoop developers. Zet jij de volgende stap?

Oh ja, we hebben bij Grrr nog een vacature voor een Backend Developer! 😉