Door de jaren heen hebben al heel wat mensen geëxperimenteerd met het gebruik van xAPI om data over het leergedrag vast te leggen. Een plek waar ze daar het nodige over schrijven is bij Watershed, een leverancier van Learning Record Stores (LRS) en Learning Analytics analysetools.
Het bericht waar ik het nu over heb is al van even geleden, maar nog steeds relevant. Het beschrijft hoe de auteur een (test-) applicatie in Virtual Reality (VR) gebouwd heeft voor gebruik als trainingsmiddel binnen een organisatie. De opdracht is simpel: identificeer de gevaarlijke situaties (“industrial safety hazards”) die je ziet.
De applicatie maakt, hoe kan het in dit geval ook anders, gebruik van xAPI om activiteiten van de gebruiker vast te leggen in de Watershed LRS.
Wat moet er bijgehouden worden in de LRS?
Geoff (de auteur van het blog) laat de applicatie uittesten en gaat dan in gesprek over wat de gebruikers zinvol vinden als het gaat om het vastleggen van activiteiten. Ze komen tot het volgende lijstje:
- Simulation start
- Simulation end
- Simulation session time
- Hazards identified
- False positives (= situaties die als gevaarlijk zijn aangemerkt, maar het niet zijn)
Een eerste reactie als ik dat lijstje zie is dat startmoment, goede antwoorden en foute antwoorden redelijk goed te doen is. Het einde van een sessie (en daarmee de duur van de sessie) is wat ingewikkelder. Daar moet het leerobject voor zorgen, binnen SCORM (een voorloper van xAPI) was het een vereiste van het leerobject dat je het niet “zomaar” kon afsluiten zoals je dat bijvoorbeeld bij een webpagina normaal wél kunt doen. Bij webpagina komt het meestal neer op het veronderstellen dat een sessie bv 20 minuten na de laatste actie afgesloten wordt (dan werd de sessie op de server namelijk meestal ook afgesloten).
Welke rapportages moeten er gemaakt worden?
Een tweede zinvolle vraag die Geoff met de testers bespreekt is welke rapportages er op basis hiervan gemaakt moeten kunnen worden, of eigenlijk: welke informatie moet een rapportage over dit leerobject bevatten?
Ze komen tot de volgende lijst:
- Users who identified all hazards
- Users who dwelled longer/was uncertain about the hazards in the simulations
- Sequence of hazards identified by users
- Hazards most identified by users
- Hazard identified first by users
- Hazard identified last by users
De laatste twee punten las ik eerst op de verkeerde manier: het zijn dus niet de de meest recente gevaarlijke situatie en de gevaarlijke situatie die het langst geleden in de LRS terecht zijn gekomen, het is gemeten ten opzichte van de start van de sessie en ik neem aan dat je per gevaarlijke situatie een telling wilt bijhouden van hoe vaak die als eerste of als laatste gemarkeerd is.
Het tweede punt: gebruikers die onzeker waren of langer twijfelden vind ik ook een wat ingewikkeldere. Ik kan me voorstellen dat je de tijd berekent tussen de start van de sessie en het moment dat de gebruiker de laatste gevaarlijke situatie vindt. Maar als een gebruiker niet alle gevaarlijke situaties kan vinden, dan kun je deze tijd niet berekenen. Wie weet is het vinden van een paar gevaarlijke situaties voor iedereen gemakkelijk, maar zijn een aantal voor veel mensen moeilijk.
Het artikel bevat helaas geen voorbeeld van hoe de antwoorden op deze vragen op basis van de getoonde, beschikbare, xAPI data (zie hieronder) beantwoord kunnen worden.
Maar het artikel geeft wél goed weer de soort gesprekken die je moet voeren bij het ontwikkelen van leermaterialen waarbij je gebruik wilt maken van data om het gebruik te analyseren en inzichtelijk te maken. Of dat nu in VR is of ‘gewoon’ in een browser, dat maakt daarbij niet uit.
En eigenlijk zou je de twee stappen in omgekeerde volgorde moeten doorlopen. Dus eerst jezelf afvragen welke vragen je achteraf wilt kunnen beantwoorden en van daaruit dan bedenken welke data je moet vastleggen!
Twee logische vragen die je jezelf (of docenten/studenten) moet stellen bij ontwikkelen van leermateriaal (in VR of… https://t.co/6Tc5I6idcd