Toekomstige features en ideeën

Deze pagina verzamelt ideeën die waardevol kunnen zijn voor een latere versie van OefenHub, maar nog niet zijn uitgewerkt als requirement, Functioneel Ontwerp, Technisch Ontwerp, usecase of schermdocumentatie.

De punten op deze pagina zijn geen V1.0-scope, geen acceptatiecriterium en geen implementatieopdracht. Een idee wordt pas onderdeel van de baseline nadat het expliciet is uitgewerkt in de daarvoor bedoelde bronlagen.

Werkwijze

Wanneer een idee wordt opgepakt, wordt minimaal bepaald:

• welk probleem of welke gebruikersbehoefte het oplost;
• voor welke rollen het bedoeld is;
• of het binnen of buiten de bestaande V1.0-architectuur past;
• welke requirements, usecases, schermdocumentatie, database-informatie en Technisch Ontwerp-aanpassingen nodig zijn;
• of bestaande privacy-, security-, performance- of beheerafspraken geraakt worden.

Ideeën

Avatar zelf samenstellen

Onderzoek of het huidige avatar-/profielfotosysteem later kan worden uitgebreid of vervangen door een avatarbouwer. In plaats van handmatig uploaden of kiezen uit een vaste afbeeldingenset stelt de gebruiker dan zelf een avatar samen op basis van vooraf gedefinieerde opties.

Mogelijke configureerbare onderdelen:

• basisvorm of presentatie, bijvoorbeeld man/vrouw of meerdere neutrale basisopties;
• haarstijl;
• haarkleur;
• oogkleur;
• type neus;
• type mond of lach;
• oorbellen;
• neuspiercing;
• kleding of een klein zichtbaar kledingdeel.

Aandachtspunten voor latere uitwerking:

• het systeem moet kindvriendelijk blijven;
• vrije upload of vrije tekst blijft niet automatisch toegestaan;
• de samenstelopties moeten beheersbaar en veilig zijn;
• opslag moet waarschijnlijk via compacte avatarconfiguratie of gegenereerde assetreferentie verlopen;
• bestaande profielavatarafspraken en privacyregels moeten opnieuw worden beoordeeld.

Gamification en snelheidsdruk

Onderzoek of gamification-elementen kunnen helpen om oefenen aantrekkelijker te maken zonder de primaire leerdoelen te verstoren.

Mogelijke richting:

• oefeningen met een countdown of tijdslimiet;
• snelheidsdruk als optionele oefenvorm;
• badges, streaks of beloningen;
• voortgangsfeedback die motiveert zonder onnodige afleiding.

Aandachtspunten voor latere uitwerking:

• snelheidsdruk moet optioneel en pedagogisch verantwoord blijven;
• toegankelijkheid en stressgevoeligheid moeten worden meegewogen;
• resultaten van tijdsdruk-oefeningen moeten mogelijk anders worden geïnterpreteerd dan reguliere oefenresultaten;
• live meekijken, statistieken en PDF-export kunnen aanvullende velden of labels nodig hebben.

Frontpage leerling: snel wisselen van niveau

Onderzoek of leerlingen met meerdere toegestane niveaus op de frontpage sneller tussen niveaus moeten kunnen wisselen.

Mogelijke richting:

• compacte niveauwisselaar op de leerling-frontpage;
• duidelijke weergave van het actieve niveau;
• snelle toegang tot recent gebruikte niveaus;
• behoud van server-side autorisatiecontrole bij iedere wissel.

Aandachtspunten voor latere uitwerking:

• niveauwissel mag geen autorisatie verruimen;
• voortgang, verdergaanlogica en recente oefeningen blijven niveaugebonden;
• de UI moet voorkomen dat kinderen per ongeluk in de verkeerde niveaucontext oefenen.

Caching van site-instellingen en popups

Onderzoek of beheerbare site-instellingen en popupdefinities centraal gecached kunnen worden om uitlezen eenvoudiger en sneller te maken.

Mogelijke cachekandidaten:

• alle site-instellingen;
• alle popupdefinities;
• eventueel gerelateerde template- of featuretoggle-informatie wanneer dat technisch logisch blijkt.

Aandachtspunten voor latere uitwerking:

• cache-invalidation na beheerwijziging moet eenduidig zijn;
• cache mag geen bron van waarheid worden;
• secrets en gevoelige waarden mogen niet via beheerbare site-instellingen worden gecached;
• beheeracties moeten direct of voorspelbaar zichtbaar worden in de applicatie;
• impact op readmodels, performance en deployment moet in het Technisch Ontwerp worden beoordeeld.

Bounce-afhandeling voor externe uitnodigingsmails

Onderzoek of OefenHub later expliciete bounce-afhandeling nodig heeft voor e-mails die technisch succesvol aan de mailserver zijn aangeboden, maar daarna alsnog niet bezorgd blijken te worden. Dit speelt met name bij externe relatie-uitnodigingen naar e-mailadressen die nog niet aan een OefenHub-account gekoppeld zijn.

Huidige V1.0-richting:

• OefenHub registreert dat een uitnodigingsmail is klaargezet en aan de mailserver is aangeboden.
• Directe SMTP-fouten kunnen als technische delivery-fout worden verwerkt.
• Een later bouncebericht of provider-signaal wordt nog niet automatisch verwerkt.
• Relatieverzoekstatus blijft functioneel leidend: openstaand, geaccepteerd, geweigerd, ingetrokken of verlopen.

Mogelijke toekomstige richting:

• bounceberichten uitlezen via mailbox polling, provider-webhook of provider-API;
• bounces koppelen aan de oorspronkelijke mailpoging, relatie-uitnodiging en correlation/source-action context;
• gebruikersvriendelijke melding tonen wanneer een uitnodigingsmail vermoedelijk niet bezorgd kon worden;
• beheerder inzicht geven in technische oorzaakcategorieën zonder gevoelige SMTP- of providerdetails aan gewone gebruikers te tonen;
• eventueel herinneren/intrekken beter ondersteunen vanuit de relatieverzoekdetails.

Aandachtspunten voor latere uitwerking:

• niet elke mailprovider ondersteunt dezelfde bounce- of webhookmogelijkheden;
• veel SMTP-acceptaties betekenen alleen dat de mailserver de mail heeft aangenomen, niet dat de ontvanger de mail daadwerkelijk krijgt;
• technische foutdetails, stacktraces, providerresponses en infrastructuurgegevens mogen niet zichtbaar worden voor gewone gebruikers;
• het systeem moet onderscheid maken tussen tijdelijke bezorgproblemen, definitieve weigering en onbekende/onvoldoende betrouwbare signalen;
• privacy en toestemming blijven belangrijk omdat relatie-uitnodigingen persoonsgegevens kunnen bevatten;
• dit is geen vervanging voor de functionele relatieverzoekstatus en mag verlopen/intrekken/accepteren niet doorkruisen.