Canvas Apps, geen Kan-vast Apps
- thim90
- Nov 17
- 5 min read
"Technisch kan het wel."
Dat is vaak het startpunt van een Canvas App. Maar te vaak ook het begin van een verkeerd gekozen route.
Canvas Apps kunnen geweldig zijn, mits goed toegepast en in de juiste scenario’s.
Maar wat ik in de praktijk zie, is dat ze te vaak worden ingezet voor situaties die vragen om een andere oplossing.
Je kunt prima een Canvas App maken om het betreffende probleem op te lossen, maar of dat verstandig is… is een andere vraag.
Niet alleen bij klanten zie ik dat men in deze valkuil trapt. Ook online zie ik regelmatig Canvas Apps die overduidelijk een slecht nagebouwde Model-Driven App zijn, vaak ook nog met SharePoint als “database”.
Sinds kort hanteer ik daar een nieuwe term voor: een Kan-Vast app.
Ja, het kan vast. Maar of je dat moet willen, is een tweede.
📝 Waarom deze blog?
Er zijn talloze breakdowns online over de verschillen tussen Canvas en Model-Driven.
Zeker sinds AI het web volspuit met vergelijkingslijstjes vol technische voor- en nadelen.
Canvas Apps: pixel-perfect, meerdere databronnen.
Model-Driven: vaste UI, Dataverse.
En steevast is het oordeel: Canvas = flexibel, Model-Driven = beperkt.
Maar de vraag is: heb je die flexibiliteit echt nodig?
En moet techniek altijd leidend zijn?
Naar mijn mening ligt dat wat genuanceerder. De vraag zou lang niet altijd moeten zijn wat kan er, maar wat wil je bereiken?
En niet alleen op korte termijn, maar ook: hoe ziet de app eruit over twee jaar?
🎯 Casus: hoe een Canvas App veranderde in een model-driven drama
Een organisatie wilde “even snel” een app bouwen voor buitendienstmedewerkers om klantbezoeken vast te leggen. Geen budget voor een Dynamics-implementatie, maar gewoon snel belangrijke zaken kunnen vastleggen.
Snel schakelen, weinig gedoe, mooie UI. Oh ja, en we willen geen hoge licentiekosten.
Klinkt als een prima Canvas App-use case, toch?
Misschien wel, totdat:
Marketing ook toegang wilde, maar dan met alleen-lezen rechten
Sales eigen dashboards wilde, in dezelfde app
Er behoefte ontstond aan auditing, validaties en rapportages
De app meertalig moest worden
De app moest integreren met andere systemen binnen het IT-landschap
En men vroeg of ook “even snel” een goedkeuringsflow en dossierbijlagen konden worden toegevoegd
Het resultaat? Een app met tientallen schermen, honderden regels losse Power Fx, inconsistent gedrag per apparaat, en een ontwikkelaar die de helft van zijn tijd kwijt was aan bugfixes.
En vooral: een app die functioneel bijna alles van een Model-Driven App nabouwde… maar dan zonder de schaalbaarheid, onderhoudbaarheid of robuustheid.
En visueel? Verre van de ‘strakke app’ die men voor ogen had.
In eerste instantie had een Canvas App prima gepast, mits men gestopt was bij het simpel registreren van gespreksverslagen. Het gevaar ligt echt in het bloemkolen van requirements.
Waarbij sommigen zullen zeggen: "Ja, maar dat is agile."
Maar agile blijven doorbouwen zonder op tijd te reflecteren of het niet verstandiger is om te refactoren, is juist het opbouwen van technical debt.
Evenals het, in naam van agile, niet nadenken over de gedroomde eindoplossing.
De fout lag niet in het beginnen met Canvas, maar in het niet heroverwegen toen de scope veranderde.
🎨 Pixel-perfect? Of gewoon pixel-gepieker?
Een veelgehoord argument vóór Canvas is: "Je kunt alles pixel-perfect ontwerpen."
En dat klopt.
Maar dat is geen voordeel op zich , het is een verantwoordelijkheid.
Als je pixel-perfect UI wilt, dan moet je het ook perfect doen:
Responsive gedrag op alle schermformaten
Componenten herbruikbaar opzetten
Consistente spacing en contrast toepassen
Rekening houden met accessibility
Zonder ervaring met UX-design én zonder diepgaande kennis van Canvas App-structuur wordt het eindresultaat zelden elegant.
Sterker nog: de veel Canvas Apps die ik in het wild zie, proberen er professioneel uit te zien, maar voelen aan als een matige website uit 2010.
UI is een vak. En vrijheid zonder richting leidt zelden tot iets moois.
Ja, er komen steeds meer mooie voorbeelden online. Maar dat kost tijd, aandacht én onderhoud.
Het idee dat Canvas “snel” is, houdt alleen stand bij simpele apps.
Model-Driven biedt daarentegen out-of-the-box:
Structuur
Beveiliging
Validatie
Auditing
En vaak: betere UI op grotere schaal
En dat zonder dat jij alles hoeft te bouwen.
Mijn verwachting is dat dit eveneens gaat gelden voor de nieuw aangekondigde Code Apps. Dat het straks mogelijk wordt om "Canvas Apps" bij elkaar te prompten, betekent nog steeds niet dat je dat ook altijd maar moet doen.
PS. Wil je wél leren hoe je moderne, strakke Canvas Apps bouwt? Schrijf je in voor mijn nieuwsbrief! ik deel er regelmatig over.
🔍 Wanneer moet je je afvragen: “Moet dit wel Canvas App zijn?”
Voor de juiste keuze zijn er meerdere aspecten die je in overweging moet nemen. Natuurlijk speelt data daarin een rol. Maar je moet jezelf ook de volgende vragen stellen:
Wat wil je oplossen?
Voor wie is de app?
Welke devices gebruiken ze?
Hoeveel gebruikersgroepen zijn er?
Hoe complex is het proces?
💡 Mijn vuistregel:
Canvas Apps zijn geschikt voor taakgerichte applicaties. Een lichte app met een duidelijk doel en beperkte scope.
Met enkele zinnen uit te leggen. Gericht op één of enkele duidelijke gebruikersgroepen.
Enkele typische red flags voor Canvas Apps zijn:
Meerdere gebruikersgroepen met verschillende rechten en rollen
Proces gedreven apps (bijv. meerdere actoren voeren elk een deel uit)
Ontzettend veel schermen en formulieren
Grote datasets
De UI is niet het onderscheidende element (qua UX)
In deze gevallen zou een solution architect serieus moeten overwegen of een Model-Driven App met Custom Pages en/of PCFs niet veel beter past.
Samengevat:
Canvas Apps zijn geen standaardkeuze. Ze zijn een bewuste keuze voor specifieke situaties, vaak taakgericht, mobiel, visueel, of sterk device-afhankelijk.
🧩 Custom Pages en PCFs: het middenpad
Het te snel grijpen naar Canvas Apps komt soms ook voort uit een gebrek aan kennis van wat er allemaal wél mogelijk is binnen Model-Driven Apps. De keuze is namelijk niet binair.
Het is goed mogelijk om de kracht van Model-Driven Apps te combineren met de flexibiliteit van Canvas Apps via Custom Pages. Daarmee kun je maatwerk UX toevoegen waar nodig.
Daarnaast zijn er verschillende andere manieren om de UI/UX van een Model-Driven App te verbeteren. Denk hierbij aan:
Ribbon Commands
Themes
PCFs
Zo combineer je de schaalbaarheid en structuur van Model-Driven Apps met de vrijheid van Canvas, maar dan zonder de chaos.
Maar er komt iets nieuws aan dat het speelveld echt kan veranderen:
Generative Pages, momenteel in preview.
Met Generative Pages kun je op basis van je datamodel en businesslogica automatisch schermen genereren inclusief responsive layout en standaardinteracties.
Deze pagina's zijn vergelijkbaar met Custom Pages, maar dan gebouwd met Vibe Coding.
Lekker prompten dus🤓
Voor organisaties zonder frontend-ervaring, maar mét UX-wensen, kan dit de sweet spot worden:
✅ Snel iets werkends
✅ Consistente layout
✅ Maatwerk waar het telt
Generative Pages hebben de potentie om een gamechanger te worden. Maar ook hierbij geldt: omdat het makkelijker wordt om ze te maken, betekent dat nog niet dat je het ook altijd maar moet doen.
🧠 Architectuur gaat over durven kiezen
Als solution architect kijk ik niet alleen naar wat er technisch kan, maar vooral naar wat verstandig is:
Wat past bij het proces?
Wie zijn de gebruikers?
Hoe ziet de moonshot eruit?
Wat is het onderhoudsprofiel?
Wie gaat dit beheren?
Waar zit de echte toegevoegde waarde van maatwerk?
Zoals Stephen Covey zegt: Start with the end in mind.
Canvas Apps zijn fantastisch, als je weet waarom en wanneer je ze gebruikt.
Maar laten we stoppen met het bouwen van "kan-vast apps" .
Bouwen wat kan is makkelijk. Bouwen wat klopt, dát is vakmanschap.
💬 Zit je met deze vragen?
Loop je met een use case rond en twijfel je of Canvas of Model-Driven de beste keuze is?
Of zie je dat een app eigenlijk iets anders moet zijn dan het nu is?
Ik denk graag met je mee.
Stuur me gerust een berichtje of plan een sparsessie via mijn site.
Soms is één goed gesprek genoeg om je weken werk (en frustratie) te besparen.
Comments