Schermlaag en UX-specificaties
21.1 Doel
De schermlaag vertaalt domeinregels, procesflows, autorisatiegrenzen en readmodels naar concrete gebruikersinterfaces.
Het FO beschrijft op hoofdlijnen welk functioneel gedrag de schermlaag moet ondersteunen. De schermdocumentatie beschrijft per scherm de concrete uitwerking: routecontext, rolcontext, hoofdentiteit, zichtbare onderdelen, dynamische waarden, acties, lege toestanden en schermspecifieke aandachtspunten.
De schermlaag is daarmee geen zelfstandige bron voor domeinwaarheid. Zij presenteert wat vanuit de onderliggende usecases, domeinregels, autorisatiecontroles, database-informatie en readmodels is toegestaan.
21.2 Bronpositie
Voor scherm- en UX-informatie gelden de volgende bronlagen.
| Bronlaag | Functie |
|---|---|
| FO | Beschrijft functionele samenhang, schermprincipes, rolgrenzen en overkoepelend UX-gedrag. |
| Schermdocumentatie | Beschrijft per scherm de concrete UI-context, zichtbare gegevens, acties, lege toestanden en waardelagen. |
| Usecases | Beschrijven procesflows, actoren, precondities, postcondities en uitzonderingsstromen. |
| Registers | Leggen traceability vast tussen usecases, schermen, requirements, popupkeys en andere bronobjecten. |
| Database-informatie | Beschrijft brondata, readmodels, auditobjecten en persistente grenzen. |
| Mockupdocumentatie en HTML-mockups | Ondersteunen visuele interpretatie, layoutcontrole en componentgedrag. |
| PNG’s | Zijn visuele referenties en geen zelfstandige functionele bron. |
De volledige schermlijst wordt niet in dit hoofdstuk onderhouden. Gebruik daarvoor de FO-schermindex en de onderliggende schermdocumentatie.
21.3 Algemene schermregels
Voor alle schermen gelden de volgende functionele uitgangspunten.
- Een zichtbaar UI-element is geen autorisatiebewijs.
- Iedere pagina, detailweergave, mutatie, export, liveactie of vervolgactie voert opnieuw server-side de relevante autorisatie- en contextcontrole uit.
- Routeparameters, clientstate, browsergeschiedenis, filters en selectiecontexten mogen toegang nooit verruimen.
- Dynamische waarden zoals aantallen, badges, statussen, datums, naamweergaven en samenvattingen worden afgeleid uit brondata of readmodels.
- Lege toestanden zijn normale toestanden wanneer de gebruiker wel toegang heeft maar er geen data beschikbaar is.
- Schermdocumentatie mag voorbeeldwaarden uit mockups gebruiken, maar die waarden zijn niet leidend tenzij expliciet als functionele waarde vastgelegd.
- Schermdocumentatie dupliceert geen popupteksten wanneer popupregisterkeys leidend zijn.
- Schermdocumentatie dupliceert geen volledige usecaseflows wanneer een klikbare verwijzing naar de usecase volstaat.
- Schermdocumentatie beschrijft header en footer alleen lokaal wanneer dit voor het scherm functioneel relevant is. Centrale regels staan in Applicatieschil, header, footer en navigatie.
21.4 Schermdocumentatie als functionele specificatie
De schermdocumentatie vult het FO vooral aan op deze punten:
| Onderdeel | Betekenis |
|---|---|
| Route- en contextverwachting | Welke route, processtap of gebruikerscontext bij het scherm hoort. |
| Autorisatiecontext | Welke rolcontext, relatie, eigendom, collaboratorstatus of beheercontext vereist is. |
| Primaire entiteit | Welk domeinobject, readmodel of tijdelijk exportmodel centraal staat. |
| Dynamische waarden | Welke waarden afgeleid zijn en dus niet hard in de UI staan. |
| Lege toestanden | Wanneer geen data een normale toestand is en geen fout. |
| Acties | Welke gebruikershandeling een vervolgflow, mutatie, popup, export of detailweergave start. |
| Schermgrenzen | Welke functionaliteit bewust niet op het scherm thuishoort. |
| Waardelagen | Welke labels, technische namen, databronnen en validaties bij UI-elementen horen. |
De schermdocumentatie is niet bedoeld als volledig pixelperfect ontwerp. Exacte CSS, componentspacing en visuele afwerking blijven buiten het FO, tenzij zij functionele betekenis hebben.
21.5 Schermdomeinen
De schermdocumentatie is opgebouwd per doelgroep of functioneel domein.
| Domein | Ingang |
|---|---|
| Beheerder | Schermdocumentatie beheerder |
| Docent | Schermdocumentatie docent |
| Leerling | Schermdocumentatie leerling |
| Ouder/voogd | Schermdocumentatie ouder/voogd |
| Generiek | Schermdocumentatie generiek |
| Mockups HTML | Mockupdocumentatie |
| Volledige FO-schermindex | FO-schermindex |
21.6 Functionele UX-principes
21.6.1 Rustige leerlingervaring tijdens oefenen
Tijdens een actieve leerling-oefenrun mag de webapp de leerling niet afleiden met nieuwe signalen die niet nodig zijn voor de oefening zelf.
Daarom geldt tijdens een actieve oefencontext:
- berichtenbadges worden visueel verborgen of niet live geüpdatet;
- meldingsterugkoppelingen worden niet opdringerig getoond;
- systeemnotificatie-overlays worden niet boven de oefening geplaatst;
- inkomende relatie-, bericht- of meldingssignalen blijven wel administratief bestaan;
- na verlaten of afronden van de oefencontext worden relevante signalen opnieuw beoordeeld.
Deze regel beïnvloedt alleen de presentatie aan de leerling. De onderliggende berichten, systeemberichten, meldingen, readstates, auditregels en notificaties blijven behouden.
Zie ook Applicatieschil, header, footer en navigatie en Berichten, communicatie en notificaties.
21.6.2 Read-only schermgedrag
Schermen voor resultaten, geschiedenis, PDF-export, online-overzichten en live meekijken kunnen dezelfde brondata gebruiken, maar niet ieder scherm mag die brondata wijzigen.
Voor read-only schermen geldt:
- tonen, filteren, sorteren, bladeren en exporteren wijzigen de brondata niet;
- filterwaarden zijn geen autorisatiebron;
- detail-ID’s uit routes worden opnieuw geautoriseerd;
- de UI mag geen gedeeltelijke gevoelige data tonen wanneer toegang ontbreekt.
Dit is vooral relevant voor ouder-/voogdresultaten, docentresultaten, live meekijken en PDF-export.
21.6.3 Muterende schermen
Schermen die wel mutaties ondersteunen, zoals profiel wijzigen, voorkeuren opslaan, relaties uitnodigen, berichten verzenden, meldingen behandelen, categorieën beheren, modules migreren of leerlingtoegang aanpassen, moeten minimaal:
- actuele server-side autorisatie controleren;
- verplichte velden valideren;
- domeinregels toepassen;
- foutgevallen veilig afhandelen;
- waar nodig audit- of historyregels veroorzaken;
- na succesvolle verwerking de zichtbare readmodels of overzichten bijwerken.
Een muterende knop in de UI mag nooit de enige controle zijn. De backend moet dezelfde beperkingen afdwingen.
21.7 Popup-, fout- en validatiegedrag
Schermen mogen gebruikersfeedback tonen via inline validatie, statusmeldingen, modals, popups of systeemnotificaties.
Voor popupgedrag geldt:
- popupregisterkeys zijn leidend waar deze bestaan;
- schermdocumentatie en usecases verwijzen naar popupkeys en dupliceren geen volledige popuptekst;
- autorisatiefouten mogen geen gevoelige inhoud lekken;
- foutmeldingen mogen geen technische payload, token, stacktrace of interne identificatie tonen;
- beheerschermen mogen compactere technische context tonen dan eindgebruikersschermen, maar alleen binnen beheerautorisatie.
Zie ook Popups, templates, features en systeemnotificaties.
21.8 Algemene foutpagina's
OefenHub vangt niet-beschikbare routes, autorisatie-onverenigbare routes en onverwachte technische fouten op met nette foutpagina's of gelijkwaardige veilige foutweergaven.
Voor 40x- en 50x-foutweergaven geldt functioneel:
- de gebruiker ziet geen stacktrace, token, payload of technische foutdetails;
- header, navigatie en footer blijven waar veilig mogelijk in dezelfde applicatiestijl beschikbaar;
- de gebruiker krijgt een begrijpelijke route terug naar een veilige context, zoals home, vorige pagina of passende rolcontext;
- de foutweergave verruimt geen autorisatie en toont geen gedeeltelijke afgeschermde data;
- technische logging en beheeranalyse kunnen plaatsvinden buiten de gebruikersweergave.
De exacte tekst, route en visuele uitwerking van zulke foutpagina's horen in schermdocumentatie of implementatie, maar de veilige en consistente foutafhandeling is een FO-brede schermregel.
21.9 Relatie met mockupdocumentatie
De mockupdocumentatie en statische HTML-mockups zijn ondersteunend voor:
- layoutinterpretatie;
- visuele groepering;
- responsief gedrag;
- schermvolgorde;
- herkenning van blokken, kaarten, tabellen, knoppen en modals;
- controle van header-, footer- en navigatiegedrag.
Voor het FO zijn mockups niet de plaats om domeinregels zelfstandig af te leiden wanneer usecases, schermdocumentatie of database-informatie iets anders bepalen.
Wanneer later pixelperfecte uitwerking of componentgerichte UI-specificatie nodig is, moeten mockupdocumentatie, HTML-bronnen en schermdocumentatie opnieuw naast elkaar worden gelegd.
21.10 Relatie met FO-hoofdstukken
Schermlaagafspraken raken meerdere FO-hoofdstukken.
| FO-hoofdstuk | Relatie met schermlaag |
|---|---|
| Applicatieschil, header, footer en navigatie | Centrale regels voor header, menu’s, badges, profielmenu en footer. |
| Frontpages en overzichtsschermen | Regels voor samenvattingsblokken, tellers, frontpagecontexten en overzichtsdata. |
| Account, profiel en voorkeuren | Profielschermen, toegankelijkheid, voorkeuren, sessiecontext en accountflows. |
| Leerling: oefenen, voortgang en resultaten | Oefenschermen, startpagina’s, voortgang, resultaten en geschiedenis. |
| Docentfunctionaliteit | Docentoverzichten, oefenaanbod, leerlingen, autorisaties en collaborators. |
| Ouder-/voogdfunctionaliteit | Kinderen, resultaten, online-overzicht en ouder-/voogd-read-only grenzen. |
| Beheerderfunctionaliteit | Beheerschermen, accountbeheer, contentbeheer, categorieën, modules en docentondersteuning. |
| Berichten, communicatie en notificaties | Berichtenoverzicht, privéberichten, systeemcommunicatie, badges en anti-afleiding. |
| Meldingen en ticketafhandeling | Meldingenoverzicht, detailpagina, discussie, oplossing, heropenen en beheerafhandeling. |
| Live meekijken | Online-overzichten, meekijksessies, browse-modus en read-only voortgangsweergave. |
21.11 Gebruik bij verdere FO-review
Bij iedere domeinreview wordt gecontroleerd of het FO-hoofdstuk:
- verwijst naar de juiste schermdocumentatie;
- geen volledige schermdocumentatie dupliceert;
- wel de functionele schermbetekenis samenvat;
- autorisatie- en read-only grenzen correct benoemt;
- lege toestanden als normale toestanden behandelt;
- popupkeys en foutafhandeling niet dubbel uitschrijft;
- voldoende doorkliklinks biedt naar detailbronnen.
Wanneer een schermspecifieke regel alleen voor één scherm geldt, hoort die regel in de schermdocumentatie en niet als algemene FO-regel in dit hoofdstuk.
21.12 Gerelateerde bronverwijzingen
| Bron | Link |
|---|---|
| Technisch Ontwerp — frontend Blazor | Frontend, Blazor, routing, state en componentopbouw |
| Schermdocumentatie — intro | Schermdocumentatie |
| Schermdocumentatie — beheerder | Beheerder |
| Schermdocumentatie — docent | Docent |
| Schermdocumentatie — leerling | Leerling |
| Schermdocumentatie — ouder/voogd | Ouder/voogd |
| Schermdocumentatie — generiek | Generiek |
| Mockupdocumentatie | Mockups HTML |
| FO-schermindex | FO-schermindex |
| FO — applicatieschil | Applicatieschil, header, footer en navigatie |
| FO — popups en systeemnotificaties | Popups, templates, features en systeemnotificaties |