CMS • 14.05.2025
CMS
Iconen in Storyblok: van technische naam naar visuele keuze
11 augustus 2026
Een icoon kiezen zou niet ingewikkelder moeten zijn dan het icoon aanklikken dat je nodig hebt. Toch is dat in veel CMS'en precies wat er gebeurt: editors klikken niet op een icoon, maar op een naam die er ooit door een developer aan is gegeven. Wij vonden dat we dat voor Storyblok anders konden aanpakken, met een custom icon field waarmee editors iconen visueel kiezen.
Waarom een naam niet hetzelfde is als een icoon
Editors krijgen in veel CMS'en een dropdown voorgeschoteld met namen als analytics, shield of arrow_outward. Dat werkt technisch prima, de waarde komt netjes in het veld terecht en de website toont het juiste icoon. Voor de editor die dagelijks content bijwerkt, is het een stuk minder prettig: die moet eerst uitzoeken welke naam bij welk icoon hoort.
Die naam komt meestal voort uit de icon library die developers gebruiken, niet uit hoe een editor over content nadenkt. Voor een developer is "arrow_outward" een duidelijke, technische term. Voor een editor die een knop wil maken met een pijltje erin, is het gewoon een pijltje. Dat verschil in perspectief zit in bijna elk veld dat rechtstreeks een technische waarde toont: het is logisch voor wie de code schrijft, en een raadsel voor wie de content vult.
De dropdown: werkt, maar niet voor de editor
Stel: je maakt een nieuwe feature op een pagina en zoekt een icoon dat veiligheid uitstraalt. In een dropdown moet je dan weten hoe dat icoon heet. Is het "security", "shield", "verified_user" of toch iets anders? Je kunt de opties één voor één proberen, maar eigenlijk ben je dan vooral aan het gokken, en dat merk je pas als de pagina live staat en het icoon toch niet is wat je in gedachten had.
Dat is vreemd, want iconen zijn bij uitstek visueel. Als je een kleur kiest, wil je de kleur zien. Als je een afbeelding kiest, wil je de afbeelding zien. En als je een icoon kiest, wil je dus ook het icoon zien, niet de interne naam waaronder het is opgeslagen.
Bij een grote library loop je hier het hardst tegen aan. Een website heeft al snel tientallen iconen: pijltjes, een zoekicoon, een hamburger-menu, iconen voor formulieren. Al die namen staan in dezelfde lange lijst, op alfabetische volgorde of erger, op volgorde van toevoeging. Een editor die op zoek is naar een simpel vinkje moet dan door namen als "check_circle_outline", "done_all" en "task_alt" heen om te ontdekken welke er het beste uitziet. Dat is geen contentwerk meer, dat is speuren naar de juiste code.
De icon picker: klikken op wat je ziet
In plaats van een dropdown krijgen editors een grid met de iconen die ze op de website mogen gebruiken. Geen lijst met cryptische namen, maar de iconen zelf. Je opent de picker, bekijkt de beschikbare opties en klikt op het icoon dat het beste bij de content past. De keuze wordt direct opgeslagen in Storyblok, en op de website wordt automatisch hetzelfde icoon gebruikt.
De picker toont daarbij alleen de iconen die bedoeld zijn voor content. Technische UI-iconen die nergens in een feature of callout thuishoren, laten we gewoon weg, zodat een editor niet door tientallen irrelevante opties hoeft te scrollen.
Dat merk je vooral zodra iconen op meerdere plekken terugkomen. Een feature kan een icoon hebben, maar ook een accordion-item, een USP of een callout. Zonder centrale oplossing krijgt elk component al snel zijn eigen lijst en zijn eigen gedrag. Met de custom field gebruiken al die componenten dezelfde picker, dus zodra je ergens weet hoe het veld werkt, werkt het overal zo.
Een klein veld, maar groot verschil
Een icon picker is op zichzelf geen grote feature. Er verandert niets aan wat er technisch wordt opgeslagen, en de website blijft dezelfde iconen tonen als voorheen. Het verschil zit in wat de editor dagelijks meemaakt: geen icon-namen meer hoeven te kennen, geen documentatie erbij pakken, geen pagina publiceren om te checken of de gok goed was.
Dat is precies het soort verbetering waar we bij een CMS-implementatie naar zoeken. Grote, zichtbare features vallen op, maar het zijn juist de kleine velden die iemand tien keer per week gebruikt die het verschil maken. Een dropdown met interne namen legt een stukje van de techniek bij de editor neer. Een visuele picker haalt dat weg, zodat iemand zich kan richten op de content in plaats van op het CMS zelf.
Wil je weten hoe wij Storyblok zo inrichten dat het beter aansluit op de mensen die er dagelijks mee werken? Neem contact met ons op.
