Je opent de Flutter Web versie van je schitterende mobiele app op je telefoon en … wacht. En dat terwijl Flutter juist bekend staat om zijn snelle mobiele app prestaties. Wat gaat er mis? 🤯

De uitdaging

🌐 Flutter Web laadt en intialiseert bij opstarten een gigantische rendering-engine in JavaScript of WebAssembly. Dit veroorzaakt lange opstarttijden vergeleken met echte mobiele Flutter-apps. Gevolg is een slechte eerste indruk en mogelijk afhaken van gebruikers. Dit maakt Flutter Web een slechte keuze voor “kleine” apps die je snel wilt raadplegen.

Enkele tips om het leed iets te verzachten zijn:

1️⃣ Bouw een loader die installatie van de mobiele app promoot. 🚀

2️⃣ Gebruik een CDN: Zorg dat de downloadsnelheid optimaal is.

3️⃣ Lazy loading: Laad enkel de noodzakelijke componenten eerst.

4️⃣ Optimaliseer assets: Gebruik lichte formaten, zoals WebP.

Het is tegenwoordig al beter dan voorheen en Google werkt nog steeds aan optimalisaties, maar we zijn er nog niet. Tot die tijd: weet wanneer Flutter Web de juiste keuze is.

Onlangs woonde ik een presentatie bij over digitale toegankelijkheid volgens de WCAG en de 🇪🇺 European Accessibility Act (EAA). Iedereen, inclusief mensen met een beperking🧑‍🦯, moet zonder drempels onze digitale producten kunnen gebruiken. Dat lijkt me logisch, en dat wordt binnenkort zelfs een wettelijke eis! ⚖️

Ik had hier zelf nog nooit bij stilgestaan, maar het blijkt in praktijk een kleine moeite om een groot verschil te maken: 🏆

👉 Vergroot de tekst in je browser of telefoon eens naar 150% of zelfs 200%. Wat doet dat met je layout? ✅ Zorg dat alles leesbaar en toegankelijk blijft voor slechtzienden.

👉 Loop je (web) app eens door met een screen reader. Kun je alle elementen herkennen en makkelijk navigeren? ✅ Zo maak je je app bruikbaar voor iedereen.

In de WCAG standaard staan hiernaast heel veel suggesties die het gebruik van (web) apps voor iedereen gemakkelijker maken. Een bron van UX inspiratie voor iedereen om eens doorheen te bladeren. 🌐

Omdat ik voor het vinden van bezienswaardigheden 🏛️ en goede eetgelegenheden 🍽️ regelmatig gebruik maak van Google reviews, deel ik zelf al jaren mijn ervaringen voor anderen. Zo ben ik in Google Maps langzamerhand opgeklommen tot een “Local Guide” van (bijna) niveau 8, met onder andere ruim een miljoen fotoweergaven.

Om dit bij te houden ga ik er soms even voor zitten om korte reviews ✍️ te schrijven, foto’s 📷 te uploaden en simpele vragen ✅ te beantwoorden over de plaatsen waar ik ben geweest. Hierbij is het telkens weer fascinerend hoe goed Google weet waar ik allemaal ben geweest.

Maar deze week gebeurde er iets vreemds: Ik kreeg vragen over een bedrijf waar ik een paar weken geleden slechts met een bemiddelaar over heb (gebeld en) gemaild. 🕵

🤔 Zou Google werkelijk mijn emails en fysieke locatie combineren tot een (hallucinante) nieuwe werkelijkheid?

Stop dus met fantaseren 🦄, en begin met bouwen! 🚀

Ken je dat? 🤔 De harde eis dat er eerst een volledige specificatie 📚 moet zijn voor we “veilig” aan de realisatie kunnen beginnen? Bij een van mijn klanten lag er na een jaar zwoegen een enorme berg documentatie, waar zelfs de auteurs het overzicht kwijt waren 😅. – Wat zouden we ook alweer bouwen?

Het probleem: te veel tijd in plannen, te weinig tijd in de praktijk. Documentatie is waardevol, maar alleen als het project vooruit gaat. Analyseren blijft belangrijk, maar er komt een punt waarop je gewoon moet starten met bouwen! Door direct aan de slag te gaan, leren we sneller en ontdekken we vroegtijdig wat werkt (en wat niet) 💡.

Een paar tips om te voorkomen dat je in analyse blijft hangen:

1️⃣ Bouw al vroeg prototypes of (beter nog) een “minimum viable product”: Laat iets tastbaars te laten zien in plaats van alleen een wolk van mooie woorden. 📦

2️⃣ Werk iteratief: Bouw en test in korte cycli; en gebruik elke stap om feedback te verzamelen en te leren. ♻

3️⃣ Betrek de echte gebruikers: Schrijf geen ellenlange rapporten en bouw geen mockups, maar toon regelmatige demo’s van het echte product en voer inhoudelijke gesprekken over wat de gebruikers nodig hebben. 🎬

Eindresultaat? Een beter product, in minder tijd. Dus… waar wacht je nog op? Tijd om te bouwen! 🛠️

Open-source code gebruiken is verleidelijk makkelijk: even iets van GitHub plukken, en voilà! 🍄 Maar niet elke open-source licentie komt zonder verplichtingen. Sommige licenties zijn “besmettelijk” ☢️. Als je code met zo’n licentie in je project opneemt, kunnen “copyleft” licentie-eisen inhouden dat je mogelijk jouw eigen code openbaar moet maken.

De bekendste besmettelijke licenties zijn:

☢️ GNU General Public License (GPL)
☢️ Affero General Public License (AGPL)

Voeg je code met een van deze licenties toe aan je eigen project, dan kunnen de licentie voorwaarden zich uitbreiden naar jouw code. Niet ideaal als je werkt aan een commercieel product. 💣

Gelukkig valt veel open source code onder een van de populaire “permissieve” licenties 🌈, die veel minder eisen stellen:

🌈 MIT-licentie
🌈 Apache-licentie 2.0
🌈 BSD-licentie

Met deze licenties kun je de code (meestal) zonder zorgen gebruiken en aanpassen.

Tips om problemen te voorkomen: 🛟

1. Check altijd de licentie voordat je een library toevoegt of kopieert.
2. Twijfel je? Win dan juridisch advies van experts in.
3. Zoek alternatieven: Die zijn er meer dan je verwacht.
4. Gebruik tracking tools zoals FOSSA, Snyk of Black Duck geven je automatisch inzicht in de gebruikte licenties binnen je project.

Open source is een geweldige bron, maar kent zijn eigen regels. Voorkom verrassingen door licenties serieus te nemen. Zo blijf je een hoop werk en stress bespaard. 💣