Standaard draaiboek voor docentprofessionalisering

Skills Labs: Hoogwaardige e-practica Water Management met EMERGO

Deliverable 3.3: Standaard draaiboek voor docentprofessionalisering

Auteurs: Hans Hummel, Rob Nadolski, Aad Slootmaker (CELSTEC)

Skills Labs penvoerende instelling: Open Universiteit Nederland - CELSTEC (Centrum voor Leertheorie en Technologieën) - Faculteit Natuurwetenschappen - Faculteit Managementwetenschappen Skills Labs partner instellingen: - Hogeschool Zeeland - Kennis Netwerk Delta Water (KNDW) (Provincie Zeeland, Delta, de Waterschappen, Roosevelt Academy, NIOO-Nederlands Instituut voor Ecologie, Rijkswaterstaat, Deltares en Wageningen Universiteit en Researchcentrum)

Datum: 12 februari 2010 Versie 1.0 Kenmerk: U2010/1057

Inhoudsopgave Samenvatting 1. inleiding 2. opzet workshops 2.1. inhoud en aanpak workshops 2.2. uitvoering en waardering workshops 3. instructiematerialen voor docenten 3.1. voorbeeldmateriaal bij workshops 3.2. normgetallen bij casusontwikkeling 3.3. instructiematerialen per fase 4. conclusies en aanbevelingen

Bijlagen B1. beschrijving workshops B2. evaluatieformulier workshops B3. instructie video en naamgevingen bestanden B4. instructie demonstrators B5. instructie bij gebruik componenten toolkit

Samenvatting Een standaard draaiboek bij de ontwikkeling van hoogwaardige e-practica is nodig om toekomstige ontwikkeling effectief en efficiënt te kunnen laten verlopen, en door docenten grotendeels onafhankelijk van experts te laten plaatsvinden. Dit draaiboek richt zich vooral op de daarvoor benodigde (onderwijstechnologische) professionalisering van docenten die als casusontwikkelaars een casus (leermateriaal) met behulp van EMERGO zullen gaan ontwikkelen. Deze deliverable bevat daartoe een beschrijving van het professionaliseringsaanbod (een set van workshops, aangevuld met on-the-job training) zoals dat binnen Skills Labs is ontwikkeld, uitgevoerd, en geëvalueerd. Dit trainingsaanbod is binnen Skills Labs geëvalueerd en een substantieel deel van de opmerkingen en gewenste aanpassingen is al meegenomen bij het opstellen van deze Deliverable 3.3. Deze evaluatie valt echter buiten de scope van deze deliverable en is in de voortgangsrapportages van het project beschreven. Ten slotte heeft er ook een meer specifiek op de inhoud gerichte doeminspecifieke onderlinge professionalisering tussen de casusontwikkelaars bij Skills Labs plaats gevonden die niet veralgemeniseerbaar is en derhalve eveneens buiten de scope valt van deze deliverable 3.3. Het document beschrijft de (reeds eerder binnen het EMERGO project ontwikkelde) methodiek en toolkit, de aanscherpingen daarvan op basis van ervaringen, wensen en behoeften binnen Skills Labs, en de neerslag ervan in instructiematerialen voor docentprofessionalisering (workshop beschrijvingen, uitgewerkte voorbeelden, demonstrators, presentatiemateriaal, instructieteksten, e.a.) waarmee casusontwikkeling door ontwikkelaars voor een groot deel zelfstandig ter hand kan worden genomen (immers een expliciet doel van het Skills Labs project). De beschrijvingen en de daarbij behorende referenties en bijlagen zullen er in de toekomst voor kunnen zorgen dat e-casus ontwikkeling met behulp van EMERGO nog efficiënter en transparanter kan verlopen. De fasering in de methodiek biedt een logisch richtsnoer voor de volgorde van de professionaliseringsactiviteiten.

Skills Labs (Del 3.3)

3

1. Inleiding Deliverable 3.3 bevat een beschrijving van de tijdens Skills Labs uitgevoerde professionalisering en het daarbij ontwikkelde en gebruikte instructiemateriaal. Doel is de opgedane ervaring als draaiboek te documenteren, en wel zo dat de binnen Skills Labs uitgevoerde professionalisering en daarbij ontwikkelde materiaal ook na afloop van het project (opnieuw) kunnen worden (her)gebruikt, oftewel opnieuw worden afgedraaid. We kunnen daarbij denken aan vergelijkbare projecten waar epractica met EMERGO ontwikkeld gaan worden waarvoor ook onderwijstechnologische professionalisering en technische support nodig zal zijn. Het document bouwt voort op de globale beschrijving van de workshops (eerder opgeleverd in Deliverable 3.1, versie 1.0, 1 maart 2009). Deze workshops zijn in het project Skills Labs voor de casusontwikkelaars (docenten) vanuit WP3 (Professionalisering en Support) georganiseerd en aangeboden in een tijdsbestek van ongeveer een half jaar. Deze workshops waren gericht op het leren werken met de EMERGO-methodiek en de EMERGO-toolkit. We beschrijven in dit document de opzet van de workshops (hoofdstuk 2), alsmede het materiaal (hoofdstuk 3) ter ondersteuning van de workshops (instructies, presentaties, uitgewerkte voorbeelden, demonstrators, e.d.). Naast de workshops is on-the-job support geboden, materiaal ontwikkeld ter ondersteuning van de professionalisering bij meer inhoudelijke casus ontwikkeling, en ondersteuning geboden bij disseminatie en communityvorming. Omdat dit laatste meer specifiek (minder herhaalbaar) is valt dit buiten het bestek van een standaard draaiboek. Dit trainingsaanbod (o.a workshops en gebruikte materialen) is binnen Skills Labs bij docenten geëvalueerd en een substantieel deel van de opmerkingen en gewenste aanpassingen is al meegenomen bij het opstellen van deze Deliverable 3.3. Deze evaluatie valt echter buiten de scope van deze deliverable en is in de voortgangsrapportages van het project beschreven. De deliverable eindigt met enkele conclusies en aanbevelingen (hoofdstuk 4). In een aantal bijlagen vindt u meer specifieke en uitgebreidere informatie of verwijzingen. Ook aan EMERGO “super-users” zijn workshops aangeboden, gericht op het meer technische beheer (bv. voor het casusrun management, het installeren en inrichten EMERGO-server, e.d.), maar deze zijn beschreven in Deliverable 3.2 (Duurzame infrastructuur en support services bij opleidingen, versie 1.1, 30 november 2009) en blijven hier buiten beschouwing. Er is sprake van de nodige overlap tussen deze deliverable 3.3 en deliverable 4.7 omdat ze beiden de EMERGO methodiek en toolkit tot onderwerp hebben. Deliverable 3.3 zal soms iets meer detail van deze methodiek en toolkit geven (maar verwijst voor de details eveneens doorgaans naar de EMERGO-Website), en richt zich primair op het professionaliseringsaanbod hierbij. Deliverable 3.3 heeft docenten als doelgroep. Deliverable 4.7 richt zich niet alleen op docenten, maar ook op cursusontwerpers (ICTO-medewerkers) en opleidingsmanagers. Daarom geeft deliverable 4.7 tevens de omstandigheden (voorwaarden) en criteria aan waaronder e-casus effectief kunnen worden ontwikkeld en ingezet, alsmede evaluatiegegevens rond het gebruik van de EMERGO methode en toolkit. Daarnaast zult u in deliverable 4.7 richtlijnen vinden voor de technische infrastructuur en exploitatie (details in deliverable 3.2), enkele normgetallen voor de ontwikkeling van e-casus, en richtlijnen voor een effectieve teamsamenstelling bij casusontwikkeling.


4

2. Opzet workshops professionalisering Gedurende de looptijd van het Skills Labs project zijn een aantal workshops voor docent professionalisering ontworpen, uitgevoerd en geëvalueerd. De functionele doelstellingen achter dit aanbod waren dat hierdoor: a. casusontwikkeling door docenten efficiënter en effectiever zal verlopen; b. docenten in het kader van disseminatie-activiteiten ook beter als ambassadeurs binnen hun instelling kunnen optreden (‘zegt het voort’); en c. de mogelijkheid wordt geboden tot het mede vormgeven van de teamvorming binnen Skills Labs. Via een aanbod van workshops en bijbehorende materialen wordt de gewenste onderwijstechnologische professionalisering van casusontwikkelaars transparanter en herhaalbaarder. In deze deliverable 3.3 wordt dit aanbod geconsolideerd en verduurzaamd in een standaard draaiboek voor docentprofessionalisering. Het ontwikkelen van een hoogwaardige e-practica (ook wel: e-casus) verloopt volgens de EMERGOmethodiek zoals deze reeds uitgebreid staat beschreven in de (binnen het Surf-project EMERGO opgeleverde) deliverable 1.4.b staat beschreven (zie Figuur 1). De e-casussen die via EMERGO worden ontwikkeld en uitgeleverd zijn via het internet benaderbaar en richten zich op het (samen) op afstand actief verwerven van complexe vaardigheden in multimediaal vormgegeven realistische praktijkconfrontaties (zie www.emergo.cc voor meer informatie).

Figuur 1. Methodiek voor casusontwikkeling: van casusidee tot casusevaluatie De open pijlen in Figuur 1 geven een geadviseerde volgorde van doorlopen in casusontwikkeling aan. De fasen kunnen bovendien iteratief (gesloten pijlen) worden doorlopen. Het gebruik en de ontwikkeling van e-casussen met EMERGO kan als een systematisch en planbaar proces worden uitgevoerd tegen afnemende kosten. De verdere aanscherping van deze methodiek en verbreding ervaring met het ontwikkelen en gebruik van e-casussen in een diversiteit van domeinen biedt een blijvend interessant perspectief voor duurzame en hoogwaardige e-learning in het HO.

2.1 De inhoud en aanpak van de workshops In het Skills Labs project heeft een aanscherping van deze EMERGO-methodiek plaatsgevonden. Dit kon enerzijds omdat de casusontwikkeling bij Skills Labs tot op zekere hoogte afwijkend bleek van de eerdere casusontwikkeling via de EMERGO-methodiek, en anderzijds omdat het binnen Skills Labs een expliciet doel was om tot zelfstandig gebruik van instructiemateriaal bij de EMERGOmethodiek en toolkit te komen. Tijdens de uitvoering van de workshops met de EMERGO-methodiek werd, op basis van tussentijdse evaluaties per workshop, besloten om het voorlopige workshop programma (zie werkdocument d.d. 15 oktober 2008; beschikbaar in surfgroep Shared documents / WP3) in grote lijnen te volgen, maar tevens geruime gelegenheid tot inhoudelijk overleg te voeren. In het voorlopig ontwerp was ervan uitgegaan dat de inhoudelijke ontwerpen gereed zouden zijn bij aanvang van de meer onderwijskundig gerichte EMERGO workshops. Dit bleek niet haalbaar, met name aangezien het domein water management nog relatief onontgonnen is. Er bleek nog veel behoefte tot inhoudelijke afstemming en teamvorming (doelstelling 3) binnen maar ook tussen de casusteams, voordat tot onderwijskundige uitwerking en implementatie kon worden overgegaan. De meer concrete invulling van de methodiek-workshops is dus niet louter tot de uitleg van de methodiek beperkt. Er zijn ook


5

momenten ingeruimd om inhoudelijke discussies te kunnen voeren. Voor dit specifieke project was dit opportuun, maar voor deze deliverable is het wel een complicatie. Deze momenten van inhoudelijke afstemming, teamvorming en professionalisering zijn namelijk domeinspecifiek en moeten we hier grotendeels buiten beschouwing laten; ze zijn immers niet als standaard te zien en kunnen niet herbruikt worden voor professionalisering bij andere projecten binnen andere domeinen.

Figuur 2. Oorspronkelijke planning programma workshops De workshops zijn gegeven in de periode november 2009 tot augustus 2009. Startdatum voor het Skills Labs project was september 2008. De eerste workshop vond dus al na twee maanden looptijd plaats, en het is dus ook niet verwonderlijk dat de inhoud van de casuïstiek nog niet voldoende was uitgewerkt. De laatste (zevende) workshop was de zogenaamde super-user (technisch beheer) workshop, welke door een technisch ontwikkelaar op de HZ in augustus 2009 is verzorgd; deze valt buiten bestek van deze deliverable maar komt aan bod in Deliverable 3.2. Bij het aantal workshops hebben we naar een middenweg gezocht tussen uitwerking en diepgang (veel workshops) en haalbaarheid in organisatorische zin (weinig workshops). De oorspronkelijk (als zevende) geplande workshop over video ontwikkeling (inclusief informatie over formaten) is komen te vervallen, vooral omdat we de opname, montage, e.d. van nieuw audio-visueel materiaal door een eigen productie crew (Multimedia, IPO, OUNL) hebben laten uitvoeren, en de docenten binnen Skills Labs dus geen bemoeienis daarmee kregen. Wel zijn er via email tips voor video formaten en (uniforme) beschrijving bestanden afgesproken (zie Bijlage 3). Mocht er bij volgende projecten wel sprake zijn dat docenten dit (deels) zelf gaan doen, zal daar dus extra in moeten worden voorzien. Via SurfNet worden trainingen voor het zelf maken van opnames aangeboden die hiervoor als startpunt gehanteerd kunnen worden. In zijn algemeenheid is het echter raadzaam om bij meer geavanceerde AV-producties gebruik te maken van AV-professionals. Uiteindelijk zijn we voor wat betreft de onderwijstechnologische workshops uitgekomen op een 2 x 3 workshops programma, waarbij de eerste drie workshops gericht waren op ondersteuning bij scenario ontwikkeling (de EMERGO methodiek, vooral verzorgd door onderwijstechnologen) en de laatste drie workshops op ondersteuning bij het gebruik van de software (de EMERGO toolkit, vooral verzorgd door technisch ontwikkelaars). -

Workshop 1: Van casusidee tot raamwerk scenario

-

Workshop 2: Van raamwerk scenario tot ingrediënten verhaal

-

Workshop 3: Van ingrediënten verhaal tot detail scenario


6

-

Workshop 4: Rollen, locaties, taken, bronnen

-

Workshops 5/6: Gesprekken, berichten, scripting

De workshops hadden elk een duur van ongeveer 4 uur (een dagdeel). Workshops zijn op diverse locaties gegeven. Afwijkingen van de oorspronkelijke planning (zie Figuur 2) waren gering. Wel zijn de workshops 5 en 6 gecombineerd (volledige dag) aangeboden vanwege organisatorische redenen. De organisatie van de workshops werd bij Skills Labs geregeld door de werkpakketleider van het werkpakket Professionalisering en Support. In Bijlage 1 vindt u een uitgebreidere beschrijving van de inhoud en aanpak van de workshops.

2.2 De uitvoering en waardering van de workshops Binnen Skills Labs werden er 4 e-casussen ontwikkeld met een voorziene studielast van 20-30 uur. Elk casusteam bestond uit 2 tot 4 personen en werd geleid door een casustrekker. Inhoudelijke coördinatie tussen de casusteams werd verzorgd door een de werkpakketleider casusontwikkeling die tevens als inhoudsdeskundige participeerde. Het ligt voor de hand om in teams aan casusontwikkeling te werken. Binnen zo’n multidisciplinair team kunnen meerdere deskundigheden vertegenwoordigd zijn (zie ook Deliverable 4.7). De setting hiervoor beschreven is specifiek voor Skills Labs. Doorgaans zal aan casusontwikkeling van een individuele casus worden gewerkt. In dat geval zal de casustrekker de centrale spil vormen. Dit kan de docent zijn, en de omvang van een team zal per casus sterk kunnen verschillen. Belangrijk is dat onderwijskundige, technische en inhoudelijke expertise vertegenwoordigd zijn bij de casusontwikkeling. Dat kan binnen het team zijn, maar kan natuurlijk ook via inhuur of anderszins plaatsvinden. Bij Skills Labs geldt dat in beginsel de casustrekkers en de werkpakketleider casusontwikkeling bij alle workshops betrokken waren, en waren de casustrekkers tevens eindverantwoordelijk voor datainvoer, inclusief de scripting van de casus. De veronderstelling is namelijk dat de casustrekker alle in’s en out’s van de casus kent (bij elke instelling) hetgeen een noodzaak is om de Scripting te kunnen doen. Een aantal andere casusteamleden waren ook bij alle workshops aanwezig, met name de eerste drie waarin de scenarios moesten worden uitgewerkt. Het aantal docenten dat per workshop deelnam lag daarmee zo gemiddeld op tien docenten. Om praktisch-organisatorische reden vonden alle Toolkit- workshops in Heerlen plaats in het CELSTEC-laboratorium van de Open Universiteit Nederland. De workshops rondom de EMERGO-methodiek hebben achtereenvolgens Heerlen (workshop 1), Heerlen & Vlissingen (workshop 2), en Eindhoven (workshop 3) aangedaan. Elke workshop werd geëvalueerd (evaluatieformulier, zie Bijlage 2). Over het algemeen werden de workshops als goed gewaardeerd. De workshops zijn door de deelnemers met de cijfers 7 en hoger gewaardeerd (gemiddeld 8). Docenten geven aan de ruimte voor teamvorming (doelstelling 3) en toepasbaarheid in de ontwikkeling (doelstelling 1) te waarderen. De werkgerichte en positieve sfeer werd door velen genoemd. Het beschikbaar zijn van duidelijke voorbeelden en instructies werd als zeer belangrijk gezien. Het niveau van detail van de besprekingen en de feedback die werd uitgewisseld werd door enkelen als te oppervlakkig beschouwd; men zou daarvoor graag (nog) meer tijd ingeruimd zien. Hier speelt de afweging tussen wat (nog) het best in een plenaire workshop, en wat het best in een on-the-job training aan bod kan komen. De gebruiksvriendelijkheid van de gebruikshandleiding zou op diverse punten nog verbeterd kunnen worden. Bij de workshops geldt dat er Internettoegang geregeld moet zijn en dat de ruimte liefst snel heringericht kan worden zodat met diverse tafelschikkingen tijdens de workshop kan worden gewerkt. Deelnemers kunnen gebruik maken van hun eigen labtop of van aangeboden apparatuur.


7

3. Instructiematerialen voor docenten Tijdens de workshops werd ter illustratie van de verschillende stappen (in scenario ontwikkeling) en de verschillende componenten (van de toolkit) gebruik gemaakt van zogenaamde uitgewerkte voorbeelden. Deze uitgewerkte voorbeelden waren, ten tijde van de workshops noodgedwongen, afkomstig uit andere, reeds met EMERGO ontwikkelde e-casus. Gelet op de verwantschap met het onderwerp is gekozen voor een e-casus op het domein Omgevingsbeleid, te weten ‘Compromis rond de Waddenzee’ (ontwikkeld tijdens het voorafgaande SURF EMERGO project). Tijdens de casusontwikkeling zijn extra Skills Labs voorbeelden per stap beschikbaar gekomen. Voor de professionalisering van docenten is naast voorbeelden gebruik gemaakt van demonstrators en instructies. In dit hoofdstuk geven we in 3.1 een korte beschrijving van de binnen Skills Labs ontwikkelde voorbeeldmaterialen, in 3.2 een aantal normgetallen die bij casusontwikkeling kunnen worden gehanteerd, en in 3.3 per stap een overzicht van de beschikbare instructiematerialen.

3.1 Voorbeeldmateriaal bij de workshops Inmiddels zijn, naast de binnen EMERGO ontwikkelde voorbeelden, ook voor de vier binnen Skills Labs ontwikkelde e-casus uitgewerkte voorbeelden beschikbaar die voor volgende projecten bruikbaar zullen zijn als illustratie bij de professionalisering. Het gaat hierbij om volgens de EMERGO methodiek uitgewerkte casusideeën (analysefase: scenario ontwikkeling), uitgewerkte raamwerkscenarios (ontwerpfase: stap 2 scenario ontwikkeling), en interactieve testversies (fase ontwikkeling). Deze voorbeelden zijn als deliverables opgeleverd en – in maart 2010 - tevens beschikbaar op de EMERGO website, en wel: - Casusidee Estuarine systems: the Scheldt (Del. 2.1.a) - Casusframework Estuarine systems: the Scheldt (Del 2.1b) - Casusidee Water Governance: Perkpolder (Del 2.2.a) - Casusframework Water Governance: Perkpolder (Del 2.2.b) - Casusidee Aquaculture: Volkerak-Zoommeer (Del 2.3.a) - Casusframework Aquaculture: Volkerak-Zoommeer (Del 2.3.b) - Casusidee Building with Nature: Blue greens in Volkerak-Zoommeer (Del 2.4.a) - Casusframework Blue greens in Volkerak-Zoommeer (Del 2.4.b) Tijdens de methodiekworkshops (WS1-3) is, naast de reeds genoemde uitgewerkte voorbeelden, gebruik gemaakt van powerpoint presentaties en Deliverable 1.4b uit het EMERGO-project (methodiekbeschrijving EMERGO). Bij de toolkitworkshops (WS 4-6) is, naast presentaties met daarin voorbeelden, gebruik gemaakt van een (conceptversie van een) Gebruikershandleiding bij de toolkit. Deze presentaties en beschrijvingen zullen via de EMERGO site beschikbaar worden gesteld. Bij de ontwikkeling van de workshops is een uitgebreide instructie (draaiboek voor gebruik) uitgeschreven bij het uitleggen (presenteren) van de verschillende componenten van de toolkit aan onervaren gebruikers (zie Bijlage 5). Tijdens de workshops is voorbeeldmateriaal gedemonstreerd uit reeds beschikbare e-casus. Behalve uit eerder genoemde e-casus ViBOA (omgevingsbeleid) ook uit de e-casus Zorgsstructuur, en uit de demonstrators ‘Limburg canon’ en ‘CSI Heerlen’ (de laatste twee zijn vanwege disseminatie doeleinden tijdens looptijd Skills Labs ontwikkeld). We duiden deze werkende voorbeelden aan met demo-materiaal EMERGO (ook wel demonstrators of showcases genoemd). Een aantal van deze demonstrators is ook online en publiek beschikbaar op de demonstrator pagina van de EMERGO Website die via de keuze ‘demonstrators’ op de startpagina te bereiken zal zijn. Ook zijn bij een aantal van deze demonstrators instructies bij demonstratie geschreven, zodat eenieder weet hoe de karakteristieke kenmerken van het scenario getoond kunnen worden (zie Bijlage 4) aan onervaren


8

gebruikers. Een aantal kenmerkende fragmenten uit e-casus Skills Labs zijn ook online en publiek beschikbaar gesteld op de Skills Labs demonstrator pagina (http://emergo.ou.nl/emergo/community/SkillsLabs/skdemonstrator.html).

3.2 Normgetallen bij casusontwikkeling Uit de ervaring bij de docent professionalisering binnen Skills Labs is gebleken dat het moeilijk is om tijdig in te schatten welke studielast de ontwikkelde e-casus precies zal opleveren. Daarnaast bestond er geen goed beeld ten aanzien van de gewenste verdeling van de tijdsbesteding over de verschillende fasen van de casusontwikkeling. Voor de kosten bij casus ontwikkeling zijn inmiddels wel richtinggevende normgetallen beschikbaar. De kosten voor de casusontwikkeling kunnen op twee manieren in kaart worden gebracht: -

Normpercentages tussenproducten casusontwikkeling en

-

Normgetallen casusontwikkeling

De normpercentages voor de tussenproducten bij de casusontwikkeling kunnen als richtsnoer bij de casusontwikkeling worden gebruikt. Uiteraard is er een zekere variatiebreedte mogelijk in de cijfers die zijn genoemd in Tabel 1, enerzijds omdat de casusontwikkeling iteratief verloopt, en anderzijds omdat er behoorlijke verschillen bij afzonderlijke e-casussen kunnen spelen. Ze geven de (relatieve) percentages binnen de totale ontwikkeltijd aan, en zeggen niets over de kwantitatieve tijden. Tabel 1. Normpercentages ontwikkeltijd voor tussenproducten van de e-casus (casus-type ‘ standaard’) Tussenproduct

Percentage ontwikkeltijd

Gesommeerd

Casusidee

10%

10

Casusframework

10%

20

Casusingrediëntenverhaal

15%

35

Casusdetailscenario

30%

65

Invoeren en testen casus

25%

90

Evaluatie (0.9-versie) + bijstellen casus

10%

100

Het casus-type kan behoorlijk wat verschillen in ontwikkelingstijd met zich meebrengen. In Tabel 2 worden de factoren genoemd die een zogenaamd casus-type bepalen. Het casus-type ‘standaard’ gaat uit van 20% AudioVisuele(AV)-ontwikkeling, dus op het normgetal van 25 is 5 voor AVontwikkeling gereserveerd. Een normgetal van een casus-type bestaat altijd uit het normgetal van het type ‘standaard’ en daarbovenop een of meer normgetallen van de verder van toepassing zijnde casus-types. Alle casus-type normgetallen zijn gemiddelden en laten een fikse variatiebreedte bij afzonderlijke casussen van een bepaald type zien ( ca. +/- 50 %). Tabel 2. Normgetal casusontwikkeling, gerelateerd aan casustype . Casus-type

Normgetal

Toelichting

Standaard

25

Casuistiek, Nederlandstalig, eenvoudig, AV-normaal

Geen casuïstiek

+5

Geen bestaande casuïstiek, domein in ontwikkeling

AV-plus

+5

meer dan gemiddeld AV

Meertaligheid

+2

Uitlevering in twee talen

Complex

+5

Inherent complex domein (bv. Leiderschapsvaardigheden)

Contacten externen

+1

Bij multidisciplinaire bijdragen buiten projectteam

Normgetal van 25 betekent 25 uur casusontwikkeltijd voor 1 uur studiemateriaal. Normgetallen zijn


9

gemiddeld over alle casus-tussenproducten van dit casus-type. Zo zal een casus die (a) speelt in een inherent complex domein, (b) bestaande casuïstiek als startpunt kan nemen, (c) Nederlandstalig is, en (d) meer dan gemiddeld AV-opnames nodig heeft, een normgetal krijgen van: 25 (standaard) + 5 (complex) + 5 (AV-plus) = 35. Stel dat er 30 uur studiemateriaal van zo’n casustype ontwikkeld moet worden, dan zijn er – gemiddeld gezien - dus 30 x 35 = 1050 ontwikkeluren nodig ( = inhoud + AV + ondersteuning). Daarnaast blijkt uit ervaringsgegevens dat technische en onderwijskundige ondersteuning gemiddeld 15% tot 20% van het normgetal casusontwikkeling beslaat. Deze ondersteuning heeft bij het begin een onderwijskundig accent en krijgt een sterker technisch accent bij het opstellen van het casusdetailscenario en het invoeren/testen van de casus. Naarmate de casus complexer is zal er wat meer ondersteuning nodig zijn. Het normgetal casusontwikkeling bij casus-type ‘geen casuistiek’ veronderstelt dat bij het maken van een casusidee niet van bestaande casuïstiek kan worden uitgegaan. Daarbij geldt dat men procentueel gezien weliswaar meer tijd voor dit tussenproduct moet besteden (normpercentage ontwikkeltijd), maar dat dit elders in het traject van de tussenproducten kan worden gecompenseerd omdat dit hogere normgetal over de hele breedte (van alle tussenproducten) doorwerkt. Normgetallen zijn gemiddeld over alle casus-tussenproducten van dit casus-type. Verschillen in normpercentages ontwikkeltijd zijn niet per casus-type uitgesplitst. De percentages in Tabel 1 gelden voor casustype ‘standaard’. Algemene (standaard) richtlijnen voor het inschatten van studielast lijken moeilijk te geven, omdat ze in grote mate afhankelijk zijn van de inhoud en complexiteit van de opdrachten. Wel is inmiddels een checklist studiebelasting ontwikkeld die tevens op de EMERGO-Website zal worden aangeboden.

3.3 Instructiematerialen per fase Bij het doorlopen van de EMERGO-methodiek en het gebruik van de EMERGO-toolkit worden (als eerder in 2.1 beschreven) als tussenproducten onderscheiden: casusidee (analysefase), casusframework (stap 1 ontwerpfase) , casus ingrediëntenverhaal (stap 2 ontwerpfase), casus detailscenario (stap 3 ontwerpfase), testversie casus (ontwikkelfase), en evaluatieversie casus (fases implementatie en evaluatie). 3.3.1 Casusidee (fase Analyse) Voordat de cursusontwikkelaars beginnen met het concrete ontwerpen ontwikkelwerk van een casus dienen ze na te denken over uiteenlopende zaken die direct en indirect verband houden met de te ontwikkelen casus. Daarbij gaat het om zaken als: -

opleidingscontext van de casus

-

inhoud van de casus

-

monitoring van voortgang in de casus

-

eventuele samenwerking en uitwisseling van informatie tussen studenten in de casus

-

mediagebruik in de casus

-

uitleverproces van de casus

-

ondersteuning van de casus (ingebouwde begeleiding, peers, docenten)

-

exploitatiekosten van de casus

-

rechten en intellectueel eigendom met betrekking tot de casus.

Door diverse malen met elkaar te spreken over deze zaken aan de hand van concrete richtvragen wordt het projectteam zich nadrukkelijker bewust van het voor wie, wat, waarom en hoe van de


10

casus (context). Een en ander leidt al vroeg in het ontwikkeltraject tot een realistisch(er) beeld van de mogelijkheden en beperkingen waarmee het team rekening te houden heeft. Mede aan de hand van de antwoorden op deze vragen kan het team een globale beschrijving van de casus maken: het casusidee. Meer in detail: Over de opleidingscontext worden de volgende vragen gesteld: •

Bij welke instellingen en in welke opleidingen wordt de casus ingezet?

•

Is de casus een zelfstandige eenheid of maakt zij deel uit van een meer omvattend programma?

•

Wat is de studiebelasting?

•

In welke tijdsperiode moet de student de casus afronden?

•

Hoeveel studiepunten levert het succesvol afronden van de casus op?

•

Hoeveel studenten worden verwacht per studie per instelling per jaar?

•

Wat is voor deze casus de docent : student ratio (bij benadering)?

Over de inhoud worden de volgende vragen gesteld: •

Welke complexe vaardigheid (competentie) staat centraal in de casus?

•

Laat de complexe vaardigheid zich opsplitsen in relevante deelvaardigheden en zo ja, welke?

•

Op welk vakgebied of vakgebieden speelt de casus? Wat zijn relevante aanpalende gebieden?

•

Welke voorkennis wordt van de student verwacht?

•

Waar draait het in de casus om (bijv.patiënt, machine, proces, …)?

•

Op welke locatie(s) speelt de casus zich af? (Indien mogelijk, beschrijf de locatie in termen van virtuele ruimtes)

•

Welke karakters/personages spelen een rol in de casus?

•

Moet de student een stapsgewijs aanpak leren?

•

Wat moet de student zoal doen om de centrale competentie te verwerven?

•

Ligt de volgorde van (een deel van) de taken die de student moet uitvoeren, vast?

•

Zijn er naast de verplichte taken ook optionele taken? Zo ja, wat zijn dat voor taken?

•

Bevat de casus alleen informatie die nodig is voor het oplossen ervan of is de informatie redundant?

•

Krijgt de student een indicatie van de verwachte tijd die hij mag besteden aan het

•

Hoe authentiek/waarheidsgetrouw is de casus?

•

Mag de student dezelfde casus meer dan een keer doen? Zo ja, gaat het dan om dezelfde

doorwerken van de taken?

casus of om een variant daarop? •

Mag de student achteraf fouten herstellen of geldt ‘afgesloten is afgesloten!) ?

•

Moeten alle studenten exact dezelfde taken uitvoeren of zijn verschillende leerpaden

•

Werken studenten samen aan een gemeenschappelijk opdracht taak?

mogelijk? •

Wordt gebruik van peer feedback gemaakt?

•

Spelen studenten verschillende rollen binnen de casus?

•

Spelen docenten een expliciete rol binnen de casus of kijken zij alleen toe?

•

Wat maakt de casus leuk of spannend voor een student?

•

Welke voor de student onverwachte gebeurtenissen kunnen ingebracht worden in de casus?

•

Welke mogelijkheden zijn er om de student te belonen voor goede inzet en/of prestaties?


11

Over de voortgang van de casus worden de volgende vragen gesteld: •

Hoe ervaart een student dat hij de competentie nog niet bezit?

•

Hoe ziet de student dat hij vorderingen maakt?

•

Hoe wordt gecontroleerd of de competentie bereikt is?

•

Wordt er tussentijds summatief getoetst? Zo ja, hoe telt deze toetsing mee in het

•

Wat moet een docent van de voortgang van de studenten zien?

eindoordeel?

Over het studentcontact en studentinformatie rondom de casus worden de volgende vragen gesteld: •

Moet contact tussen studenten gefaciliteerd worden of juist niet?

•

Moeten studenten zien of andere studenten (en docenten) tegelijk ingelogd zijn?

•

Krijgt de student de kans om zichzelf met anderen te vergelijken? (bijvoorbeeld behaalde prestatie, bestede tijd, aantal uitgevoerde taken)

Over media-gebruik in de casus worden de volgende vragen gesteld: (video) •

Wat voor soorten video worden in de casus gebruikt (registraties, interviews, docudrama, speelfilm, opname op locatie, good en bad practices …)?

•

Hoeveel minuten video worden naar schatting in de casus gebruikt?

•

Wordt bestaand videomateriaal gebruikt?

•

Hoeveel materiaal wordt aangekocht?

•

Wordt nieuw videomateriaal opgenomen? Zo ja, waartoe en hoeveel?

•

Hoe worden de eigen opnames gemaakt (zelf, externe producent, …)

•

Hoeveel materiaal wordt zelf geproduceerd?

(Audio) •

Wat voor soorten audio worden in de casus gebruikt?(voice over, telefoon, interview)?

•

Hoeveel minuten audio worden naar schatting in de casus gebruikt?

•

Wordt bestaand audiomateriaal gebruikt?

•

Hoeveel materiaal wordt aangekocht?

•

Wordt nieuw audiomateriaal opgenomen? Zo ja, waartoe en hoeveel?

•

Hoe worden de eigen opnames gemaakt (zelf, externe producent, …)

•

Hoeveel materiaal wordt zelf geproduceerd?

(Animatie) •

Worden er animaties in de casus gebruikt?

•

Hoeveel minuten animatie worden naar schatting in de casus gebruikt?

•

Wie maakt de animaties (zelf, uitbesteed)

Over het uitleverproces worden de volgende vragen gesteld: •

Zijn er beperkingen aan het aantal studenten per casusrun?

•

Wanneer wordt een nieuwe casusrun gemaakt?

•

Kan iets aan een lopende casusrun toegevoegd of weggehaald worden?

Over ondersteuning tijdens de casus worden de volgende vragen gesteld: •

Op welke manier(en) wordt inhoudelijke ondersteuning en hulp geboden?

•

Op welke manier(en) wordt technische ondersteuning en hulp geboden?

Over exploitatiekosten worden de volgende vragen gesteld: •

Hoeveel minuten zal de docent naar schatting per student besteden aan begeleiding?


12

Over rechten en intellectueel eigendom m.b.t. de casus worden de volgende vragen gesteld: •

Hoe mogen anderen de casus gebruiken?

•

Wordt in de casus gebruik gemaakt van materiaal van derden?

•

Hoe zijn de rechten van derden geregeld?

Hulpmiddelen (op EMERGO-Website beschikbaar): -

Demonstrators EMERGO

-

EMERGO-methodiek in vogelvlucht

-

Worked out examples casusidee van reeds ontwikkelde casussen

-

Checklist met richtvragen

Richtlijnen - aandachtspunten: -

Gebruik slechts de relevante set van richtvragen uit de checklist.

-

Verzamel bestaande casuïstiek als startpunt. Mogelijkerwijs dient eerst vooraf een onderwijskundige-inhoudelijke analyse plaats te vinden waarin leerdoelen en inhoud in kaart worden gebracht, alvorens op zoek wordt gegaan naar bestaande casuïstiek. In het geval geen bestaande casuïstiek aanwezig is (of gebruikt mag worden) dan zal casuïstiekontwikkeling in nauwe samenspraak met de professie moeten plaatsvinden.

-

Ga na of en waar studenten in het casusontwikkelproces/onderhoud ingezet kunnen worden (o.a., via peerbegeleiding, via prosuming). Het casusontwikkelproces krijgt hierdoor naast een topdown-benadering ook een bottom-up benadering.

3.3.2 Casusframework (fase Ontwerp) De casusontwikkelaars nemen het casusidee als input voor het uitwerken van het casusframework. Het casusframework (onderdeel van de ontwerp fase) beschrijft de globale activiteiten die reële personen (studenten, docenten) en virtuele personen (ingebouwd in het casusmateriaal) gedurende de casus ondernemen, en met welke middelen. Er gelden geen strikte voorschriften voor de uitwerking van het casusframework, maar als standaard formaat voor het noteren van de activiteiten wordt voorgesteld: “Where the management assistant (student-playing character) will...<description of the activity>”. Op deze wijze kan een eerste serie van activiteiten worden geïdentificeerd zonder dat er het gevaar bestaat voor het zich verliezen in details (eerste voordeel). In de opsomming van activiteiten kan men bovendien al een onderscheid maken tussen verplichte en facultatieve activiteiten, of er al dan niet sprake is van een bepaalde volgorde in activiteiten, en of er activiteiten onverwacht opduiken in het ‘to do-lijstje’ van de casusspeler. Deze aanpak verschaft snel een blauwdruk voor aspecten die nadere uitwerking behoeven (tweede voordeel). Het opstellen van het framework lijkt op het maken van een bouwtekening voor een gebouw. Het casusteam hoeft derhalve niet al te veel tijd te besteden om al in een vroegtijdig stadium diverse elementen in detail uit te werken (derde voordeel). Op deze manier kan vergelijkbare aandacht aan alle elementen in de uitwerking worden besteed. Het casusframework kan eenvoudig en flexibel worden bijgesteld bij de vervolgstappen in de ontwerpfase. Overigens, het casusframework kan – gegeven de iteratieslagen in de EMERGOmethodiek – bij nadere uitwerking nog tot op zekere hoogte bijgesteld worden. Deze flexibiliteit is nodig om op veranderende contextuele aspecten te kunnen inspelen (bijvoorbeeld: (on)beschikbaarheid van bronnenmaterialen, expertconsultatie). Hulpmiddelen (op EMERGO-Website beschikbaar): -


-

Worked out examples casusframework van reeds ontwikkelde casussen

-

Powerpoints ‘van casusidee tot casusframework’


13


Gebruik swimlanes om de flow tussen PC’s (playing characters) en NPC’s (non-playing characters) te beschrijven via een opsomming van hun afzonderlijke activiteiten.

-

Tracht het aantal verschillende PC’s te beperken, bijvoorbeeld door een NPC te gebruiken, of een ‘bronnenverzameling’ die dynamisch informatie kan ontsluiten. Tracht tevens het aantal activiteiten te beperken. Dit leidt namelijk doorgaans tot een minder complexe casus. NPC’s kunnen daarnaast ervoor zorgen dat de variatiebreedte in mogelijke alternatieve paden binnen de casus op een vrij natuurlijke wijze kan worden ingeperkt.

3.3.3 Casus ingrediëntenverhaal (fase Ontwerp) In het casusingrediëntenverhaal wordt het casusframework verder aangekleed. Per activiteit wordt geïnventariseerd wat allemaal gebeurt. Wat doet welke playing character (PC), en met wie of wat doet hij dat (virtuele of echte begeleider, systeem, medestudenten in dezelfde rol of andere rol, etc), levert de activiteit een concreet product op en zo ja wat gebeurt daarmee, wordt van de speler een mimimumprestatie verwacht voordat hij door mag, hoe reageert het programma op de actie van de speler, telt het product mee in de eindbeoordeling, etc. etc.). Kenmerkend voor het casusingrediëntenverhaal is dat elke activiteit nader ingevuld wordt met behulp van een reeks korte statements, waaruit de interactie tussen een playing character (bv. student) en instrumenten (bv: archief, mail, Googlemaps) of andere actoren (playing charaters of non-playing characters) blijkt. Het is nadrukkelijk geen vlot lopend verhaal. In het casusingrediëntenverhaal gaat het erom elke activiteit per playing character uitputtend te beschrijven. De ervaring leert dat ook hier verschillende slagen nodig zijn om deze volledigheid te bereiken en dat dit geen eenmansactie is, maar teamwork. Hulpmiddelen (op EMERGO-Website beschikbaar): -

demonstrators EMERGO

-

Worked out examples casusingrediëntenverhaal van reeds ontwikkelde casussen

-

Powerpoints ‘van casusframework tot casusingrediëntenverhaal’ .

-

Checklist studiebelasting.

-

Voorbeelden voor multimediale uitwerking binnen casussen (richtlijnen AV-producties)


Voorzie de activiteiten uit de swimlanes van de playing characters en non-playing characters uit het casusframwork van unieke coderingen. Bij elk van deze coderingen hoort een stukje van het complete casusingrediëntenverhaal. Maak voor elke PC een eigen swimlane zodat de onderlinge afhankelijkheid tussen PC’s zichtbaar wordt. Bij het sequentiëren van taken-activiteiten gelden drie algemene principes (1) orden van eenvoudig naar complex, (2) orden van eenvoudige problem-formats (bv. worked examples) naar complexere problem-formats (bv. conventional problem), en (3) zorg voor een variability of practice binnen dezelfde probleemklasse.

-

Ga voor de PC’s na welke bronnen-instrumenten nodig zijn bij het uitvoeren van een activiteit, en ga na of deze al dan niet beschikbaar zijn. Als bepaalde bronnen/opnames niet in de vereiste vorm (bv. taal) beschikbaar zijn, dan worden lijsten van (a) te maken opnames en (b) te vertalen bronnen of van op te stellen documenten gemaakt. Probeer tot een variatie in bronnen te komen die een goede representatie vormen van het domein in kwestie (onvolledigheid, tegenstrijdigheid, diversiteit van gezichtspunten en stakeholders). Ga tevens van de instrumenten na of deze op de gewenste wijze beschikbaar zijn (dwz, in combinatie met EMERGO en Webgebaseerde uitlevering gebruikt kunnen worden). Gebruik de voorlopige lijst van te maken opnames om een producent voor de AV aan te zoeken


14

(aanbestedingsprocedure kan impliceren dat er meerdere producenten aangezocht moeten worden). Leg reeds contacten met beoogde AV-deelnemers en maak korte proefopnames. -

Maak een heldere identificatie van taken en bronnen mogelijk (met het oog op hergebruik, onderhoudbaarheid en flexibiliteit van belang) en zorg dat er vanuit de casus GEEN verwijzingen naar andere cursusonderdelen worden gemaakt (andersom mag wel).

-

Ga voor alle bronnen-instrumenten na of er rechten geregeld moeten worden en breng deze te regelen rechten reeds in kaart.

-

Gebruik de checklist studiebelasting. Schat voor elke activiteit in hoeveel tijd de speler (= degene die een bepaalde PC-rol krijgt) nodig heeft om het concrete product op te leveren dat bij de activiteit hoort (bij minimum eisen). Betrek hierbij de bronnen en instrumenten uit het voorafgaande overzicht.

-

Geef relatie tussen detailcriteria (per activiteit) en globalere criteria voor beoordelingmonitoring aan. Tracht het aantal criteria te beperken en tracht ervoor te zorgen dat het checken van de criteria softwarematig, of met minimale begeleidingstijd mogelijk is waarbinnen bij voorkeur waar mogelijk van peer-feedback gebruik wordt gemaakt.

-

Beperk de complexiteit in de uitwerking van elke PC door diens keuzes in te perken. Dit is mogelijk via (a) ‘breedte van opties’ in plaats van ‘ diepte van opties’, (b) plausibele afleiders, (c) tussentijdse afrondingen (beperkt de diepte), en (d) parallelle taakuitvoering (zie Westera et al., 2008) voor nadere toelichting mbt ‘beperken complexiteit’).

-

Streef niet naar realisme, maar naar de eerder genoemde “suspension of disbelief” (vooral qua representatie-vormgeving, maar tot op zekere hoogte ook voor de interactiegraad). Anders gezegd, de student dient primair door de authentieke karakter van de casus gegrepen te worden, en neemt dan gemakkelijk voor lief dat de representatie, en bepaalde vrijheidsgraden of reacties uit de casus afwijken van de realiteit.

3.3.4 Casus detailscenario (fase Ontwerp) In het casusdetailscenario wordt elke activiteit uit het casusingrediëntenverhaal minutieus uitgewerkt. Waar sprake is van interviews met personen (non-playing characters) wordt aangegeven welke vragen de speler in een bepaalde rol aan wie kan stellen, als de speler bronnen kan raadplegen worden deze bronnen nog concreter aangeduid (met codering) en wordt aangegeven waar deze te vinden zijn (bijvoorbeeld op het Web, of juist als EMERGO-bron), als de speler moet observeren wordt het observatieformulier gemaakt waarmee de student aan het werk kan en wordt de observatievideo gespecificeerd (met codering). Als geen video voorhanden is en deze zelf gemaakt moet worden, wordt een draaiboek of script geschreven voor de eigen opnamen en worden voorbereidingen getroffen voor de opnamen zelf. In het casusdetailscenario staan ook de locaties beschreven. Locaties van bijvoorbeeld NPC’s waar NPC’s door PC’s bezocht kunnen worden. De PC’s hebben doorgaans ook een eigen werkplek (locatie) binnen de casus. Hulpmiddelen (deels op EMERGO-Website beschikbaar): -


-

Worked out examples casusdetailscenarios (incl. coderingsschema’s) van andere casussen

-

Powerpoints ‘van casusingrediëntenverhaal tot casusdetailscenario’

-

Checklist studiebelasting

-

Voorbeelden voor multimediale uitwerking binnen casussen.

-

Instructies voor video en naamgeving bestanden (bijlage 3)

-

Software tbv flowcharting (bv MS Visio)


Uitwerking van het casusdetailscenario geschiedt liefst met flowcharts waarin met de


15

binnen het casusteam afgesproken coderingen wordt gewerkt ter identificatie van de diverse assets (bronnen, vragen + antwoorden aan NPC’s, locaties + achtergronden, instrumenten) en visualisatie van de casusflow (per PC). In de casusflow valt af te leiden welke activiteit(en) een PC op welk moment kan doen, en met welke reactie(s) uit de casus of vanuit een andere PC. Besteed hierbij – net als bij het casusingrediëntenverhaal – opnieuw aandacht aan de beperking van de complexiteit en tracht te veel realisme te vermijden. -

In de swimlanes (casusingrediëntenverhaal) is de onderlinge afhankelijkheid tussen de PC’s terug te vinden. Stel de swimlanes bij op basis van de gemaakte afspraken tijdens de uitwerking van het casusdetailscenario.

-

Gebruik – naar analogie bij het opstellen van het ingrediëntenverhaal – bij het casusdetailscenario nogmaals de checklist studiebelasting en maak een definitieve schatting van de studielast voor elke PC-rol.

-

Maak een definitieve lijst van bronnen-instrumenten waarvoor de rechten geregeld moeten worden en start de rechtenregeling.

-

Indien nieuwe opnames nodig zijn: Maak een overzicht van nieuw te maken opnames en schrijf de AV-scenario’s uit, gebruikmakend van de voorbeelden voor multimedia uitwerking binnen casussen. Hierbij wordt ondermeer duidelijk of er acteurs nodig zijn naast de reeds gecharterde AV-deelnemers (doorgaans deskundigen uit het domein). Check of de AVbegroting volstaat en perk zo nodig het aantal opnames (verder) in, of zoek naar oplossingen in kwaliteitsreductie. Vraag de aangezochte AV-producenten om een offerte en maak een keuze voor de AV-producent.

-

Geef voor elke PC-rol in detail aan hoe elke activiteit wordt beoordeeld (criteria), en hoe

-

Zorg dat het casusdetailscenario volledig in detail is uitgewerkt en in het projectteam is

deze beoordelingen meespelen in de totale beoordeling (criteria) bij de casus. vastgesteld alvorens met de invoer van de testversie van de casus wordt gestart.

3.3.5 Testversie casus (fase Ontwikkeling) Nadat het casusdetailscenario compleet is en binnen het projectteam is vastgesteld kan met het invoeren van dit casusdetailscenario worden gestart. Dit verondersteld allereerst dat de technische infrastructuur waarbinnen de casusinvoer mogelijk is beschikbaar is (zie Deliverable 3.2 en paragraaf 2.2 van Deliverable 4.7). Bij dit invoeren wordt gebruik gemaakt van de EMERGO-toolkit (Zie Figuur 3). In het projectteam kunnen nadere afspraken gemaakt worden wie welk deel van de data-invoer doet. Omdat zowel de teamsamenstelling alsook de casusuitwerking zeer kunnen variëren, kan de werkwijze bij het invoeren behoorlijk afwijken. Doorgaans zal er tijdens het invoeren en het simultane testen van deze invoer tot kleine bijstellingen in het casus detailscenario worden besloten. Het is belangrijk om deze bijstellingen OOK in het casus detailscenario op te nemen zodat latere revisie of hergebruik van een reeds ingevoerde casus eenvoudig mogelijk is. Aan het eind van deze fase worden de AV-opnames gemaakt.


16

Casusontwikkeling Invoertools Initialisatie Casusmanagement casus maken

START

Componenten initialisatie

Invoertools Ontwikkeling Invoertools ‘the brain’

Invoertools ‘the bones’ Rollen ontwerp

Scripting (condities, voorwaarden & afhandeling)

Locaties ontwerp

Empack ontwerp

Taak ontwerp

Objectstates ontwerp

Berichten ontwerp

Meldingen ontwerp

Gespreks ontwerp

Itembank

Selectieontwerp ontwerp

Toets ontwerp

Invoertools ‘the flesh’ Bronnen ontwerp

GoogleMap ontwerp

Figuur 3. Invoercomponenten van de casusontwikkelomgeving

De gesloten pijlen geven een verplichte volgorde aan. De open pijlen geven een geadviseerde volgorde aan waar altijd vanaf geweken kan worden. Voor invoercomponenten binnen één box geldt geen geadviseerde volgorde. Bidirectionele pijlen schetsen de relaties tussen de invoercomponenten.

Hulpmiddelen (op EMERGO-Website beschikbaar): -

Invoerhandleiding (bevat tevens tips en worked out examples per invoercomponent)

-

Powerpoints casusinvoer via EMERGO-toolkit

-

Instructie bij gebruik componenten toolkit (bijlage 5)


Er dient allereerst een technische infrastructuur voor casusinvoer te zijn ingericht alvorens

-

Er geldt deels een voorgeschreven en deels een aanbevolen volgorde van invoeren (zie

casusinvoer mogelijk is (zie Deliverable 3.2). Figuur 3 voor nadere details) -

Voor nog op te nemen AV geldt dat voor testdoeleinden wel reeds met de afgesproken coderingen voor de fragmenten kan worden gewerkt. Eventueel kunnen ‘dummy’ fragmenten tijdens het testen worden gebruikt.

-

Er bestaan 3 basismanieren om een casusrol te testen die in de invoerhandleiding nader zijn toegelicht. Op deze manier is ook testen bij meerdere casusrollen mogelijk. Incrementeel testen wordt aanbevolen.


17

3.3.6 Evaluatieversie casus (fases Implementatie en Evaluatie) De evaluatieversie van de casus is de versie van de casus die aan studenten en docenten beschikbaar wordt gesteld waarin onder meer de voormontages van de AV-opnames zijn vervat (0.9-versie). Hiertoe dienen de zogenaamde invoercomponenten voor de casusuitlevering uit de EMERGO-toolkit te worden gebruikt (zie Figuur 4). Daarnaast dient uiteraard de technische infrastructuur zodanig te zijn ingericht dat de casussen bij de betreffende onderwijsinstelling uitleverbaar zijn (zie Deliverable 3.2 en paragraaf 2.2 van deze deliverable 4.7).

Casusuitlevering Invoertools Ontwikkeling Studenten-voorportaal ontwerp

Staff-voorportaal ontwerp

Casusmanagement casus controleren

Casusrunmanagement

RUN

Figuur 4. Invoercomponenten casusuitlevering

De gesloten pijlen geven een verplichte volgorde aan. De open pijl geeft een geadviseerde volgorde aan waarvan altijd afgeweken kan worden. Voor de invoercomponenten binnen één box geldt geen geadviseerde volgorde. Tijdens het gebruik van de e-casus kan de evaluatie van de e-casus worden uitgevoerd. Dit wordt sterk aanbevolen omdat de ervaring met andere vormen van e-learning laat zien dat dit vaak bijdraagt tot een extra efficiencywinst in de exploitatie. De evaluatie van de e-casus leidt tot aanpassingen van de e-casus (1.0.-versie). Hulpmiddelen (op EMERGO-Website beschikbaar): -

Invoerhandleiding (bevat tevens tips en worked out examples per invoercomponent)

-

Powerpoints casusuitlevering via EMERGO-toolkit

-

Instrumenten voor uitvoeren evaluatie bij e-casus (bij studenten)


Er dient allereerst een technische infrastructuur voor casusuitlevering te zijn ingericht alvorens casusuitlevering mogelijk is (zie Deliverable 3.2).

-

Er geldt deels een voorgeschreven en deels een aanbevolen volgorde van invoeren (zie Figuur 4 voor nadere details)

-

Maak een korte handleiding voor studenten en docenten voor het werken met EMERGO en de e-casus opstellen. Dit voorkomt problemen met Browserinstellingen.

-

Voer een evaluatie van de e-casus uit en tracht start – en afsluitende bijeenkomst met studenten te organiseren.

-

Voer na de evaluatie de aanpassingen door ten behoeve van de 1.0-versie van de e-casus.


18

4. Conclusies en aanbevelingen In voorgaande hoofdstukken zijn achtereenvolgens de workshops en daarbij beschikbare materialen voor docent professionalisering beschreven. Een deel van de betrokken staf van de bij het Skills Labs betrokken partnerinstellingen is via deze workshops en instructiematerialen bijgeschoold in het ontwerpen en aanbieden van interactieve casuïstiek via workshops, aangevuld met ondersteuning on-the-job tijdens de casusontwikkeling. Waardering is overwegend positief, en het ontwikkelde aanbod lijkt geschikt voor hergebruik binnen vergelijkbare projecten. Hoofdstuk 2 beschreef de opzet en aanpak van de workshops gericht op leren werken met de EMERGO methodiek en -toolkit. Deze zijn in het kader van het Skills Labs project als positief geëvalueerd en hebben laten zien dat de workshops hebben bijgedragen tot het (grotendeels) zelfstandig ontwikkelen van e-casus door de betrokken docenten. Alleen bij de scripting bleek onthe-job ondersteuning nodig door de CELSTEC programmeurs. De workshops zijn door de deelnemers met de cijfers 7 en hoger gewaardeerd (gemiddeld 8). De twee andere doelstellingen van de professionalisering bij Skills Labs (teamvorming en disseminatie) zijn voor u als gebruiker van dit standaarddraaiboek in detail wellicht niet relevant. Zowel teamvorming alsook het vermogen om als geprofessionaliseerde docent ná de workshops als EMERGO-ambassadeur binnen de eigen instelling en ook daarbuiten te kunnen optreden werden positief geëvalueerd tijdens het Skills Labs project. Hoofdstuk 3 beschreef (per fase in de ontwikkeling) de concrete instructiematerialen die tijdens de ontwikkeling van de workshops zijn ontwikkeld en gedocumenteerd, en nu beschikbaar zijn voor herhaalde aanbieding. Deze deliverable bevat verwijzingen naar gebruikte en ontwikkelde instructiematerialen. De meesten zullen beschikbaar worden gesteld via de EMERGO website, een aantal zijn opgenomen als bijlage bij deze deliverable. De workshops over de EMERGO-methodiek hebben een sterkere inbedding met de inhoud van de casuïstiek-ontwikkeling bij Water management gekregen dan oorspronkelijk vanuit WP3 was beoogd. De workshops hebben daardoor meer maatwerkkarakter gekregen. Desalniettemin kon het standaarddraaiboek van docentprofessionalisering (deze Deliverable 3.3) vrij eenvoudig gedestilleerd worden uit deze maatwerkworkshops. Dit laat onverlet dat er in de praktijk een spanningsveld kan zijn tussen de insteek van het standaarddraaiboek en een effectieve organisatie van docentprofessionalisering. Op dit moment is het materiaal ter ondersteuning van de docentprofessionalisering nog verspreid beschikbaar (publieke emergo site, demonstrator paginas, surfgroepen EMERGO en Skills Labs, bijlagen bij deze deliverable, andere deliverables). Het verdient aanbeveling op één centrale plaats (of via portal) al het materiaal beschikbaar te stellen, met instructie voor gebruik. We zullen dit zo veel mogelijk per 1 maart 2010 vanuit de EMERGO website beschikbaar stellen, van waaruit ook de verdere communityvorming vorm zal moeten krijgen. Vanuit deze portal zou dan een groeiende pool van demonstrators, instructies, presentaties, e.d. kunnen ontstaan met enige meta datering waardoor gerichter kan worden gezocht en geselecteerd bij volgende projecten. Het ontwikkelen van e-casussen is vrij specialistisch werk dat min of meer een multidisciplinair team veronderstelt. Alhoewel de instructiematerialen EMERGO het gebruik van de EMERGOmethodiek en EMERGO-toolkit toegankelijker hebben gemaakt en een verdere aanscherping van deze methodiek heeft plaatsgevonden, brengt de aard van het casusontwikkelwerk met zich mee dat er slechts in een zeer geleidelijk tempo opschaling kan worden verwacht en dat het door individuele docenten volledig zelfstandig gebruiken van EMERGO een utopie zal blijven. Waarschijnlijk zou zeer substantiële opschaling alleen via volledig zelfstandig gebruik door docenten mogelijk zijn. De crux zit er waarschijnlijk in dat niet alle docenten die e-casussen willen gebruiken perse casusontwik-


19

kelaars moeten zijn, maar dat ze wel reeds beschikbare e-casussen eenvoudig voor eigen gebruik zouden moeten kunnen aanpassen, of dat anderen dit voor hun kunnen doen. Dat veronderstelt echter dat er meer e-casussen beschikbaar moeten komen. De normgetallen voor de casusontwikkeling met EMERGO laten zien dat er weliswaar efficiënter ontwikkeld kan worden, maar de ontwikkelkosten zullen voor afzonderlijke onderwijsinstellingen vaak toch een barrière vormen.


20

Bijlagen B1. beschrijving workshops B2. evaluatieformulier workshops B3. instructie AV vormen, naamgeving bestanden B4. instructie demonstrators B5. instructie gebruik componenten toolkit


21

Bijlage 1: Beschrijving workshops Workshop 1 Titel: Casusontwikkeling met EMERGO-methodiek & -toolkit + van idee tot framework Inhoud: Binnen Skills Labs worden casus Water Management met EMERGO ontwikkeld om het projectdoel “verhoging van de kwaliteit en studeerbaarheid middels hoogwaardige en duurzame e-learning” mogelijk te maken. Belangrijk hierbij is dat de casus flexibel en efficiënt zijn in te zetten in diverse onderwijscontexten zoals deze bij de projectpartners voorkomen. Deze workshop gaat in op vragen als: - Wat is een casus? - Wat is een Watermanagement casus? - wat is de EMERGO-methodiek? - wat is de EMERGO-toolkit? - hoe gebruik ik de EMERGO-methodiek om van idee tot framework te komen? Werkvormen: Vooraf aan de workshop zal een uitgewerkt voorbeeld van een casusidee worden verstrekt. Ter voorbereiding zal een casusteam een casusidee uitwerken en presenteren aan de overige deelnemers. Tijdens de workshop zullen werkvormen als presentatie, uitwerken van opdrachten, nabespreking van opdrachten worden gebruikt. Daarnaast zullen zoveel mogelijk aansprekende voorbeelden worden gebruikt bij het verduidelijken van het toepassen van de EMERGO-methodiek. Het werken met de EMERGO-toolkit zal slechts kort worden aangestipt. In deze workshop zal het accent liggen op de wijze waarop je van casusidee tot casus framework komt en wordt onder meer een voorbeeld van een casus framework verstrekt.

Framework scenario

The framework scenario (part of the design phase) describes the global activities playing characters (i.e., real persons) and non-playing characters (i.e., virtual persons) carry out during the case. A standard format for noting activities is proposed “Where the management assistant (student-playing character) will...<description of the activity>”. This enables to identify a first series of activities without getting overwhelmed by details (first advantage). In this series, one can already distinguish between compulsory and non-compulsory activities, activities that need to be performed in a certain order or not, activities unexpectedly popping up or being in the students’ ‘to do-list’. The approach quickly provides a blue print for issues to be further worked upon (second advantage). The framework scenario resembles a construction drawing for a building. The team does not need to spend too much time on detailing out certain elements at the beginning (third advantage). It enables giving similar attention to all elements at several stages during design and development. The framework scenario can flexibly be adjusted during following steps of the design phase. Resultaten: Belangrijkste uitkomst van deze workshop is dat een casusidee tot stand komt dat de leidraad vormt voor de verdere uitwerking tot casus framework. Daarnaast kunnen de deelnemers hands-on experience opdoen met het uitwerken van casusidee tot casus framework. Het casus framework dient na afloop van de workshop door de casusteams verder uitgewerkt te worden en geldt als input voor de volgende workshop.

Workshop 2 Titel: EMERGO-methodiek: van framework tot ingrediëntenverhaal Inhoud: Binnen Skills Labs worden casus Water Management met EMERGO ontwikkeld om het projectdoel “verhoging van de kwaliteit en studeerbaarheid middels hoogwaardige en duurzame e-learning” mogelijk te maken. Belangrijk hierbij is dat de casus flexibel en efficiënt zijn in te zetten in diverse onderwijscontexten zoals deze bij de projectpartners voorkomen. Deze workshop gaat in op het gebruik van de EMERGO-methodiek om van casus framework tot ingrediëntenverhaal (ingredients scenario) van de casus te komen.


22

Ingredients scenario

In the ingredients scenario (part of the design phase), for each activity it is identified how playing characters (mostly students) are to perform: what does the student do, with whom, with what tools and resources, and with which support (teacher, fellow student, or embedded)? Does task performance result in a product, and if so, how will this be evaluated? Is a sufficient result needed before students can carry on? What are foreseen interactions with other participants and the program during and after carrying out an activity? The (possible) interactions for each activity are exhaustively described, but not yet in terms of required tools and resources. Werkvormen: Vóór de workshop zal een uitgewerkt voorbeeld van een ingrediëntenverhaal van een casus worden verstrekt. Elk casusteam zal een vooraf uitgewerkte versie van het casus framework tijdens de workshop inbrengen. Tijdens de workshop zullen werkvormen als presentatie, uitwerken van opdrachten, nabespreking van opdrachten worden gebruikt. Daarnaast zullen zoveel mogelijk aansprekende voorbeelden worden gebruikt bij het verduidelijken van het toepassen van deze stap uit de EMERGO-methodiek. Tijdens deze workshop zal het accent liggen op de wijze waarop je van casus framework tot ingrediëntenverhaal van de casus komt. Discussiepunten/vragen bij hun ingebrachte casus framework kunnen zij presenteren aan de overige deelnemers. Resultaten: Belangrijkste uitkomst van deze workshop is dat een eerste versie van een deel van het ingrediëntenverhaal van de casus tot stand komt dat de leidraad vormt voor de verdere uitwerking van het ingrediëntenverhaal van de casus. Daartoe kunnen de deelnemers hands-on experience opdoen met het uitwerken van casus framework tot ingrediëntenverhaal van de casus. Het ingrediëntenverhaal van de casus dient na afloop van de workshop door de casusteams verder uitgewerkt te worden en geldt als input voor de volgende workshop.

Workshop 3 Titel: EMERGO-methodiek: van ingrediëntenverhaal tot detailscenario Inhoud: Binnen Skills Labs worden casus Water Management met EMERGO ontwikkeld om het projectdoel “verhoging van de kwaliteit en studeerbaarheid middels hoogwaardige en duurzame e-learning” mogelijk te maken. Belangrijk hierbij is dat de casus flexibel en efficiënt zijn in te zetten in diverse onderwijscontexten zoals deze bij de projectpartners voorkomen. Deze workshop gaat in op het gebruik van de EMERGO-methodiek om van ingrediënten-verhaal van de casus tot detailscenario van de casus te komen.

Detailed scenario

This final step of the design phase describes for each playing character each activity exhaustively in terms of its required tools and resources to enable the actual performance. If students can interview a person, all interview questions need to be identified; if students need to read resources, all resources need to be identified. At this point, it also becomes clear if case materials (case assets) are already available or still need to be developed. Furthermore, all tools are identified. The EMERGO toolkit contains several components for developing such tools. Using Flowcharting and Scheduling software for this step is almost indispensable for more complex scenarios. Werkvormen: Vóór de workshop zal een uitgewerkt voorbeeld van een detailscenario worden verstrekt. Elk casusteam zal een vooraf uitgewerkte versie van het ingrediëntenverhaal van hun casus tijdens de workshop inbrengen. Tijdens de workshop zullen werkvormen als presentatie, uitwerken van opdrachten, nabespreking van opdrachten worden gebruikt. Daarnaast zullen zoveel mogelijk aansprekende voorbeelden worden gebruikt bij het verduidelijken van het toepassen van deze stap uit de EMERGO-methodiek. Tijdens deze workshop zal het accent liggen op de wijze waarop je van ingrediëntenverhaal bij een casus tot het detailscenario van de casus komt. Discussiepunten/vragen bij hun ingebrachte ingrediëntenverhaal kunnen zij presenteren aan de overige deelnemers. Resultaten: Belangrijkste uitkomst van deze workshop is dat een eerste versie van een deel van het detailscenario van de casus tot stand komt dat de leidraad vormt voor de verdere uitwerking van het detailscenario van de casus. Daartoe kunnen de deelnemers hands-on experience opdoen met het uitwerken van het ingrediëntenverhaal van de casus tot het detailscenario van de casus. Het


23

detailscenario van de casus dient na afloop van de workshop door de casusteams verder uitgewerkt te worden en geldt als input voor de volgende workshops die aan het werken met de EMERGOtoolkit componenten zijn gewijd.

Workshop 4 Titel: EMERGO-toolkit: componenten characters (rollen), locaties, taken, bronnen Inhoud: Deze workshop gaat in op het gebruik van de EMERGO-toolkit om uitgaand van het detailscenario van de casus tot de invoer van characters, locaties, taken, en bronnen te komen.

Characters(rollen)

Via deze component kunnen de playing characters (reële personen in het casusscenario) en de non-playing characters (virtuele personen (of objecten) in het casusscenario) worden ingevoerd. De huidige toolkit ondersteunt niet de invoer van non-playing characters die objecten zijn, zulks is bij Water Management ook niet nodig. Vandaar dat case characters thans altijd rollen zijn, hetzij een casusrol vervuld door een reële persoon, hetzij een casusrol vervult door een virtuele persoon. Voor de reële persoon die het scenario doorloopt hoeft niet persé duidelijk te zijn of deze met reële of virtuele personen van doen heeft.

Locaties

Via deze component kunnen de locaties worden ingevoerd waartussen de playing character (bv. Student) eventueel onder specifieke omstandigheden - kan bewegen. Specifieke omstandigheden dienen in de Scripting component te worden uitgewerkt. Bij locaties hoeft niet persé aan fysieke locaties gedacht te worden. Bij Interactieve Praktijkconfrontaties (IPs) als Juridisch gesproken, Buiten Dienst en anderen is de output van de locatieontwerptool in de student-uitleveromgeving de zogenoemde Plattegrond.

Taken

Via deze component worden de taken in het “Taakoverzicht” van de afspeler gedefiniëerd, en de eventuele specifieke omstandigheden waaronder de taken door de casusrol (bv: ‘student’) zijn uit te voeren. Specifieke omstandigheden dienen in de Scripting te worden uitgewerkt. Bij IPs als Juridisch gesproken, Buiten Dienst is de output van de taakontwerptool het zogenoemde Taakoverzicht (in de afspeler). Bij Taken hoeft niet persé letterlijk aan taken te worden gedacht, dit kunnen ook activiteiten, opdrachten, afspraken et cetera zijn. Daarom hoeft het Taakoverzicht in de afspeler niet persé deze naam te hebben.

Bronnen

Via deze component worden ‘dossiers’, ‘bronnen’ of andersoortige ‘stukken’ ingevoerd: de archiveringsfunctie. Bij archivering is er sprake van een database voor tekst, beeld, audio, video, animaties, webpages (statische of dynamische inhoud) et cetera. Dit lijkt sterk op een beheerder van bestanden (Windows-Verkenner) of een beheerder van links (Favorieten binnen een Webbrowser) maar kan hier ook op bepaalde punten van afwijken. NB Het Bronnenontwerp kan meer dan één keer binnen de componenteninitialisatie worden gebruikt (dwz: er kunnen meerdere instantiaties zijn binnen een casus: bv: een Archiefkast, een Dossierkast). Werkvormen: Vóór de workshop zal de gebruikershandleiding van de EMERGO-toolkit worden verstrekt. De casusteamleden die met de in deze workshop aan de orde gestelde componenten zullen werken kunnen vooraf via hun gebruikersaccount al proberen om wat invoer te doen, maar dit hoeft niet perse. Het detailscenario dient – bij voorkeur - in het casusteam te zijn vastgesteld opdat de invoer tijdens de workshop al voor casusontwikkeling geldt. Tijdens de workshop zullen werkvormen als presentatie, uitgewerkte voorbeelden, via training-onthe job (1 op 1) stapsgewijs invoeren van inhoud met een toolkit component gebruikt. De uitgewerkte voorbeelden verduidelijken de invoer met de betreffende component. Waar mogelijk worden deze voorbeelden uit de detailscenario’s genomen. Daarnaast worden tips voor het werken met deze toolkit component gegeven. Tijdens deze workshop zal het accent liggen op het invoeren van het detailscenario voor zover dit het gebruik van onderhavige component betreft. Resultaten: Belangrijkste uitkomst van deze workshop is dat een stuk van het detailscenario van de casus - voor zover dit onderhavige toolkit component betreft – wordt ingevoerd. Het restant van het detailscenario bij deze component kan dan eenvoudig ná de workshop worden ingevoerd.


24

Workshop 5 Titel: EMERGO-toolkit: componenten gesprekken, berichten Inhoud: Deze workshop gaat in op het gebruik van de EMERGO-toolkit om uitgaand van het detailscenario van de casus tot de invoer van gesprekken, en berichten te komen.

Gesprekken

Via deze component kunnen gesprekken worden gedefiniëerd. Het is één van de componenten die gebruikt kunnen worden voor het definiëren van communicatie tussen casusrollen (bv. student) en virtuele personages in het programma. Al deze communicatie noemen we gesprekken. Gesprekken tussen reële personen vinden buiten de EMERGO-speler plaats. Het kan zijn dat er input van een gespreksdeelnemer in EMERGO nodig is voor het kunnen vervolgen van diens casusflow (daartoe worden andere componenten gebruikt, bv Taken). Gesprekken zijn een krachtig middel om de verhaallijn van een casus uit te werken. In de huidige versie van de EMERGO-toolkit zijn de opties voor didactische ondersteuning bij gesprekken redelijk beperkt. De ervaring met eerdere casuïstiek laat zien dat de student een gesprek vaak zonder expliciete voorbereiding kan voeren (bijvoorbeeld afnemen van eenvoudige interviews). Bij eenvoudige interviews denken we aan interviews waarbinnen bijvoorbeeld geen gebruik wordt gemaakt van doorvraagmogelijkheden, en waarin de volgorde waarop de vragen worden gesteld niet uitmaakt voor de antwoorden.

Berichten

Via deze component kunnen een viertal zaken worden gedefiniëerd, te weten: (1) outmailpredefined: te versturen internal mails (opties voor geadresseerden én onderwerpen zijn beiden voorgedefinieerd), (2) outmailhelp: te versturen help mails (opties voor geadresseerden zijn voorgedefinieerd, maar onderwerp is vrij), (3) inmailpredefined: te ontvangen internal mails, en (4)inmailhelp: te ontvangen internal help mails. Een geadresseerde is altijd een persoon in de casus. Achter deze persoon (bijvoorbeeld begeleider) kan een reële persoon schuil gaan (bijvoorbeeld een docent), maar het kan ook een virtuele persoon (NPC) betreffen. Als er meer dan één docent is voor een specifieke casus dan zal bij het casusrun-management aangeduid moeten worden welke docent voor welke studenten geldt. Bij elk van deze vier opties kunnen specifieke omstandigheden waaronder deze mails/berichten verstuurd/ontvangen kunnen worden in Scripting zijn uitgewerkt. Bij Mails hoeft niet persé letterlijk aan mails te worden gedacht, dit kunnen ook kattebelletjes, interne notities, et cetera zijn. Daarom hoeft de “Mail” in de EMERGO-afspeler niet persé deze naam te hebben. Werkvormen: Vóór de workshop zal de gebruikershandleiding van de EMERGO-toolkit worden verstrekt. De casusteamleden die met de in deze workshop aan de orde gestelde componenten zullen werken kunnen vooraf via hun gebruikersaccount al proberen om wat invoer te doen, maar dit hoeft niet perse. Het detailscenario dient – bij voorkeur - in het casusteam te zijn vastgesteld opdat de invoer tijdens de workshop al voor casusontwikkeling geldt. Tijdens de workshop zullen werkvormen als presentatie, uitgewerkte voorbeelden, via training-onthe job (1 op 1) stapsgewijs invoeren van inhoud met een toolkit component gebruikt. De uitgewerkte voorbeelden verduidelijken de invoer met de betreffende component. Waar mogelijk worden deze voorbeelden uit de detailscenario’s genomen. Daarnaast worden tips voor het werken met deze toolkit component gegeven. Tijdens deze workshop zal het accent liggen op het invoeren van het detailscenario voor zover dit het gebruik van onderhavige component betreft. Resultaten: Belangrijkste uitkomst van deze workshop is dat een stuk van het detailscenario van de casus - voor zover dit onderhavige toolkit component betreft – wordt ingevoerd. Het restant van het detailscenario bij deze component kan dan eenvoudig ná de workshop worden ingevoerd.

Workshop 6 Titel: EMERGO-toolkit: component Scripting Inhoud: Deze workshop gaat in op het gebruik van de EMERGO-toolkit om uitgaand van het detailscenario van de casus tot de invoer van Scripting te komen.


25

Scripting

-

Via deze component worden predikaten (condities en acties) gedefinieerd die het verloop en dynamiek van de casus bepalen. Meestal zijn deze gekoppeld aan acties van de individuele student binnen de casus, maar het kan ook zijn dat een actie van buitenaf (bijvoorbeeld actie docent/begeleider, actie medestudent(en), statuswijziging van een object) invloed op programmavoortgang van de individuele student uitoefent. De component Scripting kan condities bevatten die slaan op: het niveau van de hele casus (dus niet gekoppeld aan een specifieke component) het niveau van één of meer componenten het niveau van één of meer inhoudelijke invullingen binnen één of meer componenten Dit maakt dat de component Scripting niet alleen los opgestart kan worden, maar vaak binnen (of vanuit) andere componenten aangeroepen moet kunnen worden. Vaak zullen condities en acties pas kunnen worden uitgewerkt zodra bepaalde inhoud is ingevoerd en kunnen via condities en acties onderlinge afhankelijkheden tussen allerlei invoercomponenten ontstaan, waarbinnen de component Scripting een sleutelrol speelt (vandaar de naam: ‘the brain’). Om technische redenen zullen de data van de ingevoerde condities op één plek worden opgeslagen en beheerd. Het gebruik van deze component is complexer dan de andere door casusontwikkelaars te gebruiken componenten. Werkvormen: Vóór de workshop zal de gebruikershandleiding van de EMERGO-toolkit worden verstrekt. Het casusteamlid (bij voorkeur de casustrekker) die met de in deze workshop aan de orde gestelde component zal werken kan vooraf via diens gebruikersaccount al proberen om wat invoer te doen, maar dit hoeft niet perse. Het detailscenario MOET in het casusteam te zijn vastgesteld opdat de invoer tijdens de workshop al voor casusontwikkeling geldt. Daarnaast is het bijna onontbeerlijk dat een flowchart voor de casusflow beschikbaar is. Tijdens de workshop zullen werkvormen als presentatie, uitgewerkte voorbeelden, via training-onthe job (1 op 1) stapsgewijs invoeren van inhoud met een toolkit component gebruikt. De uitgewerkte voorbeelden verduidelijken de invoer met de betreffende component. Waar mogelijk worden deze voorbeelden uit de detailscenario’s genomen. Daarnaast worden tips voor het werken met deze toolkit component gegeven. Tijdens deze workshop zal het accent liggen op het invoeren van het detailscenario voor zover dit het gebruik van onderhavige component betreft. Resultaten: Belangrijkste uitkomst van deze workshop is dat een stuk van het detailscenario van de casus - voor zover dit onderhavige toolkit component betreft – wordt ingevoerd. Het restant van het detailscenario bij deze component kunnen dan eenvoudig ná de workshops worden ingevoerd. Tijdstip: Deze workshop bestaat uit twee delen, beide rondom half april 09. Gelijktijdig met workshop 5. Workshop 5 en workshop 6 hebben een andere doelgroep.


26

Bijlage 2: Evaluatieformulier Workshop Skills Labs – Workshop Evaluation Form

Instruction: Please tick of boxes and write additional comments when you feel this to be appropriate. When indicated assess the quality with a grade.

Workshop number / title: Date workshop: Name presenter (s): Your name: USABILITY: DID WORKSHOP HELP YOU FURTHER WITH YOUR CASE?  Helped me understand and improve my work so far  Helped me proceed further in developing my case  Did not help me quite enough, because …… Overall assessment of usability: (use number from 0-10) ORGANISATION: WAS WORKSHOP WELL-ORGANIZED  Instructions, materials sent in advance to prepare  Reception / welcome / opening  Working in (case) teams  The general atmosphere of the meeting  Catering: lunch, coffee/tea, …  Room: suitability and facilities  The duration of the meeting  Timing of the various parts of the workshop Overall assessment of organisation:

meeting

(use number from 0-10)

CONTENT: LEVEL OF DETAIL    

Introduction to the aims of the workshop Explanation of this step in the development in general (‘leading questions’, Emergo tools) Explanation of this step by including worked examples Explanation of this step in the development by supporting your own case by including

assignments

 Documentation provided was of sufficient Overall assessment of content:

level of detail


WHICH PARTS OF WORKSHOP NEED TO BE ADDED/DELETED (WHY)?

WHICH PARTS OF WORKSHOP NEED TO BE IMPROVED (WHY AND HOW)?

OVERALL Overall assessment of workshop:



27

Bijlage 3: instructies AV vormen, naamgeving bestanden (excerpt van e-mail) Mogelijke suggesties voor andere AV vormen zijn: 1. Gebruik van cartoons en tekeningen 2. Gebruik van animaties om opdracht te verstrekken (denk aan opdracht HSL lijn) 3. Gebruik van animaties om verschijnsel uit te leggen (denk bv. aan getijde werking) 4. Een sfeertekening op locatie (interview met expert die aan de schelpdierenkweek bezig), of interviews op meer dynamische wijze opgenomen 5. Groepsbijeenkomsten, liefst met enige stress (denk aan de verontruste boer die opstaat tijdens de ...) 6. Gebeurtenissen laten zien (historisch, natuurwetenschappelijk, maatschappelijk) 7. Zelfde vragen aan meerdere experts (stakeholders) laten stellen, kijken hoe antwoorden varieren 8. Een visualisatie van de belangen van verschillende stakeholders (kan iemand zijn die dit op flapover tekent, of opbouwende powerpoint) 9. Een visualisatie van de organisaties en werkverbanden die een rol spelen 10. Een (werkend) model van de verschillende variabelen die een rol spelen: of je moet de variabelen zelf vinden, of kijken hoe variabelen met elkaar interacteren


28

NAAMGEVING EMERGO-INHOUDSELEMENTEN (beknopt) De naamgeving van in te voeren items (ook still under construction) zal binnen project zo consistent en eenduidig mogelijk moeten zijn. Over de codering zijn eerder (voorlopige) afspraken gemaakt, en nu door Hub op papier gezet. Dit documentje stuur ik ter informatie mee, maar ook hier adviseer ik jullie je te beperken tot de componenten die volgende week aan bod komen. Eigenlijk komt het er in het kort op neer voor wat betreft: - Rollen: geen vaste codering, gebruik voor ontwikkelaar zo helder mogelijke benaming - Taken: geen vaste codering, gebruik voor student zo helder mogelijke benaming - Bronnen: geen vaste codering, gebruik voor student zo helder mogelijie benaming, maar laat de naam van het in te lezen bestand zo duidelijk mogelijk verwijzen naar de oorsprong van de bron bijvoorbeeld: "2 Vandaag, 20040312, 20h32'-20h48'.wmv" - Locaties: vaste codering voor locaties --<elementid>, bijvoorbeeld: "WES-LOC-GVZ", of "WES-LOC-Hal redactie" (; vaste codering voor achtergronden -<elementtype-id>-<elementid> bijvoorbeeld: "WES-LOC-IMG-Docent 01"; met WES=Westerschelde, LOC=locaties, IMG=image NAAMGEVING EMERGO-INHOUDSELEMENTEN (uitgebreid) Bij het betitelen van de inhoudselementen waarmee we componenten vullen spelen 2 zaken een rol: we moeten zelf kunnen afleiden waarop het element betrekking heeft, en de student moet aan de titel kunnen zien waar het om gaat. De invoerder wil liefst een systematische betiteling, met behulp waarvan hij onmiddellijk het inhoudselement kan lokaliseren. Dat wil zeggen, hij kan zien bij welke component het element hoort, wat voor type inhoudselement het is, en welke specifieke inhoud het element bevat. De student heeft alleen behoefte aan inhoudsinformatie. Hoe meer andere informatie in de titel staat, hoe cryptischer deze voor hem wordt. In EMERGO zijn wat betreft de naamgeving 3 gevallen te onderscheiden: 1. Het inhoudselement is zichtbaar voor de student. De invoerder moet een "identificatie" invoeren die de student niet te zien krijgt (en die uniek is voor de "tak van de boom" waarin zich dit element bevindt), en hij kan een naam invoeren die de student te zien krijgt (en die niet uniek hoeft te zijn). Voert hij geen naam in, dan krijgt de student de identificatie te zien. 2. Het inhoudselement is zichtbaar voor de student. De invoerder moet een "identificatie" invoeren die ook de student te zien krijgt (en die uniek is voor de "tak van de boom" waarin zich dit element bevindt). 3. Het inhoudselement is niet zichtbaar voor de student. De invoerder moet een "identificatie" invoeren die uniek is voor de "tak van de boom" waarin zich dit element bevindt. Idealiter zou je misschien willen dat daar waar sprake is van situatie 2 eigenlijk situatie 1 zou moeten gelden. Je kunt dan heel systematisch afspraken maken voor alle in te voeren elementen. Echter, dit zou ook betekenen dat invoerders vaak in triviale gevallen 2 invoervelden moeten vullen. Om het invoeren zo eenvoudig mogelijk te houden is daarom bij een aantal inhoudselementtypen gekozen voor situatie 2. In recente projecten is in de situaties 1 en 3 bij veel inhoudselementen gebruik gemaakt van een identificatiebetiteling die er min of meer als volgt uitziet: --{-}[{<node-id>-}]{<elementtype-id>-}<elementid> Met:

een drieletterige code ter identificatie van de casus

een drieletterige code ter identificatie van de componenttemplate

(indien van toepassing) een drieletterige code ter identificatie van de component, indien er van een componenttemplate meer dan 1 component in de casus aanwezig is <node-id> (0 of meer) drieletterige codes voor alle “knooppunten” (nodes) die liggen tussen het in te voeren element en de component <elementtype-id> (indien gewenst) een drieletterige code ter identificatie van het soort element <elementid> een beschrijving van de inhoud van het element; deze beschrijving dient zo eenduidig mogelijk te zijn, en zal in het algemeen dan ook langer zijn dan 3 karakters Bij de naamgeving van de componenten kan de invoerder altijd een identificatie invoeren en, per spelerrol, een "spelernaam". Dit is echter niet voor alle componenten zinvol, omdat studenten van sommige componenten de naam niet te zien krijgen. Dit geldt bijvoorbeeld voor de gesprekkencomponent. In de bestaande casussen is er


29

geen behoefte geweest om verschillende namen voor verschillende spelerrollen te kiezen. Invoerders hebben tot dusver geen systematische codering gebruikt voor de identificatie van componenten. De identificatie van een component was vrijwel altijd gelijk aan de spelernaam. We zouden de volgende richtlijnen kunnen geven voor de betiteling van de identificaties van de inhoudselementen per component: LOCATIES: -

locatie (situatie 1): --<elementid>

o

bijvoorbeeld: "OGB-LOC-GVZ", "OPR-LOC-Hal redactie"

-

achtergrond (situatie 3): --<elementtype-id>-<elementid>

o

bijvoorbeeld: "OPR-LOC-IMG-Docent 01"

o

er zijn nog geen afspraken gemaakt over naamgeving van het in te lezen image-bestand

-

map (situatie 2): geen codering; gebruik een voor de student zo helder mogelijke benaming

-

bron (situatie 2): geen codering; gebruik een voor de student zo helder mogelijke benaming

BRONNEN:

o laat de naam van het in te lezen bestand zo duidelijk mogelijk verwijzen naar de oorsprong van de bron (is dat pleonastisch of is dat pleonastisch?) 

bijvoorbeeld: "2 Vandaag, 20040312, 20h32'-20h48'.wmv"

GESPREKKEN: Vaak zijn de gesprekken per locatie ingevoerd in een gesprekkencomponent. Dus elke locatie heeft zijn eigen gesprekkencomponent. In dit geval zullen we dus gebruikmaken van een instantiatie-id om de verschillende gesprekkencomponenten van elkaar te kunnen onderscheiden. -

gesprek (situatie 1): ---<elementid>

o

bijvoorbeeld: "OPR-INT-DC1-Orienterend gesprek met docent 01"

achtergrond (situatie 3): ---<elementtype-id>-<elementid> o

bijvoorbeeld: "OPR-INT-RCT-IMG-Rector"

o

er zijn nog geen afspraken gemaakt over naamgeving van het in te lezen imagebestand

fragment (situatie 3): ---[<node-id>-]<elementtype-id>-<elementid> o

bijvoorbeeld: "OPR-INT-DC1-ORI-FRG-Vertelt over zichzelf"

o in dit geval is er slechts 1 node-id, en wel een verwijzing naar het gesprek; maar als het fragment dieper in de boomstructuur staat, zullen er meer node-ids zijn (onder "gesprek" en onder "vraag" kunnen fragmenten worden ingevoerd, onder "fragment" kunnen mappen en vragen worden ingevoerd, onder "map" kunnen vragen worden ingevoerd, etc.) o er zijn nog geen afspraken gemaakt over naamgeving van het in te lezen imagebestand; voor de duidelijkheid misschien dezelfde naam aanhouden als de fragmentidentificatie 

dus: "OPR-INT-DC1-ORI-FRG-Vertelt over zichzelf.flv"

-

map (situatie 2): geen codering; gebruik een voor de student zo helder mogelijke benaming

-

vraag (situatie 2): geen codering; gebruik een voor de student zo helder mogelijke benaming

BERICHTEN: zowel voor map als alle mailtypen (situatie 2): geen codering; gebruik een voor de student zo helder mogelijke benaming MELDINGEN: -

melding (situatie 3): --<elementid>

o

bijvoorbeeld: "OPR-MLD-Uitnodiging van begeleider"


30

TAKEN: -

taak (situatie 2): geen codering; gebruik een voor de student zo helder mogelijke benaming

-

conditie (situatie 3): --<elementid>

o

bijvoorbeeld: "OPR-SCR-IF Hal redactie 1e keer OPEN"

o

laat de elementid beginnen met de code "IF", zodat meteen duidelijk is dat het om een conditie

SCRIPTS:

gaat o bij complexe casussen is het raadzaam meerdere scriptcomponenten te definiëren, bijvoorbeeld 1 voor elke fase; op deze manier kun je de casusstructuur wat overzichtelijker maken; voeg dan in de betiteling van de scriptelementen een instantiatie-id toe tussen de componentid en "IF" o het elementid zal meestal in zijn eenvoudige vorm bestaan uit een verwijzing naar een andere component of een inhoudselement uit een andere component (of een timer uit de scriptscomponent zelf) plus een statustestcode  gebruik voor de verwijzing naar het inhoudselement de elementid uit de ingevoerde betiteling voor dat element, eventueel, als dat niet duidelijk genoeg is, aangevuld met componentinformatie  de statustestcode bestaat in het algemeen uit een statusparameternaam plus de waarde die die parameter moet aannemen; de statusparameternaam dient gelijk te zijn aan de parameternaam die geselecteerd is bij het invoeren van de statustest; gebruik hoofdletters voor de duidelijkheid; gebruik voor de waarde een duidelijke omschrijving; als het bijvoorbeeld om de boolean "true" gaat, kun je hem weglaten, gaat het om "false", gebruik dan "niet"  als het elementid moet verwijzen naar verschillende componenten/of inhoudselementstatustesten, die met "and" en/of "or" aan elkaar gekoppeld zijn, gebruik dan openings- en sluithaken om de individuele statustests te onderscheiden, en gebruik de codes "EN" en "OF" om de statustests aan elkaar te koppelen -

actie (situatie 3): --<elementid>

o

bijvoorbeeld: "OPR-SCR-Taakoverzicht TOEGANKELIJK"

o hiervoor gelden dezelfde richtlijnen als voor condities; bij acties verwijzen de elementids altijd maar naar 1 component- of inhoudselementstatus -

timer (situatie 3): --<elementid>

o

bijvoorbeeld: "OPR-SCR-TIM toon MLD-Uitnodiging van begeleider"

o

laat de elementid beginnen met "TIM", zodat direct zichtbaar is dat het om een timer gaat

o

geef in de elementid aan waar deze timer voor bedoeld is (wat er moet gebeuren als hij afgaat)

-

vraagitem (situatie 3): --<elementid>

o

bijvoorbeeld: "OGB-ITM-VR 01 Waar gaat dit over?"

o

laat de elementid beginnen met "VR", zodat direct zichtbaar is dat het om een vraag gaat

-

alternatief (situatie 3): --<node-id>-<elementid>

o

bijvoorbeeld: "OGB-ITM-VR 01-ALT a weet niet"

o

de node-id moet verwijzen naar de vraag die bij dit alternatief hoort

o

laat de elementid beginnen met "ALT", zodat direct zichtbaar is dat het om een alternatief gaat

-

feedbackconditie (situatie 3): --<node-id>-<elementid>

o

bijvoorbeeld: "OGB-ITM-VR 01-FB 1 correct"

o

de node-id moet verwijzen naar de vraag die bij deze feedback hoort

o

laat de elementid beginnen met "FB", zodat direct zichtbaar is dat het om een feedback gaat

ITEMS:


31

bron en referentie naar bron (situatie 2): geen codering; gebruik een voor de student zo helder mogelijke benaming TOETSEN: -

toets (situatie 2): geen codering; gebruik een voor de student zo helder mogelijke benaming

-

referentie naar item (situatie 3): --<elementid>

o

bijvoorbeeld: "OGB-TTS-VR 01 Waar gaat dit over?"

o NB: het programma bepaalt zelf de in de afspeler getoonde vraagtitels; deze worden (taalafhankelijk) gezet op "vraag 1", "vraag 2", etc. -

feedbackconditie (situatie 3): --<node-id>-<elementid>

o

bijvoorbeeld: "OGB-TTS-Intaketoets-FB 1 score minder dan 3"

o

de node-id moet verwijzen naar de toets waarvoor deze feedback geldt

o

laat de elementid beginnen met "FB", zodat direct zichtbaar is dat het om een feedback gaat


32

Bijlage 4: Instructie Demonstrators Zorg er vóór begin van de demonstratie voor dat je internet-instellingen voor Internet Explorer (of Firefox) op orde zijn. Met name is het belangrijk dat je http://emergo.ou.nl toevoegt aan de “local intranet”-zone. Ook moet je Word-bestanden kunnen openen, en moet de Windows Media Player goed functioneren (voorlopig is alleen op Windows een goede werking van de demonstrators gegarandeerd). Zie voor meer informatie de handleiding die je krijgt als je op “hulp” klikt in de demonstrator. 1.

authentieke opdracht (Omgevingsbeleid, start Naardermeer) Geschatte tijdsduur demonstratie: ca. 10’. Uitgangssituatie: je hebt net van Lisette te horen gekregen dat je klaar bent met de casus Fijn stof en dat je naar Wendelijn kunt voor de Tunnelvariant-opdracht. Je bevindt je in de stagekamer. Opties: a. ga naar Lisette; je krijgt te horen dat je toch echt eerst naar Wendelijn moet b. secretariaat, grote vergaderzaal, kleine vergaderruimte, expertkamer, en de kamers van Ron, Carel en Hens zijn leeg c. ga naar Wendelijn; die stelt zich voor en vertelt je wat jij moet uitzoeken in deze casus d. na beëindiging van het gesprek volgt na 30” de melding dat je mail hebt; Wendelijn verdwijnt uit haar kamer e. ga naar de “empack” en open “e-berichten”; open de map “beleidsontwerp TRACÉ NAARDERMEER” door op het plusje te klikken vóór de mapnaam f. klik op de tekst “Opdracht tunnelvariant Naardermeer” en klik in het dan verschijnende venster op de tekst onder “Bijlagen”; als je pc goed is ingesteld opent Microsoft Word met het opdracht-bestand (eventueel krijg je eerst de vraag of je wilt opslaan of openen; kies voor openen) g. sluit Word, sluit het bericht, sluit het berichtenvenster; einde demonstratie

2.

afhankelijkheid in begeleiding (Omgevingsbeleid, start Waddenzee): Geschatte tijdsduur demonstratie: ca. 10’. Uitgangssituatie: je hebt net de casus Windenergie afgerond. Je hebt zojuist een melding gekregen dat Lisette op je zit te wachten met informatie over een volgende opdracht. Je bevindt je in de stagekamer. Opties: a. secretariaat, grote vergaderzaal en expertkamer zijn leeg; kleine vergaderruimte en Wendelijn Oolders zijn niet toegankelijk b. je kunt naar Ron Cörvers, Carel Dieperink respectievelijk Hens Runhaar; zij stellen zich voor, en je kunt hun vragen stellen over hun ViBOA-activiteiten en hun inzichten c. ga naar Lisette, die de opdracht introduceert d. na beëindiging van gesprek met Lisette zijn Hens en Carel niet meer aanwezig in hun kamers e. ga naar Ron, die een nadere toelichting geeft over de opdracht f. na afsluiten van Ron krijg je na 2’ een melding dat je een mail hebt ontvangen g. ga naar de Empack, start e-berichten; klik op het plusje voor de map “INBOX”; klik op het plusje vóór de map “Beleidsanalyse Waddenzee”; hier vind je een mail van Ron over een van de bronnen: klik op de tekst “Radioprogramma Waddenzee en thesaurus” h. na 30" krijg je een melding dat er een nieuwe mail is binnengekomen, deze bevat de opdracht van Ron (klik in e-berichten, in de map “INBOX”, in de map “Beleidsanalyse Waddenzee” op de tekst “Opdracht en werkwijze beleidsanalyse Waddenzee”) i. na 60" zie je een mededeling dat Tammo Oegema als expert te spreken is j. sluit e-berichten, klik op “locaties”, ga naar de expertkamer en stel vragen aan Tammo k. beëindig het gesprek met Tammo; einde demonstratie

3.

onverwachte gebeurtenis (Zorgstructuur, Keniaproject directrice) Geschatte tijdsduur demonstratie: ca. 10’. Uitgangssituatie: je hebt van je stagebegeleider via mail je opdracht ontvangen en je bent bezig met de uitwerking ervan. Je bevindt je op het schoolplein. Opties: a. gymzaal en hal zijn leeg b. in de toetsruimte kun je observeren hoe een lerares een test afneemt bij 2 jongetjes, na sluiten van het fragment volgt een fragment waarin ze een meisje aan het testen is


33

c. d. e. f.

g. h. i. j. k. l.

4.

in “IBer in actie” is een overleg te zien tussen een intern begeleider en een leerkracht over een van de leerlingen je kunt naar “leerkracht”, “intern begeleider”, “directeur” en “stagebegeleider” om informatie te krijgen over je opdracht en de gang van zaken op school ga naar de “mediatheek” (wordt zichtbaar na klikken op de PDA) om drie typen bronnen te bekijken: schriftelijke bronnen, websites en videobronnen 30” na starten van de demonstratie volgt een melding dat de directrice iets kan laten zien over haar Keniaproject; zorg ervoor dat je op dat moment geen vraag van de directrice aan het beluisteren bent, want als je op haar kamer bent begint ze meteen met haar Kenia-verhaal, en dan gaan 2 video’s door elkaar lopen; dit probleem moeten we nog verhelpen als je 50” na de Kenia-melding nog niet bij de directrice bent geweest laat de begeleider je weten het jammer te vinden dat je deze informatie gemist hebt; vanaf dat moment kun je de directrice weer de standaard vragen stellen 3’ na starten van de demonstratie krijg je een melding dat je de fysiotherapeute in de gymzaal in actie kunt zien; als je vervolgens naar de gymzaal gaat krijg je achtereenvolgens 3 fragmenten te zien als je na 1 minuut nog niet naar de gymzaal bent gegaan krijg je weer een melding, met de hint om daar een kijkje te nemen; als je op dat moment naar de gymzaal gaat krijg je alleen nog de laatste 2 fragmenten te zien als je 1 minuut na de 2 e gymzaal-melding nog niet in de gymzaal bent geweest krijg je een 3 e melding waarin je op je verantwoordelijkheden wordt gewezen; de fysiotherapeute is vertrokken 5’ na start van de demonstratie krijg je een mail met het verzoek je eindopdracht te sturen als je die mail gelezen hebt kun je de eindopdracht opsturen; open de PDA, en dan de e-mail; klik op “Maak nieuw bericht”; kies in de combobox naast “Aan” voor “Henk van den Brink, stagebegeleider”; kies bij onderwerp “ik ben klaar met mijn notitie”; typ wat tekst in het invoerveld en klik op “verzend”; 5” na opsturen van de mail krijg je een bevestigingsmail van je begeleider, en zijn er een aantal “cadeaubronnen” te vinden in de mediatheek; einde demonstratie

afhankelijkheid van uitwerking (Omgevingsbeleid, einde Naardermeer) Geschatte tijdsduur demonstratie: ca. 10’. Uitgangssituatie: je hebt hard gewerkt aan het rapport over de Naardermeersituatie. Je denkt dat je klaar bent, en je wil nu het rapport opsturen naar Wendelijn. Je bevindt je in de stagekamer. Opties: a. alle kamers zijn leeg b. ga naar de empack, open de bronnen; je ziet dat de map “Tunneltracé Naardermeer” geopend is; je kunt 3 bronnen bekijken c. sluit de bronnen d. open de e-berichten e. klik op de knop “Maak nieuw bericht” f. kies in de combobox achter “Aan: “ voor Wendelijn Oolders g. kies in de combobox achter “Onderwerp” voor “uitwerking opdracht Naardermeer” h. tiep wat tekst in het invoerveld, voeg eventueel een bijlage toe i. klik op de knop “verzend” j. sluit e-berichten, klik op locaties k. 30” na het verzenden van je eindrapport krijg je de melding dat je mail hebt l. ga naar de empack, klik op e-berichten, en vervolgens op de tekst “Reactie op uitwerking opdracht Tunnelvariant”; je leest dat Wendelijn nog een vraag heeft, en dat ze ook nog wat extra bronnen heeft gevonden m. sluit e-berichten, en open bronnen; je ziet nu dat het aantal Naardermeerbronnen met 5 is toegenomen; einde demonstratie


34

Bijlage 5: Instructies gebruik toolkit componenten INTRODUCTIE - hoe gaan we te werk? -> korte introducties, gevolgd door 30' invoeren - a. casusopzet/definitie - b. casusrollen - c. locaties - d. bronnen - e. taken - f. Google maps - g. gesprekken - h. berichten - i. meldingen - j. scripting • o

o

o

o

• o

o

o

o

A. CASUSOPZET Uitgangssituatie: scenario's af, rollen/taken bedacht, bronnen uitgezocht, locaties bedacht (evt + plaatjes), interviews uitgeschreven -> casusontwikkelaar definieert casus -> wordt hierdoor casuseigenaar -> voert casusrollen in -> selecteert componenten Na inloggen kan de ontwikkelaar kiezen uit 4 rollen: - casusontwikkelaar - case run manager - tutor - student => gebruik ‘casusontwikkelaar’ om het invoeren van een nieuwe casus te starten een casusontwikkelaar definieert een nieuwe casus na het klikken op de knop ‘nieuw’: -> naam/versie-combinatie moet uniek zijn -> nieuwe definitie wordt toegevoegd aan de lijst in het casusoverzicht na selecteren van een casusdefinitie in het casusoverzicht verschijnen 3 knoppen: -> "wijzig" om de definitie aan te passen -> "kopieer" om een nieuwe casus te definiëren uitgaande van de geselecteerde -> "verwijder" om de geselecteerde casus te verwijderen B. CASUSROLLEN student moet in casus een rol spelen -> in een "stand alone"-/single user-situatie: slechts 1 "student"rol (=> bijv. "assistent"/"stagiair") -> in een multi user-/multi role-situatie: vb milieuadviesbureau, met als rollen stagiair/begeleider/directeur/expert -> student moet kiezen welke rol hij aanneemt, of krijgt een rol toegewezen door een case run manager rollen zijn van belang bij de keuze van casuscomponenten (het "gereedschap" waarover een student beschikt bij het doorlopen van zijn casus; zie verder): -> elke component moet gekoppeld zijn aan 1 of meer rollen -> de inhoud van een component is alleen van belang voor de aan die component gekoppelde rollen -> bijvoorbeeld: een bronnencomponent voor een stagiaire kan een andere inhoud hebben dan een bronnencomponent voor de directeur van het bedrijf waarin de stagiaire werkt -> voordat de componenten kunnen worden ingevoerd moeten EERST de rollen worden ingevoerd per definitie is voor elke nieuwe casus al 1 rol aanwezig: de rol ‘student’ -> is aanpasbaar: selecteer de rol, dan verschijnen de knoppen ‘wijzig’ en ‘verwijder’ met de knop ‘nieuw’ kan een nieuwe rol worden ingevoerd; er zijn 2 typen rollen: - Playing Characters (PC) – dit zijn rollen die een “echt” persoon (iha een student) kan aannemen tijdens het doorlopen van de casus, en die kunnen worden gekoppeld aan de


35

casuscomponenten; deze rollen moeten dus ingevoerd zijn voordat de casuscomponenten kunnen worden gekozen - Non Playing Characters (NPC) – dit zijn namen van virtuele personen waarmee een Playing Character contact heeft binnen de casus -> de casusontwikkelaar gebruikt de NPC’s in de berichtencomponent, als afzender of geadresseerde bij een bericht -> NPC’s zijn ook vaak zichtbaar op locaties, geven interviews, en sturen meldingen -> bijvoorbeeld een begeleider, een expert, een leidinggevende -> NPC’s kunnen ook in een later stadium worden ingevoerd

CASUSCOMPONENTEN Zijn onder te verdelen in verschillende groepen: - "gereedschap" voor de Playing Characters in de player - bronnen - interviews - mail - meldingen - takenlijst - notitieblok - localizeringshulpmiddelen in de player -> waar kan een Playing Character het gereedschap vinden - locaties - empack - hulpmiddel om de interacties te definiëren tussen het Playing Caracter en de casusomgeving in de player -> scripting -> er moet altijd minimaal 1 locatiecomponent aanwezig zijn Nu we allemaal een casus hebben gecreëerd en casusrollen hebben gedefinieerd, kunnen we beginnen met het definieren van casuscomponenten. Er zijn verschillende componenten. En is er ook een bepaalde volgorde waarop de componenten het beste kunnen worden gedefinieerd. Locatiecomponent De eerste component die we gaan definieren is de locatiecomponent. Dat is een component waarin de verschillende locaties, werkplekken ed, worden gedefinieerd samen met hun achtergrondfoto’s. De student zal mogelijk een eigen locatie, werkplek, hebben. Ook zullen verschillende experts die kunnen worden geraadpleegd hun eigen werkplek kunnen hebben. We klikken op de knop ‘casecomponenten’ en kunnen vervolgens met de knop ‘nieuw …’ een nieuwe casuscomponent definieren. In de combobox kiezen we welke component we willen definieren. In dit geval gaat het om ‘locaties’ dus selecteren we dat. We kiezen hier in feite een soort template. De casuscomponent is een instantiatie van de component. Vervolgens vullen we een eigen naam in, bijv. navigator. Dan kiezen we de auteur. Default is dat degene die de casus heeft gecreëerd, de casuseigenaar, maar we kunnen ook een andere auteur kiezen. Laat zien, door Ansje Lohr te kiezen. De auteur van de casuscomponent heeft lees en schrijfrechten. De andere casusontwikkelaars alleen leesrechten. Als laatste zien we de pc casusrol(len) die we hebben gedefinieerd. Per pc casusrol kunnen we aanvinken of de casuscomponent voor deze rol beschikbaar is. Default staan alle rollen aangevinkt. Op deze manier is het mogelijk om per pc casusrol andere casuscomponenten te definieren. Dit voert op dit moment echter te ver. Mogelijk later als we nog tijd over hebben. Per casusrol kan de naam die zichtbaar is voor de student (geel) anders zijn. Vullen we niets in, dan vult het programma de eigen naam in. We klikken op ‘ok’ en zien dat de casuscomponent is toegevoegd. Selecteren we de regel door erop te klikken, dan zien we nog drie knoppen verschijnen: ‘wijzig’, ‘kopieer’ en ‘verwijder’. Als we op ‘wijzig’ klikken, kunnen we de naam of auteur van de casuscomponent eventueel wijzigen. Met ‘kopieer’ kunnen we een casuscomponent kopieren. Dat is nu nog niet aan de orde. Met ‘verwijder’ kunnen we een casuscomponent eventueel verwijderen.


36

Nu hebben we de casuscomponent gecreëerd, maar deze heeft nog geen inhoud, afgezien van zijn naam. Daarom klikken we op de knop ‘inhoud’ om de inhoud toe te voegen. We zien nu eerst twee checkboxen. Met de eerste kan ingesteld worden of de casuscomponent aan het begin van de casus al voor de student beschikbaar is. Als ik de knop uitvink, zal de casuscomponent niet aanwezig zijn voor de student totdat deze mbv de scriptcomponent beschikbaar wordt gesteld. De locatiecomponent zal bijna altijd meteen aan begin van de casus beschikbaar zijn. Met de tweede checkbox kan ingesteld worden of casuscomponent initieel toegankelijk (‘grijs’) is voor de student. Dwz de student ziet de component wel, maar er gebeurt niets als hij erop klikt. De locatiecomponent zal bijna altijd meteen aan begin van de casus toegankelijk zijn. Klikken we nu met de rechtermuisknop op het blauwe woordje ‘root’, dan krijgen we een menu met twee opties: ‘nieuwe locatie’ en ‘preview’. Over de preview later meer. Kiezen we voor ‘nieuwe locatie’ dan verschijnt een dialoogvenster. Als eerste vullen we een id in. Dit id is niet zichtbaar voor de student (niet geel), maar is nodig om een voor de auteur eenduidige naam te geven. Als het om veel inhoud gaat, zoals bronnen of gesprekken is het zinvol om hiervoor coderingen te gebruiken. Vul wat in. Als tweede vullen we een naam in die zichtbaar is voor de student. Vul wat in. De toelichting is niet verplicht, maar zullen jullie in alle invoerdialogen terug zien. Deze is bedoeld voor de auteur om bijv. iets te noteren dat nog moet gebeuren. Ook de locatie kan initieel aanwezig en/of toegankelijk zijn, net als de locatiecomponent in zijn geheel. Daarnaast kan een locatie nog voorgeselecteerd zijn. Dit betekent dat de student de casus zal starten in deze locatie. Er kan slechts een locatie voorgeselecteerd zijn. Klikken we op ok, dan is de locatie toegevoegd. Door weer op ‘root’ te klikken kunnen we meerdere locaties toevoegen. Doe dat. Klikken we nu met de rechtermuisknop op ‘locatie’ dan verschijnt een menu met vier opties. Met ‘wijzig’ kunnen we de bestaande locatie wijzigen. Met ‘verwijder’ kunnen we de locatie verwijderen. Er staat echter ook een optie ‘nieuwe achtergrond’. Klikken we hierop dan kunnen we een achtergrondplaatje van de locatie toevoegen. Ook hier geven we een id. Met de knop ‘voeg toe’ kunnen we een plaatje uploaden. We krijgen het geuploade plaatje te zien. Ook hier weer een facultatief toelichtingveld. Ook een achtergrond kan voorgeselecteerd zijn. Een locatie zou namelijk meerdere achtergronden kunnen hebben, waarvan de actieve dmv de scriptcomponent wordt gezet. We zien dat de achtergrond is toegevoegd. Preview Nu de preview optie. Er verschijnt een venster. Met de knop ‘preview’ kunnen we nu wat we ingevoerd hebben afspelen. Doe dit. Linksonder zien we nu de navigator en daarnaast twee deuren voor de locaties. We kunnen tussen de locaties wisselen door op de deuren te klikken. Met het kruisje sluiten we speler weer af. Wat we hebben gedaan is bewaard. Kijk maar, als ik weer opstart met ‘preview’ dan zitten we op de tweede locatie. We zien alle rollen die zijn gedefinieerd en kunnen per rol previewen. Met ‘preview readonly’ wordt niet bewaard wat we doen. Dit kan gebruikt worden om telkens vanaf een bepaald punt te kunnen beginnen. Met ‘wis status’ wordt alles wat je hebt gedaan gewist en begin je weer van voren af aan. Zo, nu kunnen we dit gaan oefenen. Tenminste als er geen vragen meer zijn.

• o o o o o o

D. BRONNEN In de player vindt een PC de bronnencomponent meestal op de Empack, dus de ontwikkelaar moet in dat geval ook de Empack toevoegen als casuscomponent Een casusontwikkelaar kan ook de bronnencomponent koppelen aan een locatie; dan is de Empack niet nodig Ga naar het casuscomponentenoverzichtsscherm, klik op de knop “nieuw” en selecteer “bronnen” Bedenk een unieke naam voor deze bron voor de casusontwikkelaar (van belang in de Script-component) Selecteer een casusontwikkelaar die straks de inhoud gaat vullen Selecteer de PC’s waarvoor deze casuscomponent van belang is, en voer voor elk van die PC’s een naam in voor de component, indien deze afwijkt van de casusontwikkelaarnaam


37

o o

o

Klik in het casuscomponentenoverzicht op de knop “inhoud” achter de zojuist toegevoegde bronnencomponent Configureer de manier waarop de component gestart wordt in de player: - Initieel aanwezig -> aangevinkt: de knop om deze component te starten is zichtbaar in de player - Initieel toegankelijk -> aangevinkt: als de startknop zichtbaar is, dan is hij ook actief - Uitbreidbaar door gebruiker -> aangevinkt: een PC kan zelf bronnen toevoegen/verwijderen/bewerken - Alleen aanpasbaar door creator -> een PC mag alleen zelf toegevoegde bronnen wijzigen of verwijderen (alleen van belang als ‘Uitbreidbaar door gebruiker’ en ‘gedeeld door alle gebruikers’ of ‘gedeeld door gebruikers in team’ zijn aangevinkt) - Gedeeld door alle gebruikers -> een door een PC toegevoegde bron wordt zichtbaar voor alle andere personen in die PCrol en voor alle andere PC’s die gekoppeld zijn aan deze component (alleen van belang als ‘uitbreidbaar door gebruiker’ is aangevinkt) - Gedeeld door gebruikers in team -> een door een PC toegevoegde bron wordt zichtbaar voor alle personen die bij hem in het team zitten (alleen van belang als ‘uitbreidbaar door gebruiker’ is aangevinkt, en ‘gedeeld door alle gebruikers’ niet is aangevinkt) Voer de inhoud in, start door met de rechtermuisknop op “root” te klikken; er verschijnt een popupmenu: - “wijzig root” -> koppel hiermee de bronnencomponent aan een locatie (in plaats van aan de Empack) - “nieuw op subniveau” -> “nieuwe map” hiermee kan structuur in het bronnenoverzicht worden gebracht; voer een mapnaam in, en bepaal of de map bij de eerste keer openen van de bronnencomponent zichtbaar is (‘initieel aanwezig’) en of hij dan uitgeklapt getoond wordt (‘initieel uitgeklapt’) - “nieuw op subniveau” -> “nieuwe bron” -> geef de bron een naam -> kies het type van de bron: - bestand: via filedialoog toevoegen van een bestand vanaf de eigen werkplek (bestandsgrootte tot enkele MB’s om uploadperiode acceptabel te houden) -> klik op “voeg toe” -> klik op “browse” en selecteer een bestand -> klik op “upload” -> klik op “preview” om het bestand te bekijken - interne URL: om een bestand dat al op de server staat te koppelen aan deze bron (geschikt voor grote bestanden, bijvoorbeeld video’s) -> laat een beheerder het bestand op de server zetten -> voer de bestandsnaam in door rechtstreeks te typen in het invoervak -> of klik op “kies” om een keuze te maken uit de lijst van al op de server aanwezige bestanden -> bekijk via “preview” - externe URL: om een bron te koppelen aan een website -> voer de URL in in het invoerveld -> bekijk via “preview” -> kies het mediatype -> het type bepaalt het ikoon waarmee de bron zichtbaar wordt in de player -> “initieel aanwezig” -> bronnaam + ikoon zijn zichtbaar -> “initieel toegankelijk” -> bron is te openen - rechtermuisknop op map: -> “nieuw op subniveau” -> map (zie boven) -> “nieuw op subniveau” -> bron (zie boven)


38

Takencomponent De takencomponent definieren we op dezelfde manier, door op de knop ‘nieuw’ te klikken. We kiezen voor ‘taken’, geven een naam en klikken op ok. Nu klikken we op ‘inhoud’ om de component te gaan vullen. Naast initieel aanwezig en toegankelijk, zien we nog een optie ‘taken afvinkbaar’. Hiermee definieer je of een student zelf zijn taken kan afvinken, of dat door het programma mbv de scriptcomponent zal gebeuren. Door weer met de rechtermuisknop op ‘root’ te klikken kunnen we een taak toevoegen. Ook de preview optie is weer aanwezig. We voeren een naam in die zichtbaar zal zijn voor de student. Daarnaast kunnen we een hovertekst invullen. Deze zal zichtbaar worden als de student met zijn muis over de taak beweegt. Ook kunnen we een richttijd invullen voor de taak. Hoe lang de taak gemiddeld zal duren. Dat hoeft echter niet. Naast initieel aanwezig en toegankelijk zien we nog ‘vereist’ en ‘initieel uitgeklapt’. Een taak kan vereist zijn of facultatief. Daarnaast kan een taak subtaken hebben. Met ‘initieel uitgeklapt’ wordt gedefinieerd of de subtaken al zichtbaar zijn. Ik zal dit zo tonen. Door op ‘taak’ te klikken kunnen we met ‘nieuwe taak’ subtaken toevoegen. Door op ‘root’ te klikken kunnen we nieuwe taken toevoegen. Ook hier de preview optie. Door op het ‘plusje’ te klikken, worden de subtaken zichtbaar. Als ik nu ‘initieel uitgeklapt’ had aangevinkt, dan was dit de toestand geweest. Zo, nu kunnen we dit gaan oefenen. Tenminste als er geen vragen meer zijn. Google maps component We voegen de component toe op de bekende manier. We kiezen voor ‘google maps’, geven een naam en gaan de inhoud vullen. We zien nu dezelfde opties als Hub heeft laten zien bij de bronnencomponent. Ook Google maps bronnen kunnen eventueel door studenten worden toegevoegd en gedeeld met andere studenten. Itt de andere componenten vullen we deze component door met de linkermuisknop te klikken. Zoomen we eerst eens in op de Westerschelde. Klikken we nu met links dan kunnen we op die plaats een nieuwe bron toevoegen. We krijgen eenzelfde scherm als bij de bronnencomponent. Extra is een veld ‘beschrijving’. Hierin kan een tekstje opgenomen worden dat de bron beschrijft. Klikken we op ok dan wordt de bron toegevoegd. We kunnen het prikkertje nog verplaatsen. Ook kunnen we het wijzigen door er met links op te klikken. Preview kan ook. Zo, nu kunnen we dit gaan oefenen. Tenminste als er geen vragen meer zijn. •

G. GESPREKKEN

o

o zijn ingevoerd o

o

Een “gesprek” kan in EMERGO diverse betekenissen hebben, bijvoorbeeld: - interview - videoboodschap - presentatie - documentaire -> een “gesprek” is in zijn algemeenheid een AV-fragment of een keuzelijst van AV-fragmenten die altijd gekoppeld is aan een of meer locaties -> een AV-fragment kan zijn audio (WMA, WAV, FLA), of video (WMV, MPG, FLV, SWF) Voor definitie van een gesprek moet de locatie waarop het gesprek zich afspeelt al Start met het invoeren van een of meer gesprekscomponenten - meer dan 1 component als een casus heel veel gesprekken heeft, die eenvoudig groepsgewijs zijn in te delen; bijvoorbeeld: als er met elk personage meerdere gesprekken kunnen worden gevoerd kan elk personage zijn eigen gesprekkencomponent krijgen klik in het casecomponentenscherm op de knop “nieuw” - selecteer “gesprekken” als component - geef de component een naam (van belang voor de ontwikkelaar, als hij scripts gerelateerd aan deze component gaat definiëren) - selecteer een casusontwikkelaar die straks de inhoud gaat vullen - selecteer de PC’s waarvoor deze casuscomponent van belang is


39

o

- de naam voor de PC’s is niet van belang, want die wordt niet zichtbaar in de player klik op de knop “inhoud” achter de nieuw gedefinieerde gesprekscomponent in het casecomponentvenster -> gespreksinvoervenster verschijnt - aanvinkknop “initieel aanwezig”: als aangevinkt dan zal de player de gesprekken van deze component kunnen afspelen, als niet aangevinkt dan moet de component eerst in een script op “aanwezig” gezet worden - rechtermuisknopklik op “root” -> nieuw op subniveau -> nieuw gesprek => popup-invoervenster verschijnt - Id: de identificatie voor de casusontwikkelaar - Naam: de naam voor de PC’s (zichtbaar wanneer een PC op een locatie een keuze moet maken tussen activiteiten); NB het is hier niet mogelijk om afzonderlijke namen voor elk PC in te voeren - Referentie naar locatie(s): koppel dit gesprek aan 1 of meer locaties -> kies (een van )de locatiescomponent(en) -> kies de PC’s die dit gesprek kunnen bekijken -> kies de locatie(s) waarop dit gesprek te zien is - Toelichting: geheugensteun voor de casusontwikkelaar - Initieel aanwezig: aangevinkt = gesprek kan direct gespeeld worden bij binnenkomen op de locatie; niet aangevinkt = gesprek moet via een script-actie op “aanwezig” gezet worden - rechtermuisknopklik op “gesprek” -> “nieuw op subniveau” -> “nieuwe achtergrond” -> invoervenster voor achtergrondplaatje verschijnt -> invoeren van plaatje dat zichtbaar wordt als het PC een keuze moet maken uit een aantal videofragmenten (bijvoorbeeld bij een interview) -> als geen plaatje ingevoerd, dan wordt de achtergrond zwart (dus niet automatisch gelijk aan het locatieplaatje) -> per gesprek meerdere achtergrondplaatjes mogelijk; alleen het voorgeselecteerde wordt getoond - Id: de identificatie voor de casusontwikkelaar - Achtergrond: het bestand, uploaden naar de server mbv de knop “voeg toe” -> “bestand kiezen” -> selecteer in de filedialoog een bestand op de eigen machine, klik op “open” en dan op “upload” -> het bestand wordt zichtbaar (en de knoppen “overschrijf” om het bestand te vervangen, en “verwijder” om de achtergrond leeg te maken) - Toelichting: geheugensteun voor de casusontwikkelaar - Voorgeselecteerd: als niet aangevinkt, dan wordt het plaatje alleen zichtbaar als via scripting de “open”-parameter op “true” wordt gezet; als aangevinkt, dan haalt het programma automatisch het vinkje weg bij de tot dat moment aangevinkte achtergrond (als die er is) - rechtermuisknopklik op “gesprek” -> “nieuw op subniveau” -> “nieuw fragment” -> invoervenster voor videofragment verschijnt -> op het niveau van gesprek, vraag en map kan meer dan 1 fragment worden ingevoerd; alleen het op het moment van openen voorgeselecteerde fragment wordt afgespeeld - Id: identificatie voor de casusontwikkelaar tbv scripting - Link: koppeling naar bestandsnaam of URL; mogelijke types: -> bestand: bestand vanaf eigen machine uploaden via “voeg toe” als bij achtergrondplaatjes; voor niet al te grote bestanden, zodat upload niet te veel tijd kost -> interne url: koppeling naar AV-bestand op de EMERGO-server; typ de naam van het bestand in, of selecteer via de knop “kies” het bestand als dat al op de server staat; met name voor grote videobestanden geschikt -> url: koppeling naar AV-bestand dat op een externe server staat; voer hier de url naar het bestand in (bijvoorbeeld link naar youtube-filmpje) - Toelichting: geheugensteun voor de casusontwikkelaar - Voorgeselecteerd: als niet aangevinkt, dan wordt het fragment alleen afgespeeld door via scripting “open” op “true” te


40

zetten (Aad???); als aangevinkt, dan haalt het programma automatisch het vinkje weg bij het tot dat moment aangevinkte fragment in dit niveau (als dat er is) => dmv rechtermuisknopklik op “fragment” -> “nieuw op subniveau” -> “nieuwe map” of “nieuwe vraag” kan een casusontwikkelaar een PC laten doorvragen op gegeven antwoorden - rechtermuisknopklik op “gesprek” -> “nieuw op subniveau” -> “nieuwe map” -> invoervenster voor mappen verschijnt -> om een meerlaagse structuur aan te brengen in een interview - Naam: identificatie voor casusontwikkelaar, maar ook zichtbaar voor PC in afspeelomgeving - Toelichting: geheugensteun voor casusontwikkelaar - Initieel aanwezig: als aangevinkt dan is map zichtbaar voor PC, als niet aangevinkt dan alleen via scripting zichtbaar te maken - Initieel uitgeklapt: als aangevinkt dan zijn alle vragen die in het subniveau van deze map worden ingevoerd direct zichtbaar voor het PC, als niet aangevinkt dan moet het PC op de map klikken om de subvragen zichtbaar te maken (kan ook via scripting gezet worden) => dmv rechtermuisknopklik op “map” -> “nieuw op subniveau” -> “nieuwe vraag” kan de ontwikkelaar de map vullen met vragen; via “nieuwe map” kan hij een extra laag toevoegen binnen deze map - rechtermuisknopklik op “gesprek” -> “nieuw op subniveau” -> “nieuwe vraag” -> invoervenster voor vragen verschijnt - Tekst: vraagtekst die een PC kan selecteren in de player; is tevens de identificatie voor de casusontwikkelaar - Toelichting: geheugensteun voor de casusontwikkelaar - Initieel aanwezig: als niet aangevinkt dan wordt de vraag alleen zichtbaar via een scriptactie - Kinderen initieel zichtbaar: als niet aangevinkt zijn de eventueel gedefinieerde mappen met vervolgvragen in het subniveau bij deze vraag alleen via scripting zichtbaar te maken => dmv rechtermuisknopklik op “vraag” -> “nieuw op subniveau” -> “nieuw fragment” kan de ontwikkelaar de het antwoordfragment bij deze vraag invullen (en van daaruit eventueel een hele doorvraagstructuur)

• o o o

o 1.

2.

3.

H. BERICHTEN Per PC slechts 1 berichtencomponent zinvol (meerdere definiëren mag, maar er wordt slechts 1 getoond in de afspeler) De berichtencomponent is standaard in de afspeler gekoppeld aan de Empackcomponent; die moet dus ook als casuscomponent gedefinieerd zijn Bij invoer van berichten moet de ontwikkelaar afzender en geadresseerde kunnen kiezen uit een lijst van PC’s en NPC’s; hij moet de casusrollen dus al hebben ingevoerd voordat hij de berichten kan toevoegen Casusontwikkelaar kan 4 typen berichten invoeren: voorgedefinieerde inkomende mail -> als de afzender een NPC is -> ontwikkelaar voert complete mailinhoud in -> ontwikkelaar voert een scriptactie in die de mail verstuurt in de afspeelomgeving -> mag door een tutor worden verstuurd, bijvoorbeeld bij steekproefsgewijze monitoring van ingestuurde opdrachtuitwerkingen; de tutor kan dan het standaardantwoord aanpassen inkomende helpmail -> de afzender is een tutor in de rol van een NPC -> de casusontwikkelaar definieert een mail-template (mail met lege inhoud) en koppelt die aan een NPC-afzender voorgedefinieerde uitgaande mail -> de afzender is een PC -> casusontwikkelaar definieert een mailtemplate: hij voert wel de berichttitel in, maar niet de inhoud van het bericht -> casusontwikkelaar definieert de (N)PC’s die het bericht zullen


41

4.

o o

o o

o

ontvangen (de afzender kan dat niet zelf bepalen) -> het bericht wordt door een PC verstuurd uitgaande helpmail -> afzender is een PC -> casusontwikkelaar definieert een mailtemplate (geen berichttitel noch inhoud) -> casusontwikkelaar definieert de (N)PC’s die het bericht zullen ontvangen (de afzender kan dat niet zelf bepalen) -> het bericht wordt door een PC verstuurd alle typen berichten kunnen meer dan 1 keer worden verstuurd, hetzij via een scriptactie, hetzij door het PC/de tutor klik in het casecomponentenscherm op de knop “nieuw” - selecteer “berichten” als component - geef de component een naam; deze dient als identificatie voor de casusontwikkelaar bij het invoeren van scripts, en is de standaardnaam die de PC’s in de player te zien krijgen - selecteer een casusontwikkelaar die straks de inhoud gaat vullen - selecteer de PC’s die deze casuscomponent zullen zien - voer per PC een naam in voor de component, als die moet afwijken van de standaardnaam klik op de knop “inhoud” achter de nieuw gedefinieerde berichtencomponent in het casecomponentvenster -> berichteninvoervenster verschijnt configureer de manier waarop de component gestart wordt in de player: - aanvinkknop “Initieel aanwezig” -> aangevinkt: de knop om deze component te starten is zichtbaar in de player (op de Empack) - aanvinkknop “Initieel toegankelijk” -> aangevinkt: als de startknop zichtbaar is, dan is hij ook actief; niet aangevinkt: de startknop reageert niet op een muisklik voer de berichteninhoud in: - rechtermuisknopklik op “root” -> “nieuw op subniveau” -> “nieuwe map” => popup-invoervenster voor de mappen verschijnt => elk bericht komt in een map => casusontwikkelaar bepaalt in welke map(pen) binnenkomende en verstuurde berichten zichtbaar worden voor het PC -> voor de hand ligt: alle binnenkomende berichten in een “Inbox”, alle uitgaande berichten in een “Outbox” - Naam: naam van de map, is identificatie voor de casusontwikkelaar, en is ook de naam die een PC ziet in de player - Toelichting: geheugensteun voor de casusontwikkelaar - Initieel aanwezig: als aangevinkt dan is map zichtbaar voor PC, als niet aangevinkt dan alleen via scripting zichtbaar te maken - Initieel uitgeklapt: als aangevinkt dan zijn alle berichten die binnengekomen of gearchiveerd zijn in deze map, en alle submappen onder deze map, direct zichtbaar voor het PC; als niet aangevinkt dan moet het PC op de map klikken om berichten en submappen zichtbaar te maken (deze parameter kan ook via scripting gezet worden) - rechtermuisknopklik op “map” -> “nieuw op subniveau” -> “nieuwe map” => hiermee kan een casusontwikkelaar een boomstructuur van mappen met bijbehorende berichten opbouwen - rechtermuisknopklik op “map” -> “nieuw op subniveau” -> “nieuwe uitgaande voorgedefinieerde mail”; berichteninvoervenster verschijnt => mail die door een PC kan worden verstuurd; onderwerp is voorgedefinieerd; inhoud en bijlagen kunnen worden toegevoegd door het PC - Titel: onderwerp van het bericht; is tevens de identificatie voor de ontwikkelaar in de Script-component; kan niet worden aangepast door het PC - Geadresseerden (npc’s): vink de geadresseerde NPC’s aan in de lijst (meer dan 1 is toegestaan) - Geadresseerden (pc’s): vink de geadresseerde PC’s aan in de lijst (meer dan 1 is toegestaan) - Inbox voor pc’s: indien PC’s als geadresseerden zijn gekozen moet hier de mapnaam worden ingevoerd van de map waarin een geadresseerde de mail kan vinden; als geen PC’s als geadresseerden zijn gekozen heeft deze


42

parameter geen betekenis; als de map niet bestaat wordt hij gemaakt op het moment van versturen van de mail - Toelichting: geheugensteun voor de casusontwikkelaar - Initieel aanwezig: als aangevinkt, dan kan een PC deze mail al direct bij de eerste keer starten van de berichtencomponent versturen; als niet aangevinkt, dan moet de mail eerst via script op aanwezig worden gezet - rechtermuisknopklik op “map” -> “nieuw op subniveau” -> “nieuwe uitgaande help mail”; berichteninvoervenster verschijnt => mail die door een PC kan worden verstuurd; het PC kan zowel onderwerp als berichtinhoud als bijlagen invoeren - Id: de identificatie voor de ontwikkelaar in de Scriptcomponent - Geadresseerden (npc’s): vink de geadresseerde NPC’s aan in de lijst (meer dan 1 is toegestaan) - Geadresseerden (pc’s): vink de geadresseerde PC’s aan in de lijst (meer dan 1 is toegestaan) - Inbox voor pc’s: indien PC’s als geadresseerden zijn gekozen moet hier de mapnaam worden ingevoerd van de map waarin een geadresseerde de mail kan vinden; als geen PC’s als geadresseerden zijn gekozen heeft deze parameter geen betekenis; als de map niet bestaat wordt hij gemaakt op het moment van versturen van de mail - Toelichting: geheugensteun voor de casusontwikkelaar - Initieel aanwezig: als aangevinkt, dan kan een PC deze mail al direct bij de eerste keer starten van de berichtencomponent versturen; als niet aangevinkt, dan moet de mail eerst via script op aanwezig worden gezet - rechtermuisknopklik op “map” -> “nieuw op subniveau” -> “nieuwe inkomende voorgedefinieerde mail”; berichteninvoervenster verschijnt => mail die door een (tutor in de rol van )NPC kan worden verstuurd; de tutor kan zowel berichtinhoud als bijlagen bewerken of toevoegen, maar hij kan het onderwerp niet aanpassen, en ook niet de afzender of geadresseerde - Titel: onderwerp van het bericht; is tevens de identificatie voor de ontwikkelaar in de Script-component - Afzender (npc): selecteer het NPC dat de afzender van dit bericht is; er is maar 1 afzender mogelijk - Tekst: de berichtinhoud - Toelichting: geheugensteun voor de casusontwikkelaar - rechtermuisknopklik op “mail in” -> “nieuw op subniveau” -> “nieuwe bijlage”; bijlageinvoervenster verschijnt => alleen bij berichten van het type “inkomend voorgedefinieerd” kan de casusontwikkelaar een bijlage toevoegen; bij de andere typen kan de afzender zelf (als dat een PC is) in de afspeelomgeving en of meer bijlagen toevoegen - Naam: naam van de bijlage in de afspeelomgeving; ook identificatie voor de casusontwikkelaar in de Scriptcomponent - Link: de koppeling naar het bijlagebestand -> kies het type van het bijlagebestand: - bestand: via filedialoog toevoegen van een bestand vanaf de eigen werkplek -> klik op “voeg toe” -> klik op “browse” en selecteer een bestand -> klik op “upload” -> klik op “preview” om het bestand te bekijken - interne URL: om een bestand dat al op de server staat te koppelen aan deze bijlage (geschikt voor grote bestanden, bijvoorbeeld video’s) -> laat een beheerder het bestand op de server zetten -> voer de bestandsnaam in door rechtstreeks te typen in het invoervak -> of klik op “kies” om een keuze te maken uit de lijst van al op de


43

server aanwezige bestanden -> bekijk via “preview” - externe URL: om een bijlage te koppelen aan een website -> voer de URL in in het invoerveld -> bekijk via “preview” -> kies het mediatype van de bijlage -> dit type bepaalt het ikoon waarmee de bijlage zichtbaar wordt in de player - Toelichting: geheugensteun voor de casusontwikkelaar - rechtermuisknopklik op “map” -> “nieuw op subniveau” -> “nieuwe inkomende help mail”; berichteninvoervenster verschijnt => mail die door een tutor in de rol van een NPC kan worden verstuurd; de tutor kan zowel berichtonderwerp als berichtinhoud als bijlagen bewerken of toevoegen, maar hij kan niet de afzender of geadresseerde bepalen - Id: de identificatie voor de ontwikkelaar in de Scriptcomponent - Afzender (npc): selecteer het NPC dat de afzender van dit bericht is; er is maar 1 afzender mogelijk - Toelichting: geheugensteun voor de casusontwikkelaar •

I. MELDINGEN

o getoond worden o o

o

Teksten die gedurende het doorlopen van een casus in de player aan een PC

Het tonen van een meldingtekst gebeurt door middel van een scriptactie klik in het casecomponentenscherm op de knop “nieuw” - selecteer “meldingen” als component - geef de component een naam; deze dient als identificatie voor de casusontwikkelaar bij het invoeren van scripts - selecteer een casusontwikkelaar die straks de inhoud gaat vullen - selecteer de PC’s die deze casuscomponent zullen zien - de componentnaam is niet van belang voor de PC’s, want die wordt nergens zichtbaar in de player klik op de knop “inhoud” achter de nieuw gedefinieerde meldingencomponent in het casecomponentvenster -> meldingeninvoervenster verschijnt; voer de meldingen in: - rechtermuisknopklik op “root” -> “nieuw op subniveau” -> “nieuwe melding” => popup-invoervenster voor de meldingen verschijnt - Id: de identificatie voor de ontwikkelaar in de Scriptcomponent - Modaal venster: VEROUDERDE PARAMETER, wordt niet meer gebruikt - Tekst: de meldinginhoud - Toelichting: geheugensteun voor de casusontwikkelaar Scriptcomponent Nu we alle andere Emergo componenten hebben behandeld zijn we toe aan de scriptcomponent. Dit is de ingewikkeldste van allemaal. Maakt casus dynamisch De scriptcomponent is bedoeld om een casus dynamisch te maken. Met de casuscomponenten die we tot nu toe hebben behandeld kunnen we alleen een statische casus maken. De casus zal zich altijd op dezelfde manier aan de student tonen en zal niet veranderen zolang de student ermee bezig is. Dit betekent dat Emergo altijd dezelfde content, die door jullie is ingevoerd, zal aanbieden. De content kan natuurlijk wel worden gewijzigd door andere casusdeelnemers, bijv. doordat een ander een e-bericht naar jou verstuurt, of een (Google maps) bron toevoegt. Algemeen toepasbaar De scriptcomponent kan opereren op alle andere componenten, en op zichzelf. En de enige component die totaal afhankelijk is van de scriptcomponent is de meldingen component. Vele mogelijkheden Met de scriptcomponent we er bijvoorbeeld voor zorgen dat: We kunnen bijv. pas bepaalde documenten beschikbaar stellen na verloop van tijd of na een bepaalde acties van de student. Of we kunnen ervoor zorgen dat in de loop van de tijd andere gesprekken in bepaalde locaties


44

kunnen worden gevoerd. Of we kunnen voorgedefinieerde e-berichten versturen of een melding tonen na verloop van tijd of na bepaalde acties van de student. Of we kunnen bepaalde componenten pas later beschikbaar stellen. Condities Het script dat ingevoerd wordt bestaat uit condities en per conditie een of meerdere acties. Een voorbeeld van een conditie is: Heeft de student de locatie Westerschelde bezocht? Heel belangrijk om te beseffen is dat condities meermaals kunnen afgaan. De conditie zal dus elke keer afgaan als locatie Westerschelde wordt bezocht. Later vertel ik hoe je ervoor kunt zorgen dat de conditie maar 1 maal afgaat. Ook heel belangrijk is om te beseffen dat condities niet continu worden gecheckt, maar pas worden gecheckt nadat ze getriggerd worden door een statusverandering, bijv. door een bepaalde gebruikersactie of verandering van de tijd. Acties Als een conditie waar is zullen de bijbehorende acties worden uitgevoerd. Een voorbeeld van een actie is: Stel de map Westerschelde in de bronnencomponent ter beschikking van de student. Timers Een afwijkend type actie is het instellen van een timer. Een timer zou bijv. na 5 minuten kunnen afgaan. Het afgaan van de timer wordt weer gecheckt mbv een conditie, zodat na 5 minuten bepaalde acties kunnen worden uitgevoerd. Je zou de map Westerschelde pas beschikbaar kunnen stellen 5 minuten nadat de student locatie Westerschelde heeft bezocht. (Laat scriptcomponent van demonstrator zien voor opbouw van condities, acties en timers) Het aanmaken van de scriptcomponent We voegen de component toe op de bekende manier. We kiezen voor ‘scripts’, geven een naam en gaan de inhoud vullen. Er kunnen meerdere scriptcomponenten per casus worden gedefinieerd. Handig voor het opdelen van script. We zien weer de bekende opties. (Beschikbaar is niet relevant, zal nog worden verwijderd). En gaan een conditie toevoegen. Toevoegen van een conditie We voegen de conditie toe door op de bekende manier met de rechtermuisknop te klikken op root. Ook hier moeten we weer een id toevoegen. Dit is vooral voor ons zelf relevant, zodat we het script kunnen lezen, zonder de condities of acties te hoeven openen in dit dialoogvenster. Ik wil checken of de student locatie Westerschelde, 1 maal heeft bezocht. We zien weer het bekende toelichting veld. Verder valt op dat we aanwezig van de conditie uit en aan kunnen zetten (doe). Als we uitvinken betekent dit dat de conditie nooit zal afgaan, totdat deze dmv een actie op aanwezig wordt gezet. Dus zelfs condities en acties kunnen onderdeel van scriptregels vormen. Nu volgt het moeilijkste onderdeel. We gaan de conditie opbouwen. Dit doen we door weer met de rechtermuisknop op root te klikken (doe). We zien nu een aantal opties. De onderste vijf zijn het makkelijkste. Ze zijn bedoeld om samengestelde condities te kunnen maken mbv van logische operatoren en haakjes. Ik zal dit nu niet laten zien. De eerste optie, ‘nieuwe inhoudstatustest’, is bedoeld om de status van een onderdeel van casuscomponent te kunnen testen. Bijv. of een bepaalde bron door de student is geopend. De tweede optie ‘nieuwe componentstatustest’, is bedoeld om de status van een casuscomponent zelf testen. Bijv. of de bronnentool zelf door de student is geopend. Ik zal nu alleen de eerste optie laten zien. De tweede optie is een vereenvoudigde vorm van de eerste optie (klik). We moeten nu eerst de component kiezen waarvan we de inhoud willen checken. We kiezen voor locaties want willen weten of een bepaalde locatie is bezocht (doe). Vervolgens zien we alle casusrollen (pc’s). Ze zijn default allemaal aangevinkt. Dit betekent dat de conditie zal kunnen afgaan voor alle casusrollen. Wil je dat de conditie alleen voor bepaalde casusrollen relevant is, dan moet je er een aantal uitvinken. We moeten ook het inhoudtype kiezen. Een component zal verschillende inhoudtypes kennen. Voor de locatiecomponent zijn dat locatie en achtergrond, zoals we vorige keer hebben gezien (klik open). We willen de locatie checken dus kiezen voor locatie. We zien nu alle locaties die we hebben ingevoerd en kiezen voor locatie Westerschelde (doe). We kunnen meerdere locaties selecteren. Dit betekent dan dat meerdere locaties geopend moeten zijn. De conditie wordt dan getriggerd als 1 van de locaties wordt geopend. We kunnen ook de statusparameter kiezen (klik) en zien een lijstje met parameters die we voor de locatie kunnen checken. We kunnen checken of de toegankelijk, aanwezig, geselecteerd of geopend


45

status van de locatie wijzigt. We kiezen voor geopend, omdat we willen weten of locatie 1 geopend is (doe). De betekenis van de andere opties vinden jullie terug in de handleiding. (Toegankelijk en aanwezig hebben we al eerder gezien. Deze parameters kunnen niet door de student worden gezet, maar wel doordat andere condities afgaan. Geselecteerd betekent dat de student de locatie heeft geselecteerd, dwz op de deur heeft geklikt. Geopend betekent dat de locatie is geopend, dwz de foto wordt getoond. Er kan altijd maar 1 locatie geopend zijn, dus als van 1 locatie geopend true wordt, wordt geopend van de andere locaties op false gezet. Nu kunnen we drie zaken kiezen: functie, operator en statuswaarde. We kijken eerst naar operator (klik). Er is maar 1 operator, namelijk ‘is gelijk’. Dit komt omdat geopend maar twee toestanden kan hebben: true of false. Dat zien we omdat we maar twee statuswaarden kunnen kiezen (laat zien). De default waarde is false. Als we true kiezen, kunnen we checken of locatie Westerschelde ooit geopend wordt. Kiezen we nu voor functie ‘aantal’ dan zien we dat het aantal operatoren groter is (laat zien). We kunnen dan checken of het aantal maal dat locatie Westerschelde geopend wordt gelijk is aan een bepaalde waarde, groter of kleiner is, in een interval zit of in een bepaalde verzameling. We kiezen voor ‘is gelijk’ omdat we willen checken of locatie Westerschelde, 1 maal geopend is (doe). En dus vullen we voor de statuswaarde 1 in (doe). Als ik op ok klik, wordt de invoer in een leesbaar format getoond. Door er met de rechtermuisknop op te klikken kan hij worden gewijzigd of verwijderd. We klikken op ok en de conditie wordt bewaard. Zijn hierover vragen? Toevoegen van een actie Nu kunnen we acties toevoegen aan de conditie door met de rechtermuisknop op de conditie te klikken (doe). We zien ook dat we een subconditie kunnen toevoegen. Het toevoegen van een timer behandel ik later. De bestaande conditie kan natuurlijk ook worden aangepast of verwijderd. Kiezen we voor ‘nieuwe actie’ dan krijgen we een vergelijkbaar scherm als voor een conditie. Ook de actie krijgt een id en kan wel of niet aanwezig zijn. We kiezen ervoor om een map in de bronnentool beschikbaar te stellen aan de student (typ in). Klikken we wederom met de rechtermuisknop op ‘root’, dan zien we maar twee opties. De logische operatoren ontbreken, want zijn niet relevant. Er kunnen namelijk meerdere acties per conditie worden toegevoegd. De eerste optie, ‘nieuwe inhoudstatusaanpassing’, is bedoeld om de status van een onderdeel van de casuscomponent aan te passen. Bijv. of een bepaalde bron voor de student beschikbaar komt. De tweede optie ‘nieuwe componentstatusaanpassing’, is bedoeld om de status van een casuscomponent zelf aan te passen. Bijv. of de bronnentool voor de student beschikbaar komt. Ik zal nu alleen de eerste optie laten zien. De tweede optie is een vereenvoudigde vorm van de eerste optie (klik). We moeten nu eerst de component kiezen waarvan we de inhoud willen aanpassen. We kiezen voor bronnen want willen een map in de bronnen beschikbaar stellen (doe). Vervolgens zien we alle casusrollen (pc’s). Ze zijn default allemaal aangevinkt. Dit betekent dat de actie zal worden uitgevoerd voor alle casusrollen. Wil je dat de actie alleen voor bepaalde casusrollen relevant is, dan moet je er een aantal uitvinken. We moeten ook het inhoudtype kiezen. Een component zal verschillende inhoudtypes kennen. Voor de bronnencomponent zijn dat map en bron (klik open). We willen een map beschikbaar stellen dus kiezen voor map. We zien nu alle mappen die we hebben ingevoerd en kiezen voor Westerschelde (doe). Als we ook Oosterschelde selecteren, betekent dit dat beide mappen beschikbaar worden gesteld. We kunnen ook de statusparameter kiezen (klik) en zien een lijstje met parameters die we voor de map kunnen aanpassen. We kiezen voor beschikbaar, omdat we de map beschikbaar willen stellen (doe). De betekenis van de andere opties vinden jullie terug in de handleiding. Nu kunnen we alleen nog de statuswaarde kiezen: true of false (laat zien). Kies true. Als ik op ok klik, wordt de invoer in een leesbaar format getoond. Door er met de rechtermuisknop op te klikken kan hij worden gewijzigd of verwijderd. We klikken op ok en de actie wordt bewaard. Zijn hierover vragen? Toevoegen van een timer We voegen een timer actie toe door met de rechtermuisknop op de conditie te klikken. Ook de timer krijgt een id (doe). We voeren de duur in, bijv. 3600 seconden, een uur (doe). Dit betekent dat de timer 1 uur zal afgaan nadat de bijbehorende conditie is afgegaan. We hebben het dan wel over casustijd, dwz tijd dat de Emergo player voor die student geopend was. Stopt de student bijv. een half uur nadat de conditie is afgegaan en gaat hij de volgende dat weer verder, dan duurt het nog een half uur voordat de timer afgaat. Als we ‘realtime’ aanvinken (doe) geldt de duur als reele tijd vanaf de start van de run, dus niet vanaf het moment dat de conditie afging. Ook loopt de tijd door als de speler niet is opgestart. Stel de run begint vanmiddag om 16 uur en de student start de speler om 18 uur. Dan zal de timer meteen afgaan.


46

Een timer kan ook herhalend zijn. Dat betekent dat hij elk uur zal afgaan. We kunnen dan ook het aantal herhalingen instellen. Ook een timer kan wel of niet aanwezig zijn. Het afgaan van een timer wordt gecheckt dmv een conditie. Klik op ok. Zijn hierover vragen? Demonstrator In demonstrator zien we hoe script de aangeboden content wijzigt.


47

Standaard draaiboek voor docentprofessionalisering

Recommend Documents