Ontwikkelen van e-learningmodules

Het CPIO biedt zowel onderwijskundige als technische ondersteuning bij het ontwikkelen van modules.
Het CPIO heeft expertise op de volgende gebieden:

• Teksten schrijven voor een beeldscherm
• Vraagconstructie
• De verschillende beschikbare tools, en welke waarvoor het beste geschikt is
• De verschillende vraagtypen/paginatypen die in de verschillende tools mogelijk zijn

De modules zijn meestal in de vorm van oefentoetsen, die het werkcollege kunnen vervangen, maar andere vormen zijn ook mogelijk. Er kunnen ook video's of animaties gemaakt worden.

Ontwikkeling door CPIO

Docenten kunnen zelf modules maken, waarbij het CPIO dan onderwijskundige input en technische ondersteuning kan bieden.

Het CPIO kan ook de volledige ontwikkeling (in overleg met de inhoudsdeskundige) helemaal voor zijn rekening nemen. Zodra een docent daarna ook zelf in de module veranderingen aanbrengt, is deze ook verantwoordelijk voor de module en het herstellen van mogelijke fouten en bugs. Het CPIO zal dan alleen nog op verzoek wijzigingen aanbrengen.

Hieronder het ontwikkelproces zoals het zou moeten gaan. Echter, door tijdgebrek van de docent komt het er tegenwoordig vaak op neer dat vrijwel al deze stappen worden overgeslagen en dat het CPIO een module maakt aan de hand van een bestaande PowerPoint en het boek, en pas nadat dit is afgerond een docent dit nog een keer evalueert voordat het direct gebruikt gaat worden.

Werkwijze

Hieronder worden de stappen beschreven. Scripten vergt daarvan de grootste tijdsinvestering: zo'n 80% van de ontwikkeltijd. Hierin worden bijvoorbeeld bij elke vraag voor alle mogelijke antwoorden een feedback geformuleerd, en beeldmateriaal gezocht.

1. Intake

Eerst wordt een inventarisatie uitgevoerd, waarin wordt besproken:

• Wat is de reden dat er voor een COO wordt gekozen?
• Welk probleem wordt hiermee hopelijk opgelost, en wordt bepaald of dat zo is?
• Hoeveel tijd heeft de docent om hieraan te werken?
• Welk materiaal is er al beschikbaar?
• Wanneer moet het gebruikt worden?

2. Scripten

Aan de hand van het aangeleverde materiaal wordt in stappen een script gemaakt waarin alle pagina's en vragen helemaal zijn uitgewerkt. Bij een standaard lay-out is dit script vrij simpel. Over korte perioden van bijvoorbeeld een week wordt het laatst ontwikkelde deel van het script goedgekeurd en kan dat worden geprogrammeerd. Omdat tijdens het programmeren vaak blijkt dat een andere vorm beter werkt, kan het voorkomen dat een vraag al meteen tijdens het scripten al wordt geprogrammeerd, en de docent direct de geprogrammeerde vraag kan beoordelen.

3. Programmeren

Programmeren gaat ook in stapjes, voordat het scripten van de totale module is afgerond. Dat betekent dat in de overlegmomenten zowel het laatste deel van het script, als van de module worden besproken.

4. Testen

• Eerste test door programmeur
• Tweede test door docent
• Derde test door student-assistenten

Deze laatste stap wordt wegens tijdgebrek vaak overgeslagen. Voordeel van deze laatste stap is dat de studentassistenten die straks de studenten begeleiden al weten waar de e-learning over gaat.

5. Gebruiken

1. Het meeste effect hebben deze modules als ze worden ingeroosterd, en de studenten er aan koppels aan moeten werken. Studenten die dit alleen thuis doen, hebben veelal de neiging om gewoon 'door te klikken' en de juiste antwoorden te noteren. Het leereffect is dan nihil.
2. Van elke sessie kunnen desgewenst de gegevens worden opgeslagen voor evaluatie.
3. De modules staan in principe op het internet, vrij toegankelijk voor de hele wereld. Desgewenst kunnen ze ook als SCORM-module in een ander platform zoals BlackBoard of Ulearning worden gebruikt.

6. Evaluatie

1. Voor het evalueren van het gebruik van een Xerte-module is een statistische module beschikbaar (zie [Inzetten van e-learningmodules]].
2. Voor het evalueren van de gebruikerstevredenheid is geen standaard evaluatie; evaluatie kan via een extra vraag in Caracal. Eventueel kan op de laatste pagina een link gegeven worden naar een specifieke enquête.

Kosten / tijdsinvestering

Een gemiddelde oefentoets heeft een ontwikkeltijd van ongeveer 60 uur (tijd van CPIO), en heeft de volgende kenmerken:

• ongeveer 30 vragen
• een aantal informatiepagina's
• afbeeldingen bij de meeste pagina's (liefst uit het boek)
• een student is er ongeveer 90 min mee bezig
• eventueel enkele video's
• de lay-out is standaard
• de ruwe vragen worden door de docent aangeleverd
• alle inhoud is terug te vinden in een boek (liefst met digitale afbeeldingen)
• er is één docent bij betrokken

Alles waarin afgeweken wordt van de bovenstaande punten zal extra ontwikkeltijd kunnen opleveren.
Deze 60 uur is uitsluitend tijd van het CPIO; de docent zal daarnaast ook zelf tijd kwijt zijn voor het aanleveren van de vragen, controleren van het script en beoordelen van de e-learning zelf.

Vormen van e-learning modules

Er zijn een aantal mogelijke applicaties voor de ontwikkeling van e-learning.
Hieronder een opsomming van applicaties waar het CPIO expertise in heeft, met voor- en nadelen, gerangschikt op in hoeverre de docent hier makkelijk zelfstandig mee kan werken:

BlackBoard

• Voordelen:
  1. Door docent te ontwikkelen en onderhouden
  2. Direct te koppelen aan BlackBoard, met statistieken, release-data en overzicht cijfers
  3. Eenvoudig door docent te onderhouden
• Nadelen:
  1. Geen feedback direct na beantwoorden vraag
  2. Alleen beschikbaar voor de studenten van deze cursus

Remindo

In Remindo zijn ook formatieve toetsen- mogelijk.

• Voordelen:
  1. Redelijk eenvoudig door docent te maken en te onderhouden
  2. Uitgebreide analyse van de resultaten
  3. Meer vraagtypen mogelijk dan in BlackBoard
• Nadelen:
  1. Geen koppeling naar BlackBoard
  2. Studenten moeten per module worden toegewezen

Xerte

Hierin zijn de meeste e-learningmodules door het CPIO gemaakt.

• Voordelen:
  1. Veel mogelijkheden
  2. Zonder inlog beschikbaar voor studenten
  3. Ook in BlackBoard te koppelen als SCORM-module, zonder score
• Nadelen:
  1. Ontwikkelen en onderhoud voor docenten lastiger

Lectora

Hierin is een enkele module geprogrammeerd, waarbij van de lineaire route door de module moet worden afgeweken. Een voorbeeld daarvan is Selectie en drift.

• Voordelen:
  1. Ook mogelijkheid om variabelen te gebruiken, waardoor verschillende routes door de module mogelijk zijn
  2. Zonder inlog beschikbaar voor studenten
  3. In BlackBoard te koppelen als SCORM-module, met score
• Nadelen:
  1. Ontwikkelen en onderhoud voor docenten te ingewikkeld

LabBuddy

Dit is specifiek voor ondersteuning van practica. Elke module bestaat uit een website (startboek) en een Experd (Experiment ontwerper). De website is zonder inloggen beschikbaar, maar voor de ExperD moeten de studenten zijn toegevoegd. Ontwikkeling van een LabBuddy-module kost heel veel tijd

• Voordelen:
  1. Veel mogelijkheden op de website, en nog meer in de ExperD
  2. In ExperD kan gewerkt worden met variablene, aan de hand waarvan informatie en vragen al of niet verschijnen.
  3. Koppeling vanuit BlackBoard mogelijk waardoor de benodigde inlog kan worden overgeslagen
• Nadelen:
  1. Absoluut niet gebruiksvriendelijk en voor docenten niet geschikt om zelf te gebruiken
  2. Geen directe koppeling met BlackBoard, dus alle studenten moeten met de hand ingevoerd worden (via een bestand)