Ontwerpen en ontwikkelen van multimedia

(het Methoden & Technieken-project)

Door Rik Min

In deze tekst komen de volgende begrippen voor: multimedia, courseware, educatieve software, leermiddelen, instructiemiddelen, ontwerpen, ontwikkelen, top-down, bottum-up, software-engineering, rapid prototyping, evolutionair ontwerpen, technologie, methodologie, methoden, technieken en instrumentatietechnologie.

Inleiding

De wereld van de informatie- en communicatietechnologie (IT en/of ICT) is enorm in beweging; en dientengevolge ook de wereld van de educatieve instrumentatietechnologie (ISM). Een vloedgolf van nieuwe technieken en nieuwe media komt op ons af; niet alleen op de consument, ook en vooral op de ontwerper van multimedia en de onderzoeker. De ontwerper wordt heen en weer geslingerd tussen verschillende min of meer wetenschappelijke opvattingen over het ontwerpen en ontwikkelen van multimediale software. Daarom dient een ontwerper - en zeker een aankomend ontwerper - een bepaald houvast te hebben aangaande essentiele basisbegrippen.

Binnen het op zich zeer brede vakgebied van de instrumentatietechnologie is het een komen en gaan van methoden, technieken, theorieen, concepten, ontwerp-richtlijnen, plannen van aanpak en filosofieen over hoe interactieve educatieve software moet worden ontworpen en er voor de gebruiker uit moet zien; en met welke tools een en ander moet worden gerealiseerd (Tannenbaum: T: 409-412). Dit wetenschapsgebied loopt van ergonomie en de kennis van human factors en interfaces tot zuivere computerkunde en van programmeertechnieken tot mediakeuze-onderzoek.

Er worden door de afdeling ISM een groot aantal theoretische vakken verzorgd, inclusief een groot aantal praktica op het gebied van multimedia en software-engineering. Daarbij worden zowel algemene ontwerpmethodes onderwezen als nieuwe methoden en technieken aan de orde gesteld. Zo werken wij het meeste samen met de afdeling IST; vooral als het de toegepaste methode van onderwijs of de instructie component die bij een multimediale leeromgeving hoort betreft.

Over het ontwerpen van volwaardige interactieve programmatuur, en in het bijzonder over educatieve software en multi- en hypermediale-produkten (T: p.437), bestaat een groot aantal subjectieve meningen tegenover slechts een klein aantal empirisch onderbouwde, objectieve theorieen. De afdeling ISM (voorheen 'vakgroep ISM') heeft de opdracht om enerzijds in het onderwijs van de faculteit aandacht te schenken aan deze veelheid van meningen over ontwerpen en anderzijds de taak een samenhangend curriculum van met name practica te ontwerpen en te onderhouden.

Definitie: Multimediale produkten zijn interactieve software produkten die op (eenvoudige, betaalbare) beeldschermen worden gepresenteerd en op (eenvoudige, betaalbare) computers draaien, die door mensen worden bedacht, gemaakt en gebruikt omwille van de (onderwijskundige) eigenschappen die zij bezitten en de (didactische) functies die zij kunnen vervullen. Technisch gesproken dient een multimediaal product altijd audiovisuele componenten in digitale vorm te bevatten.

In de leestekst komt aan de orde welke aspecten bij respectievelijk de ontwerp-fase zowel als bij de ontwikkel-fase van een produkt aan de orde komen. In een enkel geval zal de ontwikkel-fase gelijk vallen met de ontwerp-fase (bij de rapid prototyping ontwerp-methode), maar in de meeste ontwerp-modellen die hier aan de orde komen dienen deze fases strikt gescheiden te worden.

De leestekst moet na bestudering van de stof een indruk geven hoe instrumentatieproblemen binnen de onderwijskunde (op micro-niveau) moeten worden aangepakt en kunnen worden opgelost. Oplossingen op micro-niveau moeten altijd in het licht van problemen en context op een andere niveau worden gezien.

Soorten educatieve multimediale producten

Binnen de instrumentatietechnologie ligt de nadruk op de hedendaagse moderne leermiddelen en met name de leermiddelentechnologie. Binnen de leermiddelentechnologie spelen software engineerings methoden (T: p.391) en high tech informatie- en communicatietechnieken een overheersende rol. Typische produkten, welke binnen het vakgebied van de instrumentatietechnologie bestudeerd, onderzocht, beschreven en in haar onderwijs - in volgorde van ancienniteit - aan de orde komen, zijn:
• traditionele leermiddelen;
• traditionele instructiemiddelen;
• audiovisuele instructiemiddelen;
• digitale leermiddelen;

Tot de traditionele leermiddelen kun je boeken, spelletjes, practicum-opstellingen, etc. rekenen; tot de traditionele instructiemiddelen opdrachtformulieren, bepaalde type lesboeken, handleidingen, etc. Tot de audiovisuele instructiemiddelen worden videofilms, instructie-tapes, sheets, wandplaten, etc. gerekend. Instructiemiddelen zijn (meestal) niet interactief en soms digitaal; derhalve zijn het one-way-media. Digitale leermiddelen zijn computer-based en interactief. Dat zijn dus two-way-media.
Tot de digitale leermiddelen worden gerekend: electronische leeromgevingen (in het algemeen), moderne instructiemiddelen, courseware, educatieve spelen, drill and practice, simulaties, onderwijskundige WEB-sites, help-systemen, testsystemen, video-conferencing systemen (kortom computer ondersteund onderwijs in de ruimste zin van het woord). Deze indeling van leermiddelen en media die in het onderwijs een rol spelen is in het eerste jaar uitgebreid aan de orde gekomen. De termen educatieve software en digitale leermiddelen zijn feitelijk synoniem.

Term: 'Educatieve software' of 'digitaal leermiddel'? Het hangt feitelijk af vanuit welk gezichtspunt je naar dit fenomeen kijk: Tannenbaum is - in dit boek - meer een ontwerper dan een didacticus en gebruikt meestal de term educatieve software (p.391); een school of een docent spreekt eerder van een digitaal leermiddel.

Er zijn allerlei termen voor leer- en instructiemiddelen en er zijn allerlei subtiele verschillen tussen de termen; maar ook accenten-verschillen. Elke term heeft zijn onderwijskundige en didactische voor- en nadelen. We noemen hier een paar belangrijke oudere, wetenschappelijke termen en wat nieuwere:

oudere termen:
• Computer Assisted Instruction (CAI) (1970)
• Computer Ondersteund Onderwijs (COO) (1978)
• Computer Based Training (CBT) (1980)
• multimedia (MM) (1985)
• courseware
nieuwere termen:

• Web Based Training (WBT) (1997)
• Web-Based Courseware
• Web-Based Leermiddel
• Digitale Leermiddelen (DL)
• e-Learning (1999)

Karakteristieke produkten, welke momenteel binnen een vakgebied als de instrumentatietechnologie bestudeerd, onderzocht, beschreven en in het haar toebedeelde onderwijs aan de orde komen, zijn: interactieve leermiddelen in de gedaante van electronische, beeldschermgeorienteerde leeromgevingen, zoals de twee belangrijkste van dit moment: de stand alone leermiddelen (CD-i, CD.rom) en de on-line leermiddelen op het world wide web.
Altijd is het aan het begin van elk ontwerp- of ontwikkel-traject nodig goed in de gaten te houden welke soort software men aan het maken is. Wetenschappelijk gezien heeft elke soort educatieve software zijn eigen specifieke onderwijskundige of didactische mogelijkheden.

Door de komst van het web is er een verschuiving opgetreden van 'computer based' naar web-based'. Er zijn allerlei (specifieke) soorten educatieve software. Elke soort educatieve software werkt anders en heeft zijn bijzondere onderwijskundige voor- en nadelen, maar elke soort heeft ook zijn eigen specifieke manier van ontwikkelen; dat is voor ontwerpers en ontwikkelaars nog het aller belangrijkste. We noemen hier de belangrijkste soorten en hoe ze in het algemeen ontwikkeld worden. Hier volgen een paar soorten en de manier waarop ze meestal ontwikkeld worden:

• Tutorial-achtige programma's (ook wel de gewone courseware genoemd): worden in het algemeen gemaakt met 'auteurs-systemen' (bijvoorbeeld met AuthorWare of Fusion);
• Drill & practice-achtige programma's: moeten, vanwege het feit dat er vaak veel animaties in voorkomen, het beste worden ontwikkeld met hogere programmeer-talen of script-talen (zoals met Java, Javascript of Flash ActionScript, etc.);
• Hypertekst-achtige programma's: kunnen op alle mogelijke manieren gemaakt worden. Dat varieert van auteurs-systemen, auteurs-talen tot hogere programmeer-talen (zoals bijvoorbeeld met Visual Basic, Toolbook, PageMaker, Fusion, HTML en/of JavaScript);
• Simulaties en met name model-driven simulaties: kunnen, vanwege het feit dat ze modellen bevatten, een goede performance moeten hebben en vaak veel moeten rekenen, het beste altijd maar via een goede voorgeprogrammeerde source-code ontwikkeld worden; derhalve kunnen ze het beste met 'programma-generatoren' ontwikkelt worden (bijvoorbeeld met JavaTHESIS of met de tool MacSimAuthor). (Dan kom je uit op hogere programmeertalen die gecompileerd moeten worden, zoals Pascal en Java of op script-talen die - in een browser - geinterpreteerd (T: p.438) moeten worden, zoals JavaScript of Flash ActionScript)
• Web-sites in het algemeen, maar ook web-based courseware in het bijzonder: kan in het algemeen het beste worden ontwikkeld met auteurs-systemen maar ook vaak met gewone tekst-editors. Courseware-achtige web-sites met tekst en plaatjes kunnen snel en efficient met goede tools worden gemaakt (zoals DreamWeaver, PageMaker of Fusion);
• Lineaire, frame-by-frame-animatie: moet gemaakt worden met animatie-editors, zoals ShockWave, Flash of Liquid Motion; Veel van deze animatie-editors en met name Flash en ShockWave hebben ook scripting mogelijkheden (zoals bijvoorbeeld het script-taaltje Lingo en ActionScript).
• Interactieve animatie: moet - vanwege performance redenen - bijna altijd gemaakt worden in een hogere programmeertaal; en ook meestal toch gecompileerd worden;
• Twee of drie-dimensionale VR-animatie: zoals die welke met Cosmo-player afgespeeld kunnen worden, moeten met speciale modelling-tools worden gemaakt;
• Expert systemen (T: p.374, 436)of andere vormen van intelligente courseware of intelligente simulaties (d.w.z. smart systems): kunnen het beste gemaakt worden met hogere programmeer-talen, zoals Lisp, SmallTalk of Prolog, maar ook met Java;

Opmerking: Een programma-generator is een systeem of tool, welke source-code kan genereren. Daarna moet de source-code nog wel worden gecompileerd of geinterpreteeerd (T: p.358). Een voorbeeld is het JavaTHESIS-systeem of MacSimAuthor. Dat laatste systeem is een editor en genereert automatisch source-code; het eerste systeem genereert semi-automatisch java-applets.

Als Toegepast Onderwijskundige (TO-er) dient men al deze namen voor de verschillende soorten educatieve software te kennen en ook steeds te onderscheiden. Elke naam of elke soort dekt toch meestal iets anders.

In dit artikel zullen we zoveel mogelijk de algemene term educatieve software gebruiken. Die term is haast per definitie multimediaal en hypermediaal (en interactief, electronisch en digitaal). In dit artikel is alles wat we aan educatieve software beogen web-based.

Web-based software of courseware

Web-based software of courseware ziet er altijd uit als een web-site. Web-sites zijn er echter in allerlei soorten en maten. Opvallend zijn de enorme kwaliteits verschillen. Ook is er een enorm verschil tussen een site die publiek toegankelijk is - en commercieel moet zijn - versus sites die specifiek in het onderwijs of bij een enkele vak gebruikt worden. De meeste web-sites op het world wide web zijn geen courseware. Wanneer is nu een web-site courseware en wanneer is een web-site eigenlijk geen courseware. En wanneer spreken we van een echt (digitaal) leermiddel?
Om deze spraakverwarring kort te sluiten, introduceren we daarom hier het begrip orde. We spreken van '1e orde courseware' en '2e orde courseware' (en zelfs van '0e orde courseware'). We moeten web-sites dus altijd didactisch en onderwijskundig de maat nemen. We dienen een soort rangorde, een niveau of een orde aan web-sites te geven. We onderscheiden derhalve in dit artikel drie verschillende ordes van (web-based) courseware:
• '0e orde courseware': Een gewone web-site die niet gebruikt wordt in het onderwijs en/of niet speciaal leer-teksten bevat, noemen we 0e orde courseware; het is dan - mooi gezegd - geen courseware, maar wel een web-site met allerlei digitale elementen.
• '1e orde courseware': Een web-site waarmee iets geleerd kan worden of die informatie bevat die men binnen onderwijssituaties gebruikt of kan gebruiken, noemen we 1e orde courseware, d.w.z. gewone, 'platte' courseware met tekst, plaatjes en lineaire elementen, zoals video en audio, en degelijke.
• '2e orde courseware': Een web-site die er allelei dynamische en 'slimme' elementen bevat en er uitziet als een 'echt' leermiddel noemen we 2e orde courseware, dus courseware van een hogere orde of een niveau hoger dan gewone courseware. We noemen dat echte digitale leermiddelen. Voorbeelden daarvan zijn in web-sites geintegreerde micro-werelden of model-driven simulaties (in de vorm van applets) en dergelijke.
Al deze soorten courseware en web-sites komen in het vak van Kommers en Min, "Multimedia-ontwerp en -productie", aan de orde. Bij de opdrachten van Min ligt het accent op 2e orde courseware met interactieve applets en scripts; bij die van Kommers meer op 1e orde courseware met veel video.

Ontwerpen in relatie tot Wetenschap

Ontwerpen wordt binnen de software-engineeringswereld niet als zodanig als een wetenschap gezien maar als 'ingenieurskunde' ('ontwikkelkunde' of 'engineering'). Techniek en het toepassen van techniek zijn het resultaat van vele soorten ervaringen. Ook ervaringen uit wetenschappelijk onderzoek horen hierbij. Ontwerpen op zichzelf kan daarom beter geen wetenschap worden genoemd. Tenzij je aangeeft onder welke condities ontwerpen wetenschap is. We moeten ons realiseren dat ontwerpen voor een heel groot deel een subjectief gebeuren is. De uiteindelijke vorm of de gekozen oplossing is namelijk direct afhankelijk of onderhevig aan smaak, mode en subjectieve inschattingen. Ontwerpen heeft wel veel - maar niet alles - met wetenschap te maken. Immers elk produkt, hoe bescheiden soms ook, bevat kennis die door wetenschappers (en anderen) is verzameld. De wetenschap der techniek wordt technologie genoemd. Technologie is dus wel een wetenschap.

De beste definitie van ontwerpen - in dit verband - is:

Ontwerpen is een iteratief redeneerproces om een bepaald doel te bereiken en waarbij zoveel mogelijk gebruik gemaakt wordt van wetenschappelijk onderbouwde en (empirisch onderzochte en beproefde) kennis uit andere disciplines.

Het ontwerpen van onderdelen van een groter geheel is de minst subjectieve bezigheid. In een totaalontwerp komen sommige oplossingen volkomen rationeel tot stand. Die objectief tot stand gekomen oplossingen zijn over het algemeen gebaseerd op resultaten van (wetenschappelijk) empirisch onderzoek aan de hand van prototypen. Maar vaak ook ingegeven door marktmechanismen, in de zin dat een produkt niet 'loopt' als het publiek een produkt eenvoudig (nog) niet koopt.

Er bestaat een groot aantal meningen en interessante definities van of over ontwerpen; ongeveer gelijkluidend als bovenstaande, definitie. Hier volgen er enkele:

• Ontwerpen is het uitdenken en vastleggen van functies en eigenschappen in plannen die voor het maken nodig zijn.

• Ontwerpen is een iteratief redeneerproces van functie naar vorm waarbij gebruikt wordt gemaakt van wetenschappelijk onderbouwde en zo mogelijk beproefde kennis uit de voor het produkt relevante disciplines.

• Ontwerpen kent geen ander doel dan het realiseren van een concept. Via prototypen van dit concept wordt bewezen dat het ontwerp werkt en dus succesvol kan worden toegepast.

• Ontwerpen is een methodologie of strategie voor het oplossen van maak-problemen.

Binnen de instrumentatietechnologie worden al deze definities geaccepteerd. Ze overlappen elkaar ook grotendeels. Projectleiders die geintegreerde multimediale produkten moeten ontwerpen en ontwikkelen, dienen het besef te hebben dat tekst, geluid en bewegend beeld zo ieder hun eigen conventies, wetmatigheden en ontwerp-aanpak kennen. De kunst voor de projectleider is al deze visies en oplossingen zo zorgvuldig mogelijk op elkaar af te stemmen.

Volgens Plomp (1992) kunnen problemen waarvoor oplossingen moeten worden ontwikkeld, worden ingedeeld in weet-, kies- of maak-problemen. Ontwerpen is echter duidelijk produktgericht en onderscheidt zich van andere sociaal wetenschappelijke activiteiten. Immers de sociale wetenschap is een discipline die onderzoek doet om weet- en kies-problemen op te lossen. Kunstenaars en sommige vormgevers beoefenen het ontwerpen echter als vrije kunst. Het ontwerpen van multimediale produkten vereist in de praktijk een combinatie van inhoudelijke kennis (aangaande de 'content'; T: p.420), wetenschappelijke kennis (aangaande 'methoden en technieken'), technische kennis (aangaande 'tools'), creativiteit (slim zijn) en ambacht (handig zijn) tegelijkertijd.

Benaderingswijzen / Invalshoeken

Er bestaan in onze optiek tenminste drie soorten benaderingen of invalshoeken bij het ontwerpen en ontwikkelen van edicatieve software:

a. Top-down benadering. Deze benadering legt het primaat op het totaalontwerp. De onderdelen dienen later, afzonderlijk ingevuld te worden. De aanhangers van deze benadering gaan er van uit dat daar dan geen problemen meer bij kunnen optreden. De details rekent men niet tot het probleemgebied. Het overall-ontwerp is het enige aan te pakken probleem. De voordelen zijn evident. Een nadeel is dat studenten vaak met standaard-oplossingen komen en soms opmerkelijk weinig creativiteit tonen. Dat nadeel is - om allerlei redenen - bij de bottom-up aanpak minder. (Een voorbeeld van deze benaderingswijze is de manier van denken die bij de OKT-vakken en bij dit vak 'MMOP' aan de orde komt/is.)

b. Bottom-up benadering. Deze benadering legt het accent op onderzoek naar nieuwe methoden en technieken om te ontdekken of die een bijdrage kunnen leveren aan het geheel. Met deze gegevens kan een ervaren ontwerper dan ten alle tijden produkten, bijvoorbeeld programmatuur, ontwerpen waarbij de nieuwe technieken direct kunnen worden ingezet. Deze benadering kan dus veel sneller anticiperen op nieuwe technieken dan de voorgaande benadering. De details rekent men expliciet tot het probleemgebied. Het overall ontwerp is verder een kwestie van goed teamwork. De voordelen van deze onderwijsaanpak is dat - door de ruime keus van methoden en technieken die hij heeft leren toepassen - de student veel soorten keuzes kan maken in zijn uiteindelijke produkt-ontwerp. (Een voorbeeld van deze benaderingswijze en manier van denken kwam voor bij het inmiddels afgeschafte ISM-vak 'multimedia programmeren', waar practicumopdrachten met javascript moesten worden opgelost.)

c. De specialisatiebenadering. Deze benadering legt het accent op de vormgeving van zowel het geheel als van specifieke details (los te koppelen van het construeren van de eindoplossing). De vormgeving van de afzonderlijke onderdelen is bij deze benadering doorslaggevend. Het gaat de ontwerper in deze benadering primair om de figuren, de teksten en de (video)beelden. Evenals dat gebeurt bij universitaire vormgeversopleidingen en bij grootschalige filmprodukties. Hierbij zijn alle functies in het produktieproces consequent en duidelijk gescheiden. Technieken en programmeermethoden rekent men in de vormgeverswereld nu eenmaal niet tot het probleemgebied. Deze duidelijke scheiding tussen vormgeving en het programmeren is in het geval van interactieve multimedia zeer logisch en legitiem. De programmeur en de instrumentatietechnoloog kunnen en mogen dus het constructieprobleem geheel naar eigen inzicht oplossen, maar de vormgever heeft het laatste woord. Rapid prototyping speelt in deze benaderingswijze een grote rol. Hiermee kunnen vormgevers en programmeurs (maar ook andere betrokkenen) beter (en met name in het vroegste stadium) met elkaar communiceren. (Een voorbeeld van deze benaderingswijze en manier van denken kwam voor in de voormalige ISM-vakken 'ISM 1' en 'Mediakunde' van Min, Schmitz en Jonker.)

Een voorbeeld van deze derde benaderingswijze is de manier van denken die bij het maken van films en televisieprogramma's aan de orde is en tegenwoordig ook bij grootschalige multimedia producties, zoals bij het ontwerpen en ontwikkelen van CD-rom's en CD-i's, waarbij zeer veel verschillende disiplines betrokken zijn. Op het web zie je deze ontwikkeling nu ook.

Methoden en Technieken

Binnen de instrumentatietechnologie spelen de begrippen methodologie en 'methoden en technieken' een grote rol. Het ene begrip heeft veel te maken met de top-down benaderingswijze en het andere begrip meer met de bottom-up benadering. Onder technieken worden in deze verhandeling bepaalde opties of nieuwigheden in bepaalde gereedschappen, systemen of hardware verstaan. Ook technische nieuwigheden worden technieken genoemd; bijvoorbeeld moderne audiovisuele presentatietechnieken. (Tools of gereedschappen worden in deze tekst voor het gemak tot de technieken gerekend.) Onder methoden verstaan we expliciete kennis en zaken die te maken hebben met het realiseren van software en het integreren van losse, statische multimediale componenten in een geheel: dus hoe en met welk systeem een totaalprodukt gemaakt wordt. Dus bijvoorbeeld door gebruik te maken van een specifieke auteurstaal (T: p.359), een specifiek hogere programmeertaal of een specifieke soort editor e.d.

Als de keuze van de methode of een ontwerp-systeem vastligt komt - in deze benaderingswijze - de methodologie aan de orde: hoe men - gegeven een bepaalde ontwerp-methode - dan verder handelt. Er dient dus duidelijk onderscheid te worden gemaakt tussen de beide begrippen methode en methodologie.
Een methode of een 'ontwerp-methode' is altijd (veel) meer dan een 'techniek'. En 'methodologie' is meer dan een methode: waardevrijer. In ieder geval is de methodologie (van het ontwerpen) altijd algemener en onafhankelijker dan de gebruikte methode (in de realisatie fase), laat staan ten opzichte van de hele specifieke en in wezen - voor een universitaire studie - onbelangrijke technieken, zoals een programmeur in de programmeer-fase tegenkomt. Derhalve kunnen de volgende definities, voor een beter begrip aangaande deze benaderingswijze, een steun zijn:

Technieken zijn (in dit verband) bepaalde mogelijkheden, opties of nieuwigheden, die in bepaalde gereedschappen zitten, of met bepaalde gereedschappen kunnen worden uitgevoerd. (Bijvoorbeeld 'cutten' en 'pasten')
Methoden zijn (in dit verband) (in het team vast te leggen) realisatie-wijzen die te maken hebben met het realiseren van een (totaal-)produkt, hier meestal een ontwerp-methode of een plan van aanpak. (Bijvoorbeeld het kiezen van het juiste auteurssysteem of de juiste hogere programmeertaal; gebasseerd op de juiste argumenten; onder de gegeven condities.)

Methoden en technieken ontstaan als het ware van onderop; zij worden over het algemeen op een haast autonome manier (d.w.z. 'oncontroleerbaar') gegenereerd door de industrie, maar ook door de wetenschap zelf. De technologie en de methodologie zijn de wetenschapsgebieden die dit in kaart brengen, analyseren en synthetiseren.

Wat is nu het verschil tussen methoden en methodologie? In het Nederlands taalgebruik (en binnen de instrumentatietechnologie) heeft het woord methodologie twee betekenissen. De eerste betekenis is die van beschrijving, verklaring en waardebepaling. Daarnaast wordt het woord vaak gebruikt ter aanduiding van een bepaalde methode. Hier volgen enkele definities. De eerste is van algemene aard:

Methodologie is (in dit verband) het totaal aan kennis en inzicht van methoden die bij het ontwerpen worden of kunnen worden toegepast.

Een tweede definitie is nog:

Methodologie is (in dit verband) een hogere orde werkwijze. (In de zin van: welke aanpak? Welke ontwerp-methoden gaat men gebruiken, gegeven een bepaalde methode, bepaalde regels, bepaalde theorieen, bepaalde procedures, bepaalde richtlijnen, bepaalde 'kookboeken', etc.? Zie bijvoorbeeld het W.J. Zwart-model of het OKT-model. Zie elders)

Maar de beste en wetenschappelijk best omschreven definitie gaat uit van de overeenkomst tussen de twee fundamenteel verschillende woorden 'techniek' en 'technologie', namelijk zoals technologie de 'leer (of de wetenschap) der technieken' is, geldt naar analogie daarvan de definitie:

Methodologie is (in dit verband) de 'leer (of de wetenschap) der methoden'.

Het Ontwerp- en Ontwikkelproces

Elke ontwerper dient bij de constructie van courseware, bij de afzonderlijke TO-vakken, onderscheid te maken tussen de ontwerp- en ontwikkelfase, incl. 'het programmeren'. De ontwerpfase dient goed te worden uitgewerkt. Men dient voldoende onderscheid te maken tussen het functioneel en het technisch ontwerp. Vaak ontbeert men de technische kennis en middelen om een goed en systematisch ontwerp te kunnen maken. Daarom is het noodzakelijk dat ontwerpers in spe in het begin van hun opleiding kennis maken met tools en technieken en dus ook met programmeer-technieken. Een dergelijke basiskennis is een redelijke garantie dat men inzicht verkrijgt in de veelheid van oplossingen, zodat een ontwerp later ook werkelijk kan worden gerealiseerd.

Bij het ontwerpen en ontwikkelen van lineaire produkten zoals film of video en in zekere zin ook bij tutorials en interactieve video, speelt van oudsher het maken van een goed script een grote rol. Omdat bij het construeren van audiovisuele middelen een langere traditie bestaat, is ook de technische component daarbij beter uitgekristaliseerd. Dit in tegenstelling tot het ontwikkelen van veel soorten interactieve (educatieve) software, daarbij wordt bij het ontwerpen vaak meer de nadruk gelegd op de structuur van de software, stroomdiagrammen (met het systeem 'Flowcharter'), dan op de inhoud of de 'verhaallijn'. Maar desondanks wordt hierbij elke frame, elk beeld en natuurlijk ook het geheel, systematisch ontworpen. Maar ondanks alle theorievorming op dat punt is er bij dit type produkt nog steeds een grote mate van bottom-up benadering. De rapid prototyping-methode heeft dat in de hand gewerkt.

Desondanks dient een multimedia-produkt in principe op dezelfde manier ontworpen te worden als elk ander audiovisueel produkt. Dat bij het maken van AV-materiaal meer aandacht wordt gegeven aan een systematische benadering wordt echter ook veroorzaakt door het feit dat de produktie van het audiovisuele leermateriaal een kostbare aangelegenheid is, zeker als in een laat stadium veranderingen zouden moeten worden aangebracht. Daardoor wenst men het risico op dergelijke ingrepen te minimaliseren. Nu er echter nieuwe (multimediale) tools zijn gekomen, waardoor de hanteerbaarheid en manipuleerbaarheid van audiovisuele toepassingen zeer sterk is toegenomen, stijgt het risico dat ook in deze sector systematisch en vooraf ontwerpen minder belangrijk zal worden geacht. Onder het mom van 'rapid prototyping' gaat men als ontwerper snel op de tour van 'programmeren'. Studenten moet daarom geleerd worden later bij hun afstuderen en/of hun latere beroepspraktijk, de nodige terughoudendheid te betrachten ten aanzien van directe praktische activiteiten ten koste van een planmatig ontwerp. Wij laten hier een paar methoden de revue passeren.

Top down ontwerpen

De methode die De Diana en Min in hun vak 'Courseware Engineering' toepastten is ontwikkeld door De Diana. Je begint met de ontwikkeling van een ruw versie van een product (prototypes) en vult stap voor stap - en in overleg met de opdrachtgever - de ontbrekende onderdelen in. Met NetObject Fusion mag en kun je ook zo werken. De voortdurende aanpassingen van de opzet en de inhoud zijn de kenmerken van deze methode of werkwijze.
Stap 1: De website in contekst

Het gaat hier, bij deze eerste stap, om na te denken over alle ontwerp-aspect van de contekst van een site en het kennis maken met de auteurs-systeem NetObjects Fusion (T: p.231-237).

Bestudeer de opdrachtomschrijving, zodat je een duidelijk beeld hebt van wat verwacht wordt. Neem regelmatig contact op met de opdrachtgever(s) en/of maak regelmatig een afspraak voor een persoonlijk gesprek.
Stel samen met de opdrachtgever(s) een lijst op van behoeften en wensen met betrekking tot de site die zij gerealiseerd zouden willen zien.

Stap 2: Site struktuur en site stijl

Op basis van de lijst van behoeften en wensen zal bij deze stap een ontwerp moeten worden gemaakt van de struktuur van de site, dat wil zeggen hoe is de site georganiseerd, waarbij de pagina's van de site in een boomstruktuur ondergebracht aan elkaar gebonden zullen worden.

De lijst van wensen en behoeften moet dus worden uitgewerkt en omgezet in zo'n, struktuur en die struktuur moet voor de opdrachtgever 'logisch' en helder zijn.
Ook moet in deze opdracht de 'stijl' van de site worden vormgegeven. Met behulp van Fusion kan de huisstijl van een site met weinig moeite 'op maat' worden gemaakt. Dat is niet alleen leuk om te doen, maar ook belangrijk omdat de stijl van de site in grote mate bijdraagt aan de waardering en acceptatie van de site door gebruikers.

Stap 3: De site: tekst, afbeeldingen en links

Op dit moment moet de 'kale' site beschikbaar, waarin een struktuur en een stijl aanwezig is, maar verder nog niet. In deze fase is het de bedoeling om deze site voor een deel in te vullen, namelijk met teksten, afbeeldingen en eventueel te voorzien van links.
Als dit soort informatie gericht en zorgvuldig aan de kale site wordt toegevoegd, dan ontstaat een wat wij een eerste prototype, versie 1 van je product, kunnen noemen.

Stap 4: De site: niet-tekstuele informatie ('resources' en 'assets')

Het is in deze fase zaak om het prototype verder te ontwikkelen en te voorzien van aanvullende typen informatie, zoals video, audio, animaties, formulieren of applets.
Als dit soort informatie gericht en zorgvuldig aan de site wordt toegevoegd, dan ontstaat een wat wij een tweede prototype, versie 2 van je product, kunnen noemen.

Om zo'n prototype te kunnen maken, moet de ontwerper van de site kunnen beschikken over de nodige informatie en/of losse onderdelen. Overleg met de opdrachtgever wat hij voor stand-alone applets of micro-worelden hij op de site wil hebben.

Stap 5: De site: intensivering van de interactiviteit

In deze fase is versie 2 beschikbaar. Het is hier de bedoeling om dit prototype verder te ontwikkelen en te voorzien van aanvullende software bouwblokken (componenten, applets of scripts), waardoor de interactie tussen site en gebruiker veel intensiever en aantrekkelijker kan worden gemaakt.

Als dergelijke componenten gericht en zorgvuldig aan de site wordt toegevoegd, dan ontstaat een wat wij het derde prototype, de 3e versie van je product, kunnen noemen.

Stap 6: De site: integratie, publicatie, evaluatie In deze fase is er het prototype, de 3e versie van je product, beschikbaar. Het is de bedoeling om dit prototype nu af te ronden en te evalueren.

In de eerste opdracht is samen met de opdrachtgever een lijst opgesteld van wensen met betrekking tot een site. In hoeverre komt het nu beschikbare prototype overeen met die wensen?
Als de overeenstemming redelijk/goed is, dan is er tussen opdrachtgever en ontwerper een relatief eenvoudige situatie: missie geslaagd. Is die overeenstemming slecht/matig, dan ligt de situatie aanmerkelijk gecompliceerder.

Tussen deze twee posties ligt nog een scala aan andere mogelijkheden. Het is de bedoeling om in deze opdracht goed na te gaan hoe functioneel bezien het beschikbare prototype overeenkomt met de wensen van de opdrachtgever en hoe bruikbaar het prototype in de gebruikspraktijk zou kunnen zijn.

Deze methode met 6 stappen kan meestal zeer succesvol bij het ontwikkelen van 1e orde courseware en web-sites in het algemeen worden toegepast. Maar er zijn nog andere methoden of modellen, zoals het rapid prototype-model en het W.J. Zwart-model.

Rapid prototyping

In figuur 1 staan de handelingen die plaatsvinden als rapid prototyping wordt toegepast op onderwijskundig ontwerpen. De tijd verloopt van links naar rechts en er is dan te zien dat de verschillende handelingen elkaar in de tijd overlappen: er is sprake van parallelle processen.


Figuur 1: Het 'rapid prototyping'-model van Tripp & Bichelmeyer uit 1990


De methode van rapid prototyping is bijzonder geliefd geworden door de opkomst van HyperCard-achtige systemen (T: p.410), zoals HyperCard, maar ook door VisualBasic en de komst van WYSIWYG auteurs-systemen. In de meest eenvoudige vorm komt rapid prototyping ook voor bij tekstverwerken, d.w.z. het op een moderne manier schrijven en opmaken van een boek of artikel. Je begint met een 'outline' en vult later stap voor stap - en in overleg met anderen - de ontbrekende onderdelen in. Met NetObject Fusion mag en kun je ook zo werken. De voortdurende aanpassingen van de opzet en de inhoud zijn de kenmerken van deze methode of werkwijze.
Het evolutionair ontwikkelen van produkten heeft deze zienswijze geheel tot zich genomen (Tolido, 1996). Het evolutionair ontwikkelen van produkten is in de software wereld ontstaan uit de rapid prototyping methode en inmiddels een niet weg te denken methode om het gewenste produkt te krijgen. Zie hiervoor het boek van Tolido: "Evolutionair ontwikkelen van informatiesystemen", Uitgeverij Academic Service, 1996. Een bedrijf dat deze methode toepast, zet (meestal snel) een product in de markt als versie 1.0; weet daarmee een markt te veroveren, en bouwt en ontwikkelt daarna op een rustige manier stap voor stap betere versies: versie 2.0, 3.0, etc. Men werkt dus niet met een echte, complete voorstudie of duidelijke onderzoeksvraag of ontwikkel-opdracht, maar meer het idee van dat een aanbod een vraag creeert.

Het W.J. Zwart-model

Binnen de afdeling instrumentatietechnologie wordt veelvuldig gewerkt met het zogenaamde W.J. Zwart-model (Zwart, 1988). Dit model beschrijft een andere aanpak dan zomaar een voor een de fases uit het OKT-model: vooronderzoek, ontwerp, constructie, evaluatie, revisie en implementatie. Bij het OKT-model worden deze fasen in principe sequentieel doorlopen. Bij dit model niet. Iedere fase levert een (aantal) produkt(en) op waarmee in de volgende fase verder gewerkt kan worden. Onderzoek wijst derhalve uit welke vervolg-oplossing mogelijk is. Men werkt van prototype naar prototype en uiteindelijk naar het meest optimale eindproduct. De prototypen worden gebruikt om een methode of techniek te testen, d.w.z. een (kleinschalig) performance-onderzoek. Cruciaal bij deze methode is dat de ontwerpfase een blauwdruk oplevert, waarmee in de constructiefase de oplossing geproduceerd kan worden.

Het OKT-model gaat er - ten onrechte - vanuit dat in de ontwerpfase de methoden en technieken die in de constructiefase gebruikt moeten worden zomaar voorspelbare output opleveren. Laat staan dat daar literatuur over is. Niets is minder waar in deze sector. Min en van Schaik Zilessen stelden in 1988 al, dat "indien er nieuwe methoden en technieken worden gebruikt een ontwerp nooit helemaal van te voren 'uitgetekend' kan worden"; "het eindproduct hangt af van bevindingen in tussentijdse prototypisch onderzoek". "In de educatieve softare-engineering schiet het OKT-model als methode tekort".
De beste aanpak voor educatieve software-problemen is daarom het werken via het W.J. Zwart-model, een echte onderwijskundige ingenieurs-aanpak: een mengvorm van het OKT-model, rapid prototyping en evolutionair denken en werken (via prototypes, performance-onderzoek en steeds - later - nieuwe versies uit te geven).


Figuur 2 Het J.W. Zwart model.


Bij het W.J. Zwart-model worden niet alle fasen streng mechanisch een voor een doorlopen. Bij het W.J. Zwart-model kan men vanuit elke fase terecht komen in een andere fase. Er zijn ontwerpers die van mening zijn dat het OKT-model voldoende vrijheidsgraden heeft om het op de manier te gebruiken waar Zwart en anderen een pleidooi voor houden, maar de verdienste van het W.J. Zwart-model is dat het bijvoorbeeld expliciet aangeeft dat men verder moet kijken dan de fase waarin men verkeert en dat men de problemen van verderop gelegen fasen al vast moet inventariseren (en op een stapel - een 'stack' - moet leggen) en dat men, op rustige momenten in een project, alvast oplossingen moet zoeken en/of moet zien uit te testen. De uitvinders van dit model waarschuwen hiermee impliciet dat software ontwikkelaars altijd te maken krijgen met onverwachte gebeurtenissen (bijvoorbeeld het bestellen van materialen, tools, insprekers, etc.). Planningsdeskundigen waarschuwen hier altijd al voor. Zorg dat er bij een project - in het planningstraject - zo min mogelijke 'kritische paden' (momenten) zijn.

Deze overwegingen, opvattingen en voorbeeld van projecten waarbij het OKT-model niet goed werkte, hebben geleid tot een (laten we maar zeggen) variant van het OKT-model, zodat ontwerpers bij instrumentatietechnologische opdrachten en wellicht in meer algemene zin voor het oplossen van instrumentatie-technologische problemen en beter handvat hebben om problemen op te lossen en voor te blijven. Het proces is schematisch weergegeven in figuur 2. Rechts ziet de lezer de stapel 'problemen' - die fase na fase - ontdekt worden en - gaande de rit en binnen de gestelde projecttijd - opgelost dienen te worden. De volgorde van oplossen doet er in principe (dan) niet veel (meer) toe.

Na het 'normale' vooronderzoek bestaat het model uit een cyclische middenfase. Daarin zijn de fasen ontwerp en constructie uitgebreid met een testprocedure. Tevens moet er in deze fase onderzoek gedaan worden om een aantal problemen op te kunnen lossen. Het vooronderzoek levert o.a. als tussenprodukt een lijst met problemen, die nog niet opgelost zijn en waarvoor ook geen bestaande oplossing voor handen is. In de cyclische middenfase vinden de volgende zaken plaats:

• ordenen van de nog niet-opgeloste problemen naar verwachte moeilijkheidsgraad en importantie voor de uiteindelijke simulatie.
• onderzoek naar, constructie en testen van mogelijke oplossingen van de problemen in oplopende moeilijkheidsgraad
• het aanvullen van de lijst met onopgeloste problemen

In de cyclische middenfase wordt voor het produktie-gedeelte gebruik gemaakt van een bepaalde werkwijze die in de volgende paragraaf beschreven wordt. Dit levert een prototype van de computersimulatie en wellicht als nevenprodukt mogelijk een aantal ontwerpprincipes en/of methodieken. In evaluatie/revisie-fase wordt het eindprodukt van de cyclische middenfase, een eerste prototype, formatief geevalueerd. Bij de implementatie wordt het normale OKT-model gevolgd.

Het W.J. Zwart-model kan het best gebruikt worden als er nog helemaal niets vast staat aangaande het systeem waarmee het product gebouwd moet gaan worden en de opdrachtgever het beste van het beste en de nieuwste technieken wil. In dat soort gevallen dient er nog in de ontwerpfase onderzoek gedaan te worden naar de 'performance' van die nieuwe technieken, d.w.z. kan de opdracht uberhaupt wel met die nieuwe techniek uitgevoerd worden. (Heeft deze techniek wel voldoende 'power': is de performance voldoende?) Er moet dan een (klein) pilot onderzoek gedaan worden naar de performance van zowel de tool als het product. Is de tool onhandig of is het product te traag, dan moet u die methode of techniek - vooralsnog - vermijden. Net zo lang tot dat collega-onderzoekers of de literatuur u vertellen dat de tijd er wel rijp voor is.

In zijn - alternatief - model volgt, na het vooronderzoek, een cyclische middenfase. Daarin zijn de fasen ontwerp en constructie uitgebreid met een testprocedure. In die fase moet er al (performance-) onderzoek gedaan worden om een aantal problemen te kunnen voorspellen en op te lossen. Het vooronderzoek levert onder andere als tussenprodukt een lijst met problemen, die nog niet opgelost zijn en waarvoor ook geen bestaande oplossing voorhanden is. Die zetten we dan (voorlopig) op de stack; tot we er wat mee kunnen; tot de tijd rijp is of tot we iemand daarvoor (eventueel) kunnen inhuren.

Systemen, Tools of Talen?

Er zijn drie fundamenteel verschillende manieren om multimediale producten, educatieve IT producten en/of courseware te maken. Bij het ontwerp van een educatief multimediaal product dient men van tevoren - bij het ontwerpen ervan - goed na te denken waarmee het product uiteindelijk gemaakt moet worden. Deze methode c.q. manier bepaalt wat kan of niet kan. Die eenvoudige gedachte is voor sommige ontwerpers niet vanzelfsprekend.
Deze drie fundamenteel verschillende manieren om educatieve software te maken zijn:
• met auteurssystemen (A-systemen)
• met auteurstalen (A-talen)
• met hogere programmeertalen (P-talen)

Er zijn ontwerpers die het realiseren van courseware geheel aan anderen overlaten en noemen het reele ontwikkelen dan ook nog vaak denigrerend coderen. Toen er alleen nog maar in Fortran, Pascal, C en Cobal werd geprogrammeerd lag dat in zekere zin voor de hand. Tegenwoordig zijn er honderden manieren om software en met name educatieve software te ontwikkelen en te realiseren. Voor elke type software is er vaak wel een aparte methode, een aparte techniek of een aparte tool. Er zijn wel dertig soorten educatieve software, courseware of COO. Elke soort komt anders tot stand.
Wat is de juiste methode om een (educatief) multimediaal product te ontwikkelen en/of te programmeren? Dat is een hele wetenschap. Het ene multimediale product komt op en geheel andere wijze tot stand als een andere. Om daar iets zinnigs over te zeggen zijn in de loop der jaren hele studies gemaakt.

Je moet dus precies weten wat voor soort educatieve software, courseware of COO je wilt maken of welk type software de klant wil. En dat hangt weer af van het budget en de tijd die je voor een project hebt. Als je gewone 'platte' courseware wilt maken kun je volstaan met een auteursomgeving, maar wil je een simulatie maken dan ontkom je er niet aan om minstens bepaalde onderdelen te programmeren in een hogere programmeertaal. Soms ontkom je er zelfs niet aan om alles in een hogere programmeertaal te programmeren.

Als vuistregel kun je nemen dat 80 procent van alle educatieve software gemaakt wordt met auteurssystemen of auteurstalen en de rest met hogere programmeertalen. Maar de leukste en de effectiefste onderdelen van educatieve software vaak met hogere programmeertalen zijn gemaakt. Dat komt voor bij 'drill and practice', 'simulaties' en dergelijken. Misschien zijn de 80 procent effectiefste stukken software wel met hogere programmeertalen gemaakt. Professionals grijpen vaak terug op hogere programmeertalen. Deze methode is onlosmakelijk verbonden aan de methode om met losse componenten te werken en in dimensies te (leren) denken.

Aparte Dimensies, Aparte Componenten: Apart Ontwikkelen

Er zijn bij multimediale producten altijd, vier of vijf (of soms zelfs zes) dimensies te onderscheiden. Wij onderscheiden: tekst, beeld, geluid, animatie, video en - wat ons betreft - ook nog als zesde en aparte soort: kleine, losse, interactieve elementen ('applets'). Elke dimensie heeft zijn eigen specifieke onderdelen (tekststrings, plaatjes, foto's, muziekjes, filmpjes, applets, etc.) en eigen specifieke tools om dat soort onderdelen te maken (tekst-editors, grafische bitmapped editors, video-editors, java-tools, etc.). (Zie ook de opmerkingen die bij de specialisten-benaderingswijze - elders in dit stuk - zijn gemaakt.) De zes dimensies met hun manier van maken zijn:
• tekst: met tekst-editors (Word, etc.)
• beeld: met grafische editors (PhotoShop, Illustrator, etc)
• (lineair) geluid: met geluids-editors
• (lineaire) animatie: met animatie editors (Flash, etc.)
• (lineaire) video: met video editors (QuickTime, Premiere, etc.)
• (interactieve) applets: met speciale tools voor Java.

Deze methode komt erop neer dat je de losse componenten van een product goed moet kennen en apart moet kunnen maken.

Elk onderdeel en elke dimensie van een multimediaal product moet op een andere manier worden ontwikkeld. Daarna moeten ale onderdelen tot een geheel worden gesmeed. Daar zijn weer andere methoden, technieken of systemen voor.

Soorten tools

De verschillende soorten ontwikkel- of programmeer-tools (-gereedschappen, of -systemen) zijn in allerlei combinaties mogelijk en ook vaak zeer wenselijk. Elke soort educatieve software heeft zijn eigen methodologische aanpak nodig. We zullen er hier een aantal soorten educatieve software en bijbehorende specifieke, kenmerkende ontwikkelmethode de revu laten passeren, t.w.:
• Auteurs-systemen, zoals AuthorWare, Taiga, Inigo, Fusion, etc., maar ook HyperCard, SuperCard, etc.;
• Auteurs-talen (die 'ge-interpreteerd' worden), zoals Tutor, Pilot, TenCORE, etc. Wij rekenen in dit verband nadrukkelijk vooralsnog ook HTML tot de auteurstalen;
• Hogere programmeer-talen (die meestal 'gecompileerd' moeten worden)', zoals Pascal, Basic, Visual Basic, Toolbook, Java, etc.; en ook hogere programmeer-talen (logische talen), zoals Lisp, Prolog, etc.; maar ook object georienteerde programmeer-systemen (die meestal 'geinterpreteerd' moeten worden)' zoals SmallTalk, HyperTalk, etc.;
• Script-talen zijn feitelijk gewoon hogere programmeer-talen, maar worden meestal niet 'gecompileerd' maar 'geintepreteerd'. Het zijn talen zoals JavaScript, Lingo, etc. Script-talen horen meestal bij een auteurssysteem of bij een bepaald type bestand weer behorende bij een bepaald merk tool. Bijvoorbeeld: de scripttaal Lingo is onlosmakelijk verbonden met MacroMind-Director, een veel gebruikt ontwikkelsysteem om lineaire animatie-films te produceren.
• Combinatie-systemen (A-systeem en A-taal, dus feitelijk met script mogelijkheid), zoals HyperCard met HyperTalk of SuperCard (ook met HyperTalk), MacroMind-Director (met Lingo), EDUC (met Pascal) en/of NetObject Fusion (met een ingebouwde javascript-editor);
• Simulatie-systemen, zoals bijvoorbeeld het MacTHESIS systeem (voor grote modellen; hoge performance), het javaTHESIS systeem (voor web-based applicaties en 3e orde courseware) of SimQuest (voor stand alone applicaties);
• Modelling-systemen, zoals STELLA, LabView en CSMP. Maar ook LOGO. Dat systeem, speciaal voor kinderen ontwikkeld, moeten we nadrukkelijk functiomneel gezien, tot de modelling-systemen rekenen;
• Editors voor losse componenten, zoals PhotoShop, PixelPaint, Painter, Freehand, MacDraw, Simpletext, TeachText, SoundEdit, WYSIWYG-editors voor maken van web-pages, etc.; maar ook gecompliceerde editors, zoals SuperCard (en natuurlijk het onvolprezen HyperCard), Adobe Premiere, Director, maar ook AuthorWare; Ook animatie-systemen (editors) voor lineaire animatie-filmpjes, zoals MacroMind-Director, Flash en Liquid Motion, etc. zijn functioneel gezien editors.
Opmerking: Elk multimediaal product bestaat uit losse 'mono'-multimediale elementen (of componenten). Elke element dient op zijn eigen specifieke wijze te worden (aan-)gemaakt en/of te worden geedit. Elk element heeft zijn eigen specifieke editor. Het 'aan-elkaar-programmeren' of 'aan-elkaar-knopen' en/of 'het intelligent maken van het geheel' gaat (ook) met een aparte editor. Tenslotte zit de eindgebruiker (de 'user') achter het totale multimediale eind-product: het software-programma (bijvoorbeeld een vier, vijf of zes dimensionele web-site).


Kwesties, die in het hoofd van de ontwikkelaar c.q. ontwerper altijd moeten opkomen, zijn: kan of moet ik een interpreter gebruiken? Kan of moet ik mijn software compileren? Moet ik voor dit onderdeel niet een hele goede performance hebben? (d.w.z. is de 'power' van mijn systyeem of de toekomstige applicatie uiteindelijk wel voldoende voor wat ik wil?) Moet ik voor een bepaald onderdeel snelle respons-tijden nastreven? (Of is dat niet nodig?) Hoe maak je beeld, graphics, graphs (T: p.429) of achtergronden dynamisch? Hoe programmeer je een goed mogelijkheid voor 'file-I/O' (file-input/output)? Etc. Dat zijn allemaal vragen die bepalen of een ontwerp haalbaar is of niet. Ervaring en inzicht spelen hierbij een grote rol.

Implementatie & Evaluatie

Studenten bij de afdeling ISM maken over het algemeen geen eindprodukten, maar meer prototypes om inzicht in bepaalde methoden en technieken te verkrijgen. Wetenschapers maken ook vaak geen eindproducten, maar juist alleen maar prototypen. In dat soort gevallen zijn de werkzaamheden meestal voltooid bij een interne evaluatie en eventuele revisie, van het prototype.

Te dikwijls wordt bij evaluatie gedacht dat evaluatie slechts op het einde, bij een geheel voltooid produkt kan gebeuren. Vaak ontbreekt de tijd (of het geld) om zorgvuldig te evalueren. Meestal is zelfs een evaluatie op het einde overbodig, omdat de mogelijke resultaten van de evaluatie, wegens gebrek aan tijd en middelen, toch niet meer geimplementeerd zullen worden. Aangezien de afdeling ISM haar specifieke ontwerp-karakter wil behouden en benadrukken is het wel logisch dat het ontwikkeltraject vaak extra lang is en het evaluatie-traject vaak relatief kort. Dat hoeft bij student-werk op zich geen probleem te zijn, omdat studenten tijdens hun studie relatief vaak evaluaties moeten doen. Daarbij speelt bij evaluatie van educatieve software ook nog mee dat de ontwerper of de ontwikkelaar zelf, niet de juiste persoon is om een echt onafhankelijke evaluatie-studie, van zijn eigen produkt, te leiden.

Er ontstaat momenteel een nieuwe trend, waarbij een deel van de constructie-activiteit verschuift naar de eindgebruiker. De huidige eindprodukten zullen dan als 'halfprodukten' worden opgeleverd, waarmee de eindgebruiker - de leerkracht of de trainer - als een 'second author' het halfprodukt kan aanvullen of instellen tot een 'definitief' eindprodukt dat aansluit bij zijn eigen inzichten. Een ander alternatief is dat eindprodukten eerder als aparte 'objecten' (kleine op zich zelf staande produkten met een zeer specifieke doelgerichte doelstelling) beschikbaar komen, waarmee de eindgebruiker dergelijke 'objecten' kan bundelen tot een bij zijn inzichten aansluitend eindprodukt. Produktie van multimedia is ten opzichte van film en video relatief nieuw en er is nog steeds weinig ervaring beschikbaar voor commercieel toepasbare ontwerp-modellen.

Men merkt vooralsnog dat op vele fronten een zeer sterke interesse ontstaat voor hergebruik of het aanpasbaar maken van bestaand produkten. Men kan dan bestaande multimedia componenten (her-) gebruiken in moderne multimedia. Als een dergelijke trend zich doorzet, dan zal dat ook consequenties hebben voor de ontwerpmodellen.

In de praktijk is er een algemene trend om de diverse fasen binnen een OKT-benadering, zo zelfstandig mogelijk te maken. Het doel daarbij is de fase af te sluiten met een duidelijk resultaat wat input moet zijn voor de volgende fase. Wegens de moeilijkheden die men ervaart om tot definitieve specificaties te komen, is deze benadering enkel acceptabel als er voor de doelgroep voldoende mogelijkheden zijn de specificaties te confronteren met een voorlopig produkt, waarna zeer snel en in die fase revisie kan volgen.

Alhoewel een strak projectmanagement nodig is, wordt dat door deelnemers in het proces niet steeds gewaardeerd. Dit betekent dat men ernaar moet streven dat een strak projectmanagement zich vooral bezighoudt met het bewaken van de globale opzet van een project. Het projectmanagement stelt randvoorwaarden en kwaliteitseisen vast voor de verschillende fasen. Binnen elke fase zijn de uitvoerders zelf verantwoordelijk. Zij beginnen met een bepaalde input, krijgen middelen, kwaliteitseisen en tijd toegewezen voor de uitvoering, en leveren een door de doelgroep geaccepteerde output.

Karakteristieke Ervaringen en voorlopige Conclusies

De aard van het constructieproces (bijvoorbeeld het ontbreken van definitieve specificaties) en de aard van het produkt (meestal met een meervoudige doelstelling), hebben als gevolg dat een lineaire opeenvolging van constructiefasen, zoals het OKT-model lijkt voor te schrijven, bij de constructie van media, niet volstaat. Als ontwerpers dit beseffen kan het OKT-model best een handvat zijn om een project te starten. Het heeft immers zijn kwaliteiten. Maar met name het op leren knippen van grote problemen in kleinere (en dus meestal oplosbaardere) problemen is meer de verdiensten van het W.J. Zwart-model.

De typische activiteit voor een student die afstudeert bij de afdeling ISM, is het maken van (interactieve) multimedia-produkten. Afstudeeropdrachten binnen de instrumentatietechnologie zijn meestal afkomstig van een externe opdrachtgever of sluiten direkt aan bij lopende onderzoeksprojecten van de afdeling. De uitvoering ervan volgt in principe een traject waarbij de keuze, het ontwerp, de ontwikkeling, de implementatie en de evaluatie van een beoogd produkt aan de orde komen, althans van het prototype van dat produkt. In grote lijnen loopt dit traject parallel met het OKT-model. Bij dit type projecten is het echter noodzakelijk de mogelijkheden en onmogelijkheden van de 'gereedschappen' te kennen. Dus niet alleen de voor- en nadelen van een bepaalde oplossing of tool, maar veel specifieker. Kent men die 'weerbarstigheden' niet, dan kan men ook bijna geen goed ontwerp maken. Daarom is het TO curriculum afwisselend zowel gevuld met 'methoden en technieken'-vakken (waar je meestal bottum-up moet leren werken en waar je spelenderwijs de performance van een tool leert kennen), zowel als met 'methodologie'-vakken (waar je met name top-down en OKT-achtig leren denken en werken).

Ervaringen met afstudeeropdrachten maken duidelijk dat het OKT-model in de praktijk niet steeds gevolgd wordt (of kan worden), maar vanaf het begin geoperationaliseerd moet worden, conform de vereisten van de probleem-context. Er zijn binnen de afdeling ISM in de loop der jaren een aantal explicietere modellen ontdekt en ontwikkeld. Het W.J. Zwart-model is daar een voorbeeld van. W.J. Zwart heeft in zijn onderzoek toendertijd heel expliciet aan de orde gesteld dat het OKT-model op een bepaalde manier moet worden geinterpreteerd (meer dynamisch), zodat het past bij de meest voorkomende afstudeeropdrachten van de afdeling ISM, met name bij engineerings-achtige opdrachten, waarbij nieuwe gereedschappen in het geding zijn.

De problemen waarnaar Zwart verwijst zijn vooral van technische aard. Door zijn suggestie om de ontwerp- en constructiefase cyclisch te doorlopen kan voortdurend aandacht worden gegeven aan het oplossen van de deelproblemen binnen die fase, en kan met de invloed van de gekozen oplossingen op het uiteindelijke produkt in een vroeg stadium rekening worden gehouden. Vooraleer meer in detail in te gaan op de problemen die ISM-studenten ervaren bij de uitvoering van hun opdracht, zullen we eerst nagaan hoe men in de praktijk interactieve media construeert.

Praktijkopdrachten (en dus ook afstudeeropdrachten) op het gebied van de instrumentatietechnologie worden vaak door een bedrijf of een andere externe organisatie verstrekt. In dat soort situaties is er meestal geen echte keuze ten aanzien van het medium. De opdrachtgever heeft een duidelijk idee over wat gemaakt moet worden en de ontwerper (of afstudeerder) kan het daar vanuit zijn positie nauwelijks mee oneens zijn. De consequentie is echter dat de zorgvuldige analyse van de randvoorwaarden en de openheid waarmee een onderwijskundig verantwoorde oplossing voor het gestelde onderwijskundige probleem gezocht kan worden, ontbreken. Daarbij blijkt ook keer op keer dat de opdrachtgever aan een vooral onderwijskundig georienteerd vooronderzoek geen behoefte heeft. Dit leidt tot de situatie dat een student dikwijls nauwelijks in staat is de door hem op dit punt verworven theoretische kennis praktisch toe te passen. Hoe kan men deze impasse doorbreken? Het is onwaarschijnlijk dat de opdrachtgevers van mening zullen veranderen. Daarom moet men zoeken naar oplossingen die ook voor de opdrachtgever aantrekkelijk zijn. Men kan stellen dat opdrachtgevers, in plaats van zorgvuldige onderwijskundige analyses, meer behoefte hebben aan praktische voorbeelden: bestaande mediapakketten die illustreren hoe de beoogde oplossing eruit zou kunnen zien. Vermoedelijk heeft men dergelijk voorbeeld al gezien, dan wel erover gelezen, waardoor de conclusie ontstaat om 'iets dergelijks' te laten maken als oplossing voor een bestaand probleem.

Conclusies

Uit de bundeling van ervaringen, analyses en toekomstverwachtingen ten aanzien van de evolutie van de media, wordt geconcludeerd dat vooral ISM-studenten zich ook met de technische uitvoering binnen een project zullen bemoeien. Er wordt daarom in het bijzonder van ISM-studenten verlangd dat ze een sterke ingenieursverwantschap voelen.

Ter bevordering van de over-all ontwerp-aspecten en de technische uitvoerings-aspecten zou het OKT-model, ook in relatie tot wat in de praktijk van media ontwikkeling gebeurt, een meer modulaire opbouw moeten krijgen. Daarbij zou elke fase uit het model, via een cyclisch proces van formatieve evaluatie en revisie, tot een stabieler tussenprodukt moeten leiden. Het Rapid Prototyping-model en het W.J. Zwart-model zijn daarom binnen het vakgebied van de leermiddelentechnologie de meest reele ontwerp-modellen.

Referenties en Literatuur

Diana, I. De, J. de Goeijen, J .Wetterling en R. Min (1999/2000). Courseware Engineering. Reader en web-site. Toegepaste Onderwijskunde; Universiteit Twente (online beschikbaar op internet).

Kommers, P.A.M., R. Verleur, B. Reimerink en P. Verhagen (1999/2000). Lineaire en Hypermedia. Reader. Toegepaste Onderwijskunde; Universiteit Twente.

Min, F.B.M. en J. de Goeijen (1998/1999). Multimedia programmeren; methoden en technieken. Faculteit Toegepaste Onderwijskunde, Universtiteit Twente. Enschede (online beschikbaar op internet)

Moonen, J. (1991). Toegepast onderwijskundigen: Architecten of Ingenieurs. In 'De onderwijskundige ontwerper'. Red.: S. Dijkstra, H. Kramer en J. Pieters. Liber Amicorum prf. E. Warries. Swets & Zeitlinger ISBN 90 265 1161 2.

Plomp, Tj., A. Feteris, J. Pieters en W. Tomic (red), (1992). Ontwerpen van onderwijs en trainingen. Uitgeverij Lemma. ISBN 90-5189-104-0

Procee, H. (1997). De nieuwe ingenieur; over techniekfilosofie en professioneel handelen. Boom Amsterdam.

Verhagen, P. W., N. Pals en N. van der Woert (1986). Interactieve video als videoprogramma: toepassing en vormgeving.In Verhagen, P.W., en B.J. Wielinga (1986) Media in het onderwijs. Vereniging voor Onderwijsresearch. Proceedings ORD, Swets & Zeitinger BV. Lisse.

Zwart, W.J. (1988). Flowsim: een computersimulatieprogramma voor het Waterloopkundig Laboratorium. Universiteit Twente, Faculteit Toegepaste Onderwijskunde (doktoraalverslag).

Rik Min, 2000, Enschede. Gerestaureerd in 2020