DRY January #2
- thim90
- Jan 20
- 4 min read
Component libraries: voorspelbaarheid voor gebruikers, rust voor beheerders
Dry January gaat over bewust kiezen.
Niet alles blijven herhalen en niet steeds hetzelfde trucje opnieuw doen.
In Power Platform-oplossingen geldt dat ook. En dit beperkt zich niet alleen tot logica, maar zeker ook tot de UI.
Al ligt dat op UI-gebied iets genuanceerder.
Je wilt immers een voorspelbare en herkenbare applicatie.
En daarvoor is herhaling juist cruciaal.
Maar…om daar te komen, wil je voorkomen dat je jezelf te vaak herhaalt.
Volg je me nog?
Of moet ik het nog een keer herhalen?
DRY in de UI gaat over voorspelbaarheid
Een voorspelbare UI voelt sneller vertrouwd.
Gebruikers hoeven minder na te denken en maken minder fouten.
Niet omdat ze slimmer worden, maar omdat de App consequenter is en daarmee als één geheel aanvoelt.
Dat is waar component libraries hun echte waarde laten zien.
UI-herhaling voelt klein, tot je gebruiker het merkt
Zeker voor Canvas Apps is dit een belangrijk punt.
Ik heb eerder al geschreven dat er vaak voor Canvas Apps wordt gekozen, terwijl een voorspelbare Model-Driven App soms beter zou passen. 🔗
Voor developers voelt UI-herhaling vaak onschuldig. Snel meters maken en vooral voortgang maken.
Een knopje hier, een labeltje daar. Prima toch?
Totdat je merkt dat, een “kleine” aanpassing twintig keer herhaald moet worden in de hoop dat de app nog een beetje als één geheel voelt
Dan ben je niet alleen aan het herhalen, maar ook aan het onderhouden wat je zelf gekopieerd hebt.
Afgezien van de (neem ik aan) ergernis die je als developer ervaart, gaat dit ook ten koste van de gebruikerservaring.
Wat gebruikers namelijk écht vervelend vinden, is wanneer een applicatie onlogisch aanvoelt.
Schermen die nét anders werken. Een andere opbouw. Kleine verschillen die je niet kunt uitleggen.
En dan heb ik het niet eens over de hoofdlijnen van een Canvas App.
Door het “snel” bouwen met standaard controls wijken vaak zelfs de details af:
net een andere fontgrootte, net een andere kleur, net een andere spacing.
Het resultaat?
Een app die professioneel probeert te zijn, maar toch een beetje hobbybob aanvoelt.
En dat wil je voorkomen. Component libraries zijn daarbij een uitkomst.
Oh ja, en niet onbelangrijk: performance. Minder losse controls betekent vaak ook simpelweg betere performance.
Component libraries als afspraak
Een component library is eigenlijk een afspraak binnen je oplossing:
Zo ziet dit eruit.
Zo gedraagt dit zich
En zo voelt dit altijd
Je definieert onder andere:
de layout (hoe ziet het component eruit?)
de interactie (events gekoppeld aan het component, zoals een knop)
Vervolgens koppel je hier inputparameters aan. Die zorgen ervoor dat je hetzelfde component in meerdere situaties kunt gebruiken, zonder dat het zijn herkenbaarheid verliest.
Het wordt daarmee een dynamisch UI-component dat toch telkens vertrouwd aanvoelt voor de gebruiker.
Wil je een praktisch voorbeeld? In een eerder blog leg ik uit hoe je het bovenstaande component kan maken!
Tip: zelf kies ik er vaak voor om niet voor ieder detail een aparte inputparameter te gebruiken. Maar maak ik gebruik van objecten waarin ik diverse parameters bundel voor een specifiek doeleinde.
Dus: één component, op meerdere schermen, in meerdere apps.
Daarmee creëer je niet alleen herkenbaarheid binnen één app,maar zorg je er meteen voor dat meerdere apps uniform en dus voorspelbaar aanvoelen.
En ja, je repeat het component.
Maar niet het werk.
Het onderschatte voordeel: beheer
Het grote voordeel zit niet in “we kunnen dit hergebruiken”.
Het zit erin dat je het geheel maar één keer hoeft te maken.
Maar het grootste voordeel van component libraries beperkt zich dan ook niet tot hergebruik.
Een niet te onderschatten voordeel is het beheer.
Stel je wilt:
een kleur aanpassen
een icoon vervangen
een interactie net iets duidelijker maken
Dan wil je dat één keer doen.
Niet op twintig schermen, met klamme handen en de hoop dat je niets mist.
Zonder component library ga je zoeken en vertrouw je op discipline.
En ergens blijft altijd nog zo’n “bijna dezelfde” variant staan.
Met een component library weet je waar je moet zijn en hoef je enkel het component bij te werken.
“Waarom niet gewoon YAML kopiëren?”
Die vraag komt altijd.
En eerlijk is eerlijk: soms is kopiëren prima.
Maar... kopiëren heeft een houdbaarheidsdatum.
Elke kopie kan afwijken en iedere wijziging moet je onthouden.
Een component library maakt dat expliciet.
Eén definitie.
Eén plek om aan te passen
Eén bewuste keuze voor consistentie
Dat maakt onderhoud niet alleen makkelijker, maar verbeteren ook veiliger.
Het verschil zit niet in techniek, maar in intentie
Met YAML-snippets kopiëren bouw je snel. Met component libraries bouw je bewust.
Bij kopiëren vertrouw je op discipline. Bij componenten leg je patronen vast.
Dat verschil voelt klein aan het begin, maar wordt groot zodra je oplossing groeit of zodra meerdere mensen eraan werken.
Het consequent gebruik van component libraries, tilt je Power Platform-strategie naar een meer enterprise-niveau.
Waar het vaak fout gaat
Hier moet ik Stephen Covey er toch even bij halen:
begin with the end in mind.
Wat vaak gebeurt, is dat men gewoon begint. De snelheid zit erin.
En voor je het weet is de app zo groot dat elementen achteraf ombouwen naar componenten voelt als lastig, risicovol en misschien zelfs overkill.
Future improvement, de backlog op…en daar mag het vervolgens jaren verstoffen.
En juist in deze mindset zou de shift moeten zitten, vanaf het begin denken in herbruikbare componenten.
Vanaf het eerste moment dat je eerste ideeën ontstaan.
Wellicht dat het begin dan even wat meer werk is, maar dat betaalt zich op al snel uit.
Met als extra voordeel dat je niet begint te zweten tijdens je eerste demo als de klant vraagt of die knop toch liever een andere kleur krijgt.
Dus laten we het gelijk goed doen, dan hoeft de optimalisatie story niet te verstoffen op de backlog.
Comments