Applicatieschil, header, footer en navigatie

3.1 Doel

De applicatieschil omvat de vaste elementen rond alle functionele schermen: logo, header, begroeting, hoofdnavigatie, categorienavigatie, rolmenu’s, berichtenicoon, profielmenu, meldingsindicaties, systeemnotificaties en footer.

Deze onderdelen vormen geen losse domeinflow, maar bepalen wel hoe gebruikers veilig, rustig en consistent door OefenHub navigeren. De applicatieschil is vooral belangrijk omdat:

• meerdere rollen dezelfde applicatie gebruiken;
• gebruikers rolcombinaties kunnen hebben;
• leerlingcategorieën en rolnavigatie responsief moeten blijven werken;
• leerlingen tijdens een actieve oefening niet mogen worden afgeleid door nieuwe signalen;
• header- en footerregels op alle schermen consistent moeten blijven.

De centrale bron voor deze overkoepelende regels is Header, footer en responsieve navigatie. Schermdocumentatie beschrijft header en footer alleen lokaal wanneer dat voor een specifiek scherm functioneel relevant is.

3.2 Header na login

Na succesvolle login toont de header onder of bij het logo een korte begroeting op basis van de voornaam van de ingelogde gebruiker.

Situatie	Tekstregel
Eerste OefenHub-bezoeksessie op dezelfde serverdatum	Welkom <voornaam>
Latere bezoeken of dezelfde sessie op een latere serverdatum	Welkom terug, <voornaam>

De bepaling van de eerste bezoeksessie komt uit betrouwbare account- en sessiecontext. Bij het inlogmoment wordt vastgelegd of LastSeenAtUtc nog leeg was; alleen dan krijgt de auth-sessie een tijdelijke first-visit-vlag met serverdatum. Browserstate mag deze tekst niet zelfstandig afdwingen.

Wanneer de identity-providerlogin wel slaagt maar de interne OefenHub-initialisatie faalt, ontstaat geen bruikbare OefenHub-login. De gebruiker krijgt dan geen normale ingelogde header en geen reguliere applicatiecontext.

3.2.1 Focused onboarding-shell

Tijdens verplichte eerste onboarding gebruikt OefenHub centraal een focused onboarding-shell. Deze shell geldt voor onboardingroutes zoals /onboarding/* en voor verplichte rolkeuze zolang de gebruiker nog geen afgeronde OefenHub-onboarding heeft.

De focused onboarding-shell toont wel:

• logo;
• begroeting volgens de centrale first-visit-regel;
• een losse actie Uitloggen als veilige escape.

De focused onboarding-shell toont niet:

• reguliere rol- of hoofdnavigatie;
• responsief Menu;
• berichtenicoon of berichtenbadge;
• profielmenu.

Deze regel wordt niet per onboardingpagina opnieuw uitgevonden. De shellresolver bepaalt centraal op basis van route en onboardingcontext welke shellvariant actief is.

3.2.2 Browserpaginatitel

De browserpaginatitel wordt centraal opgebouwd in de applicatieschil. De sitebasis en separator zijn configureerbaar via OefenHub:Display:PageTitle en OefenHub:Display:PageTitleSeperator.

Voor gewone pagina's geldt het patroon:

<sitebasis> <separator> <paginanaam>

Met de standaardconfiguratie wordt bijvoorbeeld de berichtenpagina weergegeven als OefenHub - Berichten. Pagina's mogen dit patroon niet per scherm met losse stringopbouw dupliceren; de centrale helper/component blijft leidend.

3.3 Hoofdregels voor éénregelige header

De header blijft in basis één regel hoog. Navigatie-elementen mogen bij ruimtegebrek niet naar een tweede regel doorlopen.

Wanneer de beschikbare breedte onvoldoende is, wordt inhoud gegroepeerd in uitklapbare menu’s. Dit geldt voor:

• leerlingcategorieën;
• rolgebonden hoofdnavigatie;
• combinatierollen;
• beheer-, docent- en ouder-/voogdmenu’s;
• smalle vensters of tabletbreedtes.

Deze groepering is uitsluitend responsief presentatiegedrag. Autorisatie, routebeschikbaarheid en rolcontext blijven server-side bepaald.

3.4 Leerlingcategorieën in de header

Leerlingen kunnen meer categorieën beschikbaar hebben dan op één headerregel passen. Wanneer losse categorieknoppen niet meer passen, worden zij gegroepeerd onder één uitklapbaar menu met het label Categorieën.

De inhoud van dit menu volgt exact dezelfde functionele regels als losse categorieknoppen:

• alleen categorieën binnen het actieve leerlingniveau;
• alleen categorieën waarvoor de leerling server-side toegang heeft;
• alleen categorieën die functioneel zichtbaar zijn doordat zij minimaal één actieve toegankelijke oefening bevatten;
• geen categorieën op basis van oude clientstate, bookmarks of verborgen browserselecties.

Het inklappen wijzigt geen categorie, oefening, niveaucontext of autorisatie.

3.5 Responsieve rolnavigatie

Wanneer rolgebonden menu-items niet passen, worden zij per rolcontext gegroepeerd.

Rolcontext	Groeplabel	Menu-items op hoofdlijnen
Beheerder	Beheer	Site Instellingen, Content, Categorieën beheren, Modules beheren, Docent ondersteuning, Accounts beheren en overige beheeritems volgens de actuele navigatiestructuur.
Docent	Docent	Oefenaanbod, Leerlingen, Online.
Ouder/voogd	Ouder/Voogd	Kinderen, Online.

Wanneer ook deze rolgroepen samen niet meer op de headerregel passen, worden zij nog één niveau verder gegroepeerd onder Menu.

Onder Menu staan alleen de rolcontextgroepen die voor de gebruiker daadwerkelijk beschikbaar zijn, bijvoorbeeld:

• Beheer;
• Docent;
• Ouder/Voogd.

Ook deze extra groepering is uitsluitend responsief presentatiegedrag. Zij kent geen rechten toe en verruimt geen route- of actieautorisatie.

3.5.1 Interactiegedrag van categorie- en oefeningmenu's

Voor categorie- en oefeningmenu's gelden vaste interactieregels zodat desktop- en tabletgedrag niet verschillend wordt geïnterpreteerd. Deze regels beschrijven uitsluitend presentatie- en navigatiegedrag; autorisatie, niveaucontext en zichtbare oefenset blijven server-side bepaald.

Context	Regel
Desktop hover	Een oefeningmenu mag openen via mouse-over op een categorieknop.
Desktop klik	Een oefeningmenu mag ook openen via linker muisklik, behalve wanneer dezelfde menuopening al door de voorafgaande hoveractie is geactiveerd.
Tablet/touch	Het submenu opent via tik of aanraking op de categorieknop.
Zichtbaar blijven	Een geopend submenu blijft zichtbaar totdat buiten het submenu wordt geklikt/getikt of totdat een oefening wordt gekozen.
Wisselen van categorie	Wanneer al een categorie openstaat en een andere categorie wordt aangeklikt of geactiveerd, sluit de eerdere categorie en opent de nieuwe categorie.
Desktop hover verlaten	Alleen de muis buiten het submenu bewegen sluit het menu niet automatisch; bewegen naar een andere categorie mag wel de actieve categorie wisselen.

Deze interactieregels mogen responsief anders worden vormgegeven, maar de functionele betekenis blijft gelijk: een zichtbaar menu toont alleen actuele, geautoriseerde categorieën en oefeningen binnen de actieve leerling- of rolcontext.

3.6 Combinatierollen in navigatie

Bij combinatierollen worden navigatie-items niet dubbel getoond. De zichtbaarheid van een navigatie-item geeft geen autorisatie op zichzelf. Iedere onderliggende pagina en iedere actie herhaalt server-side de relevante contextcontrole.

De runtime-prioriteit voor gecombineerde frontpages blijft:

1. Beheerder;
2. Docent;
3. Ouder/voogd.

Deze prioriteit bepaalt de volgorde van samenvattingsblokken op de frontpage. Zij geeft geen extra rechten buiten de actieve rolcontext.

3.7 Berichten, badges en meldingsindicaties

De header kan signalen tonen voor ongelezen berichten, meldingen die actie vragen en profielgerelateerde aandachtspunten. Deze signalen zijn afgeleide readmodelwaarden. Zij mogen nooit als bron worden gebruikt voor autorisatie, mailboxinhoud of ticketstatus.

Voor leerlingen geldt een aanvullende anti-afleidingsregel tijdens een actieve oefening:

• berichtenbadges worden visueel verborgen of niet geüpdatet;
• meldingsindicaties en meldingsterugkoppelingen worden niet opdringerig getoond;
• systeemnotificatie-overlays worden niet boven de oefening geplaatst;
• realtime signalen naar de leerling worden uitgesteld tot de oefencontext is verlaten of afgerond.

De onderliggende data wordt wel correct opgeslagen. Ongelezenstatus, systeemberichten, privéberichten, relatie-uitnodigingen en meldingsupdates blijven bestaan en worden na afloop opnieuw beoordeeld.

Deze regel geldt specifiek voor de leerlingervaring tijdens een actieve oefenrun. Zij voorkomt afleiding door de webapp, maar mag geen berichten, meldingen, readstates of auditinformatie verliezen.

Nieuwe of gewijzigde mailboxitems kunnen via realtime transport of een gelijkwaardige invalidatie aan de shell worden doorgegeven, maar de shell moet de actuele teller altijd opnieuw uit de server-side readmodels kunnen bepalen. Wanneer realtime invalidatie niet beschikbaar is, blijft navigatie, openen, reconnect of expliciet opnieuw ophalen voldoende om de badge te synchroniseren.

3.8 Profielmenu

Het profielmenu biedt afhankelijk van rolcontext, featurestatus en autorisatie toegang tot onder meer:

• Profiel;
• Toegankelijkheid;
• Voorkeuren;
• Berichten;
• Relaties;
• Meldingen;
• Geschiedenis;
• Uitloggen.

Een zichtbaar menu-item betekent alleen dat de gebruiker de route mag proberen te openen. De inhoud van de route wordt altijd opnieuw server-side bepaald.

Tijdens een actieve leerling-oefenrun mogen profielmenu- of headerindicatoren geen afleidende live-updates tonen. De route of onderliggende data verdwijnt daardoor niet; alleen de visuele signalering wordt uitgesteld of verborgen zolang de oefencontext actief is.

3.9 Footer

De footer bestaat functioneel uit drie kolommen:

1. links;
2. midden;
3. rechts.

Bij voldoende breedte staan deze kolommen naast elkaar. Bij smalle schermen worden zij onder elkaar geplaatst in deze volgorde:

1. midden;
2. rechts;
3. links.

Deze volgorde is bewust gekozen zodat op smalle schermen eerst de meest functionele navigatie- en linkblokken zichtbaar zijn.

Footerinhoud wordt per rolcontext beheerd via het content-, footer- en handige-linksmodel. De footerstructuur, kolomposities en responsive overgang zijn codegedreven en worden niet door beheerders vrij als layout gewijzigd.

Zie voor footerbeheer ook Contentbeheer, vaste pagina’s en footer.

3.10 Functionele schermbron

De header en footer komen terug in vrijwel alle schermdocumentatie, maar worden daar alleen beschreven voor zover zij voor het betreffende scherm functioneel relevant zijn.

De centrale regels in dit hoofdstuk zijn leidend voor consistent gedrag over rollen heen. Schermdocumentatie mag deze regels verder concretiseren per scherm, maar hoort de applicatieschilregels niet per scherm afwijkend opnieuw uit te vinden.

3.11 Gerelateerde bronverwijzingen

Bron	Link
Technisch Ontwerp — frontend Blazor	Frontend, Blazor, routing, state en componentopbouw
Technisch Ontwerp — communicatie	Berichten, systeemberichten, notificaties en privéthreads
Technisch Ontwerp — security-infrastructuur	Security, infrastructuur, secrets en omgevingen
Ontwerpbron — header, footer en navigatie	Header, footer en responsieve navigatie
Schermdocumentatie — intro	Schermdocumentatie
Schermdocumentatie — publieke frontpage	Generiek — Niet ingelogd
Schermdocumentatie — leerling frontpage	Leerling — Frontpage
Schermdocumentatie — docent frontpage	Docent — Frontpage
Schermdocumentatie — ouder/voogd frontpage	Ouder/voogd — Frontpage
Schermdocumentatie — beheerder frontpage	Beheerder — Frontpage
Usecases generiek — berichten	Berichten
Usecases generiek — meldingen	Meldingen
FO — contentbeheer, vaste pagina’s en footer	Contentbeheer, vaste pagina’s en footer
FO — schermlaag en UX-specificaties	Schermlaag en UX-specificaties