EMERGO Deliverable 5.3b: Documentatie toolkit (tweede versie)

Transcriptie

1 EMERGO Deliverable 5.3b: Documentatie toolkit (tweede versie) Auteurs: Aad Slootmaker, Hub Kurvers Penvoerende instelling: Open Universiteit Nederland - Onderwijstechnologisch Expertisecentrum - Faculteit Psychologie - Faculteit Natuurwetenschappen - Ruud de Moor Centrum Partner instellingen: Universiteit Maastricht, Faculteit Psychologie Radboud Universiteit, Faculteit Managementwetenschappen Universiteit Utrecht, Faculteit Geowetenschappen Datum: 30 juni 2007 Versie: 1.0 Kenmerk: U2007/4143 Onderwijstechnologisch expertisecentrum OUN EMERGO, Open Universiteit Nederland

2 1. Introductie 3 2. Gebruikersinterface invoerdeel Rollen in EMERGO De EMERGO-beheerder-rol Beheren van accounts Beheren van componenten Beheren van casussen De casusontwikkelaar-rol Definiëren van casussen Van component tot casuscomponent Vullen van een casuscomponent De case run manager-rol Case runs beheren Case run members selecteren De docent-rol De student-rol Componenten Stukken Case Empack Gesprekken Locaties Scripts Berichten Meldingen Taken Personen Items Toetsen Samenvatting.. 58 EMERGO, Open Universiteit Nederland 2

3 1. Introductie Dit document is een definitieve beschrijving van de toolkit van EMERGO. In Deliverable 5.3a (maart 2007) werd de toolkit voorlopig en gedeeltelijk beschreven. De toolkit is het geheel aan componenten waaruit EMERGO bestaat. Beheerders van een EMERGO-omgeving kunnen in dit document lezen hoe ze gebruikersaccounts en componenten moeten invoeren, wijzigen en verwijderen. Casusontwikkelaars lezen hier hoe ze casussen kunnen beheren, en afzonderlijke componenten aan een casus kunnen toevoegen of uit een casus kunnen verwijderen. Ook vinden ze hier hoe ze de afzonderlijke componenten met casusspecifieke inhoud kunnen vullen. De toolkitspecificaties zijn vastgelegd in het functionele ontwerp (deliverable 1.3) en meer in het bijzonder in het technisch ontwerp (deliverable 5.2). De toolkit is ontwikkeld met behulp van technologieën die beschreven zijn in deliverable 5.1. De ontwikkeling van componenten is gericht op het zo snel mogelijk kunnen aanbieden van basisfunctionaliteit voor het inbouwen van casussen. Dit betekent dat componenten die niet direct noodzakelijk zijn bij invoeren en afspelen van casussen pas in een later stadium aan EMERGO worden toegevoegd. Een aantal aanvullende onderdelen, beschreven in deliverables 1.3 en 5.2, zullen dan ook op zijn vroegst pas in de opschalingsfase worden ingebouwd, en kunnen hier nog niet worden beschreven. Het gaat met name om de volgende onderdelen: Een uitgebreid voorportaal in de afspeelomgeving. Hier kunnen case run members niet alleen de case run kiezen die ze willen starten, maar ze beschikken ook over hulpmiddelen voor communicatie met andere case run members (forum, chat, mail), ze kunnen overzichten opvragen van hun vorderingen in de verschillende case runs, ze kunnen algemene, eventueel instituut- of cursusafhankelijke EMERGO-nieuwsberichten lezen, etc. De mogelijkheid om instituten en cursussen te onderscheiden. Casussen behoren bij cursussen, en cursussen bij een instituut. Elk instituut heeft zijn eigen EMERGObeheerder, en elke beheerder kan gebruikers en gebruikersrollen per instituut toevoegen. Een aantal tools. Met name Docenttool, Studenttool en Eventtool zullen voorlopig niet worden ingebouwd. In deliverable 1.3 (en ook in de methodiekbeschrijving, deliverable 1.4) wordt onderscheid gemaakt tussen invoercomponenten of ontwerptools en afspeelomgeving-componenten. In deze beschrijving leggen we de nadruk op de technische implementatie. Een component is dan de implementatie van een bepaalde functionaliteit, door middel van een stuk programmacode, dat gecombineerd wordt met een hoeveelheid gegevens of kenmerken. Hoe de component zich manifesteert aan de gebruiker hangt af van de rechten van die gebruiker. Door middel van zijn view op een component (we reserveren het begrip player voor de manifestatie van de component aan case run members) heeft een gebruiker de mogelijkheid bepaalde variabele gegevens en/of kenmerken te wijzigen. Zo bepaalt een EMERGO-beheerder in zijn invoerscherm onder andere uit welke elementen een component kan bestaan, en welke statuswaarden de component en zijn elementen kunnen aannemen. Een EMERGO-casusontwikkelaar kiest uit de door de beheerder gedefinieerde componenten die componenten die in zijn casus een rol spelen, en vult de componenten met elementen en initiële statusgegevens. In de afspeelomgeving kan een docent over andere EMERGO, Open Universiteit Nederland 3

4 deelfunctionaliteiten beschikken dan een student, en zal hij andere statusparameters beïnvloeden. In hoofdstuk 3 gaan we nader in op de mogelijkheden per rol. Bij het beschrijven van de componenten gebruiken we in het vervolg de namen zoals die op moment van schrijven door de EMERGO-beheerder zijn ingevoerd. Deze namen kunnen afwijken van de namen die gebruikt zijn in deliverables 3.1 en 4.1. In 3.1 en 4.1 is bij de benaming uitgegaan van ontwerp -componenten en afspeelcomponenten, de huidige beheerderbenamingen zijn gebaseerd op de elementen die gemaakt en getoond kunnen worden met de component. Momenteel bevat de toolkit de volgende componenten (tussen haakjes, indien afwijkend, de benaming zoals gebruikt in 3.1 en 4.1): stukken (bronnenontwerp) gesprekken (gespreksontwerp) empack (empackontwerp) locaties (locatieontwerp) case scripts (scripting) berichten (berichtenontwerp) meldingen taken (taakontwerp) personen items (itembank) toetsen (toetsontwerp) In hoofdstuk 4 zullen we de componenten gedetailleerd beschrijven. Tenslotte: zoals gemeld is EMERGO momenteel nog volop in ontwikkeling. Dit betekent dat de lezer er rekening mee moet houden dat de in dit document opgenomen afbeeldingen en de gebruikte terminologie kunnen verschillen met de meest recente EMERGO-versie. EMERGO, Open Universiteit Nederland 4

5 2. Gebruikersinterface invoerdeel Voordat we de invoerfunctionaliteit nader gaan bespreken willen we eerst enkele opmerkingen maken over de manier waarop een invoerder of beheerder met EMERGO communiceert. EMERGO is een webapplicatie. Dat betekent dat een gebruiker eerst een Internet-browser moet starten, en vervolgens naar de EMERGO-site moet navigeren. In principe zou elke Internet-browser geschikt moeten zijn. EMERGO is tijdens het ontwikkelen voortdurend getest met Internet Explorer en Mozilla Firefox, de twee momenteel meest gangbare browsers. Binnen EMERGO is er steeds één hoofdinvoervenster zichtbaar met gegevens en interactiestarters ( knoppen ) die betrekking hebben op het deelfunctionaliteitsniveau waarmee de gebruiker op dat moment bezig is. Wil de gebruiker terug naar een eerder ( hoger ) niveau, dan moet hij de terugknop -functionaliteit van zijn browser gebuiken. Een volgend ( dieper ) niveau van functionaliteit bereikt de gebruiker meestal door op een startknop te klikken (ook het selecteren van een item uit een lijst beschouwen we als het klikken op een startknop), waarna de inhoud van het venster vervangen wordt. Aanpassing van de gegevens behorende bij het huidige niveau gebeurt in principe door met de rechtermuisknop op de betreffende gegevens te klikken. Er verschijnt dan een popupmenu, met menuitems als nieuw, wijzig, verwijder. Bij elk van deze keuzes wordt bovenop het browservenster een nieuw popupvenster zichtbaar, modal, hetgeen inhoudt dat het browserhoofdvenster dan niet meer reageert op muis- of toetsenbordactiviteiten. Als gekozen is voor nieuw of wijzig bevat dit popupvenster een invulformulier, met velden voor tekst, keuzelijsten, etc. Als gekozen is voor verwijder moet alleen de vraag naar zeker weten bevestigend dan wel ontkennend worden beantwoord. De gegevens worden indien mogelijk in een boomvormige structuur ( tree ) gepresenteerd. Als er meerdere typen gegevens zijn (bijvoorbeeld in de bronnentool -component, waar het gaat om bestanden die zich in mappen en submappen kunnen bevinden) wordt het type aangegeven met behulp van ikonen. Gegevens zijn met de muis te verslepen naar andere knooppunten in de tree, mits die knooppunten gegevens van hetzelfde type accepteren. Wordt de Ctrl -toets ingedrukt tijdens het loslaten van de muisknop, dan wordt er op de plaats van loslaten een kopie gemaakt van het gegeven, anders wordt het gegeven verplaatst. Wordt het gegeven losgelaten boven een map -knooppunt, dan wordt in die map een nieuw knooppunt gemaakt met het gegeven. In andere gevallen wordt het gegeven toegevoegd vóór het knooppunt waarboven het wordt losgelaten, in dezelfde map. Wanneer er geen sprake is van hierarchische niveaus, en een gegeven uit meerdere elementen bestaat, ligt het meer voor de hand de gegevens onder elkaar in een lijst te tonen, waarbij elk element in een afzonderlijke kolom staat. Kolom koppen zijn dan te gebruiken om gegevens elementafhankelijk te sorteren, hetgeen de overzicht- en zoekmogelijkheden vergroot. Een voorbeeld zijn de gebruikersgegevens, die onder andere een gebruikersid, een wachtwoord en rolinformatie bevatten. Middels rolkolom-sortering kunnen we dan bijvoorbeeld snel alle casusontwikkelaars vinden. In een aantal gevallen kan een invoerder een indruk krijgen van de manier waarop een student tijdens een case run de ingevoerde gegevens te zien krijgt. Hij kan zo testen of het onderdeel waarmee hij op dat moment bezig is foutloos werkt en conform zijn bedoelingen overkomt. Die zogenaamde preview wordt geïnitieerd door middel van een extra rechtermuisklik-popupmenu-optie, de preview -optie. EMERGO, Open Universiteit Nederland 5

6 3. Rollen in EMERGO De functionaliteit die is ingebouwd in EMERGO is verdeeld over een aantal rollen. Elke gebruiker die toegang heeft tot EMERGO is gekoppeld aan minimaal 1 rol. Bij het starten van de EMERGOwebsite krijgt hij eerst een aanmeldscherm te zien. Hij moet inloggen met een gebruikersid en een wachtwoord. Als die combinatie te vinden is in de database zal het programma vervolgens een venster tonen dat past bij de rol die de gebruiker binnen EMERGO heeft. Heeft hij meerdere rollen, dan moet hij eerst kiezen welke rol hij in deze EMERGO-sessie wil hebben. De volgende rollen zijn momenteel gedefinieerd: EMERGO-beheerder casusontwikkelaar case run manager docent student We zullen de functionaliteit die bij elk van deze rollen hoort nu meer in detail beschrijven. Omdat dit document betrekking heeft op de EMERGO-toolkit zullen we hierbij de rollen die bij de invoer van casussen een rol spelen benadrukken. Het gaat dan om de EMERGO-beheerder, de casusontwikkelaar en de case run manager. 3.1 DE EMERGO-BEHEERDER-ROL Bij installatie van EMERGO wordt automatisch één gebruikersaccount gemaakt, het zogenaamde EMERGO-beheerder-account (in de toolkit aangeduid als admin en administrator ). Iemand die met deze accountgegevens inlogt krijgt de beschikking over de beheerdersfunctionaliteit die gekoppeld is aan deze EMERGO-beheerder-rol. In het eerste EMERGO-beheerder-venster moet de gebruiker kiezen wat hij wil beheren: accounts componenten casussen Selecteert de gebruiker één van deze beheerstaken dan wordt de inhoud van het venster vervangen door gegevens en knoppen die specifiek zijn voor die taak Beheren van accounts In het accounts-venster kan de beheerder nieuwe gebruikersaccounts toevoegen, en bestaande accounts aanpassen of verwijderen. Een nieuw account toevoegen Als de beheerder op de knop nieuw klikt dan verschijnt een modal venster met een invulformulier (zie Figuur 1). EMERGO, Open Universiteit Nederland 6

7 Figuur 1. Invoer van een nieuw gebruikersaccount. De EMERGO-beheerder kan de volgende gegevens invoeren: Gebruikersid invoer van tekst, één regel Wachtwoord invoer van tekst, één regel Titel invoer van tekst, één regel Initialen invoer van tekst, één regel Tussenvoegsel invoer van tekst, één regel Achternaam invoer van tekst, één regel Actief aanvinkknop EMERGO-beheerder ( Administrator ) aanvinkknop Casusontwikkelaar ( Case developer ) aanvinkknop Case run manager aanvinkknop Docent ( Tutor ) aanvinkknop Student aanvinkknop Gebruikersid en Wachtwoord moet een gebruiker invoeren tijdens het inloggen. Titel, Initialen, Tussenvoegsel en Achternaam krijgt hij als gebruikersgegevens na inloggen te zien in het EMERGO, Open Universiteit Nederland 7

8 EMERGO-hoofdvenster. De Actief-knop moet aangevinkt zijn wil de gebruiker daadwerkelijk toegang krijgen tot EMERGO. Door een bestaande gebruikersaccount op nonactief te zetten kan een EMERGO-beheerder een gebruiker de toegang tot EMERGO ontzeggen terwijl zijn gegevens nog wel bewaard blijven. De resterende aanvinkknoppen bepalen de rol(len) die de gebruiker kan aannemen binnen EMERGO. Voor deze accountgegevens gelden de volgende restricties: gebruikersid-veld, wachtwoord-veld en achternaam-veld mogen niet leeg zijn gebruikersid moet uniek zijn, dus het mag niet al bij een ander account gebruikt zijn tenminste één van de knoppen EMERGO-beheerder, Casusontwikkelaar, Case run manager, Docent en Student moet worden aangevinkt Een bestaand account wijzigen De beheerder selecteert eerst een account in de lijst. Vervolgens klikt hij op de knop edit. Hij krijgt dan hetzelfde popupvenster te zien als wanneer hij een nieuw account toevoegt (Figuur 1), nu uiteraard ingevuld met de gegevens van het te wijzigen account. Alle gegevens zijn wijzigbaar. En er gelden dezelfde restricties als bij invoer van een nieuw account. Een bestaand account verwijderen De beheerder selecteert eerst een account in de lijst. Dan klikt hij op de knop verwijder. In een popupvenster komt de vraag of er echt moet worden verwijderd. De beheerder klikt op ok Beheren van componenten In het componentenvenster kan een beheerder nieuwe componenten toevoegen, en bestaande componenten aanpassen of verwijderen. Met toevoegen van een component bedoelen we hier het invoeren van een aantal eigenschappen van de component. De invoeromgeving behorende bij die component die een casusontwikkelaar te zien krijgt wordt volledig en automatisch afgeleid uit deze eigenschappen. De EMERGO-beheerder ontwerpt dus als het ware de component-ontwerptool waarmee de casusontwikkelaar aan de slag gaat. De eigenschappen en de casusontwikkelaar-invoer zijn daarentegen vooralsnog niet voldoende om automatisch de afspeelomgeving te kunnen genereren. Voor elke nieuw toegevoegde component moet een programmeur de code leveren waarmee het afspelen zal plaatsvinden. Figuur 2. Invoer van een component door de EMERGO-beheerder. EMERGO, Open Universiteit Nederland 8

9 Een nieuwe component toevoegen Als de beheerder op de knop nieuw klikt dan verschijnt een modal venster met een invulformulier (Figuur 2). De componentdefinitie moet de volgende gegevens bevatten: Ouder ofwel geen ofwel een keuze van een component uit de lijst van al ingevoerde componenten; geen staat voorgeselecteerd Code invoer van tekst, één regel; mag niet leeg zijn Naam invoer van tekst, één regel; mag niet leeg zijn Type keuze uit systeemcomponent of functionele component ; functionele component staat voorgeselecteerd XML-definitie invoer van tekst, onbeperkt Versie invoer van tekst, geheel getal; mag niet leeg zijn Meervoudig aanvinkknop Actief aanvinkknop De EMERGO-beheerder identificeert een component door middel van een code, en daaraanvast koppelt hij een naam. De code wordt door het programma gebruikt om elke component te identificeren en tijdens een case run de bijbehorende afspeelfunctionaliteit in werking te zetten. Een beheerder kan de code dus niet zo maar willekeurig kiezen. Hij moet goed weten welke code bij welke afspeelfunctionaliteit hoort. De naam moet, in combinatie met het versienummer, uniek zijn. Deze configuratie maakt het mogelijk om meerdere componenten te definiëren die gebaseerd zijn op dezelfde code, maar van verschillende versies. De oude versies zijn dan bijvoorbeeld gedeactiveerd en niet meer te selecteren voor nieuwe casussen, maar alle eraan gekoppelde statusinformatie blijft in het systeem bewaard. De naam is vooral bedoeld voor de casusontwikkelaar. Die ziet de naam in zijn componentenkeuzelijst. Voor een goede werking van de applicatie is het, zoals beschreven, van belang dat van een bestaande component de code niet meer verandert. De naam daarentegen mag gewijzigd worden. Zo kan in de toekomst bijvoorbeeld meertaligheid worden geïmplementeerd. We onderscheiden twee typen componenten: systeemcomponenten en functionele componenten. Systeemcomponenten zijn niet direct zichtbaar voor de student, het is geen gereedschap waarmee hij iets kan doen. Ze zijn echter nodig, en wel in elke casus, om de algemene, universele eigenschappen en functionaliteiten van een casus te representeren. Momenteel is er één systeemcomponent, de case-component. Hij houdt onder andere bij wanneer en hoe vaak een student de casus heeft gestart, en hoelang hij bezig is geweest per sessie. Deze statusinformatie kan een casusontwikkelaar gebruiken om de casus ruimte van de student te beïnvloeden. Waarbij we dan met casusruimte bedoelen zowel de virtuele omgeving die de student te zien krijgt als de bewegingsvrijheid van die student binnen de virtuele omgeving. Een andere functie van de case-component is de opslag van relaties tussen componenten. Zo kan in EMERGO, Open Universiteit Nederland 9

10 condities die gebouwd zijn met behulp van de scripting-component statusinformatie van meerdere andere componenten een rol spelen. In de case-component bevindt zich nu een tabel waarin voor alle componentelementen verwijzingen staan naar de scripting-condities waarin ze voorkomen. Zo kunnen we gemakkelijk aan een casusontwikkelaar laten weten wat er nog meer moet gebeuren als hij een componentelement wijzigt of verwijdert. Functionele componenten zijn componenten die door een casusontwikkelaar gekozen kunnen worden als onderdeel van een casus, maar die niet direct noodzakelijk zijn. Elke zinvolle casus zal wel altijd bestaan uit minstens één functionele component. De meeste functionele componenten hebben een case run-afspeelgedeelte (in het vervolg zullen we hiervoor de benaming speler gebruiken), dat ervoor zorgt dat de door de casusontwikkelaar ingevoerde inhoud zichtbaar wordt voor de student. Hoe die inhoud zichtbaar wordt ligt vast in de programmacode van de speler, wanneer welk deel van de inhoud zichtbaar wordt bepaalt de casusontwikkelaar, door het conditioneel zetten van statuswaarden. Een functionele component die niet direct in de afspeelomgeving zichtbaar is, is de scripts-component. Hiermee kan een casusontwikkelaar definiëren hoe in een case run de inhoud van de aanwezige componentspelers verandert als gevolg van statusveranderingen (die bijvoorbeeld worden geïnitieerd door gebruikersacties of timeralarm). De scripts-component is dus bij uitstek een ontwerpcomponent, een hulpmiddel voor de casusontwikkelaar om het casusverloop te structureren. Elke functionele component kan een andere functionele component als ouder-component hebben. Heeft een component een functionele oudercomponent, dan is hij in een case run alleen mogelijk aanwezig als de oudercomponent zichtbaar is. Een student start zo n component dan met behulp van een ikoon dat zich bevindt in het functionele gebied van de oudercomponent. Momenteel zijn er drie functionele componenten die als oudercomponent fungeren: de empackcomponent, de locatiescomponent en de toetsencomponent. Selecteert de casusontwikkelaar in zijn casus een component die een van deze componenten als ouder heeft, dan moet hij ook die oudercomponent aan de casus toevoegen. Empack en locaties hebben zelf geen functionele oudercomponent. Elke functionele component zonder oudercomponent, maar wel met een speler in de case run, krijgt automatisch de case-component als ouder. Hetgeen eenvoudig betekent dat als de case-component niet mag worden geopend, een case run niet kan worden gestart. De XML-definitie definieert de invoerbare inhoud van de component en de verschillende statusparameters. De definitie moet resulteren in valide XML. Deze definitie wordt rechtstreeks omgezet naar een invoerscherm dat de casusontwikkelaar moet gebruiken om de component te vullen. De inhoud wordt gedefinieerd in de vorm van een boomstructuur of tree. Elke tak van de boom representeert een inhoudselement van een bepaald type. Dit inhoudselement heeft eigenschappen ( attributes ) en kan weer subtakken bevatten met andere inhoudselementen van hetzelfde of een ander type. Die attributes zijn bijvoorbeeld het datatype van het element, de statusparameters die voor dit element van belang zijn en hun default waarden, de statusparameters die door de casusontwikkelaar als initiële waarden kunnen worden ingesteld, en een parameter die bepaalt of het element in een preview kan worden bekeken. Als voorbeeld van een XML-definitie volgt hier de definitie van de stukkencomponent: EMERGO, Open Universiteit Nederland 10

11 <?xml version="1.0" encoding="iso "?> <data> <component type="root"> <initialstatus attributes="present,accessable"/> <status present="true" accessable="true" selected="false" opened="false" status=""/> </component> <content type="root" childnodes="map,piece" maxid="" preview="true"> <map id="" type="node" childnodes="map,piece" key="name"> <name type="line"/> <initialstatus attributes="present,outfolded"/> <status present="true" outfolded="false" outfoldable="true" selected="false" opened="false" status=""/> </map> <piece id="" type="node" childnodes="" key="name"> <name type="line"/> <blob type="blob" blobtypes="database,int_url,ext_url" mediatypes="text,picture,audio,video,other" blobtype="" mediatype=""/> <initialstatus attributes="present"/> <status present="true" selected="false" opened="false" finished="false" status=""/> </piece> <refpiece id="" type="ref" refnode="piece"> <xmlref type="xml"/> <initialstatus attributes="present"/> <status present="true" selected="false" opened="false" finished="false" status=""/> </refpiece> </content> </data> Alle relevante informatie moet worden opgenomen binnen een <data>-tag. Als basis voor de data-informatie moet de beheerder twee tags definiëren binnen de <data>-tag: een <component>-tag en een <content>-tag, beide van het type root om aan te geven dat ze de basis in de XML-boom vormen voor alle bijbehorende informatie. De <component>-tag bevat statusparametergegevens die betrekking hebben op de component in zijn totaliteit. Een beheerder legt de statusparameters vast met behulp van de tags <status>, met als elementen de namen van de parameters plus eventueel hun default initiële waarden, en <initialstatus>, die een attributes -element heeft, dat als waarde een lijst van in <status> vastgelegde parameternamen heeft. De in <initialstatus> genoemde parameters zijn door een casusontwikkelaar in het algemene casuscomponentinvoerscherm in te stellen. De casusontwikkelaar heeft op die manier voor die parameters de mogelijkheid de default initiële waarden aan te passen. In de <content>-tag kan de beheerder in het attribuut childnodes een lijst van elementnamen opnemen van de objecten die op root -niveau deel uitmaken van de component. De stukkencomponent heeft dus map - en piece -objecten. Verder heeft de <content>-tag altijd een maxid -attribuut, dat voor de beheerder niet van belang is, maar door het programma wordt gebruikt om bij te houden hoeveel elementen een casusontwikkelaar heeft toegevoegd aan de casuscomponent. Ook is er mogelijk een preview -attribuut, dat aangeeft dat een ontwikkelaar zijn invoer kan testen. Vervolgens moet de beheerder alle in het <content>-childnodes-attribuut genoemde objecten verder gaan definiëren. Ze moeten een type -attribuut hebben (meestal node, of object dat als knooppunt in het netwerk kan worden gezien, maar soms ook ref, of verwijzing naar een ander object), en ze kunnen zelf ook weer kinderen hebben, waarvan de namen genoemd staan in het childnodes -attribuut, en die voor zover het om nieuwe objecten gaat op hun beurt binnen de <content>-tag moeten worden gedefinieerd. Het id -attribuut gebruikt het programma om een element een binnen de casuscomponent unieke identificatie te geven. In het key -attribuut moet de beheerder aangeven welk attribuut of welke tag (naast het id -attribuut) uniek moet zijn voor de elementen bij een knooppunt. Zo mag de <name>-tag van een stuk in een stukkencasuscomponent niet dezelfde waarde hebben als de <name>-tag van een ander stuk in dezelfde map. EMERGO, Open Universiteit Nederland 11

12 De beheerder ook aan de childnode-objecten een <status>- en een <initialstatus>-tag geven. Verder kunnen de childnodes componentspecifieke tags bevatten. Door een type -attribuut te vullen met een waarde die door het programma herkend wordt kan de beheerder ervoor zorgen dat het programma in de casuscomponentinvoer automatisch een geschikt invoerobject genereert voor zo n componentspecifieke tag. Het programma herkent onder andere de types node, ref, blob, xml, line, simplerichtext, boolean. In sommige gevallen, bijvoorbeeld bij blob en ref, moet het type nog nader worden gespecificeerd. Als meervoudig is ingeschakeld betekent dit dat een casusontwikkelaar de mogelijkheid heeft verschillende versies van een component aan zijn casus toe te voegen. Momenteel zijn de case-, de locaties-, de empack-, de berichten- en de taken-component niet meervoudig, de andere componenten wel. Die andere componenten zijn òfwel componenten waarvan te verwachten is dat ze voor verschillende functionaliteiten gebruikt kunnen worden (de stukkencomponent kan bijvoorbeeld gebruikt worden om bronnen te tonen en om een casusdossier bij te houden), òfwel componenten waarin mogelijk grote hoeveelheden informatie moeten worden ingevoerd, zodat een opsplitsing een overzichtelijker structuur geeft, en de mogelijkheid biedt om de invoer te verdelen over meerdere casusontwikkelaars (er is dan in de casus bijvoorbeeld een interviews met deskundige X -gesprekkencomponent, die door casusontwikkelaar A gevuld moet worden, en een interviews met deskundige Y -gesprekkencomponent, waarvan casusontwikkelaar B de invoerder is). Door een component op nonactief te zetten zorgt een EMERGO-beheerder ervoor dat een casusontwikkelaar die component niet meer kan selecteren bij een nieuwe casus. Naast de genoemde gegevens voegt het programma nog enkele gegevens toe aan nieuw gedefinieerde componenten: een identificatienummer, eigenaarsgegevens en aanmaakdatum. Het identificatienummer gebruikt het programma onder water bij alle verwijzingen naar deze component. Het zorgt voor de uniekheid van deze component. Het is dan ook niet aanpasbaar, en wordt alleen getoond om gegevens in de database eenvoudiger te kunnen interpreteren in geval van problemen met het programma. De eigenaarsgegevens verwijzen naar de beheerder die de component heeft gedefinieerd. Hij is de enige die de componentdefinitie mag aanpassen. Andere beheerders mogen alleen de definitie inzien. Een bestaande component aanpassen De beheerder selecteert eerst een component in de lijst. Vervolgens klikt hij op de knop edit. Hij krijgt dan hetzelfde popupvenster te zien dat hij ziet als hij een nieuwe component toevoegt (Figuur 2), nu uiteraard ingevuld met de gegevens van de te wijzigen component. Alle gegevens zijn wijzigbaar. Bij wijzigen van de code moet de beheerder er wel op letten dat de nieuwe code overeenkomt met een bestaande afspeelfunctionaliteit. En als de component al gekozen is bij een casus mag de code niet worden aangepast. De door het programma toegevoegde gegevens identificatienummer, eigenaar en aanmaakdatum, blijven uiteraard ongewijzigd. Een bestaande component verwijderen De beheerder selecteert eerst een component in de lijst. Vervolgens klikt hij op de knop verwijder. In een popupvenster komt de vraag of er echt moet worden verwijderd. De beheerder klikt op ok Beheren van casussen In het casussenvenster ziet een beheerder een overzicht van alle casussen die in EMERGO door casusontwikkelaars zijn ontwikkeld of nog in ontwikkeling zijn. Hij heeft verder alleen de edit - knop ter beschikking. Als hij hierop klikt krijgt hij een modal popup-venster waarin hij de casusstatus en het actief zijn van een casus kan aanpassen. Hij kan hiermee de casus van in EMERGO, Open Universiteit Nederland 12

13 ontwikkeling zetten op compleet, of hij kan de casus ontoegankelijk maken voor anderen. Deze opties zijn momenteel (medio 2007) nog niet functioneel, maar ze zullen in de nabije toekomst worden geïmplementeerd. 3.2 DE CASUSONTWIKKELAAR-ROL Een casusontwikkelaar kan casussen definiëren, hij kan per casus componenten selecteren, en hij kan per casus bij elke component de inhoud invoeren. Een casusontwikkelaar kan op twee manieren betrokken zijn bij een casus: als eigenaar van de casus, en als invoerder van één of meer componenten van de casus. Als een casusontwikkelaar niet de eigenaar van een casus is, dan mag hij de casusgegevens niet wijzigen, en de casus niet verwijderen. Evenzo mag hij van componenten waarvan hij niet de eigenaar is alleen de ingevoerde gegevens inzien. Hij mag ze niet wijzigen Definiëren van casussen Het casusoverzichtvenster is het eerste venster dat een casusontwikkelaar ziet na inloggen. In dit venster ziet een casusontwikkelaar een overzicht van alle casussen waarbij hij betrokken is. Hij kan hier nieuwe casussen definiëren, en als eigenaar kan hij casusgegevens wijzigen of casussen verwijderen. Een nieuwe casus toevoegen Als de casusontwikkelaar op de knop nieuw klikt dan verschijnt een modal venster met een invulformulier (Figuur 3). Figuur 3. Invoer van een nieuwe casus door de casusontwikkelaar. De casusontwikkelaar kan de volgende velden invoeren: Code invoer van tekst, één regel Naam invoer van tekst, één regel; mag niet leeg zijn EMERGO, Open Universiteit Nederland 13

14 Versie invoer van tekst, geheel getal; mag niet leeg zijn De combinatie naam-versie moet uniek zijn. De ingevoerde naam is ook de naam die de student ziet als hij de casus start. De code is facultatief, en kan worden gebruikt om gelijksoortige casussen in de lijst te groeperen. Het programma voegt aan deze gegevens nog de datum en tijdstip van aanmaak toe, en een verwijzing naar het eigenaarsaccount (de casusontwikkelaar die de casus definieert). In het casusoverzichtsvenster wordt aangegeven dat de casusontwikkelaar van deze casus de eigenaar is. Casusgegevens wijzigen De casusontwikkelaar selecteert in het casusoverzichtsvenster een casus waarvan hij de eigenaar is. De knoppen edit en verwijder verschijnen. Als de casusontwikkelaar op de knop edit klikt verschijnt het popupvenster van Figuur 3, waarin de velden zijn gevuld met de gegevens van de geselecteerde casus. Alle velden zijn te wijzigen. Bij accordering test het programma weer of de naam niet leeg is, het versienummer een getal is, en de naam-versiecombinatie uniek is. Een casus verwijderen De casusontwikkelaar selecteert in het casusoverzichtsvenster een casus waarvan hij de eigenaar is. De knoppen edit en verwijder verschijnen. Als de casusontwikkelaar op de knop verwijder klikt komt in een popupvenster de vraag of er echt moet worden verwijderd. De casusontwikkelaar klikt op ok Van component tot casuscomponent De door de EMERGO-beheerder gedefinieerde componentgegevens (en in het bijzonder de XMLdefinitie) kunnen worden gezien als modellen of templates voor de componentgegevens die in de casusontwikkeling een rol spelen. Als een casusontwikkelaar besluit een component toe te voegen aan zijn casus, dan maakt het programma een componentinvoerscherm dat correspondeert met de XML-definitie. (Het is dus gevaarlijk om de XML-definitie te wijzigen als een component al onderdeel is van een casus, dit kan tot dataconflicten en een niet goed werkende casus leiden.) Het programma materialiseert als het ware de component-template voor deze casus. We zullen in het vervolg voor een aan een casus toegevoegde component de term casuscomponent gebruiken, ter onderscheiding van de bijbehorende door de beheerder gedefinieerde component. In het casusoverzichtsvenster bevindt zich voor elke casus achter de casusgegevens een knop componenten (nog net zichtbaar in Figuur 3). Als de casusontwikkelaar hierop klikt komt hij in het casuscomponentenoverzichtsvenster. Hij ziet nu een overzicht van alle casuscomponenten die behoren tot de geselecteerde casus. Er zijn nu twee mogelijkheden: de casusontwikkelaar is eigenaar van de casus, of hij is dat niet. Casusontwikkelaar is niet de eigenaar De casusontwikkelaar ziet in dit geval een casuscomponentenovezicht als in Figuur 4. Hij krijgt dit scherm alleen te zien als hij door de casus-eigenaar is aangewezen als auteur van tenminste één casuscomponent. Hij ziet zijn naam dus in de lijst genoemd bij die betreffende casuscomponent(en). Hij kan de gegevens die zichtbaar zijn in dit venster niet wijzigen. Bij selecteren van een casuscomponent verschijnen er dan ook geen knoppen edit en verwijder. Ook de knop nieuw ontbreekt. Het enige dat hij kan doen is klikken op een van de component -knoppen, waarna het venster vervangen wordt door het casuscomponentinvoervenster van de bijbehorende casuscomponent (zie paragraaf 3.2.3). EMERGO, Open Universiteit Nederland 14

15 Figuur 4. Casuscomponentenoverzicht voor niet-casuseigenaar. Casusontwikkelaar is de eigenaar Als de casusontwikkelaar eigenaar van de casus is, kan hij de gegevens die getoond worden in een overzicht als in Figuur 4 aanpassen. Hij kan nieuwe casuscomponenten definiëren, hij kan afspeelnaam en eigenaar van bestaande casuscomponenten wijzigen, en hij kan bestaande casuscomponenten verwijderen. Initieel is in het casuscomponentenscherm altijd de case -casuscomponent zichtbaar. Dit is een systeemcomponent, die in alle casussen aanwezig moet zijn. In de initiële situatie is er dan ook alleen de knop nieuw : de case-casuscomponent mag niet worden verwijderd, en is ook niet aanpasbaar. De eigenaar van de casus is ook eigenaar van de case-casuscomponent. Een casuscomponent toevoegen Als de casusontwikkelaar op de knop nieuw klikt dan verschijnt een modal venster met een invulformulier (Figuur 5). De casusontwikkelaar moet de volgende velden vullen: Component selectie uit een lijst; geen is voorgeselecteerd; mag niet geen zijn Naam invoer van tekst, één regel; mag niet leeg zijn; moet uniek zijn Auteur selectie uit een lijst; de huidige gebruiker is voorgeselecteerd De component-lijst bevat alle door de EMERGO-beheerder gedefinieerde functionele componenten (templates). De naam die de casusontwikkelaar geeft aan de casuscomponent is ook de afspeelnaam, dat wil zeggen de naam die gebruikt wordt tijdens de case run (althans als de casuscomponent zichtbaar is in de afspeelomgeving). De auteur die hij kiest gaat de inhoud van de casuscomponent vullen. Die auteur kan dus niet de afspeelnaam aanpassen, tenzij hij ook de casus-eigenaar is. Bij de meeste componenten is het toegestaan dat de casusontwikkelaar per casus meer dan één casuscomponent definieert. Zo kan hij de stukkencomponent bijvoorbeeld gebruiken om een bronnen -casuscomponent te maken, en tevens een (vak)woordenboek -casuscomponent. Bij EMERGO, Open Universiteit Nederland 15

16 een aantal componenten is dit niet toegestaan. Zo mag de locatiescomponent maar één keer gebruikt worden (er is maar één locatie-afspeler toegestaan in de afspeelomgeving). Hetzelfde geldt voor de empackcomponent. Figuur 5. Toevoegen van nieuwe component aan casus. Casuscomponentgegevens wijzigen De casusontwikkelaar selecteert in het casuscomponentoverzichtsvenster een casuscomponent. De knoppen edit en verwijder verschijnen, tenminste als het niet gaat om de casus - casuscomponent. Als de casusontwikkelaar op de knop edit klikt verschijnt het popupvenster van Figuur 5, waarin de velden zijn gevuld met de gegevens van de geselecteerde casuscomponent. Alle velden zijn te wijzigen. Bij accordering test het programma weer of de naam niet leeg is, en of hij uniek is. Een casuscomponent verwijderen De casusontwikkelaar selecteert in het casuscomponentoverzichtsvenster een casuscomponent. De knoppen edit en verwijder verschijnen, tenminste als het niet gaat om de casus - casuscomponent. Als de casusontwikkelaar op de knop verwijder klikt komt in een popupvenster de vraag of er echt moet worden verwijderd. De casusontwikkelaar klikt op ok Vullen van een casuscomponent In het casuscomponentoverzichtsvenster bevindt zich voor elke casuscomponent achter de casuscomponentgegevens een knop component (zie Figuur 5). Als de casusontwikkelaar hierop klikt komt hij in het casuscomponentinvoerscherm behorende bij deze casuscomponent. De aangeboden functionaliteit in het invoervenster is specifiek voor de bijbehorende component (template), en wordt bepaald door de XML-definitie die de EMERGO-beheerder heeft ingevoerd. In het venster wordt wel altijd de naam van de casus getoond, en de (afspeel)naam van de casuscomponent. Ook nu zijn er twee mogelijkheden: de casusontwikkelaar is benoemd tot eigenaar ( auteur ) van de casuscomponent, of hij is niet de auteur. EMERGO, Open Universiteit Nederland 16

17 Figuur 6. Voorbeeld van casuscomponentinvoervenster voor niet-auteur. Casusontwikkelaar is niet de auteur De casusontwikkelaar ziet in dit geval een invoervenster als in Figuur 6. Het gaat in dit voorbeeld om de locatiescomponent (zie hoofdstuk 4.5). De aanvinkknoppen initieel aanwezig en initieel toegankelijk geven aan dat in de afspeelomgeving de locatieselectiefunctionaliteit te zien en te gebruiken is. De lijst onder content bevat de namen van de locaties en per locatie de namen van de eventueel getoonde achtergrondplaatjes. Verder is met (present) aangegeven dat een locatie in een case run initieel aanwezig is (en toegankelijk door te klikken op het bijbehorende ikoontje in de locatiekeuze-speler, als die tenminste aanwezig en toegankelijk is). (preselected) betekent dat de locatie is voorgeselecteerd (bij starten van de case run komt de student in deze locatie terecht), of, voor achtergrondplaatjes, dat bij binnenkomst in de locatie de betreffende achtergrond zichtbaar is. De casusontwikkelaar kan zien wat er is ingevoerd, maar hij mag niets wijzigen. Alle aanvinkknoppen zijn gedeactiveerd. Rechtermuisknopmenu s bevatten geen nieuw, edit of verwijder -opties. Alleen de preview -optie is aanwezig, als het element waarop geklikt wordt tenminste previewbaar is. Zijn aan het betreffende element nog overige, niet zichtbare, gegevens gekoppeld, dan is er ook een menu-item bekijk item. Hiermee kunnen bijvoorbeeld mediabestanden, zoals locatie-achtergronden en gespreksvideofragmenten, rechtstreeks worden getoond, los van de casus-preview. Casusontwikkelaar is de auteur De casusontwikkelaar beschikt in dit geval over alle invoermogelijkheden (Figuur 7). Zoals gezegd zijn die mogelijkheden vastgelegd door de EMERGO-beheerder in de XML-definitie. Het gaat enerzijds om inhoudelijke gegevens, anderzijds om statusinformatie. De statusinformatie bepaalt welke inhoudelijke gegevens initieel tijdens een case run zichtbaar / geselecteerd / enabled, etc zijn. De inhoudelijke gegevens worden weergegeven in een boomstructuur (zie hoofdstuk 2), de status wordt geregeld door aanvinkknoppen. Toevoegen en wijzigen van boomtakken gebeurt middels modal popup-vensters. Initiële status die in zo n venster wordt ingesteld is in het overzichtvenster aangegeven via een code tussen haakjes. EMERGO, Open Universiteit Nederland 17

18 Structuur en type van de inhoud, en mogelijke statuswaarden verschillen van component tot component. We zullen daar nader op ingaan in de gedetailleerde beschrijving van de toolkitcomponenten (hoofdstuk 4). Figuur 7. Voorbeeld van casuscomponentinvoervenster voor auteur. 3.3 DE CASE RUN MANAGER-ROL De case run manager beheert case runs. Met een case run bedoelen we een afgesloten omgeving bestaande uit de afspeelomgeving van EMERGO-componenten gevuld met de inhoud en statusgegevens van een gekozen casus, een gekozen groep gebruikers (de case run members ), een ingestelde tijdsperiode gedurende welke die gebruikers toegang hebben tot de afspeelomgeving, en per gebruiker de statusveranderingshistorie van de afspeelomgeving ten gevolge van eigen of externe activiteiten binnen de case run. Met afgesloten bedoelen we hierbij dat case runs geen invloed op elkaar kunnen uitoefenen. Dat wil bijvoorbeeld zeggen dat een case run manager twee case runs kan definiëren die betrekking hebben op dezelfde casus, dezelfde groep gebruikers, en dezelfde tijdsperiode, zonder dat activiteit in de ene case run de status van de andere case run beïnvloedt Case runs beheren Na aanmelden bij EMERGO ziet een case run manager het case run-overzichtsscherm. Hierin ziet hij alle case runs die hij ooit heeft gedefinieerd en niet verwijderd. De case run manager kan in dit scherm voor afgeronde casussen case runs definiëren, case run-gegevens wijzigen en case runs verwijderen. EMERGO, Open Universiteit Nederland 18

19 Een case run definiëren Als de case run manager op de knop nieuw klikt dan verschijnt een modal venster met een invulformulier (Figuur 8). De case run manager vult de volgende velden: Case selectie uit een lijst; geen is voorgeselecteerd; mag niet geen zijn Code invoer van tekst, één regel Naam invoer van tekst, één regel; mag niet leeg zijn Startdatum invoer van tekst in datumformaat, één regel, of selectie van dag uit kalender-combobox Einddatum invoer van tekst in datumformaat, één regel, of selectie van dag uit kalender-combobox Running aanvinkknop Hierbij geldt: datumformaat = <dagnr>-<maandnummer>-<jaarnummer> <dagnummer> = geheel getal tussen 1 en 31 <maandnummer> = geheel getal tussen 1 en 12 <jaarnummer> = geheel getal tussen 2007 en Is het formaat niet correct, of is er geen datum ingevuld/gekozen, dan vult het programma automatisch hiervoor de huidige datum in. In het overzicht wordt ook het tijdstip getoond, zodat start- en eindmoment precies vastliggen. Het tijdstip kan echter niet worden ingevoerd. Als de datum overeenkomt met de huidige datum dan voegt het programma het huidige tijdstip toe, anders voegt het het tijdstip 00:00:00.0 toe (12 uur s nachts). Case is de casus waarop de case run betrekking heeft. Code is een facultatieve case run-code om case runs wat eenvoudiger van elkaar te kunnen scheiden. Naam is de naam waarmee de case run onder de case run members bekend is. Voor een geldige case run moet de startdatum uiteraard eerder vallen dan de einddatum. Met de Running -aanvinkknop kan de case run manager de case run naar believen activeren of deactiveren (de deelnemers hebben dan tussen start- en einddatum respectievelijk toegang of geen toegang). Het programma voegt zelf nog een creatiedatum toe, die overeenkomt met het tijdstip waarop de case run gedefinieerd is, en een statuswaarde. Met de statuswaarde kunnen we aangeven of de case run onder constructie, lopend, of gearchiveerd is, of of het een test -run is (zie het technisch ontwerp, deliverable 5.2). Door wie of wat, hoe en wanneer deze status gezet wordt, moet nog verder worden uitgewerkt. Case run-gegevens wijzigen De case run manager selecteert in het case run-overzichtsvenster een case run. De knoppen edit en verwijder verschijnen. Als de case run manager op de knop edit klikt verschijnt het popupvenster van Figuur 8, waarin de velden zijn gevuld met de gegevens van de geselecteerde case run. Alle velden zijn te wijzigen, tenzij de startdatum al gepasseerd is. Deze datum kan dan niet meer worden gewijzigd. Bij accordering test het programma weer of de case niet geen is, en de naam niet leeg. EMERGO, Open Universiteit Nederland 19

20 Figuur 8. Toevoegen van case run. Een case run verwijderen De case run manager selecteert in het case run-overzichtsvenster een case run. De knoppen edit en verwijder verschijnen. Als case run manager op knop verwijder klikt komt in een popupvenster vraag of er echt moet worden verwijderd. De case run manager klikt op ok Case run members selecteren In het case run-overzichtsscherm staat in elke case run-gegevensregel de knop deelnemers. Als de case run manager hierop klikt krijgt hij een overzicht te zien van alle accounts in EMERGO die een docent-rol of een student-rol hebben (Figuur 9). Bij elk account staat een aanvinkknop waarmee de case run manager het kan toevoegen als case run member. Hieruit volgt dat als een EMERGO-gebruiker een account heeft dat zowel docent als student is, die gebruiker dan voor elke case run waarin hij meespeelt bij inloggen moet kiezen welke rol hij tijdens de huidige sessie aanneemt. Dient een gebruiker in de ene case run docent te zijn, en in een andere case run student, dan moet hij twee accounts krijgen in EMERGO, één voor elke rol. Figuur 9. Deelnemers aan een case run selecteren. EMERGO, Open Universiteit Nederland 20

21 3.4 DE DOCENT-ROL Deze rol is momenteel nog niet uitontwikkeld. De bedoeling is dat een docent kan zien wat de vorderingen van studenten in een case run zijn, en indien nodig actief aan een case run kan deelnemen om studenten te begeleiden. 3.5 DE STUDENT-ROL Als studenten aan verschillende case runs deelnemen moeten ze na inloggen de case run kiezen die ze willen doorlopen. Nemen ze maar aan één case run deel, dan wordt direct begonnen met afspelen van die case run. Alle studentkeuzes worden als statusinformatie bij de betreffende component opgeslagen. Bij hervatten van een case run zal de student de case run aantreffen in een toestand die overeenkomt met de toestand zoals hij hem achterliet bij zijn meest recente sessie, tenzij de casus zo is opgezet dat de toestand ook door activiteiten van buiten (andere studenten, docenten, onverwachte gebeurtenissen, timers) wordt beïnvloed. EMERGO, Open Universiteit Nederland 21

22 4. Componenten We beschrijven hier de momenteel in EMERGO door de EMERGO-beheerder gedefinieerde componenten en de manier waarop een casusontwikkelaar ze kan vullen. Zoals we schreven identificeert de EMERGO-beheerder een component door middel van een code, en daaraanvast koppelt hij een naam. Een casusontwikkelaar ziet in zijn componentenkeuzelijst alleen de naam terug. De code is alleen van belang tijdens een case run, hierdoor wordt de juiste afspeelfunctionaliteit geactiveerd. De hierna volgende lijst is vooral bedoeld voor casusontwikkelaars. We gaan dan ook uit van de namen van de componenten, en niet van de code. De code noemen we wel (staat genoemd achter EMERGO-beheerdercode ), zodat de bijbehorende afspeelfunctionaliteit herleidbaar blijft voor EMERGO-beheerders als de naam ooit wordt aangepast. Een casusontwikkelaar mag de meeste componenten meer dan één keer aan zijn casus toevoegen, telkens onder een andere naam. Zo n instantiatie, of casuscomponent, kan hij vervolgens gaan vullen. Een casuscomponent wordt in principe gevuld met drie verschillende soorten data: kenmerken, statusparameters, en deelcomponenten of elementen. Elk element kan ook weer met deze drie soorten data gevuld worden, afhankelijk van de definitie die de EMERGO-beheerder aan de component gekoppeld heeft. Kenmerken leveren de inhoud van de casuscomponent. Dit is deels inhoud die alleen voor de casusontwikkelaar bedoeld is, zoals een identificatie, en deels inhoud die bedoeld is voor een case run member in de afspeelomgeving, zoals een naam. Bij elke component is aangegeven uit welke elementen hij bestaat, hoe de structuur is van die elementen, en welke statusparameters gelden voor component en elementen. Van een aantal statusparameters kan de casusontwikkelaar de initiële waarde invoeren, dat wil zeggen de statuswaarde die het bijbehorende element of de casuscomponent bij het starten van een case run heeft. Zo kan de casusontwikkelaar bijvoorbeeld instellen welke locatie een student ziet als hij voor het eerst een case run start. Is de parameter instelbaar, dan is dat in het overzicht aangegeven door de term initieel. Ook staan in het overzicht de default-waarden genoemd. De default-waarde is de statuswaarde bij aanvang van een case run (tenzij de casusontwikkelaar deze initiële waarde heeft gewijzigd). Voor de statusparameters gebruiken we hier de Engelse benamingen. Deze benamingen gebruikt het programma intern bij het testen van de waarden van de parameters. Een casusontwikkelaar ziet bij het instellen van initiële waarden voor deze parameters momenteel een Nederlandse vertaling voor deze termen, maar de terminologie is nog onderwerp van discussie. De parameters kunnen meestal twee waarden aannemen: waar ( true ) of onwaar ( false ). We noemen nu de meest voorkomende parameters (eventuele componentspecifieke parameters zullen bij de component zelf worden beschreven; tussen haakjes de term die de casusontwikkelaar momenteel in EMERGO ziet): present ( aanwezig ) als deze de waarde true heeft wil dit zeggen: zichtbaar of bereikbaar; bijvoorbeeld: een student kan een present locatie die momenteel niet zichtbaar is bezoeken door de locatie-navigatie-knop te klikken en vervolgens op het locatie-icoon behorende bij de gewenste locatie (de user interface van de afspeelomgeving wordt in een ander EMERGO, Open Universiteit Nederland 22

23 document, de gebruikershandleiding, beschreven); voorwaarde is wel dat de accessible -parameter voor deze locatie niet false is; is de accessible -parameter wel false, dan kan de locatie alleen indirect bereikt worden, bijvoorbeeld via een conditie die als gevolg heeft dat de selected van deze locatie true wordt (voor een bespreking van condities en acties verwijzen we naar paragraaf 4.6); kortom: een present component of element bestaat, of is aanwezig in een case run; dit wil nog niet zeggen dat hij zichtbaar of toegankelijk is voor de student, wel dat er een startknop of ikoon is waarmee hij zichtbaar te maken is accessible ( toegankelijk ) als deze de waarde true heeft wil dit zeggen: startbaar; bijvoorbeeld: een student kan een accessible locatie die momenteel niet zichtbaar is bezoeken door de locatienavigatie-knop te klikken en vervolgens op het locatie-icoon behorende bij de gewenste locatie te klikken; de present -parameter voor deze locatie moet dus op true staan, anders is er geen start-ikoon opened als deze de waarde true heeft wil dit zeggen: zichtbaar en gestart; bijvoorbeeld: een student heeft door een klik op een document-ikoon in de bronnencasuscomponent een document geopend; van dit document stonden bij starten dus zowel present als accessible op true ; bij een volgende keer starten van de afspeelomgeving kan de student dan bijvoorbeeld zien welke documenten hij in het verleden geopend heeft via een vink bij de betreffende documenten selected als deze de waarde true heeft wil dit zeggen: het laatst gestart; bijvoorbeeld: een student selecteert een vraag uit een lijst vragen bij een interview; alle ooit geselecteerde vragen uit die lijst hebben opened op true staan; echter de selected gaat voor al deze vragen op false behalve voor de nu geselecteerde vraag; als selected op true staat, staat ook opened op true ; maar present en accessible kunnen dan false zijn! Het gaat hier om zogenaamde singleopen -elementen: elementen waarvan er op elk moment van de case run slechts één geselecteerd is; selecteert de student een ander element, dan wordt bij het oorspronkelijk geselecteerde element automatisch de selected op false gezet; de casusontwikkelaar kan in een lijst met dergelijke elementen instellen welk element initieel voorgeselecteerd ( preselected ) is; van dit element wordt de selected bij aanvang van de case run op true gezet outfolded ( uitgeklapt ) als deze de waarde true heeft wil dit zeggen: in het element zijn de subelementen zichtbaar; bijvoorbeeld: een student klikt in de bronnencasuscomponent op het + - teken voor een map waarin zich documenten en submappen bevinden; de bijbehorende documentikonen en mapikonen (om documenten en submappen te kunnen openen) worden nu getoond, en het + -teken verandert in een - -teken; door op dit - -teken te klikken wordt outfolded weer op false gezet, en verdwijnen subdocumenten en submappen; hiermee samen hangt: outfoldable deze parameter geeft aan of een element subelementen kan hebben; zo ja, dan is het element te beschouwen als een map, waarvoor een + of een - wordt gezet in de afspeelomgeving; een voorbeeld hiervan is ook een hoofdvraag in een interview, die een aantal subvragen kan hebben; deze subvragen zijn zichtbaar te maken door op het + - teken vóór de hoofdvraag te klikken finished als deze de waarde true heeft wil dit zeggen: de student is klaar met deze EMERGO, Open Universiteit Nederland 23

24 casuscomponent of dit componentelement; het op true zetten van deze paramater zal altijd het resultaat zijn van het afgaan van een conditie die is opgesteld met de scriptscasuscomponent; zo kan bij een interview worden getest op het gesteld zijn van bepaalde vragen (de opened hiervan moet dan true zijn); zo ja, dan wordt een actie uitgevoerd die de finished -parameter op true zet; en finished kan ook weer op false gezet worden, bijvoorbeeld als een student nieuwe informatie krijgt, zodat hij een onderdeel nogmaals moet bekijken De waarde van een statusparameter wordt tijdens een case run studentafhankelijk opgeslagen zodra er een activiteit plaatsvindt die samenhangt met die statusparameter. Dus als een student een locatie binnengaat zal de opened van die locatie op true gezet worden. In de opslag wordt ook bijgehouden op welk moment de statusparameter een waarde gekregen heeft. Zo kunnen we in een scripts-conditie niet alleen testen hoe vaak de student die locatie bezocht heeft, maar ook wanneer. Voor elke component is ook aangegeven of hij een oudercomponent heeft, en zo ja welke. Als er een oudercomponent is betekent dat dat de casuscomponent alleen actief kan worden in de afspeelomgeving als ook de oudercomponent als casuscomponent aan de casus is toegevoegd. Het startikoon van de betreffende casuscomponent bevindt zich dan in het functionele gebied van de oudercasuscomponent. Is de Case -component genoemd als oudercomponent, dan is er verder geen probleem omdat deze component altijd aan een casus wordt toegevoegd (zie paragraaf ). De Case -component zelf is de enige component zonder ouder-component. We zullen nu de tot dusverre in de toolkit aanwezige en door een casusontwikkelaar te kiezen componenten nader beschrijven. Als de beheerder-instelling meervoudig is aangevinkt (zie paragraaf 3.1.2) geven we dat aan met herbruikbaar: ja. 4.1 STUKKEN Oudercomponent: Empack EMERGO-beheerdercode: references Herbruikbaar: ja Componentstatusparameters: present ( true, initieel) accessible ( true, initieel) opened ( false ) selected ( false ) Basiselementen: map - kenmerken: o name - statusparameters: o present ( true, initieel) o outfolded ( false, initieel) o outfoldable ( true ) o opened ( false ) o selected ( false ) EMERGO, Open Universiteit Nederland 24

25 - subelementen: o piece - kenmerken: name blob blobtypes: database,int_url,ext_url mediatypes: text,picture,audio,video,other - statusparameters: present ( true, initieel) opened ( false ) finished ( false ) selected ( false ) o map piece Een stukkenlijst in de stukkencomponent kan dus worden samengesteld uit map -elementen en piece -elementen. Een map heeft alleen een naam, en kan weer map- en piece-elementen als subelementen hebben. Een piece heeft een naam en is tevens verbonden met een blob (van binary large object ). Figuur 10. Stukken: keuze van een database-blob. EMERGO, Open Universiteit Nederland 25

26 Een blob is een verwijzing naar inhoudelijke gegevens. Eigenlijk draait het in stukken om de blob (tenzij iemand een woordenlijst -component wil toevoegen aan zijn casus). De blob-inhoud kan hier van 3 typen zijn. Toevoegen van een database -blob betekent het uploaden van een bestand naar de server. Figuur 10 toont hoe dat voor een casusontwikkelaar in zijn werk gaat: rechtermuisklik op een map in het stukken-invoerscherm, kies voor nieuw stuk, stel in de dan verschijnende popup het blobtype in op database en klik op de dan verschijnende knop voeg toe. Kies in de file upload -popup voor browse (of bladeren als uw browser Nederlandstalig is), en selecteer tenslotte een bestand op de eigen computer. Klik op upload en het bestand wordt naar de EMERGO-server gestuurd. Het int_url -blobtype vraagt om een bestand dat zich binnen de website bevindt. De naam van dit bestand, plus het relatieve pad in de EMERGO-site, moet handmatig worden ingevoerd. Het ext_url -type is hiermee vergelijkbaar. Alleen gaat het nu om een bestand dat of (deel)website die extern op het internet te vinden is. Het mediatype moet worden gekozen om in de afspeelomgeving in de user interface duidelijk te kunnen maken om wat voor type stuk het gaat. We kunnen bijvoorbeeld voor elk mediatype een apart ikoon tonen voor de naam van het stuk. Ook kan het mediatype worden gebruikt om te bepalen wat er moet gebeuren als een case run member een stuk wil openen: voor het type other kunnen we ervoor kiezen het stuk downloadbaar te maken (als het gaat om een database-blob), voor alle andere types kunnen we de default-browserplayer zijn gang laten gaan. 4.2 CASE Oudercomponent: geen EMERGO-beheerdercode: case Herbruikbaar: nee Componentstatusparameters: opened ( false ) Dit is een systeemcomponent, die automatisch wordt toegevoegd wanneer een casusontwikkelaar een casus definieert (op moment van schrijven is dit de enige systeemcomponent, de andere componenten zijn alle functionele componenten). Hij is bedoeld om onder water allerlei componentoverstijgende algemene casuseigenschappen te kunnen bijhouden. Bijvoorbeeld een cross refence -lijst van componentelementen en script-condities en -acties waarin ze voorkomen. Of ook een lijst met per locatie de bijbehorende gesprekken. De opened -statusparameter kan eventueel in de scriptcomponent gebruikt worden om te testen op het aantal keren dat de casus is gestart 4.3 EMPACK Oudercomponent: Case EMERGO-beheerdercode: empack Herbruikbaar: nee EMERGO, Open Universiteit Nederland 26

27 Componentstatusparameters: present ( true, initieel) accessible ( true, initieel) opened ( false ) selected ( false ) Deze component moet een casusontwikkelaar aan een casus toevoegen als hij een component heeft gekozen die deze component als oudercomponent heeft. Deze component is eigenlijk een omhulsel voor componenten die deze component als oudercomponent hebben. Hij is als zodanig een user interface -component, in tegenstelling tot de inhoudelijke componenten die in de afspeelomgeving te openen zijn vanuit het functionele gebied van de empack. In de afspeelomgeving is de empack te beschouwen als de gereedschapskist die de student overal mee naar toe kan nemen en gebruiken (als tenminste niet de present en/of accessible initieel of via script op false zijn gezet). Het gereedschap dat in de kist zit zijn de casuscomponenten die de empack als ouder hebben. 4.4 GESPREKKEN Oudercomponent: Locaties EMERGO-beheerdercode: conversations Herbruikbaar: ja Componentstatusparameters: geen Basiselement: conversation - kenmerken: o pid o name o reflocations type: ref reftype: locationtags_conversationtags refcomp: locations reftag: location - statusparameters: o present ( true, initieel) o opened ( false ) o finished ( false ) o selected ( false ) - subelementen: o background - kenmerken: pid singleopen: true picture - statusparameters: opened ( false, initieel) o map - kenmerken: EMERGO, Open Universiteit Nederland 27

28 o o name - statusparameters: present ( true, initieel) outfolded ( false, initieel) opened ( false ) outfoldable ( true ) selected ( false ) - subelementen: question fragment - kenmerken: pid singleopen: true blob blobtypes: int_url, ext_url - statusparameters: opened ( false, initieel) present ( true ) selected ( false ) finished ( false ) - subelementen: map question question - kenmerken: text - statusparameters: present ( true, initieel) outfolded ( true ) outfoldable ( false, initieel) opened ( false ) selected ( false ) - subelementen: fragment Vrij vertaald betekent dit dat in de gesprekkencomponent een casusontwikkelaar eerst een gespreksidentificatie ( pid ) en een gespreksnaam moet invoeren. Het gesprek kan een achtergrondplaatje hebben, in te voeren in het background -element (heeft ook een identificatie). Dit plaatje wordt in de afspeelomgeving getoond op het moment dat de gespreksvideo is afgelopen. De ontwikkelaar moet ook aangeven in welke locatie(s) het gesprek gestart kan worden. Hiertoe is een referentiekenmerk in de XML-definitie opgenomen, reflocations. Zo n referentie- tag (van het type ref ), heeft als attributen: reftype, een verwijzing naar het type dat in de case-component wordt bewaard; in dit geval een cross-reference tussen de gesprekken- en de locaties-component, dit wordt aangeduid met locationtags_conversationtags refcomp, een verwijzing naar de beheerdercode van de component waarin het gerefereerde element zich moet bevinden; hier is dat locations reftag, een verwijzing naar de tagnaam van het gerefereerde element; in dit geval location EMERGO, Open Universiteit Nederland 28

29 Een gesprek kan beginnen met een video- of audiofragment, of met een lijst van vragen ( question ) en/of mappen waaruit de case run member een keuze moet maken. Kiest een case run member een vraag, dan volgt een fragment als reactie (als dit is ingevoerd, en we laten hier eventuele scriptactiviteiten buiten beschouwing). Kiest hij een map, dan volgt een lijst met vragen. Pas als hij daaruit een keuze maakt volgt het bijbehorende videofragment. Telkens na een fragment volgt een lijst met vragen en/of mappen. Een achtergrond is van het picture -type. Een picture is een blob (zie 4.1), en wordt toegevoegd via een file upload -dialoog. Selecteer een afbeeldingbestand op de eigen computer. Dit wordt dan aan de EMERGO-database toegevoegd. Ook het fragment, dat ook een casusontwikkelaar-identificatie heeft, is een blob, van het type int_url of ext_url. De URL-verwijzing dient zich te bevinden op de EMERGO-streaming server (interne url, voeg dan bestandsnaam plus eventueel relatief pad toe), of op een externe streaming server (externe url; voeg volledig URL-pad plus bestandsnaam toe). Als reactie op een vraag kunnen meerdere fragmenten ingevoerd worden. Het fragment dat daadwerkelijk gespeeld wordt in de case run is het fragment waarvan de selected -parameter op true staat. De casusontwikkelaar kan aangeven welk fragment dat moet zijn door de Voorgeselecteerd - aanvinkknop aan te zetten in het fragment-invoerscherm. In de gesprekken-lijst verschijnt dan bij het betreffende fragment het label (preselected). Figuur 11. Gesprekken: nieuw gesprek invoeren. In Figuur 11 zien we hoe een casusontwikkelaar een nieuw gesprek kan invoeren. Hij vult een idenitificatie in voor zichzelf (merk op dat het label Id grijs is; een grijs label betekent dat de informatie niet in de afspeelomgeving van belang is), en een naam voor de student. Initieel aanwezig wordt na klikken op ok omgezet naar een label in de overzichtslijst: (present). Dit label komt overeen met de statusparameter die dan automatisch op true gezet wordt. Bij Referentie naar locatie(s) moeten één of meer locaties gekozen worden waarin het gesprek kan EMERGO, Open Universiteit Nederland 29

30 plaatsvinden. In de huidige versie van EMERGO moeten hiervoor eerst selecties worden gemaakt in twee comboboxen. In de eerste combobox moet vooralsnog altijd student gekozen worden, in de tweede moet in dit geval worden gekozen voor locaties. Zodra deze keuzes gemaakt zijn verschijnt de aanvink-keuzelijst met alle ingevoerde locaties. In een volgende versie van de toolkit zullen de comboboxen alleen getoond worden als er meer dan één relevante keuzes zijn. Bij vragen kan de casusontwikkelaar nog aangeven of ze met Kinderen initieel zichtbaar moeten worden getoond, dat wil zeggen dat alle eventueel ingevoerde deelvragen bij zo n hoofd vraag (de vragen die zijn ingevoerd bij het antwoordfragment op de hoofdvraag) al in de vragenlijst zichtbaar (en te stellen) zijn voordat het antwoordfragment gespeeld is. De uitklapknop wordt dan in de afspeler al toegevoegd aan de hoofdvraag, zodat studenten naar believen de deelvragen kunnen verbergen of tonen. In het invoerscherm krijgt de hoofdvraag in dat geval het label (outfoldable). Op dezelfde manier kan een ontwikkelaar aangeven dat een map Initieel uitgeklapt moet worden getoond. Het label (outfolded) wordt dan toegevoegd aan de map in het invoerscherm, en de gelijknamige parameter wordt op true gezet bij aanvang van een case run. Overigens staat de outfoldable -parameter van een map default op true : de map is tijdens de case run altijd in- en uitklapbaar. Vragen hebben zowel een outfolded - als een opened -status. Opened wordt true als het bijbehorende fragment gespeeld is (dus de vraag is geklikt). Outfolded is true als de bijbehorende deelvragen getoond worden (dus de case run member heeft op het + -teken geklikt). 4.5 LOCATIES Oudercomponent: Case EMERGO-beheerdercode: locations Herbruikbaar: nee Componentstatusparameters: present ( true, initieel) accessible ( true, initieel) opened ( false ) selected ( false ) Basiselement: location - kenmerken: o pid o name o singleopen: true - statusparameters: o present ( true, initieel) o accessible ( true, initieel) o opened ( false, initieel) o selected ( false ) - subelementen: o background - kenmerken: pid EMERGO, Open Universiteit Nederland 30

31 picture singleopen: true - statusparameters: opened ( false, initieel) Deze component moet een casusontwikkelaar aan een casus toevoegen als hij voor die casus ook een component heeft gekozen die deze component als oudercomponent heeft. Wat dat betreft is de component vergelijkbaar met de empack. Alleen kunnen hier meerdere omhulsels voor de kindercomponenten gedefinieerd worden. Zo n omhulsel, of locatie, bestaat uit een identificatie voor de casusontwikkelaar (pid), een naam en een of meer backgrounds. Een background heeft ook een identificatie, is van het type picture, en wordt weer aan de EMERGOdatabase toegevoegd door middel van een file upload-dialoog (zie 4.1). Een case run member bevindt zich altijd in één locatie. Een casusontwikkelaar moet aangeven in welke locatie een member binnenkomt als hij voor het eerst de case run start. Het singleopen - kenmerk van het locatie-element zorgt ervoor dat zodra de casusontwikkelaar een locatie tot startlocatie benoemt (door in het locatie-invoervenster aanvinken van de knop bij Voorgeselecteerd ), automatisch de tot dan geldende startlocatie wordt gedeselecteerd. De Voorgeselecteerd -status wordt in het componentvenster aangegeven door het label (preselected). Van de voorgeselecteerde locatie wordt de opened -status bij starten van de case run automatisch op true gezet. Iets dergelijks geldt voor de achtergrond. Er is per locatie één achtergrond voorgeselecteerd door de casusontwikkelaar (default is dat trouwens de eerste achtergrond die wordt ingevoerd bij een locatie). Van andere achtergronden kan de ontwikkelaar via scripts de opened op true zetten, waardoor automatisch de tot dan toe zichtbare achtergrond wordt vervangen (diens opened wordt false ). Figuur 12. Locaties: nieuwe locatie invoeren. EMERGO, Open Universiteit Nederland 31

32 Figuur 12 toont hoe het invoeren van een locatie in zijn werk gaat. Achter Id (grijs om aan te geven dat dit gegeven niet in de afspeelomgeving van belang is) vult de casusontwikkelaar een identificatie in. Hij geeft verder de naam die zichtbaar is in de afspeelomgeving, en bepaalt of de locatie bij eerste keer starten van de afspeelomgeving aanwezig ( Initieel aanwezig ) is, startbaar ( Initieel toegankelijk ) is, en/of voorgeselecteerd. Na klikken op ok wordt de locatie toegevoegd in de lijst. In deze lijst is met labels aangegeven of de locatie initieel aanwezig ( (present) ) en/of voorgeselecteerd ( (preselected) ) is. Dit geldt ook voor de achtergrond(en) die vervolgens op een gelijksoortige manier moeten worden toegevoegd. 4.6 SCRIPTS Oudercomponent: Case EMERGO-beheerdercode: scripts Herbruikbaar: ja Componentstatusparameters: present ( true, initieel) accessible ( true, initieel) opened ( false ) selected ( false ) Basiselementen: condition - kenmerken: o pid o conditionstring - statusparameters: o present ( true, initieel) o opened ( false ) - subelementen: o condition o action - kenmerken: pid actionstring - statusparameters: present ( true, initieel) opened ( false ) o timer - kenmerken: pid delay repeats - statusparameters: present ( true, initieel) opened ( false ) started ( false ) finished ( false ) timer EMERGO, Open Universiteit Nederland 32

33 Met de scripts-component kan een casusontwikkelaar de toestand van andere componenten of elementen van componenten tijdens een case run beïnvloeden als reactie op activiteit van een case run member, of als reactie op het afgaan van een wekkeralarm (timer). Het initiatief (of de trigger ) voor een toestandswijziging is gedefinieerd in het condition-element. Elk toegevoegd condition-element bevat in de conditionstring een logische bewering. Het programma analyseert deze bewering, en bepaalt of hij waar of onwaar is. Als hij waar is, handelt het programma alle ingevoerde subelementen bij deze condition af. Er zijn drie typen subelementen mogelijk: het condition-element, het action-element, en het timer-element. Het action-element bevat in de actionstring informatie die door het programma wordt vertaald in de wijziging van de toestand van een of meer componenten of componentelementen. Bij een condition kunnen meerdere action-elementen worden ingevoerd. Het condition-element als subelement is alleen zinvol als, naast één of meer toestandswijzigingen die altijd moeten worden uitgevoerd als de hoofdbewering waar is, er ook toestandswijzigingen zijn die ook nog afhankelijk zijn van andere beweringen. Het timer-element is een speciaal geval van het action-element. Met dit element definieert de casusontwikkelaar een wekker. Impliciet zet het programma bij instantiatie van deze wekker in de case run de started -parameter van de wekker op true (als tenminste de casusontwikkelaar Initieel aanwezig heeft aangevinkt bij definitie van de wekker). In feite is een wekker een zelfstandig virtueel object tijdens een case run, zoals ook een locatie een object is, of een e- mailbericht, of een bron. De wekker heeft echter (vooralsnog) geen zichtbare afspeler (er is bijvoorbeeld geen klok of zandloper aanwezig), hij is alleen manifest voor een casusontwikkelaar, en dan nog alleen in de scriptscomponent. Vandaar dat we hebben besloten om hem ook op deze plaats te definiëren, en, om de invoer te vergemakkelijken, de definitie te laten samenvallen met het zetten van de started -toestand. Uiteraard is het ook mogelijk van een al gedefinieerde wekker via een action statusparameters te wijzigen (de wekker kan op deze manier hergebruikt worden). Een wekker is niet alleen conditie-afhankelijk te definiëren, maar kan ook worden ingevoerd als basiselement. Indien Initieel aanwezig is aangevinkt tijdens de invoer zal een dergelijke wekker direct starten met lopen wanneer een case run member start met de case run. Is Initieel aanwezig niet aangevinkt, dan moet de casusontwikkelaar een action toevoegen met als opdracht het starten van de wekker. Het programma is tijdens een case run niet voortdurend bezig met controleren van conditionbeweringen. Dat zou erg inefficiënt zijn, en de performance negatief beïnvloeden. Het programma reageert daarentegen alleen op case run member-acties, en op het afgaan van wekkers. Op dat moment gaat het programma eerst een selectie maken van alle conditionelementen waarin de actie of wekker een rol speelt. Vervolgens analyseert het uitsluitend deze elementen, en voert het bijbehorende toestandswijzigingen uit als de bewering waar is. Bovendien behandelt het programma alleen conditions en actions waarvan de present - statusparameter de waarde true heeft. Per casus kan een ontwikkelaar meer scriptscomponenten definiëren. Voor elk van deze componenten kan de invoerder (initieel of via script) de present - en accessible - statusparameters instellen. Hierdoor is het mogelijk om niet alleen enkelvoudige conditions en EMERGO, Open Universiteit Nederland 33

34 actions, maar hele groepen scripts te activeren of deactiveren. Het programma analyseert alleen de scripts in de actieve componenten. In Figuur 13 is een voorbeeld te zien van het invoeren van een nieuwe logische bewering. (In het vervolg zullen we in plaats van logische bewering de term conditie gebruiken.) De casusontwikkelaar heeft op de content -balk, of op een eerder gedefinieerde conditie geklikt en in het volgende popupmenu gekozen voor nieuwe conditie. Hij heeft een identificatiecode (label Id ) ingevoerd, en Initieel aanwezig geeft aan dat deze conditie vanaf het begin van een case run geanalyseerd wordt. Het toevoegen van de conditie zelf gebeurt door met de rechtermuisknop te klikken op een conditiestringonderdeel in het veld naast het label Conditie (initieel staat daar altijd de tekst _leeg_ ). Er verschijnt een popupmenu met alle mogelijke onderdelen waarmee de conditie kan worden samengesteld: haakjes ( (, ) ), de operatoren en, of en niet, (indien geklikt op een al ingevoerd gedeelte) de opties edit item en verwijder item, en de opties nieuwe componentonderdeelstatustest en nieuwe componentstatustest. Met deze onderdelen zijn willekeurig complexe condities te bouwen. De menu-items van het popupmenu zijn op dit moment nog niet erg contextafhankelijk, waardoor het mogelijk is een syntactisch niet correcte conditie in te voeren. Maar op het moment dat de ontwikkelaar op de knop ok klikt krijgt hij in dat geval de melding Conditie niet valide!. Met de menu-optie nieuwe componentonderdeelstatustest kan de ontwikkelaar een (deel)conditie invoeren die betrekking heeft op elementen uit een component. Met nieuwe componentstatustest voert hij een (deel)conditie in die betrekking heeft op een component in zijn geheel. De componentstatustest kijkt bijvoorbeeld of een student de berichten-component al geopend heeft tijdens de case run. De onderdeelstatustest controleert op geopend zijn van één of meer berichten in de berichtencomponent. Als de ontwikkelaar in het popupmenu van Figuur 13 kiest voor nieuwe componentonderdeelstatustest of voor edit item verschijnt het scherm voor de invoer van een onderdeelstatustest. Momenteel bestaat dit uit een aantal comboboxen waarin de ontwikkelaar een selectie moet maken, een aanvinklijst, en een tekstinvoerveld. Figuur 14 geeft een voorbeeld hiervan. De ontwikkelaar selecteert eerst de rol van de gebruiker waarvoor de deelconditie moet worden getest, en de casuscomponent waarop de conditie betrekking heeft. Nu verschijnt een aanvinklijst met alle elementen die voor de betreffende casuscomponent zijn ingevoerd. In Figuur 14 zien we bijvoorbeeld alle in de berichtencomponent ingevoerde s en mappen. De ontwikkelaar kiest de van belang zijnde berichten en/of mappen, en selecteert vervolgens de statusparameter waarop hij wil testen. Als hij elementen van verschillend type geselecteerd heeft in de aanvinklijst (bijvoorbeeld zowel berichten als mappen), dan moet hij zich wel goed realiseren dat hij een statusparameter kiest die op alle gekozen typen van toepassing is (in de toekomst moet de gepresenteerde parameterkeuzelijst afhankelijk worden van de gekozen elementen, en komt er wellicht nog een elementtype-combox tussen casuscomponent-combobox en element-aanvinklijst). De in de lijst gebruikte naamgeving van de statusparameters kan verschillen van de in dit hoofdstuk per component en componentelement beschreven statusparameters. Per EMERGO-installatie dient er dan ook een vertaaltabel te komen die de gebruikte terminologie koppelt aan de hier beschreven parameters. Na selectie van de parameter kiest de ontwikkelaar eventueel nog een functie die hij wil gebruiken met betrekking tot de parameter. Momenteel zijn twee functies ingebouwd: Aantal, waarmee de ontwikkelaar test hoe vaak een boolean statusparameter de waarde true heeft aangenomen, en Tijd, waarmee de ontwikkelaar kan testen wanneer een boolean statusparameter de waarde true heeft aangenomen. (Is de parameter niet boolean, dan gaat EMERGO, Open Universiteit Nederland 34

35 het om het aantal keren dat en de tijdstippen waarop de parameter van waarde is veranderd.) In het tekstinvoerveld voert de ontwikkelaar een voor de test gewenst getal in. Als hij de Tijd - functie gekozen heeft gaat het dan om het aantal seconden sinds het begin van de case run. De laatste combobox biedt de mogelijkheid te testen op een waarde of een interval; mogelijke keuzes zijn =, <, >, <=, >=, in interval, is in. Figuur13. Scripts: nieuwe conditie invoeren. Als de ontwikkelaar geen functie kiest test het programma de momentane toestand van de statusparameter. In de laatste combobox moet = zijn geselecteerd, en in het tekstinvoerveld moet, in geval van boolean statusparameters, 1 staan, of 0, respectievelijk corresponderend met true en false. In uitzonderingsgevallen is de parameter niet-boolean, maar een geheel getal (bijvoorbeeld version in de berichtencomponent). In die gevallen kunnen combobox en invoerveld ook andere waarden aannemen. De invoer van een componentstatustest is volledig vergelijkbaar met de invoer van een componentonderdeelstatustest. De ontwikkelaar krijgt nu echter geen aanvinklijst met casuscomponentelementen, en de casuscomponentcombobox is vervangen door een casuscomponentaanvinklijst, waardoor een statusparameter voor meerdere casuscomponenten tegelijk kan worden getest. EMERGO, Open Universiteit Nederland 35

36 Figuur 14. Scripts: nieuwe componentonderdeelstatustest. Zodra de ontwikkelaar klaar is met zijn selecties klikt hij op de knop ok onderaan in het statustestinvoerscherm. De gemaakte keuzes verschijnen dan in enigszins cryptische notatie als deelconditie in het conditie-invoerscherm. Eventueel breidt de ontwikkelaar de conditie nog uit met andere bouwstenen en deelcondities, en als hij klaar is klikt hij op ok. De ingevoerde conditie-identificatie verschijnt met het label conditie en eventueel de statusparameter (present) in het scripts-overzichtscherm. Als een ontwikkelaar in het scriptoverzichtscherm na een rechtermuisknopklik op een ingevoerde conditie of actie de optie nieuwe actie kiest in het popupmenu, verschijnt een actie-invoerscherm dat overeenkomt met het conditie-invoerscherm van Figuur 13. Het label Conditie is vervangen door het label Actie. In het bijbehorende veld staat weer de tekst _leeg_, en na een rechtermuisknopklik verschijnt een popupmenu. Omdat een actie in tegenstelling tot een conditie niet uit meerdere deelacties kan worden samengesteld bevat dit popupmenu slechts twee items: nieuwe componentonderdeelzetstatus en nieuwe componentzetstatus. Selectie van nieuwe componentonderdeelzetstatus levert dan bijvoorbeeld een scherm op als in Figuur 15. De ontwikkelaar moet weer eerst een case run-rol kiezen, en een casuscomponent. Dan selecteert hij de van belang zijnde componentelementen. In dit geval kan hij ingevoerde locaties en bijbehorende achtergrondplaatjes kiezen. Vervolgens selecteert hij de gewenste statusparameter. Tenslotte moet hij aangeven of de nieuwe waarde van deze parameter true of false wordt. Analoog aan de statustestinvoer bij condities verdwijnt bij nieuwe componentzetstatus de elementenaaanvinklijst, en is de casuscomponentencombobox vervangen door een casuscomponentenaanvinklijst. EMERGO, Open Universiteit Nederland 36

37 De invoer van een nieuwe wekker ( timer ) is te zien in Figuur 16. In het rechtermuisknopklikpopupmenu in het scriptoverzichtvenster kiest de ontwikkelaar voor nieuwe timer. Hij voert een identificatie in, en de tijdsduur tussen starten van de timer en afgaan van het alarm. Hij kan er ook een repeterende timer van maken, door de knop bij Herhalend aan te vinken. Een repeterende timer is handig als periodiek een bepaalde toestand moet worden ingesteld (bijvoorbeeld een locatie die maar een bepaald gedeelte van de dag toegankelijk is). Figuur 15. Scripts: nieuwe componentonderdeelzetstatus. Figuur 16. Scripts: nieuwe wekker. EMERGO, Open Universiteit Nederland 37

38 4.7 BERICHTEN Oudercomponent: Empack EMERGO-beheerdercode: mail Herbruikbaar: nee Componentstatusparameters: present ( true, initieel) accessible ( true, initieel) opened ( false ) selected ( false ) Basiselementen: map - kenmerken: o name - statusparameters: o present ( true, initieel) o outfolded ( false, initieel) o accessible ( true ) o outfoldable ( true ) o opened ( false ) o selected ( false ) - subelementen: o map o inmailpredef - kenmerken: title refsender type: ref reftype: persontags_mailtags refcomp: persons reftag: person richtext - statusparameters: present ( true ) opened ( false ) selected ( false ) sent ( false ) version ( 0 ) - subelementen: attachment - kenmerken: name blob - blobtypes: database,int_url,ext_url - mediatypes: text,picture,audio,video,other - statusparameters: opened ( false ) EMERGO, Open Universiteit Nederland 38

39 o o o inmailhelp - kenmerken: pid refsender type: ref reftype: persontags_mailtags refcomp: persons reftag: person - statusparameters: present ( true ) opened ( false ) selected ( false ) sent ( false ) version ( 0 ) childnodes ( attachment ) title richtext outmailpredef - kenmerken: title refreceivers type: ref reftype: persontags_mailtags refcomp: persons reftag: person multiple: true - statusparameters: present ( true, initieel) opened ( false ) selected ( false ) sent ( false ) version ( 0 ) childnodes ( attachment ) richtext outmailhelp - kenmerken: pid refreceivers type: ref reftype: persontags_mailtags refcomp: persons reftag: person multiple: true - statusparameters: present ( true, initieel) opened ( false ) selected ( false ) sent ( false ) version ( 0 ) childnodes ( attachment ) EMERGO, Open Universiteit Nederland 39

40 title richtext Door de berichtencomponent op te nemen in zijn casus kan een casusontwikkelaar mailfunctionaliteit inbouwen. Niet alle mogelijkheden van een regulier mailpakket zijn in deze component aanwezig (want daarvoor heeft eenieder een regulier mailpakket), maar wel kan de casusontwikkelaar de noodzakelijke interactie van een student met andere al dan niet virtuele personen reguleren. Figuur 17. Berichten: nieuwe map. Een casusontwikkelaar moet alle berichten die hij ontwerpt plaatsen in mappen. Hij begint dus met de definitie van één of meer mappen en/of submappen. In Figuur 17 zien we dat de ontwikkelaar twee hoofdmappen gedefinieerd heeft, één voor alle inkomende berichten, en één voor de uitgaande berichten. Binnen die hoofdmappen heeft hij weer submappen gemaakt, voor elk casusonderdeel een submap. Bij de definitie van een nieuwe map (na rechtermuisknopklik op de content -balk, of op een al gedefinieerde map komt een popupmenu; kies nieuwe map ) moet de ontwikkelaar een mapnaam invoeren en aangeven of de map vanaf het begin van de case run zichtbaar is, en of hij in uitgeklapte toestand moet worden weergegeven of ingeklapt. EMERGO, Open Universiteit Nederland 40

41 Figuur 18. Berichten: mailkeuzemenu. Als de ontwikkelaar berichten wil toevoegen aan een map klikt hij met de rechtermuisknop op de mapnaam. In het dan verschijnende popupmenu heeft hij de keuze tussen vier soorten berichten (Figuur 18): nieuwe inkomende voorgedefinieerde mail (inmailpredef, Figuur 19) Deze mail wordt door een van de gedefinieerde virtuele personen binnen de case run naar de case run member gestuurd. De ontwikkelaar moet zowel het onderwerp ( Titel ) als de inhoud ( Tekst ) van het bericht invoeren. Ook moet hij aangeven welke virtuele persoon het bericht gestuurd heeft. De virtuele personen heeft hij eerst moeten invoeren in een personen-casuscomponent (zie 4.10). Hij kiest nu eerst in de eerste combobox achter het label Referentie naar afzender de case run member-rol (in het algemeen student ), en vervolgens selecteert hij in de tweede combobox de personencasuscomponent waarin de afzender is ingevoerd. Nu wordt de derde combobox gevuld met alle personen die in de geselecteerde personen-casuscomponent zijn ingevoerd. Hierin selecteert de ontwikkelaar de gewenste afzender. De ontwikkelaar kan ook een of meer bijlagen koppelen aan dit type bericht. Hij voegt eerst het zojuist ingevoerde bericht toe aan de database door op de knop ok te klikken in het bericht-invoervenster. De titel van het zojuist ingevoerde bericht wordt zichtbaar in het berichtenoverzichtvenster (Figuur 18). De ontwikkelaar klikt er met de rechtermuisknop op, en kiest voor nieuwe bijlage. Figuur 20 toont het dan verschijnende venster. De bijlage moet een naam hebben, en kan ofwel een bestand zijn dat via een file-upload-dialoog aan de EMERGO-database is toe te voegen, ofwel een URL naar een mediabestand, hetzij op de EMERGO-server hetzij op een externe server. Toevoegen van een bijlage komt overeen met het toevoegen van een piece in de stukkencomponent (zie paragraaf 4.1 voor een uitgebreide beschrijving). Een inkomend bericht is voor een case run member niet direct in de gedefinieerde map zichtbaar. De casusontwikkelaar zal moeten aangeven op welk moment tijdens de case run dit bericht verzonden wordt. Dit doet hij door in een script-action de sent - statusparameter van dit bericht op true te zetten (zie paragraaf 4.6). De berichtenafspeler in EMERGO zal dan een mailnotificatie aan de student geven, en het bericht zichtbaar maken in de gedefinieerde map. EMERGO, Open Universiteit Nederland 41

42 Figuur 19. Berichten: invoer van inkomend voorgedefinieerd bericht. Figuur 20. Berichten: toevoegen van een bijlage. nieuwe inkomende helpmail (inmailhelp, Figuur 21) Definitie van een hulp -bericht maakt het mogelijk dat een begeleider tijdens het verloop van een case run een hulp -bericht van een student beantwoordt, of die student aanwijzingen geeft als hij constateert dat de student problemen heeft met het doorlopen van de casus. De begeleider doet dit dan binnen EMERGO, hij krijgt als het ware de rol van een virtuele persoon. Op voorhand kan de casusontwikkelaar niet bepalen wat het onderwerp en de inhoud van een dergelijk bericht is (en anders zou hij er een voorgedefinieerd bericht van kunnen maken). Tijdens de case run moeten deze gegevens dus door de begeleider worden ingevoerd. De begeleider kan ook bijlagen toevoegen. Zoals blijkt uit de definitie van het inmailhelp-element worden onderwerp, inhoud en bijlagen in statusparameters, per case run member, bewaard. De casusontwikkelaar kan alleen aangeven in welke rol de begeleider het hulpbericht verstuurt, en in welke map het bericht bij de student komt te staan. Verder voert hij een identificatietekst in. In de case run moet de begeleider ook het moment van versturen aangeven (in theorie kan ook de casusontwikkelaar dit regelen via scripting, maar dat heeft weinig zin tenzij EMERGO, Open Universiteit Nederland 42

43 hij ook onderwerp en inhoud via scripting regelt). De begeleider zal daartoe op een verzend -knop moeten klikken. EMERGO reageert hier dan op door de sent - statusparameter op true te zetten, en de afspeler zal een mailnotificatie aan de student geven. Figuur 21. Berichten: definitie van een inkomend hulpbericht. nieuwe uitgaande voorgedefinieerde mail (outmailpredef, Figuur 22) Door middel van definitie van uitgaande voorgedefnieerde berichten kan de casusontwikkelaar bepalen welke berichten een student binnen EMERGO geacht wordt te versturen. De berichten horen bij een bepaald onderwerp of een gegeven opdracht. Vandaar dat voor de duidelijkheid de casusontwikkelaar de titel van het bericht vastlegt. De inhoud van het bericht (bijvoorbeeld opdrachtuitwerking), en eventuele bijlagen, zullen door de student zelf moeten worden ingevoerd tijdens de case run. Vandaar dat in de outmailpredef-elementdefinitie deze gegevens in statusparameters worden bewaard. De student moet ook het moment van verzenden bepalen via de verzend - knop. De EMERGO-afspeler zal op dat moment een mailnotificatie geven aan eenieder die in de rol van een geadresseerde de case run doorloopt. De casusontwikkelaar voert dus een onderwerp in, en geeft aan naar welke virtuele personen het bericht moet worden gestuurd door de gewenste personen te selecteren uit de lijst behorend bij de geselecteerde personen-casuscomponent. Standaard ziet een student het bericht in de bijbehorende map staan, gereed om te worden verzonden. Maar een casusontwikkelaar kan ook de knop Initieel aanwezig uitzetten. Dan moet hij via scripting zorgen dat het bericht op een gegeven moment in de case run voor de student zichtbaar wordt (hij moet in een actie de present -statusparameter op true zetten). Bijvoorbeeld als de casusontwikkelaar wil dat het bericht pas kan worden verstuurd nadat de student een bepaalde bijbehorende opdracht heeft gekregen. Figuur 22. Berichten: definitie van een uitgaand voorgedefinieerd bericht. EMERGO, Open Universiteit Nederland 43

44 nieuwe uitgaande helpmail (outmailhelp, Figuur 23) De bedoeling hiervan is dat de student op enig moment hulp kan vragen over een zelf gekozen onderwerp. Definitie van een uitgaand hulpbericht is vrijwel gelijk aan de definitie van een uitgaand voorgedefinieerd bericht. Het enige verschil is dat de casusontwikkelaar het onderwerp niet kan invoeren. Dat zal de student zelf moeten doen tijdens de case run. En die kan ook weer de inhoud invoeren en eventuele bijlagen toevoegen. De casusontwikkelaar bepaalt waar het bericht naar toe gaat, en of de hulpvraagmogelijkheid al vanaf het begin van de case run aanwezig is, of via scripting moet worden toegevoegd. Figuur 23. Berichten: definitie van een uitgaand hulpbericht. 4.8 MELDINGEN Oudercomponent: Case EMERGO-beheerdercode: alerts Herbruikbaar: ja Componentstatusparameters: present ( true ) accessible ( true ) opened ( false ) selected ( false ) Basiselementen: alert - kenmerken: o pid o modal ( true ) o richtext - statusparameters: o present ( true ) o selected ( false ) EMERGO, Open Universiteit Nederland 44

45 o sent ( false ) o opened ( false ) o version ( 0 ) De meldingen-component biedt de casusontwikkelaar de mogelijkheid de student tijdens de case run te attenderen op (dreigende) toestandsveranderingen. Figuur 24 toont de invoer van een melding in de melding-casuscomponent. Het meldinginvoervenster verschijnt na een rechtermuisknopklik op de content -balk. De casusontwikkelaar voert een identificatie in, en de tekst die de case run member te zien krijgt. Ook geeft hij aan of de melding in een modaal venster moet worden getoond of niet. Als het meldingvenster modaal is betekent dat dat de case run member pas door kan gaan met de case run op het moment dat hij het meldingvenster sluit. Moeten er veel meldingen worden getoond, en snel na elkaar (bijvoorbeeld bij een intensieve begeleiding van een student), dan verdient het aanbeveling Modaal venster uit te zetten. De student kan dan gewoon doorgaan met de case run, zonder gestoord te worden door/van verplicht te sluiten vensters. Via scripting bepaalt de casusontwikkelaar op welk moment tijdens de case run de melding verschijnt. Hij kan de verschijning bijvoorbeeld afhankelijk maken van het afgaan van een wekker: heeft een student vóór die tijd een opdracht nog niet volbracht, dan wordt hij daarop geattendeerd door middel van een melding. Figuur 24. Meldingen: invoer van een melding. 4.9 TAKEN Oudercomponent: Case EMERGO-beheerdercode: tasks Herbruikbaar: nee EMERGO, Open Universiteit Nederland 45

46 Componentstatusparameters: present ( true, initieel) accessible ( true, initieel) taskscheckable ( false, initieel) opened ( false ) selected ( false ) Basiselementen: task - kenmerken: o name o richtext - statusparameters: o present ( true, initieel) o outfolded ( false, initieel) o accessible ( true, initieel) o required ( true, initieel) o outfoldable ( true ) o opened ( false ) o selected ( false ) o canceled ( false ) o finished ( false ) - subelementen: o task Via de takencomponent kan een casusontwikkelaar aan case run members duidelijk maken wat er van hen verwacht wordt in de casus. Hij kan de noodzakelijke of facultatieve activiteiten rubriceren, en door middel van scripting fasering aanbrengen in de aangeboden functionaliteit tijdens een case run. Het overzicht van te verrichten taken dient te allen tijde beschikbaar te zijn voor een case run member. Vandaar dat deze component zijn eigen startknop heeft in de afspeelomgeving; de case run member hoeft niet eerst de Empack te starten of naar een bepaalde locatie te gaan. Vanwege het feit dat er maar één knop is om de takencasuscomponent te starten is het niet mogelijk om meer dan één takencasuscomponent te tonen in de afspeelomgeving. Daarom kan de casusontwikkelaar ook maar één takencasuscomponent per casus definiëren. Een taak bestaat uit een naam en een omschrijving (Figuur 25). Het invoeren van een nieuwe taak wordt gestart door een rechtermuisknopklik op de content -balk (voor een hoofdtaak) of op een al ingevoerde taak (voor een subtaak bij die taak), en in het dan verschijnende popupmenu te kiezen voor nieuwe taak. De knoppen Vereist (corresponderend met statusparameter required ), Initieel aanwezig ( present ) en Initieel toegankelijk ( accessible ) staan standaard aan, hetgeen betekent dat de taak verplicht moet worden gedaan, en vanaf het begin van de case run in de takencasuscomponentspeler zichtbaar en selecteerbaar is. Een taak is niet standaard Initieel uitgeklapt ( outfolded ): als hij subtaken heeft zijn die niet direct te zien in de afspeelomgeving. De case run member kan de subtaak wel zien door de hoofdtaak uit te klappen, als de outfoldable -statusparameter van de hoofdtaak tenminste niet op false gezet is in een script. Het afgerond zijn van een taak wordt bewaard in de finished -statusparameter. De casusontwikkelaar kan met behulp van scripting deze parameter op true zetten, bijvoorbeeld EMERGO, Open Universiteit Nederland 46

47 als de case run member bepaalde interviews heeft afgerond, bronnen heeft geopend, en berichten verstuurd. De ontwikkelaar kan echter ook de Taken afvinkbaar -knop (statusparameter taskscheckable ) van de casuscomponent aanzetten. Dat betekent dat case run members voor elke taak zelf kunnen/moeten aangeven of ze de taak hebben afgerond (uiteraard kan de casusontwikkelaar altijd nog via scripting finished aanpassen als hij dat noodzakelijk vindt). Afgerond zijn van een hoofdtaak is onafhankelijk van het afgerond zijn van zijn subtaken. Dat betekent dat de casusontwikkelaar altijd nog via script (of de case run member via een aanvinkknop) de finished van de hoofdtaak op true moet zetten als alle subtaken zijn afgerond. Figuur 25. Taken: invoer van een taak. Het Vereist zijn van een taak heeft alleen gevolgen voor de manier waarop die taak in de afspeelomgeving getoond wordt. Ook hier moet de casusontwikkelaar via scripting regelen dat de casus of hoofdtaak afgerond is als alle verplichte (sub)taken afgerond zijn. Een casusontwikkelaar kan fasering aanbrengen in het doorlopen van een case run door via scripting selectief aan- of uitzetten van present -, accessible - en/of outfoldable - statusparameters, en vervolgens, als een case run member een taak selecteert, (weer via scripting) activiteiten, bronnen, berichten, etcetera aan de afspeelomgeving toe te voegen of ze eruit te verwijderen PERSONEN Oudercomponent: Case EMERGO-beheerdercode: persons Herbruikbaar: ja EMERGO, Open Universiteit Nederland 47

48 Componentstatusparameters: geen Basiselementen: person - kenmerken: o name - statusparameters: o present ( true, initieel) In deze component kan de casusontwikkelaar alle virtuele personen definiëren die een rol spelen in zijn casus. De component heeft geen eigen afspeler in de case run-omgeving, vandaar dat er ook geen statusparameters worden bijgehouden. Voorlopig kan de casusontwikkelaar alleen namen van personen invoeren of personen die begin case run aanwezig zijn (Figuur 26). Figuur 26. Personen: invoer van nieuwe persoon. De enige component die op het ogenblik een koppeling heeft met de personencomponent is de berichtencomponent (zie 4.7). Bij elk bericht kan de casusontwikkelaar kiezen van welke persoon het bericht afkomstig is, of naar welke personen het moet worden verzonden. Deze component is ontwikkeld met het oog op toekomstige uitbreiding van functionaliteit. We kunnen dan denken aan de mogelijkheid dat studenten verschillende rollen kunnen aannemen binnen een case run. De case run manager zou elke student aan een virtuele persoon kunnen koppelen (of de student zou misschien zelf een persoon kunnen kiezen), en de student krijgt vervolgens al dan niet de beschikking over bepaalde functionaliteit of bronnen (de casusontwikkelaar kan dat via scripting bepalen, of hij moet in staat worden gesteld per virtuele persoon de inhoud van de casuscomponenten te vullen). Ook zouden virtuele personen elkaars toestand moeten kunnen beïnvloeden. Dit maakt levendige rollenspelen mogelijk ITEMS Oudercomponent: Toetsen EMERGO-beheerdercode: items Herbruikbaar: ja EMERGO, Open Universiteit Nederland 48

49 Componentstatusparameters: geen Basiselementen: item - kenmerken: o pid o type type: singleselect items: mkea selecteditem: o richtext - statusparameters: geen - subelementen: o alternative - kenmerken: pid richtext - statusparameters: geen - subelementen: piece (zie verder) refpiece (zie verder) o feedbackcondition - kenmerken: pid conditionstring type: condition subtype: itemfeedback correct type: boolean score ( 0 ) type: singleselect items: 0,1,2,3,4,5,6,7,8,9,10 selecteditem: richtext - statusparameters: geen - subelementen: piece (zie verder) refpiece (zie verder) o piece - kenmerken: name blob blobtypes: database,int_url,ext_url mediatypes: text,picture,audio,video,other - statusparameters: EMERGO, Open Universiteit Nederland 49

50 o present ( true, initieel) opened ( false ) finished ( false ) selected ( false ) refpiece - kenmerken: name ref type: ref reftype: piecetag_itemstag refcomp: references reftag: piece - statusparameters: opened ( false ) selected ( false ) De itemscomponent is eigenlijk geen zelfstandige EMERGO-component, in die zin dat hij, net zoals de personencomponent, geen eigen afspeler heeft in een case run. Maar terwijl de personencomponent straks een rol gaat spelen bij de invulling van een groot aantal andere componenten is de itemcomponent uitsluitend bedoeld als basis voor de toetsencomponent (paragraaf 4.12). In een itemscasuscomponent kan de casusontwikkelaar de vraagitems invoeren die hij vervolgens kan selecteren bij toetsen die hij bouwt in een of meer toetsencasuscomponenten. De idee van een aparte itemscomponent met een database van vraagitems is, dat elk ingevoerd vraagitem in meerdere toetsen een rol kan spelen. Wanneer de ontwikkelaar de items rechtstreeks als subelement bij de toetsen zou moeten invoeren zou hij elk meervoudig gebruikt vraagitem ook meervoudig moeten invoeren, met allerlei onderhoudsproblematiek als gevolg. Figuur 27. Items: invoer van nieuw vraagitem. Omdat de vraagitems in verschillende toetsen kunnen worden gebruikt ligt het voor de hand dat de itemscomponent en zijn elementen geen eigen statusparameters hebben. Een case run EMERGO, Open Universiteit Nederland 50

51 member kan immers in de ene toets de vraag anders beantwoord hebben dan in de andere toets. De status wordt dan ook bewaard in parameters behorend bij referentie-elementen in de toetsen. De items-database is een platte (één niveau diepe) lijst met vraagitems. Momenteel kan de ontwikkelaar alleen vraagitems van het type multiple choice invoeren (de items -lijst van het item- type -kenmerk bevat alleen het element mkea, ofwel: meer keuze één alternatief ). Elk mkea -item bestaat uit een vraagtekst, alternatieven en feedbackcondities. Zowel aan de vraagtekst als aan de alternatieven als aan de feedbackcondities kan de ontwikkelaar bronnen koppelen. In Figuur 27 is de casusontwikkelaar de itemscasuscomponent vragen Waddenzee aan het vullen. Door met de rechtermuisknop te klikken op de content -balk van het itemsoverzichtscherm en dan te kiezen voor het menu-item nieuw vraagitem komt hij in het iteminvoerscherm. Elk vraagitem heeft een (unieke) identificatie. Het enige vraagtype dat de ontwikkelaar momenteel kan selecteren is mc (is gelijk aan mkea in de componentdefinitie). In de richtext-tekstverwerker kan hij de vraagtekst inoeren. Bij elk ingevoerd item dient de casusontwikkelaar alternatieven en feedbackcondities in te voeren. Hij kiest daartoe de geschikte menuitems uit het popupmenu dat verschijnt na een rechtermuisknopklik op de identificatie van een ingevoerd item in het itemsoverzichtscherm. De alternatiefinvoer (Figuur 28) ziet er hetzelfde uit als de iteminvoer. De identificatie is uniek voor dit item (en het is voor de herkenbaarheid in een scriptscasuscomponent verstandig om hem voor de gehele casus uniek te maken). Figuur 28. Items: invoer van nieuw alternatief. Kiest de ontwikkelaar voor de invoer van nieuwe feedbackconditie, dan krijgt hij een invoervenster als weergegeven in Figuur 29. De conditie bestaat uit een identificatie ( pid ), een logische bewering ( conditionstring ), een goed/fout-indicator ( correct ), een cijfer ( score ; geheel getal tussen 0 en 10), en een feedbacktekst ( richtext ). EMERGO, Open Universiteit Nederland 51

52 Figuur 29. Items: invoer van nieuwe conditie. De logische bewering wordt op een zelfde manier geconstrueerd als in de scriptscomponent (paragraaf 4.6). De ontwikkelaar heeft dezelfde bouwstenen ter beschikking, alleen zijn de menuitems nieuwe componentonderdeelstatustest en nieuwe componentstatustest vervangen door nieuwe itemalternatieftest. De hier in te voeren conditiestring is namelijk rechtstreeks gekoppeld aan de alternatieven die ingevoerd zijn bij het betreffende item. Als een ontwikkelaar de feedback op een alternatiefkeuze afhankelijk wil maken van de toestand van andere items of zelfs (elementen uit) casuscomponenten, dan zal hij dat via scripting (gebruik makend van de statusparamers van de bijbehorende itemreferentie uit de bijbehorende toetsencasuscomponent, en met feedback in de vorm van meldingen-acties) moeten regelen. Figuur 30 toont de invoer van een itemalternatieftest -onderdeel van een conditionstring. De ontwikkelaar kan alleen selecteren uit de alternatieven ingevoerd bij het huidige vraagitem. Omdat de itemalternatieven geen eigen statusparameters hebben, en er ook geen referentiealternatieven gedefinieerd zijn in de toetsencomponent koppelt het programma automatisch bij het afhandelen van een itemfeedback -conditie de geopend -parameter aan elk gekozen alternatief. In het invoervenster kan een casusontwikkelaar meer dan één alternatief kiezen om op te testen. Omdat tot dusver alleen mkea -type vraagitems kunnen worden ingevoerd, is dit alleen zinvol als het gaat om een geopend=0 -test, dus om het niet-gekozen zijn van alternatieven. Figuur 30. Items: invoer van conditieonderdeel. EMERGO, Open Universiteit Nederland 52

53 Het invoerscherm voor het toevoegen van bronnen ( piece -element) aan vraagtekst, alternatieven en feedbacktekst (verschijnt na de menuitemkeuze nieuw stuk ) ziet er precies hetzelfde uit als het invoerscherm voor het toevoegen van stukken aan een stukkencasuscomponent. Voor de te volgen procedure verwijzen we naar paragraaf 4.1. De hier toegevoegde bronnen hebben wel hun eigen statusparameters. Het zou bijvoorbeeld vreemd zijn dat wanneer een case run member een bron gezien heeft bij een vraagitem in een toets, de opened -status van de bron bij dat vraagitem in een andere toets nog op false zou staan. Eenmaal geopend blijft geopend, ongeacht in welke toets het vraagitem voorkomt. Een casusontwikkelaar kan ook een bron willen gebruiken die hij al eerder in een stukkencasuscomponent heeft toegevoegd. Dit is mogelijk, hij dient dan het popupmenuitem nieuwe referentie naar stuk te selecteren (Figuur 31). De ontwikkelaar kiest in het invoerscherm de gewenste stukkencasuscomponent, en vervolgens selecteert hij het gewenste stuk uit de bijbehorende stukkenlijst. De referentie naar dit stuk heeft wel eigen opened - en selected -statusparameters, maar geen eigen present -statusparameter. Die wordt overgenomen van het gerefereerde stuk. Op deze manier kan worden voorkomen dat de case run member via een toetsvraagitem een stuk kan openen dat nog niet aanwezig is in een stukkencomponent (bijvoorbeeld omdat de case run member dit stuk pas te zien krijgt als hij bepaalde opdrachten heeft afgerond). Figuur 31. Items: invoer van referentie naar een stuk TOETSEN Oudercomponent: Empack EMERGO-beheerdercode: assessments Herbruikbaar: ja Componentstatusparameters: present ( true, initieel) accessible ( true, initieel) directfeedback ( true, initieel) opened ( false ) selected ( false ) Basiselementen: EMERGO, Open Universiteit Nederland 53

54 assessment - kenmerken: o name o richtext o numberofiitems o duration - statusparameters: o present ( true, initieel) o opened ( false ) o selected ( false ) o finished ( false ) o score ( 0 ) o sent ( false ) o version ( 0 ) - subelementen: o refitem - kenmerken: pid ref type: ref reftype: itemtag_assessmenttag refcomp: items reftag: item weighting ( 1 ) type: singleselect items: 0,1,2,3,4,5,6,7,8,9,10 selecteditem: - statusparameters: opened ( false ) selected ( false ) answer feedbackcondition o feedbackcondition - kenmerken: pid conditionstring type: condition subtype: assessmentfeedback richtext - statusparameters: opened ( false ) selected ( false ) Met behulp van een toetsencasuscomponent kan een casusontwikkelaar een of meer toetsen aan zijn casus toevoegen. Elke gedefinieerde toets krijgt zijn eigen startknop op de Empack. Door meerdere toetsencasuscomponenten te definiëren kan een casusontwikkelaar de toetsen verdelen in groepen. De present - en accessible -componentstatusparameters bieden dan de mogelijkheid om alle toetsen uit een groep gelijktijdig aan te bieden aan een case run member, of ze te vervangen door toetsen uit een andere groep. Per toetsgroep kan een casusontwikkelaar EMERGO, Open Universiteit Nederland 54

55 ook beslissen of een case run member op elk vraagitem direct bij elke alternatiefselectie feedback krijgt, of zelf actief om feedback moet vragen. In Figuur 32 is het invoerscherm voor een nieuwe toets (element assessment ) te zien. De casusontwikkelaar heeft voor deze casuscomponent beslist dat er direct feedback moet komen ( MKEA direct feedback corresponderend met statusparameter directfeedback is aangevinkt). De toetsen uit deze casuscomponent zijn in principe vanaf het begin van de case run beschikbaar. Een toets heeft een titel (het Naam -veld), en een omschrijving ( Tekst -veld). De ontwikkelaar moet ook het aantal items aangeven dat een case run member moet beantwoorden. Hij geeft verder aan hoe lang een case run member mag doen over de toets. Met de aanvinkknop Initieel aanwezig beslist de ontwikkelaar of deze toets al vanaf het moment dat deze casuscomponent beschikbaar komt gestart kan worden of niet. Figuur 32. Toetsen: invoer van toets. Na definitie van een nieuwe toets zal de ontwikkelaar in eerste instantie de vraagitems willen koppelen aan de toets. Hij klikt met de rechtermuiskop op de toetsnaam in het toetsenoverzichtscherm, en kiest voor nieuwe referentie naar item. In Figuur 33 zien we het referentieinvoerscherm. Een referentie heeft een identificatie en een koppeling naar een eerder in een itemscasuscomponent ingevoerd vraagitem. De ontwikkelaar kies bij Referentie de gewenste itemscasuscomponent en vervolgens het gewenste vraagitem. Hij kan ook aangeven hoe belangrijk deze vraag voor deze toets is vergeleken met andere vraagitems. Daartoe kiest hij in het Weging -veld een waarde tussen 0 (de vraag telt niet mee) en 10 (de vraag is maximaal belangrijk). Als de ontwikkelaar deze weging wil laten afhangen van het beschikbaar komen van extra informatie, of van gedane activiteiten, dan zal hij een nieuwe toets moeten definiëren die alleen op weging verschilt van de huidige toets, en deze toets via scripting moeten aanzetten in plaats van de huidige toets. Als de ontwikkelaar bij een toets meer vragen EMERGO, Open Universiteit Nederland 55

56 invoert dan er gesteld worden in een case run, dan bepaalt het programma een random selectie uit de totale lijst ingevoerde vraagitems. Figuur 33. Toetsen: invoer van referentie naar vraagitem. Figuur 34. Toetsen: invoer van toetsconditiefeedback. Na invoer van de items kan de ontwikkelaar de conditieafhankelijke toetsfeedback gaan invoeren ( feedbackcondition -element, van het type assessmentfeedback ). Hij kiest hiervoor het rechtermuisknopklikpopupmenuitem nieuwe feedbackconditie. Figuur 34 toont het invoerscherm. Nadat hij een conditieidentificatie en feedbacktekst heeft ingevoerd kan hij de logische bewering invoeren waarop het programma moet testen. De bouwstenen die hij hiervoor kan gebruiken zijn gelijk aan de bouwstenen die hij gebruikt in een scriptscasuscomponent (zie paragraaf 4.6). Na selectie van nieuwe componentonderdeelstatustest is in het conditieonderdeelinvoervenster (Figuur 35) de huidige toetsencasuscomponent voorgeselecteerd, en tevens de statusparameter score. De ontwikkelaar moet alleen nog de juiste toets selecteren en een gewenste score invullen, en eventueel nog een relationele parameter kiezen ( =, >, etcetera). Het staat de ontwikkelaar in dit geval (in tegenstelling tot bij de conditieinvoer in de itemscasuscomponent) echter vrij om een willekeurige statusparameter van een willekeurig element van een willekeurige casuscomponent te testen. EMERGO, Open Universiteit Nederland 56