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

Vormen van e-learning modules

Er zijn een aantal mogelijkheden om modules voor zelfstudie te ontwikkelen:

BlackBoard

Dit kan de docent in principe zelf, maar kan ook samen met het CPIO worden ontwikkeld.

1. Oefeningen die in BlackBoard worden gemaakt en afgenomen.
   • Voordelen:
     1. Direct te koppelen aan BlackBoard, met statistieken, release-data en overzicht cijfers
     2. Eenvoudig door docent te onderhouden
   • Nadelen:
     1. Geen feedback direct na beantwoorden vraag
     2. Alleen beschikbaar voor de studenten van deze cursus
2. Formatieve toetsen van het elektronische toetsprogramma Remindo die als oefentoets kunnen worden aangeboden. Ook dit kan de docent in principe zelf.
   • Voordelen:
     1. Redelijk eenvoudig door docent 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
3. Ontwikkeling in Xerte
   • Voordelen:
     1. Veel mogelijk
     2. Voor iedereen beschikbaar
     3. Makkelijk te onderhouden voor docenten
     4. Ook in BlackBoard te koppelen
   • Nadelen:
     1. Niet alle gegevens worden opgeslagen
     2. Buiten BlackBoard geen inlog mogelijk
   • Voorbeeld: Ontwikkelingsbiologie, module Hamster

Ontwikkeling door CPIO

Bij het CPIO worden de COO-modules op maat geproduceerd in overleg met de docent.
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.

• Hierna zal voornamelijk gesproken worden over het ontwikkelen in de eigen omgeving, hoewel het hele ontwikkelproces ook gebruikt kan worden voor ontwikkeling met de andere platforms (BlackBoard en Remindo).
• 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 PowerPoint en het boek, en pas nadat dit is afgerond een docent dit nog een keer evalueert voordat het gebruikt gaat worden.
• Zodra een docent 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.

Kosten / tijdsinvestering

Een gemiddelde oefentoets heeft een ontwikkeltijd van ongeveer 120 uur, en heeft de volgende kenmerken:

• ongeveer 40 vragen, inclusief subvragen zijn dat 50-60 vragen
• een student is er ongeveer 90 min mee bezig
• heeft hooguit 3 korte animaties
• de lay-out is standaard
• de ruwe vragen worden door de docent aangeleverd
• alle inhoud is terug te vinden in een boek
• er is één docent bij betrokken

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

Andersoortige COO's zijn ook mogelijk, zoals simulaties.

Werkwijze

Er zijn een aantal stappen:

1. Intake
2. Scripten
3. Programmeren
4. Testen
5. Gebruiken
6. Evalueren

Scripten vergt de grootste tijdsinvestering: zo'n 80% van de ontwikkeltijd. Hierin worden bijvoorbeeld bij elke (sub)vraag voor alle mogelijke antwoorden feedbacks 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 deze 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 tijdens het uitwerken 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 wordt 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 COO 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. Er zijn wat beperkingen: niet van alle type vragen worden de gegeven antwoorden opgeslagen.
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 worden gebruikt.

6 Evaluatie

1. Er is geen standaard evaluatie; evaluatie kan via een extra vraag in Caracal.
2. In de toekomst is er hopelijk een uitgebreidere mogelijkheid voor het evalueren van de antwoorden