latest

FDND Docs

Body of Knowledge, Skills and Attitude

In dit document beschrijven wij de gerichtheid en het corpus van de opleiding Frontend Design & Development. In het hoger onderwijs wordt dit de body of knowledge, skills and attitude (BOKSA) genoemd.

Wij lichten eerst toe wat wij verstaan onder de term ‘frontender’, omdat dit verheldert waar wij voor opleiden. Vervolgens brengen wij aan de hand van de development lifecycle (DLC) de BOKSA zo volledig mogelijk in kaart. Vanzelfsprekend, en geheel in lijn met de aard van het vakgebied, zien wij dit als een levend document dat doorlopend aan verandering onderhevig is.

De Frontender

Het is lastig om te beschrijven wat een frontender precies doet. Er is geen algemeen geaccepteerde en gebruikte functietitel die specifiek gericht is op vaardigheden in HTML, CSS en JS. Er zijn in het vakgebied wel wat suggesties — voorbeelden zijn: CSS/HTML Developer, Frontend Developer, Frontend Engineer, Frontend Web Designer, UI Developer, Mobile Frontend Developer, Frontend SEO Expert, Frontend Toegankelijkheidsexpert, Frontend DevOps, Frontend Tester — maar deze hebben allemaal hun eigen beperkingen (Cohier, 2017).

Zoals overal binnen de ICT vindt ook binnen het frontend-vakgebied arbeidsdeling plaats. Enerzijds zijn er frontenders die zich meer richten op HTML, CSS en user experience (UX). Deze front-of-the-front-end ontwikkelaars zijn verantwoordelijk voor de vormgeving en het uiterlijk van een website door middel van HTML, CSS en presentatie-JavaScript. Anderzijds zijn er frontenders die zich focussen op JavaScript, frameworks en tools. Deze back-of-the-front-end ontwikkelaars schrijven de bedrijfslogica en functionaliteit van een website met JavaScript door bijvoorbeeld gegevens van API's op te halen en weer te geven. (Frost, 2021) Deze twee groepen lopen steeds meer uit elkaar door de groeiende complexiteit van JavaScript. Dit ligt ten grondslag aan eerder beschreven onduidelijkheid over functiebeschrijvingen en waardering van vaardigheden. (Cohier, 2019) FDND omarmt en bedient beide specialisaties omdat ze elkaar aanvullen en blijft daarmee gericht op het geheel.

Een goede frontender wordt gekenmerkt door een aantal belangrijke eigenschappen. Vooraleerst beschikt deze over sterke technische vaardigheden op het gebied van HTML, CSS en JavaScript en ontwerpen voor het web. Heel belangrijk is gedegen kennis op het gebied van gebruiksvriendelijkheid en toegankelijkheid. Een frontender kan zich inleven in de gebruiker en stelt deze centraal in het ontwerp- en ontwikkelproces. Daarbovenop heeft een frontender uitstekende communicatieve vaardigheden en lost met een team op een constructieve manier problemen op. Tenslotte blijven frontenders voortdurend bijleren gezien de snelle ontwikkelingen in het vak. (Cohier, 2018)

Bronnen en voorbeelden

Fenna vertelt in 7 minuten waar ze nu werkt en wat ze zoal doet als frontend developer bij Build - https://vimeo.com/456884089

Chanel vertelt wat zij zoal doet bij Triple als Frontender - https://vimeo.com/453220098

Development lifecycle

Met FDND willen wij studenten zo goed mogelijk voorbereiden op de beroepspraktijk. De veranderlijke beroepspraktijk en de diversiteit in instroom van studenten qua vooropleiding, gender en cultuur vragen om een flexibel onderwijsprogramma. Die diversiteit maakt het bovendien belangrijk dat wij goed kunnen omgaan met individuele verschillen tussen studenten. Daarnaast vinden wij het van groot belang dat studenten leren zelfstandig te opereren in een steeds complexer wordende wereld.

Om die reden gebruiken wij bij het ontwerp van het curriculum en de fasering van opdrachten een projectmethodiek (Scrum) die in de beroepspraktijk standaard is. Scrum hanteert een vaste, in de praktijk beproefde projectcyclus die de development lifecycle (DLC) wordt genoemd. FDND implementeert deze manier van werken in het hele programma. Daarom beschrijven wij de BOKSA ook aan de hand van de DLC. Bij elke fase worden werkzaamheden en een woordenlijst beschreven.

De development-lifecycle

Bij elke leertaak wordt de DLC doorlopen. Daardoor i) ontwikkelen studenten een standaardaanpak voor frontend-praktijkvraagstukken, ii) werken zij systematisch aan leertaken, iii) ontwikkelen zij doorlopend het gedragscriterium ‘Methodisch handelen’, iv) ervaren zij de relevantie van het geleerde en v) verwerven zij de kennis, houding en vaardigheden die de beroepspraktijk van hen vraagt.

De development lifecycle hanteert de volgende fasering:

  1. Analyseren – bijvoorbeeld: teamorganisatie, grip krijgen op een opdracht door gesprekken met een opdrachtgever, schrijven van een debriefing, maken van een takenlijst, inventarisatie van bestaande informatie, overzicht creëren, plannen, definition of done et cetera.
  2. Ontwerpen – bijvoorbeeld: het maken van idee-schetsen, customer journey, breakdown chart, wireflows, navigatiestructuur en layout.
  3. Bouwen – bijvoorbeeld: toepassen van webtechnologie (HTML, CSS, JS), gebruik van tooling, werken volgens conventies en wetgeving, documenteren en bijhouden van een changelog.
  4. Integreren – bijvoorbeeld: publiceren, live zetten, uploaden naar de server, toevoegen in een bestaand systeem, FTP‑en.
  5. Testen – bijvoorbeeld: unit testing (TDD), system tests, user tests, device lab tests, A/B testing.

Analyseren

In de analysefase onderzoekt en inventariseert de student wat er moet gebeuren om een taak uit te voeren. Er zijn verschillende technieken die daarbij kunnen worden gebruikt. De aanpak verschilt per sprint, afhankelijk van de fase van het project.

Wanneer een student voor de eerste keer met een team samenwerkt, is het zinvol om een teamcanvas in te vullen om afspraken te maken en conventies vast te stellen. Vaak spreekt het team de opdrachtgever in een briefing- en debriefingsessie.

Leeruitkomsten Analyseren

Kennis: de student kent ...

  • de rol van de analysefase binnen de development lifecycle (DLC) en Scrum.
  • het doel en de opzet van een teamcanvas en (code) conventies.
  • het verschil tussen briefing en debriefing en de belangrijkste onderdelen van beide.
  • de stappen van een contentanalyse (inventarisatie, beoordeling, SEO, UX).
  • de basisconcepten van project management:
    • project board (kolommen, taken, workflow),
    • GitHub‑begrippen: repository, commit, branch, fork, issues, pull request, README.
  • de begrippen epic, user story, job story en hun onderlinge relatie.
  • het principe van planning poker als schattingsmethode.
  • de categorieën in MoSCoW‑prioritering (must, should, could, won’t).
  • het idee van verschillende budgetten (financieel, performance, accessibility) en hun impact op scope.
  • de factoren die meewegen bij het bepalen van een tech‑stack (doelen, expertise, infrastructuur, community, security, etc.).

Skills: de student kan ...

  • samen met een team een teamcanvas invullen en (code)conventies afspreken en vastleggen.
  • op basis van een briefing een debriefing schrijven die doelen, scope, randvoorwaarden en open vragen expliciteert.
  • een contentinventarisatie maken en content globaal beoordelen op kwaliteit, relevantie, structuur en vindbaarheid.
  • een project board opzetten (kolommen, kaarten, labels) en dit gedurende de sprint actief bijhouden.
  • een eenvoudige GitHub‑projectinrichting doen:
    • repo aanmaken/klonen,
    • README toevoegen,
    • issues en branches gebruiken om werk te structureren.
  • uit een opdracht epics afleiden en deze vertalen naar concrete user stories en/of job stories.
  • stories vertalen naar taken en deze opnemen in board/issues.
  • met het team planning poker uitvoeren en verschillen in inschatting bespreken.
  • taken en stories prioriteren met behulp van MoSCoW.
  • op basis van doelen en constraints meedenken over een passende tech‑stack en keuzes beargumenteren.
  • eenvoudige budgetten (tijd, performance, accessibility) meewegen bij het bepalen van scope.

Attitude: de student...

  • neemt actief deel aan het maken van teamafspraken en houdt zich hieraan.
  • vraagt expliciet om verduidelijking bij onduidelijke opdrachten (briefing/debriefing‑houding).
  • toont methodisch handelen: analyseert eerst het probleem voordat er gebouwd wordt.
  • is transparant over voortgang door het project board en issues up‑to‑date te houden.
  • weegt belangen van eindgebruiker, opdrachtgever en team af bij scope‑ en prioriteitskeuzes.
  • is bereid aannames te herzien na nieuwe informatie (bijv. uit contentanalyse of debriefing).
  • heeft oog voor haalbaarheid: denkt in termen van budgetten (tijd, performance, toegankelijkheid) en maakt dit bespreekbaar.
1. Samenwerking en teamafspraken
Teamcanvas

Een teamcanvas is een raamwerk dat helpt bij het ontwikkelen en uitlijnen van de teamdynamiek. Met aandacht ingevuld helpt het teams bij:

  • het definiëren van doelen voor het team en voor individuele teamleden;
  • het maken van afspraken over kernwaarden en gedragsregels;
  • het in kaart brengen van sterke en zwakke punten;
  • het bespreekbaar maken van behoeften en verwachtingen.

Lees meer op: https://www.theteamcanvas.com/

(Code) Conventions

(Code) conventions zijn richtlijnen voor programmeurs om de leesbaarheid en het onderhoud van broncode te verbeteren. Ze omvatten zaken als bestandsorganisatie, inspringen, commentaar, naamgeving en programmeerpraktijken. Het volgen van deze richtlijnen kan de onderhoudskosten van software verlagen en de kwaliteit verbeteren.

Even bad code can function. But if code isnt clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code.
– Robert C. Martin

Voorbeelden:

In semester 1 werken studenten met drie basisregels voor code conventions:

  • Geef HTML ademruimte.
  • Schrijf CSS‑selectors in dezelfde volgorde als de HTML.
  • Nest media queries.

In Semester 3 & 4 worden de code conventies van FDND Agency geïntroduceerd: https://docs.fdnd.nl/conventies.html#code-conventies

2. Opdracht en inhoud begrijpen
Briefing en debriefing

Een briefing is de initiële instructie waarin de opdrachtgever duidelijk maakt wat er onderzocht moet worden. Dit omvat de hoofdvraag, doelen, de afbakening van het onderzoek en de verwachtingen van de opdrachtgever. De briefing helpt om het onderzoeks- of ontwerpproces in goede banen te leiden en zorgt ervoor dat de student weet wat er verwacht wordt.

Een debriefing is de terugkoppeling van de student (of het team) aan de opdrachtgever om te bevestigen dat de opdracht goed is begrepen. Tijdens de debriefing worden onduidelijkheden opgehelderd en wordt besproken of de student op de juiste weg zit. Het doel is om misverstanden te voorkomen en ervoor te zorgen dat het werk aansluit bij de verwachtingen.

Bronnen:

Contentanalyse

Een contentanalyse voor een website is een gestructureerde methode om de inhoud van een website te evalueren en te beoordelen. Het doel is om te begrijpen hoe effectief de content is in het bereiken van de doelgroep en het behalen van bedrijfsdoelen. Dit proces omvat vaak de volgende stappen:

  • Inventarisatie van content: een volledige lijst maken van alle inhoud op de website, inclusief tekst, afbeeldingen, video’s, blogs, productpagina’s, enzovoort.
  • Evaluatie van kwaliteit en relevantie: beoordelen of de content voldoet aan de doelen van de website, zoals informatie verstrekken, de gebruiker begeleiden of een merkboodschap overbrengen.
  • SEO‑analyse: controleren of de content geoptimaliseerd is voor zoekmachines. Dit omvat het analyseren van het juiste gebruik van zoekwoorden, meta‑tags en andere SEO‑elementen die de zichtbaarheid in zoekresultaten beïnvloeden.
  • User experience (UX): beoordelen hoe goed de content georganiseerd is en of deze gemakkelijk te navigeren en te consumeren is. Hierbij wordt gekeken naar lay‑out, leesbaarheid en hoe intuïtief de site is.

Een goede contentanalyse helpt bij het identificeren van zwakke plekken in de inhoud en biedt een strategie om deze te verbeteren, zodat beter wordt aangesloten bij de behoeften van de doelgroep en de bedrijfsdoelen.

Bronnen:

3. Project management en tooling
Project board inrichten

Een project board is een visueel hulpmiddel om de voortgang van een project te organiseren en te beheren. Het helpt teams om taken, deadlines en verantwoordelijkheden duidelijk te visualiseren. Een goed ingericht project board bestaat vaak uit een aantal standaardcomponenten die bijdragen aan overzicht en efficiëntie.

Stappen om een project board in te richten:

  1. Kies een tool: er zijn verschillende tools beschikbaar voor project boards, zoals GitHub, Trello, Asana, Jira of MS Azure DevOps. Elk biedt aanpasbare borden waarmee taken en statussen kunnen worden bijgehouden. Bij FDND wordt voornamelijk gewerkt met GitHub, maar tijdens stages kunnen studenten andere tools tegenkomen.

  2. Maak kolommen aan: organiseer het project board door kolommen te creëren die de workflow representeren. Veelvoorkomende kolommen zijn: To do, In progress, Review, Done. Afhankelijk van de aard van het project kunnen extra kolommen nuttig zijn, zoals “Blokkerende issues” of “Afwachting goedkeuring”.

  3. Maak taken (cards): voeg specifieke taken toe als cards (op GitHub, Trello of Jira bijvoorbeeld) binnen de kolommen. Elke taak bevat bij voorkeur gedetailleerde informatie, zoals beschrijvingen, subtaken, deadlines en verantwoordelijke teamleden.

  4. Wijs verantwoordelijkheden toe: koppel teamleden aan de taken, zodat duidelijk is wie waarvoor verantwoordelijk is.

  5. Stel prioriteiten: geef aan welke taken het meest urgent zijn door prioriteitslabels of kleuren te gebruiken. Dit helpt het team te focussen op wat eerst moet worden aangepakt.

  6. Werk het project board bij en onderhoud het: een project board is dynamisch. Het wordt regelmatig geüpdatet om voortgang bij te houden, taken te verplaatsen tussen kolommen en nieuwe taken toe te voegen.

  7. Voeg tijdslijnen en deadlines toe: maak gebruik van tijdsmanagementfuncties zoals deadlines, kalenderintegraties en herinneringen. Zo blijft iedereen op de hoogte van de planning en kan er tijdig worden bijgestuurd.

Belangrijke tips:

  • Gebruik visuele elementen (labels, kleuren, tags) om verschillende taken of fasen van elkaar te onderscheiden.
  • Maak gebruik van communicatie- of commentaarsecties binnen taken voor snelle updates of vragen.
  • Zorg voor een duidelijk overzicht van voltooid werk, werk in uitvoering en wat nog gepland is; dit ondersteunt rapportages en evaluaties van de projectvoortgang.
Projectinrichting

GitHub is in het vakgebied een van de meest gebruikte platformen om samen te werken aan webprojecten en biedt verschillende tools om een project in te richten. Hieronder een samenvatting van de meest gebruikte onderdelen:

  • Project Board: geeft een visueel overzicht van de voortgang van taken, met kolommen zoals "To Do", "In Progress" en "Done". Het helpt bij het organiseren van werk en het volgen van de status van het project.
  • Repository: een repository (repo) is een centrale opslagplaats op GitHub voor projectbestanden en de volledige geschiedenis van wijzigingen. Het bevat broncode, documentatie en andere bestanden. Met behulp van versiebeheer (zoals Git) kunnen teams wijzigingen bijhouden, samenwerken en terugdraaien naar eerdere versies.
  • Commit: een commit is een wijziging in een Git‑repository. Deze legt vast wat er is veranderd in de code en bevat een beschrijving (commit message) van die wijziging. Elke commit functioneert als een versie van het project, waardoor kan worden teruggekeerd naar eerdere versies van de code.
  • Forks: een fork is een kopie van een project naar een eigen GitHub‑account. Dit stelt ontwikkelaars in staat om aanpassingen te maken zonder de originele code te beïnvloeden. Dit is handig voor experimenteren of bijdragen aan externe projecten.
  • README.md: de README.md bevat belangrijke informatie over het project, zoals installatie‑instructies, gebruikshandleidingen en doelstellingen. Het helpt teamleden en bijdragers om snel aan de slag te gaan.
  • Issues: issues worden gebruikt om taken, bugs of verbeteringen bij te houden. Ze zorgen voor een overzicht van wat er gedaan moet worden, wie eraan werkt en wat de prioriteit is.
  • Pull Requests (PR’s): een pull request is een voorstel om wijzigingen uit een afzonderlijke branch te integreren in de dev branch. Het team kan de voorgestelde wijzigingen beoordelen, feedback geven en, indien goedgekeurd, samenvoegen.
  • Branches: een branch is een aparte versie van de code die onafhankelijk van de hoofdtak ontwikkeld kan worden. Voor elke nieuwe feature of bugfix wordt een aparte branch aangemaakt om gefocust te werken zonder de stabiele versie te verstoren.

Bronnen:

4. Scope, planning & prioritization
Taken vaststellen

In een webproject worden epics, user stories en job stories gebruikt om het werk te structureren en overzichtelijk te maken. Hieronder volgt een uitleg over hoe deze elementen kunnen worden afgeleid en hoe ze uiteindelijk worden vertaald naar concrete taken binnen het project.

  1. Epics: een epic is een grote, overkoepelende functie of onderdeel van een project dat vaak te complex is om in één keer te realiseren. Het beschrijft een kernfunctionaliteit van de webapplicatie op hoog niveau.
    Voorbeeld: “Gebruikers kunnen inloggen en hun profiel beheren”.

  2. User stories: uit een epic worden user stories afgeleid, die specifieke delen van de epic beschrijven vanuit het perspectief van de gebruiker. Een user story focust op wat de gebruiker wil bereiken met de functionaliteit, geschreven in eenvoudige, niet‑technische taal.
    Template: Als [type gebruiker] wil ik [doel], zodat [reden].
    Voorbeeld: Als ingelogde gebruiker wil ik mijn profielgegevens kunnen wijzigen, zodat ik mijn persoonlijke informatie kan updaten.

  3. Job stories: job stories zijn een alternatief voor user stories, waarbij de focus meer ligt op de context en motivatie achter het gebruik van een functie. Ze leggen uit wat een gebruiker probeert te bereiken in een specifieke situatie, wat handig kan zijn bij het verfijnen van functionaliteit.
    Template: Wanneer [situatie], wil ik [actie], zodat [uitkomst].
    Voorbeeld: Wanneer ik mijn adres wil updaten, wil ik een intuïtieve manier om dit te doen op mijn profielpagina, zodat ik zeker weet dat mijn leveringen goed aankomen.

  4. Taken afleiden: uit zowel user stories als job stories kunnen concrete taken worden afgeleid. Deze taken zijn specifieke acties die nodig zijn om de vereiste functionaliteiten te realiseren.
    Voorbeelden van taken op basis van bovenstaande stories:

    • Ontwerp en implementeer een "Bewerk profiel"-pagina.
    • Voeg een formulier toe om naam, e‑mail en adres te wijzigen.
    • Zorg voor validatie van het formulier.
    • Implementeer een back‑end API om profielwijzigingen op te slaan.
    • Test de functionaliteit en de mobiele versie.

Bronnen:

Planning poker

Planning Poker is een Agile‑methode die teams helpt om de tijd en moeite voor taken of user stories in te schatten.

Werkwijze in hoofdlijnen:

  1. Presentatie: de product owner introduceert user stories.
  2. Stemmen: teamleden kiezen in stilte een kaart (met waarden zoals 1, 2, 3, 5, 8, etc.) die hun inschatting weergeeft.
  3. Discussie: na het onthullen van de kaarten bespreken teamleden hun keuzes om verschillende perspectieven te delen.
  4. Herhaling: het proces kan worden herhaald totdat er consensus is.

Bron:

MoSCoW‑prioritering

MoSCoW‑prioritering is een techniek die wordt gebruikt om de prioriteit van vastgestelde taken in een project te bepalen. Het helpt teams bij het focussen op wat essentieel is voor een succesvolle oplevering. De term "MoSCoW" staat voor vier categorieën van prioriteiten:

  • Must have: essentiële taken die absoluut moeten worden gerealiseerd om het project te laten slagen.
  • Should have: belangrijke taken die niet kritisch zijn, maar wel aanzienlijke meerwaarde bieden.
  • Could have: wensen of optionele features die kunnen worden toegevoegd als er tijd en middelen beschikbaar zijn.
  • Won’t have this time: vereisten die voor nu worden uitgesloten, maar mogelijk in de toekomst kunnen worden overwogen.

Bron:

Budgetten

Een frontender maakt gebruik van verschillende budgetten die de mogelijke reikwijdte van een project begrenzen:

  • Een financieel budget wordt gebruikt om kosten en uitgaven van een project te beheren. Dit type budget is belangrijk voor het plannen en controleren van financiële aspecten en bepaalt vaak de uren die voor ontwerp en ontwikkeling van een website beschikbaar zijn.
  • Een performance budget is een set richtlijnen om de minimale prestaties van een website of webapplicatie af te bakenen. Het helpt bij het maken van keuzes tijdens de ontwikkeling en waarborgt dat eindgebruikers een positieve gebruikservaring hebben. Opgenomen worden afspraken over: maximale laadtijd, grootte van assets, aantal HTTP‑requests, time to interactive (TTI) en de first contentful paint (FCP). Zie ook Performance budgets 101 @ web.dev.
  • Een accessibility budget is een set richtlijnen om ervoor te zorgen dat een website toegankelijk is. Een accessibility budget helpt bij het waarborgen van een inclusieve en gebruiksvriendelijke ervaring. Opgenomen worden afspraken over: WCAG‑compliance (bijv. A+, A++ of A+++), contrast‑ratio, lettergrootte, keyboard‑navigatie, audiobeschrijving, formulieren, foutmeldingen, focus states, testen en validatie.
Tech‑stack bepalen

Het bepalen van de tech‑stack heeft invloed op de ontwikkeling, prestaties, schaalbaarheid en het onderhoud van een applicatie. Bij deze keuze weegt de student onder meer mee: projectvereisten en -doelen, teamexpertise, compatibiliteit met bestaande IT‑infrastructuur, community en ondersteuning, beveiliging, wetgeving en trends.

Bronnen:

Ontwerpen

Bij de start van deze fase kent de student het doel, het beoogde resultaat en het aanwezige materiaal voor het project. De student weet welke eisen opdrachtgever, eindgebruikers en andere belangrijke partijen aan het resultaat stellen. Het doel van de ontwerpfase is dat de student een ontwerp maakt om mogelijke oplossingsrichtingen te verkennen en een duidelijk beeld te vormen van wat er gerealiseerd gaat worden.

Soms maakt de student het ontwerp van een website from scratch, maar in het frontend‑vak wordt vaak een ontwerp of huisstijl aangeleverd. Doorgaans is dit ontwerp onvolledig of slechts op één resolutie uitgewerkt. Heel af en toe is het ontwerp goed uitgewerkt en zijn alle states van (micro)interacties en transities tussen pagina’s ontworpen of beschreven. Als frontender neemt de student doorlopend ontwerpbeslissingen met betrekking tot structuur (semantiek), flow (breakpoints), (micro)interacties, animaties, toegankelijkheid en prestaties.

Aan het einde van de ontwerpfase is duidelijk hoe het resultaat van het project eruit zal zien. De student maakt keuzes en eventuele alternatieve ontwerpen vallen af.

Leeruitkomst Ontwerpen

Kennis: de student kent ...

  • de rol van de ontwerpfase binnen de development lifecycle (DLC):
    • verkennen van oplossingsrichtingen vóór de bouw,
    • verschil tussen oriënteren, uitwerken en kiezen.
  • de basis van visual thinking en het nut van visueel werken om ideeën en structuren te verkennen.
  • kernbegrippen rond ideation:
    • divergeren en convergeren,
    • het doel van creatieve technieken (brainstorm, mindmap, schetsen).
  • de functie en inzet van:
    • moodboards (sfeer, stijl, richting),
    • style tiles (typografie, kleur, UI‑elementen),
    • morphological charts (ontwerpparameters en combinaties),
    • Harris profiles (gewogen vergelijking van concepten).
  • het doel van prototyping in verschillende fidelities:
    • verschil tussen LoFi en HiFi,
    • wanneer gekozen wordt voor schetsen, paper prototypes of digitale tools (zoals Figma).
  • de basis van information architecture (IA):
    • structureren van content,
    • navigatie‑ en labelingsystemen.
  • de rol en vorm van:
    • sitemaps (hiërarchie),
    • wireframes (pagina‑opbouw),
    • wireflows (schermen + interactiestroom),
    • breakdown‑schetsen (annotaties voor HTML/CSS/JS).
  • het nut van eenvoudige data‑ en flow‑modellen:
    • datamodellen (data models) (entiteiten, relaties),
    • data flow diagrams,
    • activity diagrams (control flow, states).
  • belangrijke design principles voor interfaces:
    • algemene UI‑principes (bijv. van Joshua Porter),
    • atomic design (atoms → molecules → organisms → templates → pages),
    • de UI‑stack (verschillende states, feedbacklagen),
    • responsive design en breakpoints,
    • touch‑design (targets, bereik, gestures),
    • color & contrast, visual hierarchy, proximity en contrast als Gestalt‑principes.

Skills: de student kan ...

  • op basis van een opdracht en doelstellingen:
    • de context en randvoorwaarden van het ontwerpprobleem benoemen,
    • relevante voorbeelden en referenties verzamelen.
  • visual thinking inzetten:
    • ideeën, structuren en user flows schetsen,
    • informatie en beslissingen visueel ordenen.
  • ideation‑sessies voorbereiden en uitvoeren:
    • uiteenlopende oplossingsrichtingen genereren (divergeren),
    • samen met het team keuzes maken en focussen (convergeren).
  • visuele richtingen expliciteren met:
    • een moodboard (sfeer, kleur, beeldtaal),
    • een style tile (fonts, kleuren, UI‑elementen).
  • concepten systematisch verkennen en beoordelen:
    • een morphological chart opstellen met varianten per parameter,
    • een Harris profile maken om concepten op criteria te scoren.
  • ideeën vertalen naar concrete schermvoorstellen:
    • LoFi wireframes schetsen voor verschillende layouts en states,
    • HiFi wireframes of mockups maken in een digitale tool.
  • de structuur van een site of applicatie ontwerpen:
    • een sitemap opstellen op basis van content en user needs,
    • information architecture (IA) beargumenteren (navigatie, labels).
  • interacties en flows uitwerken:
    • wireflows tekenen voor belangrijke user journeys,
    • een breakdown‑schets maken met annotaties voor HTML/CSS/JS.
  • eenvoudige data‑ en procesmodellen maken:
    • een basic datamodel schetsen voor de benodigde informatie,
    • een data flow diagram of activity diagram gebruiken om logica te verduidelijken.
  • design principles toepassen in eigen werk:
    • visual hierarchy, proximity, contrast en kleurgebruik bewust inzetten,
    • rekening houden met responsive gedrag en touch‑interactie,
    • interfaces opbouwen volgens atomic design of componentgedachte.

Attitude: de student...

  • neemt een user‑centered houding aan:
    • denkt vanuit doelen, taken en context van de gebruiker,
    • is bereid aantrekkelijke oplossingen aan te passen als deze niet werken voor de gebruiker.
  • ziet ontwerpen als een iteratief proces:
    • is niet gehecht aan eerste ideeën en durft te schrappen en te verbeteren,
    • gebruikt prototypes om te leren in plaats van om alleen te bewijzen dat iets “af” is.
  • werkt onderzoekend en nieuwsgierig:
    • verkent meerdere oplossingsrichtingen voordat er gekozen wordt,
    • experimenteert met stijlen, structuren en interacties.
  • staat open voor feedback en critique:
    • presenteert ontwerpen vroegtijdig,
    • verwerkt feedback van peers, docenten en stakeholders constructief.
  • denkt in systemen en componenten:
    • kijkt voorbij losse pagina’s naar patronen en herbruikbare elementen,
    • bewaakt consistentie in stijl, interactie en structuur.
  • neemt verantwoordelijkheid voor toegankelijkheid en haalbaarheid:
    • houdt rekening met beperkingen (tijd, technologie, toegankelijkheid),
    • ontwerpt oplossingen die realiseerbaar zijn in HTML, CSS en JS.
1. Orientation & ideation

In deze fase onderzoekt de student het probleem en genereert hij/zij mogelijke richtingen en stijlen voordat er in detail wordt uitgewerkt.

Visual Thinking

Visual thinking leert studenten en docenten hun gedachten en doelen te verbeelden. Het helpt hen bij het creëren van overzicht en het overbrengen van hun boodschap. Kijk voor een overzicht van tekenmethodes op visualthinking.school.

Ideation

Ideation is het creatieve proces waarin actief nieuwe ideeën worden gegenereerd, ontwikkeld en verfijnd. Het gaat verder dan alleen het bedenken van losse ideeën: het omvat een gestructureerde aanpak waarbij verschillende technieken en methoden worden ingezet, zoals brainstormen, mindmaps, design‑thinking‑sessies en schetsen. Het doel van ideation is om innovatieve oplossingen, concepten of strategieën te vinden die inspelen op een specifieke uitdaging of een vraagstuk.

Divergeren & convergeren

Bij ideation verkent de student eerst breed mogelijke richtingen (divergeren) en kiest daarna doelgericht de beste opties (convergeren). Visualiseren helpt om keuzes helder te maken en te communiceren met het team.

Moodboard

Een moodboard is een visueel overzicht dat de sfeer, stijl en richting van een idee of project samenvat. Het bestaat vaak uit een collage van afbeeldingen, kleuren, materialen, typografie en korte teksten die samen een gevoel communiceren.

Het doel van een moodboard is om inspiratie te ordenen en duidelijk te maken welke emotie of stijl een ontwerper wil neerzetten voordat er daadwerkelijk wordt ontworpen of uitgevoerd. Het helpt bij het overbrengen van een concept naar anderen en vormt een gezamenlijk referentiepunt voor een team of klant.

Style Tile

Een style tile bestaat uit lettertypen, kleuren en interface‑elementen die de essentie van een visueel merk voor het web communiceren. Style tiles helpen een gemeenschappelijke visuele taal te vormen tussen ontwerpers en belanghebbenden binnen een project en ondersteunen bij het vaststellen van voorkeuren en doelen van de opdrachtgever. Zie voor uitleg en voorbeelden styletil.es.

Morphological Chart

Een morphological chart laat alternatieven per ontwerp‑parameter zien en stimuleert combinaties om tot nieuwe concepten te komen. Het is een hulpmiddel om systematisch varianten te verkennen vóórdat er een prototype wordt gemaakt.

Harris Profile

Een Harris‑profile is een gewogen beoordelingsmatrix om concepten objectief te scoren op criteria. Zo worden keuzes transparant en herhaalbaar gemaakt binnen het team of de squad.

2. Prototyping & structuring

In deze fase werkt de student ideeën uit in concrete structuren en schermindelingen, zodat duidelijk wordt wat waar komt en hoe gebruikers door de interface bewegen.

Prototyping

Om een ontwerpprobleem op te lossen kan de student verschillende (schets)technieken toepassen om grip te krijgen op de opdracht, ideeën te verkennen en te onderzoeken. In de ontwerpfase van het project is het doel om snel een prototype te maken dat getest en geprobeerd kan worden. Zo ontstaat een helder beeld van wat er gebouwd moet worden.

Een prototype kan van alles zijn, bijvoorbeeld een schets om te bespreken met iemand uit de squad, een paper‑prototype om snel te testen met een gebruiker of een gedetailleerd uitgewerkt design in Figma.

De student kan een wireframe LoFi (low fidelity) of meer HiFi (high fidelity) maken met meer detail en kleur. Voor een HiFi‑wireframe kan goed prototypesoftware worden gebruikt, zoals Figma. Door LoFi‑wireframes te schetsen kunnen snel verschillende layouts worden uitgeprobeerd, ideeën gevisualiseerd, besproken en aangepast.

Information architecture (IA)

Information architecture (IA) is een ontwerpdiscipline die zich bezighoudt met het structureren en organiseren van de content van een website, zodat bezoekers (gebruikers) makkelijk het antwoord op hun vragen kunnen vinden. Het organiseren en structureren van informatie gebeurt door passende organisatiesystemen te ontwerpen voor de content en duidelijke labels en navigatiesystemen te gebruiken.

Sitemap (hiërarchie)

Een sitemap geeft een gestructureerd overzicht van alle pagina’s van een website. Er bestaan verschillende (online) tools om sitemaps mee te maken. Het handmatig schetsen en uitdenken van de sitestructuur met een team kan ook zorgen voor focus en gedeeld begrip in een project.

Breakdown‑schets

Een breakdown‑schets is een wireframe of wireflow met annotaties voor de HTML, CSS en/of JS. Het is een methode die frontenders gebruiken om te onderzoeken welke techniek nodig is om een ontwerp te realiseren in code.

Door blokken in de schets te tekenen voor de HTML, CSS‑properties te annoteren en ideeën voor JS te noteren, ontdekt de student welke technische problemen of uitdagingen te verwachten zijn. Op basis daarvan kan gericht worden gezocht naar inspiratie en codevoorbeelden en kan onderzocht worden hoe iets technisch opgelost kan worden. Dit helpt ook om gerichter te zoeken naar oplossingen online.

Wireframe

Een wireframe is een schematische tekening van een pagina. Met een wireframe kan de student (snel) schetsen hoe een pagina eruit kan komen te zien, wat belangrijk is, welke onderdelen waar komen te staan, wat in de viewport staat en welke elementen interactief zijn.

Wireflow

Een wireflow toont een aantal schermen van een interactie. Het is nuttig om uit te denken wat een gebruiker te zien krijgt wanneer deze iets op een pagina doet, zoals een formulier versturen of met een carrousel verschillende plaatjes of producten bekijken.

3. Data & flows

In deze fase brengt de student in kaart welke data nodig is en hoe die door het systeem en de interface stroomt, zodat ontwerp en architectuur goed op elkaar aansluiten.

Data model

Een data model laat de logische structuur van een database zien, inclusief de relaties tussen tabellen.

Data Flow Diagram

Een Data Flow Diagram is een manier om systemen en software te visualiseren met behulp van Unified Modeling Language (UML). Developers maken dergelijke diagrammen om inzicht te krijgen in de ontwerpen, code‑architectuur en implementatie van complexe softwaresystemen.

Activity Diagram

In een activity diagram ontwerpt de student de logica en structuur van de code door de wireflow en de control flow van een applicatie te combineren.

4. Design principles

Naast concrete technieken werkt de student in de ontwerpfase ook vanuit een aantal algemene design principles die zorgen voor consistente, toegankelijke en schaalbare interfaces.

UI Principles

UI principles zijn richtlijnen voor het ontwerpen van duidelijke, voorspelbare en gebruiksvriendelijke interfaces. Ze helpen je beslissen hoe elementen eruitzien, waar ze staan en hoe ze zich gedragen in reactie op acties van de gebruiker. Denk bijvoorbeeld aan consistentie (zelfde acties geven dezelfde feedback), zichtbaarheid van belangrijke functies, duidelijke affordances (het is zichtbaar wat klikbaar is) en feedback op iedere actie (knoppen, foutmeldingen, loading‑states).

Door bewust met UI principles te werken, voorkom je “toevallig” design: keuzes worden herhaalbaar en uitlegbaar. Dat maakt interfaces niet alleen prettiger voor gebruikers, maar ook beter onderhoudbaar voor teams, omdat iedereen vanuit dezelfde set principes ontwerpt en bouwt.

Atomic Design

Atomic design is een ontwerpmethode voor digitale interfaces die uitgaat van het opdelen van een design in kleine, herbruikbare bouwstenen. Het concept wordt vaak toegepast bij web‑ en app‑ontwikkeling om consistente en schaalbare gebruikersinterfaces te maken.

Met atomic design wordt het eenvoudiger om consistente interfaces te ontwikkelen, componenten te hergebruiken en efficiënter samen te werken tussen ontwerpers en ontwikkelaars.

Not ignoring the UI‑Stack

De UI‑stack is een set van vijf samenhangende states die elke schermervaring dekt. Een ontwerper ontwerpt niet één perfecte statische scherm, maar een continuüm waarin het scherm logisch verandert met de context. De UI‑stack benadrukt alle lagen van een interface (data, state, feedback, affordances, microcopy); door expliciet voor elk niveau te ontwerpen wordt “awkward UI” voorkomen. Een FDND‑toevoeging op het artikel van Scott Hurff is de “initial state”.

Responsive Design

Responsive design is een ontwerpbenadering waarbij websites en applicaties zich automatisch aanpassen aan de schermgrootte en het apparaat van de gebruiker. Het doel is om een optimale gebruikerservaring te bieden, ongeacht of iemand een desktop, tablet of smartphone gebruikt.

Door responsive design te gebruiken, hoeven ontwikkelaars geen aparte mobiele en desktopversies te onderhouden en blijft de inhoud overal goed leesbaar en bruikbaar.

Touch

Ontwerpen voor touch‑interfaces vraagt grotere targets, duidelijke feedback en aandacht voor gestures. Ontwerpers houden rekening met bereikbaarheid, context en verschillende soorten touch‑interactie.

Color & contrast

Color contrast in een ontwerp is belangrijk voor visual hierarchy, leesbaarheid en toegankelijkheid. In de WCAG‑richtlijnen wordt in de standaard Perceivable, onderdeel Distinguishable, beschreven hoe ontwerpers het mensen makkelijker kunnen maken om een website te zien en te horen.

Wat kunnen ontwerpers doen om ervoor te zorgen dat mensen informatie goed kunnen onderscheiden?

  1. Gebruik naast kleur altijd alternatieve informatie.
  2. Gebruik onderscheidende kleuren.
  3. Zorg dat er onderscheid is in saturation en brightness.
  4. Vermijd complementair contrast groen/rood.
  5. Test kleurcontrasten.
Visual hierarchy

Visual hierarchy is belangrijk in webdesign. Het vertelt gebruikers waar zij moeten kijken en welke elementen op het scherm het belangrijkst zijn. Een goede visual hierarchy kan op verschillende manieren worden bereikt, zoals met de grootte van tekst of elementen, gebruik van kleur en contrast, witruimte en de positie van elementen op het scherm.

Proximity

Het Gestalt‑principe van proximity bepaalt hoe gebruikers samenhang zien: gerelateerde elementen worden gegroepeerd en witruimte tussen groepen wordt vergroot om “scanbaarheid” te verbeteren.

Contrast

Contrast in kleur, licht‑donker en grootte stuurt aandacht en leesbaarheid en is cruciaal voor toegankelijkheid. Ontwerpers testen hun combinaties en zorgen dat deze voldoen aan WCAG‑richtlijnen.

Bouwen

In de bouwfase vertaalt de student de keuzes uit de ontwerpfase naar werkende code in HTML, CSS en JavaScript. Op basis van een ontwerpschets bepaalt de student hoe de interface wordt opgebouwd: een project wordt ingericht (bijvoorbeeld met GitHub), de repository wordt lokaal opgezet en stap voor stap wordt aan de frontend gebouwd. Er wordt gestart met een semantische HTML‑structuur, vervolgens wordt CSS toegevoegd voor layout en vormgeving en wordt JavaScript ingezet om interactie en gedrag te realiseren.

In deze fase staat het toepassen van webtechnologie centraal: werken met HTML, CSS en JS, het inzetten van tooling, het volgen van conventies en best practices, en het documenteren van het werk (bijvoorbeeld in een changelog). De student ontwikkelt zijn/haar vaardigheid om deze technologieën te beheersen, past passende ontwikkelmethodes toe en denkt in herbruikbare componenten, bijvoorbeeld met atomic design.

Leeruitkomst Bouwen

Kennis: de student kent ...

  • de basis van web fundamentals:
    • rol en structuur van HTML (semantische elementen, documentstructuur),
    • rol van CSS (layout, typografie, spacing, theming),
    • rol van JavaScript (interactie, gedrag, data‑koppeling).
  • de principes van progressive enhancement:
    • eerst solide HTML, daarna CSS, vervolgens JS,
    • het belang van feature detection en graceful degradation.
  • de kernprincipes van responsive design:
    • mobile first en content first,
    • media queries, container queries, viewport‑meta‑tag,
    • basis van responsive typografie en responsive layouts.
  • het belang van semantiek, toegankelijkheid en DRY in HTML, CSS en JS.
  • de basisconcepten van architecture & data aan de frontend:
    • wat een API is en hoe deze wordt aangesproken,
    • verschillen tussen REST API en GraphQL,
    • het CRUD‑principe (Create, Read, Update, Delete),
    • URL‑driven development en het belang van betekenisvolle URL’s.
  • de verschillende render strategies:
    • client‑side rendering (CSR),
    • server‑side rendering (SSR),
    • static site generation (SSG / static rendering),
    • universal / isomorphic rendering,
    • hydration en het effect op performance, SEO en UX.
  • het doel van een template engine binnen server‑side rendering.
  • de rol van frontend frameworks en meta frameworks:
    • frameworks als Svelte, React, Vue, Angular, 11ty, etc.,
    • meta frameworks als SvelteKit, Next, Nuxt, Astro.
  • het onderscheid tussen frameworks en libraries (bijv. GSAP, Three.js, Storybook, Tailwind).
  • de basis van tooling & workflow:
    • code editors (bijv. VS Code), relevante plugins (ESLint, Prettier, Live Server/Live Preview),
    • browsers en devtools (Elements, Network, Performance, Console),
    • npm als package manager (dependencies, scripts),
    • issues als manier om werk, bugs en verbeteringen te organiseren.

Skills: de student kan ...

  • een ontwerp vertalen naar een werkende webpagina met:
    • semantische HTML,
    • gestructureerde CSS (bijv. mobile‑first, modulair, DRY),
    • doelgerichte JavaScript voor interactiviteit.
  • progressive enhancement toepassen:
    • eerst een bruikbare, toegankelijke basis zonder JS realiseren,
    • daarna styling en enhanced behavior toevoegen.
  • een responsive layout opzetten:
    • werken met mobile‑first media queries,
    • content en typografie laten meeschalen,
    • eenvoudige componenten (nav, cards, grids) responsive maken.
  • semantische HTML kiezen en inzetten (headings, landmarks, lists, forms).
  • herhaling verminderen volgens DRY:
    • herbruikbare CSS‑classes en componenten maken,
    • gedrag in JS structureren (functions, modules) in plaats van copy‑paste.
  • data ophalen en gebruiken in de frontend:
    • eenvoudige requests doen naar een REST API of GraphQL endpoint,
    • responses verwerken (JSON) en data renderen in de UI.
  • een eenvoudige render strategy kiezen en implementeren die past bij de opdracht (bijv. statische site vs. client‑rendered app) en deze keuze beargumenteren.
  • werken met een frontend framework of meta framework op instapniveau:
    • een project opzetten met tooling (bijv. via create‑app / CLI / template),
    • componenten aanmaken, props/state gebruiken,
    • basisrouting begrijpen (pages/views).
  • gericht libraries inzetten:
    • een library installeren en importeren via npm,
    • de documentatie volgen om een concrete use‑case te bouwen (bijv. animatie met GSAP, 3D‑scene met Three.js, componenten met Chakra).
  • effectief werken met code editors en browser devtools:
    • syntax highlighting, formatters, linters gebruiken,
    • DOM inspecteren, styles debuggen, network requests en performance analyseren.
  • issues gebruiken om werk te structureren:
    • taken en bugs als issues vastleggen,
    • issues koppelen aan commits/PR’s,
    • issues sluiten na implementatie.

Attitude: de student...

  • neemt verantwoordelijkheid voor de kwaliteit van code:
    • streeft naar leesbare, consistente en onderhoudbare HTML, CSS en JS,
    • is bereid code te refactoren als het schoner of duidelijker kan.
  • denkt tijdens het bouwen na over toegankelijkheid, performance en responsiveness in plaats van dit achteraf te “fixen”.
  • toont nieuwsgierigheid naar frameworks, libraries en tooling, maar:
    • kiest niet blind voor “de nieuwste tool”,
    • kan keuzes onderbouwen vanuit de opdracht en context.
  • gebruikt documentatie (MDN, framework‑docs, library‑docs) actief als bron en verwijst ernaar.
  • is bereid eigen aannames over implementatie te herzien wanneer tests, feedback of metingen dat vragen.
  • werkt gestructureerd:
    • bouwt stap voor stap (van werkende basis naar complexer),
    • houdt overzicht over bestanden, componenten en dependencies.
1. Web fundamentals

In dit deel staat de basis van webontwikkeling centraal: HTML voor structuur, CSS voor vormgeving en JavaScript voor interactie, aangevuld met principes als toegankelijkheid, responsive design, progressive enhancement en performance.

HyperText Markup Language (HTML)

HTML (HyperText Markup Language) is de standaardtaal die wordt gebruikt om webpagina’s te maken en structureren. Het bestaat uit een verzameling elementen en tags die bepalen hoe de inhoud op een website wordt weergegeven. Met HTML kan onder andere de structuur van koppen, paragrafen, lijsten, links, afbeeldingen en formulieren worden vastgelegd.

Webbrowsers lezen HTML‑bestanden en zetten de code om in de zichtbare webpagina die gebruikers zien. HTML werkt vaak samen met CSS voor opmaak en JavaScript voor interactieve functies.

Bronnen:

Cascading Style Sheets (CSS)

CSS (Cascading Style Sheets) wordt gebruikt om de presentatie en vormgeving van HTML‑documenten te bepalen. Met CSS legt de student onder andere kleur, typografie, spacing, layout, animaties en responsief gedrag vast.

JavaScript

JavaScript wordt gebruikt om webpagina’s interactief te maken. Met JavaScript kan de student onder andere events afhandelen, DOM‑elementen manipuleren, data ophalen van API’s en eenvoudige state beheren.

Progressive enhancement

Bij progressive enhancement bouwt de student eerst een robuuste HTML‑basis, voegt vervolgens presentatie toe met CSS en verrijkt het gedrag met JavaScript. Hierdoor blijft de website bruikbaar in verschillende browsers en onder verschillende omstandigheden. Een belangrijk onderdeel van progressive enhancement is feature detection: in de code wordt gecontroleerd of bepaalde CSS‑ of JavaScript‑features door de browser worden ondersteund. Afhankelijk van deze ondersteuning wordt bepaald of specifieke code wel of niet wordt uitgevoerd.

Responsive

Responsive ontwerp past layout en typografie aan op basis van de viewport en het gebruikte apparaat. Door het inzetten van media‑ of container queries en een correcte viewport‑meta‑tag wordt een betrouwbare weergave op verschillende schermformaten gegarandeerd. Moderne CSS‑features maken het steeds eenvoudiger om responsive design te realiseren.

Veelgebruikte principes binnen responsive webdesign zijn content first en mobile first. Daarbij wordt een website vanuit de inhoud eerst ontworpen voor een mobiele viewport (single‑column layout) en vervolgens opgeschaald naar grotere viewports.

Bronnen:

Mobile first

Mobile first is een ontwerp- en ontwikkelprincipe waarbij een website of applicatie eerst wordt ontwikkeld voor mobiele schermen. Vanuit deze basis wordt het ontwerp vervolgens uitgebreid naar grotere schermformaten. Door te starten met mobile first ligt de focus op essentiële content en functionaliteit, wat leidt tot betere performance, gebruiksvriendelijkheid en een duidelijkere structuur.

Semantic HTML

Semantic HTML betekent dat HTML‑elementen worden gebruikt volgens hun betekenis, niet alleen voor opmaak. Zo wordt <header> gebruikt voor een kopgedeelte, <article> voor een zelfstandig stukje inhoud en <footer> voor de voettekst. Door semantische HTML te gebruiken, wordt de structuur van een website duidelijker voor browsers, zoekmachines en hulpmiddelen voor toegankelijkheid, wat de gebruikerservaring en het onderhoud van de site verbetert.

Web API's

Web API’s in de browser zijn ingebouwde functionaliteiten die de browser via JavaScript aanbiedt, zoals; de URL API, Intersection Observer, Fetch API, Web Storage of Geolocation. In plaats van alles zelf te moeten bouwen, kun je met deze API’s bijvoorbeeld URLs parsen, lazy‑loaden als elementen in beeld komen, data ophalen, dingen opslaan in localStorage of de locatie van een gebruiker opvragen. Ze vormen de toolbox waarmee je “gewone” JavaScript koppelt aan alles wat de browser kan: DOM, netwerk, performance, audio/video, sensoren en meer.

DRY principle

Het DRY‑principe staat voor “Don’t Repeat Yourself”. Het betekent dat herhaling in code zoveel mogelijk wordt vermeden. In plaats van dezelfde logica, waarden of structuren meerdere keren te kopiëren, legt de student deze vast op één centrale plek (bijvoorbeeld in een functie, component of CSS‑class). Zo worden inconsistenties voorkomen en wordt code beter onderhoudbaar, overzichtelijker en minder foutgevoelig.

KISS principle

Bij het kiezen van technieken, patronen en libraries geldt: zo simpel als kan, zo complex als nodig. De student voorkomt onnodige afhankelijkheden en over‑engineerde oplossingen. Er wordt begonnen met een eenvoudige, goed te testen basis en alleen complexiteit toegevoegd als daar een duidelijke reden voor is (bijvoorbeeld performance, schaalbaarheid of hergebruik).

2. Architecture & data

In dit deel gaat het over hoe de frontend met data omgaat en hoe de student applicaties structureert rond resources, URL’s, data models en verschillende render strategies.

REST API

Een REST API (Representational State Transfer) is een manier om data en functionaliteit van een server toegankelijk te maken via het web. Het volgt de fundamentele werking van het web: elke bron heeft een unieke URL en wordt benaderd met standaard HTTP‑methodes zoals GET, POST, PUT en DELETE. Door REST API’s te gebruiken, kunnen front‑end en back‑end developers op een overzichtelijke en consistente manier gegevens uitwisselen en applicaties schaalbaar bouwen.

GraphQL

GraphQL is een alternatief voor traditionele REST API’s en stelt front‑end developers in staat precies de gegevens op te vragen die nodig zijn. In plaats van vaste endpoints zoals bij REST, kan de client zelf aangeven welke velden en objecten uit de server moeten komen. Dit maakt de data‑uitwisseling efficiënter, overzichtelijker en flexibeler en helpt bij het ontwikkelen van schaalbare webapplicaties.

URL‑driven development

URL‑driven development is gebaseerd op een fundamentele werking van het web: elke URL verwijst naar een unieke bron of pagina. Bij deze aanpak wordt de structuur van een webapplicatie rondom de URL’s ontworpen, zodat elke pagina of toestand (state) van een pagina direct toegankelijk, deelbaar en te bookmarken is. Door URL’s als uitgangspunt te nemen, blijft de navigatie overzichtelijk, de gebruikerservaring consistent en het beheer van complexe applicaties eenvoudiger.

CRUD

CRUD staat voor Create, Read, Update en Delete en beschrijft de vier basisbewerkingen die mogelijk zijn op data binnen een applicatie. Dit principe sluit aan op de fundamentele werking van het web, waarin bronnen via URL’s toegankelijk zijn en bewerkt kunnen worden. Door CRUD als uitgangspunt te gebruiken, blijft het beheer van data overzichtelijk, voorspelbaar en consistent, zowel voor de gebruiker als voor de ontwikkelaar.

Client‑side rendering

Bij client‑side rendering wordt de webpagina opgebouwd in de browser van de gebruiker met behulp van JavaScript. De server levert meestal een minimale HTML‑basis, waarna de inhoud dynamisch wordt gerenderd. Dit maakt interactieve applicaties mogelijk, maar kan invloed hebben op performance en SEO.

Server‑side rendering

Server‑side rendering houdt in dat de HTML van een pagina op de server wordt gegenereerd en volledig naar de browser wordt gestuurd. Hierdoor is de pagina direct zichtbaar voor de gebruiker en beter toegankelijk voor zoekmachines. JavaScript kan daarna worden gebruikt om extra interactiviteit toe te voegen.

https://developer.mozilla.org/en-US/docs/Glossary/SSR

Prerendering

Prerendering is het proces waarbij HTML van een pagina al tijdens build-tijd wordt gegenereerd. De browser krijgt kant-en-klare HTML. Term wordt vaak gebruikt in frameworks zoals SvelteKit of Next.js.

Static Site Generation

Bij Static Site Generation worden pagina’s vooraf gegenereerd tijdens een build‑proces en als statische bestanden geserveerd. Dit resulteert in snelle laadtijden en hoge betrouwbaarheid. Static rendering wordt vaak gebruikt voor websites met grotendeels vaste content, zoals documentatie of marketingpagina’s.

Hydration

Hydration is het proces waarbij een server‑gerenderde pagina in de browser interactief wordt gemaakt. JavaScript neemt de bestaande HTML over en koppelt hier gedrag aan, zoals event handlers en state. Zonder hydration blijft een pagina statisch en niet interactief.

3. Tooling & workflow

In dit deel staan de tools, frameworks, libraries en werkwijzen centraal die de student helpen om code te schrijven, te organiseren en effectief samen te werken binnen een team.

Node.js

Node.js is een JavaScript‑runtime waarmee JavaScript buiten de browser kan worden gedraaid, op de server of lokaal tijdens development. Hierdoor kan met één taal – JavaScript – zowel frontend als backend worden ontwikkeld. Voor frontenders is Node.js vooral belangrijk als basis voor tooling (npm, bundlers, linters) en voor het bouwen van eigen servers of API’s die content aan de frontend leveren.

Express

Express is een veelgebruikt webframework voor Node.js waarmee snel HTTP‑servers en API’s kunnen worden opgezet. Met Express worden routes (URL’s) gedefinieerd en wordt bepaald welke data of HTML bij welke request wordt teruggegeven. Voor frontenders is Express relevant om eenvoudige backends, prototypes of server‑side rendering op te zetten die goed aansluiten op de URL‑structuur en databehoefte van de frontend.

Template engines

Een template engine is een hulpmiddel om HTML‑pagina’s (of andere tekstbestanden) dynamisch te genereren op basis van views en data. In een template wordt statische markup gecombineerd met placeholders en eenvoudige logica (zoals loops en conditions). Tijdens het renderen worden deze placeholders ingevuld met data uit bijvoorbeeld een database of API.

Voor frontenders is een template engine belangrijk bij server‑side rendering: de server genereert HTML die naar de browser wordt gestuurd. Dit verbetert vaak de eerste laadtijd, SEO en toegankelijkheid, terwijl de pagina daarna eventueel verder interactief kan worden gemaakt met client‑side JavaScript.

Frontend frameworks

Frontend frameworks bieden een gestructureerde basis voor het bouwen van webinterfaces, met collecties van opinionated patterns, utilities en herbruikbare componenten. Ze nemen veel repetitief werk uit handen – zoals state management, routing en het opzetten van een consistente componentstructuur – en bevorderen herbruikbare, voorspelbare patronen in HTML, CSS en JavaScript.

Frameworks richten zich meestal op één laag van de applicatie – vaak de UI‑laag in de browser, soms gecombineerd met een eenvoudige serverlaag. Voor frontenders maken ze het makkelijker om grote applicaties onderhoudbaar, testbaar en uitbreidbaar te houden.

Meta frameworks

Meta frameworks bouwen bovenop bestaande frontend frameworks en voegen daar zaken aan toe als routing, data‑fetching, renderstrategieën (SSR, SSG, CSR), bestandsstructuur en tooling voor productie. Ze geven een opinionated manier van werken die veel keuzes standaardiseert, zoals hoe pagina’s worden opgebouwd, hoe er wordt gebundeld en hoe er wordt gedeployed.

Voor frontenders zijn meta frameworks belangrijk omdat ze de brug slaan tussen componenten, data en hosting: er wordt nog steeds gewerkt met bijvoorbeeld Svelte, maar er komt een complete applicatie‑ en deploymentstructuur bij.

Libraries

Libraries zijn losse, herbruikbare packages die specifieke functionaliteit aan een project toevoegen. In tegenstelling tot frameworks bepalen ze meestal niet de overall application structure, maar hebben ze één doel, zoals animaties, 3D‑graphics, UI‑componenten of real‑time communicatie.

Frontenders gebruiken libraries om sneller te kunnen werken, complex gedrag betrouwbaar te implementeren en consistente UI‑patronen te hergebruiken, zonder alles from scratch te bouwen.

Voorbeelden: Chakra (UI‑componenten), Three.js (3D‑graphics), Threlte (Three.js + Svelte), Storybook (component‑documentatie), GSAP (animaties), Framer (animaties/prototyping), socket.io (real‑time communicatie).

Living styleguide

Een living styleguide documenteert componenten, varianten en tokens met voorbeelden. Dit borgt consistentie en versnelt samenwerking tussen design en development.

Component library

Een component library bevat herbruikbare, toegankelijke UI‑onderdelen met duidelijke props en states. Met goede documentatie ontstaat een schaalbare design‑system‑workflow.

Code editors

Code editors helpen frontenders bij het schrijven, lezen en onderhouden van code. Ze bieden functionaliteiten zoals syntax highlighting, automatische code‑aanvulling, foutdetectie en integratie met versiebeheersystemen. Moderne code editors, zoals Visual Studio Code, zijn uitbreidbaar met plugins en extensies, waardoor de werkomgeving kan worden afgestemd op specifieke workflows en programmeertalen. Hierdoor werken developers efficiënter, consistenter en met minder fouten.

Code‑editor plugins

VS Code‑plugins kunnen frontenders helpen hun workflow te optimaliseren, bijvoorbeeld door sneller en netter code te schrijven en fouten te signaleren. Voorbeelden van plugins zijn: ESLint, Prettier en Live Server/Live Preview. Binnen een webteam kunnen afspraken worden gemaakt over de plugins die gebruikt worden en hoe deze zijn geconfigureerd.

Browsers

Browsers zijn de programma’s waarmee gebruikers websites en webapplicaties bekijken. Ze verwerken HTML voor de structuur, CSS voor de opmaak en JavaScript voor de functionaliteit. Dankzij ingebouwde ontwikkelaarstools kunnen front‑end developers code inspecteren, fouten opsporen en prestaties verbeteren. Omdat browsers verschillen in de ondersteuning van webstandaarden en features, is het belangrijk bij het ontwikkelen rekening te houden met compatibiliteit en toegankelijkheid.

npm

npm staat voor Node Package Manager en is de standaard package manager voor Node.js. Met npm kunnen JavaScript‑packages (libraries en tools) worden geïnstalleerd, dependencies van een project beheerd en scripts gedraaid, zoals build‑, test‑ of lint‑taken.

Afhandelen van issues

Het afhandelen van issues betekent dat problemen, bugs of verzoeken die in een project worden geregistreerd, systematisch worden opgepakt en opgelost. Dit omvat het beoordelen, prioriteren, toewijzen en uiteindelijk sluiten van een issue wanneer het is opgelost. Een gestructureerde aanpak zorgt voor overzicht, betere samenwerking en een hogere kwaliteit van het eindproduct.

Integreren

In de integratiefase zorgt de student ervoor dat een applicatie vanuit de ontwikkelomgeving naar een gedeelde (test‑ of productie‑)omgeving wordt overgezet, zodat verschillende teamleden en medestudenten kunnen testen en doorontwikkelen, docenten kunnen beoordelen en een opdrachtgever of eindgebruikers de toepassing daadwerkelijk kunnen gebruiken. De student brengt de code samen via Git, maakt een werkende build en publiceert deze op een geschikt hosting platform, zoals Netlify, Vercel, Render of een (gehoste) server.

Leeruitkomst Integreren

Kennis: de student kent ...

  • de rol van integreren binnen de development lifecycle (DLC):
    • code samenbrengen, publiceren, automatiseren en overdraagbaar maken.
  • de basis van version control met Git:
    • wat een Git‑workflow is en waarom afspraken hierover nodig zijn,
    • het verschil tussen lokale en remote repositories,
    • de rol van branches, commits en pull requests.
  • de belangrijkste begrippen in Git:
    • Git CLI (commit, push, pull, branch, merge, clone, etc.),
    • het belang van duidelijke commit messages,
    • het idee achter Gitmoji als visuele commit‑conventie.
  • concepten rond deploy & hosting:
    • wat hosting is en welke vormen er zijn (statisch, server, serverless),
    • verschil tussen handmatig uploaden met (S)FTP en geautomatiseerde deploys,
    • de basis van platforms als Render, GitHub Pages, Vercel en Netlify.
  • de principes van automation & configuration:
    • continuous integration (CI) als praktijk om automatisch te testen en builden,
    • de rol van GitHub Actions bij het opzetten van workflows (test, build, deploy),
    • het doel van environment variables en .env‑bestanden (scheiding code/configuratie, security).
  • de functie van documentation & handover:
    • het verschil tussen README.md, Handover.md en Contributing.md,
    • welke informatie waar thuishoort (installatie, gebruik, structuur, bijdragen, overdracht).

Skills: de student kan ...

  • met Git werken in een teamcontext:
    • een bestaande repository clonen en lokaal opzetten,
    • wijzigingen gestructureerd vastleggen met commits en duidelijke commit messages,
    • branches aanmaken voor features of fixes en deze later samenvoegen.
  • een eenvoudige maar heldere Git‑workflow volgen:
    • werken met feature branches,
    • pull requests aanmaken, bespreken en verwerken,
    • kleine, logische stappen maken in plaats van grote “alles‑in‑één” commits.
  • projecten deployen naar een hosting platform:
    • een statische site publiceren (bijv. met GitHub Pages, Netlify of Vercel),
    • basisinstellingen configureren (build‑command, output‑folder, environment variables),
    • een eenvoudige update‑flow gebruiken (push → build → deploy).
  • verschillende deployment‑strategieën herkennen en toepassen:
    • herkennen wanneer (S)FTP nog relevant is (bijv. legacy hosting),
    • een Git‑gebaseerde pipeline gebruiken bij moderne platforms.
  • eenvoudige CI‑workflows begrijpen en inzetten:
    • een basic GitHub Action configureren (bijv. lint/test op elke push of pull request),
    • build‑ en testfouten interpreteren en oplossen.
  • veilig omgaan met configuratie en secrets:
    • gevoelige gegevens in een .env‑bestand plaatsen,
    • .env uitsluiten van version control,
    • environment variables instellen in het deployment platform.
  • documentatie schrijven en bijhouden:
    • een duidelijke README.md opstellen (doel, installatie, gebruik, tech‑stack),
    • een Handover.md maken voor overdracht (structuur, scripts, bekende issues),
    • eenvoudige Contributing.md‑richtlijnen formuleren (branches, commits, PR‑flow).

Attitude: de student...

  • ziet version control als essentieel onderdeel van professioneel werken:
    • commit regelmatig in kleine stappen,
    • schrijft eerlijke, beschrijvende commit messages,
    • is voorzichtig met direct op main/master werken.
  • neemt verantwoordelijkheid voor de stabiliteit van de main branch:
    • test lokaal voordat er gecommit wordt,
    • gebruikt pull requests voor review en checks,
    • lost merge conflicts zorgvuldig op in overleg met het team.
  • heeft een automation‑first mentaliteit waar passend:
    • zoekt naar mogelijkheden om repeterende taken (testen, builden, deployen) te automatiseren,
    • ziet CI/CD niet als “extra werk”, maar als kwaliteitsborging.
  • is zich bewust van security en privacy:
    • pusht geen secrets (API‑keys, wachtwoorden) naar Git,
    • gaat zorgvuldig om met .env en configuratie.
  • schrijft documentatie met het oog op anderen:
    • helpt toekomstige ontwikkelaars of stagiairs met een goede README/Handover,
    • houdt documentatie up‑to‑date bij belangrijke wijzigingen.
  • werkt transparant en samenwerkingsgericht:
    • gebruikt issues, PR‑beschrijvingen en documentatie om keuzes te communiceren,
    • staat open voor code reviews en is bereid eigen code aan te passen na feedback.
1. Version control & workflow

In dit deel wordt beschreven hoe de student met Git samenwerkt aan dezelfde codebase: hoe branches worden gebruikt, wijzigingen worden vastgelegd en samengevoegd en hoe de workflow voorspelbaar en veilig blijft.

Git‑workflow

Een Git‑workflow beschrijft de afspraken en stappen die een team volgt bij het werken met Git. Denk aan hoe branches worden aangemaakt, hoe wijzigingen worden samengevoegd en wanneer code wordt gereviewd. Een duidelijke workflow zorgt voor overzicht, voorkomt conflicten en maakt samenwerking voorspelbaar en efficiënt.

Git CLI

De Git CLI (Command Line Interface) is een tekstgebaseerde manier om Git te gebruiken via de terminal. Hiermee kunnen developers repositories beheren, commits maken en branches aansturen. Werken met de Git CLI geeft veel controle en inzicht in version control en vormt een belangrijke basisvaardigheid voor frontenders.

Branches

Branches maken het mogelijk om los van de hoofdcode aan nieuwe features, bugfixes of experimenten te werken. Elke branch vormt een aparte ontwikkellijn die later kan worden samengevoegd. Dit voorkomt dat onvoltooide of foutieve code direct invloed heeft op de hoofdversie.

Commit messages

Commit messages beschrijven welke wijzigingen in een commit zijn gedaan en waarom. Duidelijke en consistente commit messages maken de projectgeschiedenis beter leesbaar en helpen bij debugging, samenwerking en code reviews.

https://git-scm.com/docs/git-commit

Gitmoji

Gitmoji is een conventie waarbij emoji’s worden gebruikt in commit messages om het type wijziging aan te geven, zoals ✨ voor nieuwe features of 🐛 voor bugfixes. Dit maakt commits visueel herkenbaar en verbetert de leesbaarheid van de commitgeschiedenis.

https://gitmoji.dev/

Pull request

Een pull request is een verzoek om wijzigingen uit een branch samen te voegen met een andere branch, meestal de hoofdbranch. Het biedt ruimte voor code review, discussie en automatische checks, en speelt een belangrijke rol in samenwerking en kwaliteitsbewaking.

2. Deploy & hosting

In dit deel gaat het over hoe de student applicaties daadwerkelijk online krijgt en beschikbaar maakt voor gebruikers, met verschillende vormen van hosting en deployment platforms.

Hosting

Hosting is het beschikbaar maken van een website of applicatie op het internet via een server. Front‑end developers gebruiken hostingdiensten om projecten te publiceren, te testen en te delen. Goede hosting zorgt voor bereikbaarheid, performance en betrouwbaarheid.

GitHub Pages

GitHub Pages is een hostingdienst van GitHub waarmee statische websites direct vanuit een repository gepubliceerd kunnen worden. Het wordt vaak gebruikt voor portfolio’s, documentatie en demo’s en sluit goed aan bij Git‑gebaseerde workflows.

Netlify

Netlify is een hosting platform voor statische websites en front‑end applicaties. Het ondersteunt automatische deploys, form‑handling en serverless functies. Door de Git‑integratie kunnen projecten eenvoudig en snel worden gepubliceerd.

https://www.netlify.com/

Vercel

Vercel is een platform gericht op het hosten en deployen van moderne front‑end applicaties. Het biedt automatische builds, previews per branch en optimale performance voor frameworks zoals Next.js. Deployments worden direct gekoppeld aan Git‑repositories.

Render

Render is een cloudplatform waarmee webapplicaties automatisch kunnen worden gedeployed. Het ondersteunt onder andere statische sites, webservers en databases. Door integratie met Git kunnen wijzigingen direct live worden gezet na een commit of merge.

(S)FTP

(S)FTP staat voor (Secure) File Transfer Protocol en wordt gebruikt om bestanden van en naar een server te versturen. Het wordt vaak ingezet bij traditionele hosting om websites handmatig te uploaden en te beheren. SFTP voegt encryptie toe voor extra beveiliging.

3. Automation & configuration

In dit deel gaat het over het automatiseren van builds, tests en deploys (CI/CD) en over het veilig beheren van configuratie via omgevingsvariabelen.

Continuous integration

Continuous integration (CI) is een ontwikkelpraktijk waarbij codewijzigingen automatisch worden getest en gecontroleerd zodra ze worden toegevoegd aan een repository. Dit helpt fouten vroeg te signaleren en zorgt voor stabielere en betrouwbaardere software.

GitHub Actions

GitHub Actions is een tool voor het automatiseren van workflows binnen GitHub, zoals testen, builden en deployen. Het wordt veel gebruikt voor continuous integration en continuous deployment en werkt op basis van configuratiebestanden (YAML) in de repository.

.env

Een .env‑bestand (ok bekend als dotenv) wordt gebruikt om environment variables op te slaan, zoals API‑keys en configuratie‑instellingen. Deze gegevens worden gescheiden van de code om veiligheid en flexibiliteit te verbeteren en worden niet meegenomen in version control (door .env in .gitignore op te nemen).

https://dotenvx.com/docs/env-file

4. Documentation & handover

In dit deel gaat het over hoe de student projecten documenteert en overdraagt, zodat anderen (of de student zelf later) het werk kunnen begrijpen, gebruiken en voortzetten.

Documentatie

Documentatie beschrijft hoe een project werkt, hoe het gebruikt kan worden en hoe het onderhouden wordt. Goede documentatie helpt bij samenwerking, onboarding van nieuwe developers en het langdurig beheer van een project.

README.md

De README.md is het centrale document van een repository en geeft een overzicht van het project. Het bevat vaak informatie over installatie, gebruik, structuur en gebruikte technologieën. Een duidelijke README maakt een project toegankelijk en begrijpelijk voor anderen.

De README is het eerste wat iemand ziet op GitHub. In de README kan het team uitleggen wat er is gemaakt, screenshots toevoegen en toelichten wie aan de website hebben gewerkt. De README fungeert als uithangbord van het project.

Handover.md

De Handover.md bevat informatie die nodig is om een project over te dragen aan andere developers of beheerders. Hierin staat onder andere hoe het project is opgebouwd, hoe het lokaal kan worden gedraaid en welke aandachtspunten of openstaande zaken er zijn. Dit document zorgt voor een soepele overdracht en continuïteit.

Contributing.md

De Contributing.md beschrijft de richtlijnen voor het bijdragen aan een project. Denk aan afspraken over branches, commit messages, code‑style en pull requests. Door deze regels vast te leggen, wordt samenwerking duidelijker en blijft de kwaliteit van het project consistent.

Testen

In de testfase controleert de student of de oplossing werkt zoals bedoeld. Dat kan gaan om technische checks, tests met echte gebruikers of een review/presentatie bij de opdrachtgever.

Voor een frontender betekent dit onder andere: gebruikerstesten, toegankelijkheidstesten, prototypetesten en browsertesten. Ook de Sprint Review met de opdrachtgever hoort hierbij: de student demonstreert wat er is gebouwd, verzamelt feedback en neemt die mee naar de volgende sprint.

Leeruitkomst Testen

Kennis: de student kent ...

  • de rol van testen binnen de development lifecycle (DLC) en Scrum:
    • testen als integraal onderdeel van het proces, niet alleen aan het eind,
    • verschil tussen ontwikkeltests, acceptatietests en regressietests.
  • de belangrijkste soorten tests voor webprojecten:
    • functionele tests (doet het wat het moet doen?),
    • usability tests (is het begrijpelijk en bruikbaar?),
    • accessibility tests (is het toegankelijk voor verschillende gebruikers?),
    • performance tests (laadtijd, responsiviteit),
    • basis van unit, integration en end‑to‑end tests.
  • basisbegrippen rond teststrategie:
    • werken vanuit user stories en acceptatiecriteria,
    • het doel van een testplan en testscripts (wat test je, hoe, met wie?).
  • de mogelijkheden van browser devtools voor testen:
    • console, network, performance, device emulation, Lighthouse.
  • basisprincipes van usability testing:
    • verschil tussen think‑aloud en observatietests,
    • belang van realistische taken en neutrale vragen.
  • basisprincipes van accessibility testing:
    • semantische HTML, toetsenbordtoegankelijkheid, contrast,
    • hulpmiddelen zoals screenreaders, devtools en linters (bijv. axe, WAVE).
  • basisconcepten van geautomatiseerd testen:
    • idee achter unit tests en test frameworks (bijv. Jest, Vitest),
    • het nut van linters (ESLint) en formatters (Prettier) als kwaliteitschecks,
    • het principe van CI die tests automatisch draait.
  • het belang van bug‑tracking en issue‑beheer:
    • wat een bug report bevat,
    • hoe issues gebruikt worden om bugs te registreren en op te volgen.

Skills: de student kan ...

  • op basis van user stories en acceptatiecriteria:
    • een eenvoudige teststrategie opstellen,
    • een kort testplan of testscripts formuleren (scenario’s, stappen, verwachte uitkomst).
  • webapplicaties functioneel testen:
    • cruciale user flows doorlopen (aanmelden, formulier invullen, navigeren),
    • vastleggen wat er misgaat, inclusief stappen om dit te reproduceren.
  • usability tests voorbereiden en uitvoeren op kleine schaal:
    • passende testpersonen en taken kiezen,
    • een kort testscript maken,
    • observaties en citaten verzamelen,
    • bevindingen samenvatten in concrete verbeterpunten.
  • eenvoudige accessibility checks uitvoeren:
    • basis toetsenbordnavigatie testen (focus, tabvolgorde),
    • controleren op duidelijke labels, headings en alt‑teksten,
    • (visueel) contrast beoordelen en browser‑/plugin‑tools inzetten.
  • performance globaal beoordelen:
    • met devtools/network nagaan welke resources laden en hoe lang dat duurt,
    • eenvoudige optimalisaties herkennen (afbeeldingen, ongebruikte code).
  • browser devtools gebruiken voor foutopsporing:
    • console‑errors uitlezen en interpreteren,
    • DOM en styles inspecteren, breakpoints gebruiken,
    • netwerkverkeer analyseren (API‑calls, statuscodes).
  • geautomatiseerde kwaliteitschecks inzetten:
    • linters en formatters draaien (bijv. npm run lint, npm run format),
    • indien beschikbaar een eenvoudige unit test schrijven of aanpassen,
    • fouten uit test‑/lint‑output interpreteren en oplossen.
  • bugs en bevindingen gestructureerd vastleggen:
    • duidelijke bug reports schrijven (context, stappen, verwacht vs. werkelijk resultaat, omgeving),
    • issues aanmaken, labelen en koppelen aan user stories of taken.

Attitude: de student...

  • ziet testen als vast onderdeel van ontwikkelen, niet als sluitpost:
    • test tussentijds, niet alleen vlak voor oplevering,
    • plant tijd in voor het oplossen van gevonden problemen.
  • neemt een kritische maar constructieve houding aan:
    • zoekt actief naar fouten en onduidelijkheden,
    • ervaart bugs niet als falen, maar als informatie om te verbeteren.
  • denkt vanuit de eindgebruiker:
    • test scenario’s die passen bij realistisch gebruik,
    • heeft oog voor begrijpelijkheid, toegankelijkheid en frustraties van gebruikers.
  • is zorgvuldig in vastleggen en communiceren:
    • beschrijft bugs volledig en reproduceerbaar,
    • koppelt testbevindingen aan concrete acties of issues.
  • staat open voor feedback en iteratie:
    • gebruikt testresultaten om ontwerpen en implementaties bij te sturen,
    • is bereid eerder gemaakte keuzes te herzien als tests iets anders uitwijzen.
  • heeft aandacht voor kwaliteit op lange termijn:
    • ziet de waarde van automatisering (linting, tests in CI),
    • denkt vooruit over testbaarheid bij nieuwe features (small, testbare units, duidelijke flows).
1. Process & sprint tests

In deze categorie staan de momenten centraal waarop de student samen met opdrachtgever en team het werk beoordeelt, feedback ophaalt en besluit of iets “af” is.

Sprint Review

De Sprint Review is het officiële moment tijdens elke sprint waarop het team het gemaakte werk bespreekt met de opdrachtgever. De opdrachtgever geeft feedback naar aanleiding van het (deel)product dat gedemonstreerd wordt. Het maakt niet uit dat de opdracht nog niet af is: de student laat zien waar aan is gewerkt en bespreekt of de gekozen oplossing overeenkomt met de wensen van de opdrachtgever.

Vooraf maakt de student een testplan. Zo wordt duidelijk wat er getest moet worden en wordt voorkomen dat belangrijke zaken worden vergeten. Na de test verwerkt de student de resultaten in issues, past de code aan en test vervolgens opnieuw om te zien of de interface is verbeterd.

Bronnen:

Client review

Bij een client review wordt het product besproken met de opdrachtgever of klant. Hierbij wordt gekeken of het resultaat aansluit bij de wensen, doelen en verwachtingen. Feedback uit een client review kan leiden tot laatste aanpassingen voor oplevering.

Code / design review

Een code‑ of designreview is een controle van code of ontwerp door andere developers of designers. Hierbij wordt gelet op kwaliteit, consistentie, leesbaarheid en best practices. Reviews helpen fouten te voorkomen en kennis te delen binnen een team.

Expert review

Een expert review is een evaluatie van een website of applicatie door een specialist, bijvoorbeeld op het gebied van UX, toegankelijkheid of performance. De expert identificeert verbeterpunten op basis van kennis en best practices.

Quality assurance

Quality assurance (QA) omvat alle processen en controles die worden ingezet om de kwaliteit van een product te waarborgen. Dit omvat onder andere testen, reviews en validaties gedurende het hele ontwikkelproces. QA zorgt ervoor dat software betrouwbaar, consistent en klaar voor gebruik is.

2. User & usability

In deze categorie gaat het om tests waarbij echte of representatieve gebruikers centraal staan: hoe ervaren zij de interface, begrijpen zij de flow en kunnen zij hun doelen bereiken?

Usability testing (user testing)

Het ontwerpen van een goede gebruikerservaring (UX) gaat niet alleen over iets bouwen dat werkt, maar vooral over iets maken dat intuïtief en prettig te gebruiken is. Een student kan denken dat een micro‑interactie perfect is – alles functioneert precies zoals bedoeld – maar hoe ervaart een gebruiker dat werk? Om dat te ontdekken, zet de student usability testing in. Het doel is om te achterhalen hoe een echte gebruiker de interface ervaart.

Bronnen:

Testen in een usability lab

Testen in een usability lab richt zich op het observeren van gebruikers tijdens het uitvoeren van taken binnen een applicatie of website. Door gebruikersgedrag te analyseren – zoals navigatie, interactie en feedback – worden knelpunten in gebruiksvriendelijkheid en toegankelijkheid zichtbaar. Deze vorm van testen helpt bij het verbeteren van de gebruikservaring van de website.

Real user monitoring

Voorbeelden en inspiratie:

Roast / design critique

Een roast of design critique is een sessie waarin een ontwerp kritisch wordt besproken door anderen. Hierbij wordt feedback gegeven op onder andere gebruiksvriendelijkheid, visuele hiërarchie en consistentie. Het doel is niet om het ontwerp af te kraken, maar om verbeterpunten te ontdekken en de kwaliteit van het ontwerp te verhogen.

Elderly test

De elderly test richt zich op het testen van een website met oudere gebruikers. Hierbij wordt gekeken naar leesbaarheid, navigatie en begrijpelijkheid. Deze test helpt om interfaces eenvoudiger en gebruiksvriendelijker te maken voor een brede doelgroep.

3. Accessibility & inclusion

In deze categorie richt de student zich op de toegankelijkheid van de interface voor mensen met verschillende beperkingen en situaties, zodat zoveel mogelijk gebruikers het product kunnen gebruiken.

Tab / keyboard test

De tab‑ of keyboard test controleert of een website volledig te bedienen is met alleen het toetsenbord. Hierbij wordt gekeken naar de tabvolgorde, focus‑states en bereikbaarheid van interactieve elementen. Deze test is belangrijk voor toegankelijkheid en ondersteunt gebruikers die geen muis kunnen gebruiken.

Color & contrast test

Een color & contrast test controleert of tekst en interactieve elementen voldoende contrast hebben ten opzichte van de achtergrond. Dit is essentieel voor leesbaarheid en toegankelijkheid, vooral voor gebruikers met visuele beperkingen. Deze test helpt te voldoen aan toegankelijkheidsrichtlijnen zoals WCAG.

Kleurenblindheidstest

Een kleurenblindheidstest controleert of informatie niet uitsluitend door kleur wordt overgebracht. Hierbij wordt gekeken of contrast, patronen of tekstlabels voldoende ondersteuning bieden. Deze test is belangrijk om de website bruikbaar te houden voor gebruikers met kleurenblindheid.

Brillentest

De brillentest simuleert verminderd zicht door bijvoorbeeld een wazig filter of een bril met beperkte scherpte. Hiermee wordt getest of teksten, knoppen en interacties nog steeds goed leesbaar en bruikbaar zijn. Dit helpt bij het verbeteren van toegankelijkheid en leesbaarheid.

WCAG‑test

Een WCAG‑test controleert of een interface voldoet aan toegankelijkheidscriteria (contrast, keyboard, focus, semantiek) en helpt prioriteit te geven aan verbeteringen.

Accessibility test / a11y‑test

Een accessibility test (a11y‑test) controleert of een website of applicatie bruikbaar is voor mensen met verschillende beperkingen. Hierbij wordt gekeken naar onder andere toetsenbordbediening, screenreader‑ondersteuning, kleurgebruik en semantiek. Deze test draagt bij aan inclusieve en toegankelijke digitale producten.

Screenreader‑test

Een screenreader‑test controleert hoe een website wordt voorgelezen door screenreadersoftware. Hierbij wordt gekeken of de content logisch is opgebouwd, of semantische HTML correct wordt gebruikt en of interactieve elementen goed worden aangekondigd. Deze test is essentieel voor blinde en slechtziende gebruikers.

4. Technology, compatibility & performance

In deze categorie vallen tests die vooral gericht zijn op technische correctheid, compatibiliteit tussen apparaten en browsers en de prestaties van de site.

Manual testing

Manual testing is het testen van een applicatie door deze zelf te gebruiken, zonder geautomatiseerde scripts. Hierbij wordt gekeken naar functionaliteit, gebruiksvriendelijkheid en randgevallen. Manual testing is vooral waardevol voor het beoordelen van de gebruikerservaring en het opsporen van fouten die lastig te automatiseren zijn.

Automated testing

Automated testing houdt in dat tests automatisch worden uitgevoerd met behulp van testtools en scripts. Deze tests controleren bijvoorbeeld of functionaliteit correct werkt na codewijzigingen. Automated testing wordt vaak ingezet binnen continuous integration (CI) en helpt om fouten vroegtijdig te signaleren en regressies te voorkomen.

W3C‑validator

De W3C‑validator is een geautomatiseerde tool die HTML en CSS controleert op fouten en naleving van webstandaarden. Het gebruik van deze validator helpt bij het verbeteren van compatibiliteit, toegankelijkheid en onderhoudbaarheid van websites.

Browser testing

Bij browser testing wordt gecontroleerd of een website correct werkt en wordt weergegeven in verschillende browsers. Omdat browsers verschillen in rendering en ondersteuning van features, helpt deze test compatibiliteitsproblemen te voorkomen.

Device testing

Bij device testing wordt een website getest op verschillende apparaten, zoals desktops, tablets en smartphones. Hierbij wordt gekeken naar layout, interactie en performance. Deze test helpt om een consistente gebruikerservaring te garanderen op uiteenlopende schermformaten en hardware.

Performance testing

Een performance test meet hoe snel en efficiënt een website of applicatie werkt. Hierbij wordt gekeken naar laadtijden, responsiviteit en resourcegebruik. Goede performance draagt bij aan een betere gebruikerservaring en hogere betrouwbaarheid.

Waterfall performance

Waterfall performance beschrijft het analyseren van de laadtijd per onderdeel van een pagina, zoals HTML, CSS, JavaScript en afbeeldingen. Door deze volgorde inzichtelijk te maken (bijv. via de network‑tab in devtools), kunnen knelpunten in performance worden opgespoord en geoptimaliseerd.