Ontwikkelen van e-learningmodules

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

• Teksten schrijven voor een beeldscherm
• Vraagconstructie
• De verschillende beschikbare tools, en welke waarvoor het meest 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.

Het ontwikkelproces van een e-learningmodule ziet er als volgt uit:

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 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 lesmateriaal 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 soms 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. Afhankelijk van de instellingen van de module kunnen ze opengesteld worden voor een algemeen publiek of alleen voor een specifieke groep gebruikers. 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.

Applicaties voor 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. Docent en leerlingen zijn al bekend met het platform
• 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

Ulearning

• Voordelen:
  1. Redelijk eenvoudig door docent te maken en te onderhouden
  2. Veel opties voor gebruikersbeheer, statistieken en evaluatie
  3. Veel opties voor (groeps-)opdrachten
• Nadelen:
  1. Grafische interface kan niet bewerkt worden

Xerte

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

• Voordelen:
  1. Veel mogelijkheden
  2. Zonder inlog beschikbaar voor studenten
  3. Dashboard met resultaten en statistieken
  4. 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. Veel mogelijkheden
  2. Ook mogelijkheid om variabelen te gebruiken, waardoor verschillende routes door de module mogelijk zijn
  3. Zonder inlog beschikbaar voor studenten
  4. 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: start minstens 2 maanden van te voren met ontwikkeling. Voor ons kost dit 100-200 uur, maar als docent moet je ook goed nadenken over hoe de module eruit komt te zien. Elk practicum is weer anders (leert de ervaring), en moet weer op maat ontworpen worden.

• Voordelen:
  1. Veel mogelijkheden op de website, en nog meer in de ExperD
  2. In ExperD kan gewerkt worden met variabelen, 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. Ontwikkelen en onderhoud voor docenten te ingewikkeld
  2. Geen directe koppeling met BlackBoard, dus alle studenten moeten met de hand ingevoerd worden (via een bestand met namen en e-mailadressen)