Blueprints die meegroeien met de redactie
Een veld toevoegen is makkelijk. De kunst is om een blueprint zo te schrijven dat de redacteur hem over een jaar nog begrijpt.
Elke blueprint begint netjes. Titel, intro, tekst. Een jaar later staan er vierentwintig velden in, waarvan de helft "alleen voor die ene landingspagina". Dat is geen technisch probleem maar een redactioneel probleem: niemand weet meer wat hij moet invullen.
Schrijf instructies, geen documentatie
Elk veld heeft een instructions-regel. Gebruik hem. Niet om te herhalen wat het label al zegt, maar om de vraag te beantwoorden die de redacteur écht heeft: hoe lang mag dit worden, waar komt het te staan, wat gebeurt er als ik het leeg laat.
- Slecht: "De titel van de pagina."
- Beter: "Komt in de tab van de browser en in de deelkaart. Houd het onder de zestig tekens."
Groepeer de sets
Een replicator met twintig sets is een muur. Zet ze in groepen — opening, inhoud, uit de content, afsluiting — en de keuze wordt weer een keuze.
Durf nee te zeggen
Niet elk verzoek hoort een veld te worden. "Kan deze kop ook rood?" is meestal een vraag naar een nieuw soort sectie, niet naar een kleurkiezer op de bestaande. Een kleurkiezer geef je één keer weg en neem je nooit meer terug.
Meer lezen
Beeld zonder gedoe
De redacteur uploadt één bestand. De template vraagt om de maat die hij nodig heeft. Daartussen zit Glide, en verder niemand.
Antlers in een uur
Dubbele accolades, partials, tags en modifiers. Wie Blade kent, is hier binnen een middag thuis — en wie geen PHP kent ook.
Waarom platte bestanden nog steeds een goed idee zijn
Geen database betekent geen migraties, geen dumps en geen "werkt op mijn machine". Wat je ervoor terugkrijgt is een geschiedenis d...