Technische Informatica BSc-project - InterLectio
Dirk-Jan Hoek - 1509179 Nathan van Ofwegen - 1509314 Wouter Klein Heerenbrink - 1540823
11 juli 2012
Vakcode: IN3405 Faculteit: EWI Bedrijf: Fluxility Zoetermeer Opdrachtgever: Lars Blommers Begeleider: Peter van Nieuwenhuizen Commissie: Peter van Nieuwenhuizen & Martha Larson
Inhoudsopgave 1 Introductie
4
2 Omgeving van de applicatie
5
2.1
Conventionele interactiviteit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Het huidige klaslokaal
6
2.3
2.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Huidige digitale oplossingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.1
TurningPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.2
Microsoft Interactive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.3
Socrative
7
2.3.4
SmartSync
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.5
ActiVote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
Vraagsoorten
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Software ontwikkelproces
7
9
3.1
Scrum
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2
Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.3
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4
Vooronderzoek
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Ontwerp 4.1
4.2
4.3
4.4
11
Het algemene concept
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aanmeldprocedure docent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.1.2
Basiswerking
11
Soorten vragen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.2.1
Aanwijsvragen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.2.2
Meerkeuze en ja/nee vragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.2.3
Taalfouten ontdekken
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.2.4
Klassikaal behandelde open vragen . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
Beeldvorming stofbeheersing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.3.1
Per klas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.3.2
Per leerling
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Criteria voor user-interface
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.4.1
Positionering
4.4.2
Kleur
4.4.3
Gebruikersgemak . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.4.4
Fysieke beperkingen
17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5.1
Gebruikte frameworks
5.2
Schematische weergave van het systeem
5.4
11
4.1.1
5 Implementatie
5.3
9 10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
5.2.1
Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.2.2
Docent-applicatie (client 1)
20
5.2.3
Leerling-applicatie (client 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
5.2.4
Server-applicatie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Gra sche User-Interface
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.3.1
Docent GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.3.2
Student GUI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
Backbone en relaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.4.1
Backbone-Relational
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.4.2
Beperken van relaties
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.5
Freehand selectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.6
Tekenen op een dia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.6.1
Voor de gebruiker
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.6.2
Implementatiekeuzes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
2
5.6.3 5.7
5.8
Implementatie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Drag 'n Drop met afbeeldingen
33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.7.1
Native HTML5 Drag 'n Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.7.2
Vanuit browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.7.3
Vanuit lokaal foldersysteem
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Integratie met Dropbox 5.8.1
Dropbox REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Omgaan met schermafmetingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.9.1
Dia-inhoud op een ander formaat . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.9.2
Onnauwkeurigheid bij aanwijsvragen . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.10 Software Improvement Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.9
6 Testen
41
7 Discussie
42
7.1
Re ectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
7.2
Aanbevelingen
42
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Bijlagen
45
A.1
Backlog
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2
Planning en agenda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 49
A.3
Oriëntatieverslag
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
A.4
Requirements Speci cations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
A.5
Vergelijking bestaande digitale lesmiddelen
A.6
Projectomschrijving
. . . . . . . . . . . . . . . . . . . . . . . . . .
59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
Referenties
60
3
1
Introductie
Steeds meer basis-, middelbare- en hogescholen maken tegenwoordig gebruik van digitale schoolborden. Deze schoolborden kunnen worden beschreven met een speciale pen die het mogelijk maakt om te schrijven in computerprogramma's. Op deze manier heeft het bord dezelfde basisfunctionaliteit als een analoog schoolbord, maar biedt zij veel extra mogelijkheden, zoals het afspelen van lmpjes of het tonen van diapresentaties. Een andere nieuwe trend is de introductie van laptops en tablets voor leerlingen in het klaslokaal. Leerlingen kunnen actief deelnemen aan de les door bijvoorbeeld informatie op te zoeken op internet, door digitaal huiswerk opgaven te maken of te werken aan een werkstuk. Deze computersystemen maken het mogelijk om nieuwe vormen van interactie te introduceren in klaslokalen.
Een vorm van interactie die al snel op de markt kwam was het gebruik van stemkastjes.
Docenten konden in hun diapresentaties multiple choice vragen opnemen waar de leerlingen op konden stemmen met behulp van een stemkastje. Nadat alle antwoorden ontvangen waren door de computer van de docent konden de statistieken over de gegeven antwoorden direct worden bekeken. De huidige stemkastjes beperken zich doorgaans nog tot gesloten vragen en vereisen vaak veel voorbereiding. Ons stagebedrijf Fluxility wil een nieuw systeem op de markt brengen dat, gebruikmakend van de laptops en tablets van leerlingen en het digitale schoolbord van de docent, het mogelijk maakt om open vragen te stellen waarbij voorbereiding niet noodzakelijk is. Dit systeem krijgt de naam InterLectio, wat de Latijnse benamingen voor 'tussen' en 'les' verbindt. Gedurende een stageperiode van tien tot twaalf weken zullen wij onderzoek doen naar hoe een dergelijk systeem zou kunnen werken en produceren wij een eerste prototype.
Hierbij zullen wij spreken met
verschillende instanties die ervaringen hebben met doceren en de bestaande oplossingen voor stemkastjes. Dit rapport bevat onze bevindingen.
Het eerste hoofdstuk is een analyse van de huidige situatie
en van de omgeving waar het product moet integreren.
In het tweede hoofdstuk wordt het software
ontwikkelproces beschreven en het derde hoofdstuk geeft een globaal ontwerp van de applicatie. In het vierde en vijfde hoofdstuk wordt beschreven hoe het systeem respectievelijk geïmplementeerd en getest is en in het zesde hoofdstuk geven wij aanbevelingen voor verdere uitbreidingen.
4
2
Omgeving van de applicatie
In dit hoofdstuk zullen wij een beschrijving geven van de omgeving, het klaslokaal, waarin Interlectio gebruikt gaat worden. Het eerste deel schetst de situatie van een les en de interactie tussen leerling en docent, het tweede gedeelte gaat in op de huidige oplossingen op het gebied van interactie en het laatste deel gaat in op de vormen van vragen die wenselijk zouden zijn, maar nog niet altijd mogelijk zijn met de bestaande systemen. In de afgelopen decennia is het besef onder docenten en onderzoekers gegroeid dat het stellen van vragen belangrijk is voor het leerproces van studenten. Leren is niet puur een kwestie van luisteren, bij leren is het ook belangrijk om aan de slag te gaan met de gegeven stof. In de 'seven priniciples of good practice for education'[4] staat onder andere vermeld dat het stimuleren van actief leren (het stellen van vragen) en het geven van directe feedback op gedachten belangrijke aspecten zijn van eectief leren. Naast het werken met de stof zorgen tussentijdse vragen ook voor het motiveren van leerlingen om beter bij de les te blijven. Uit onderzoek[3] blijkt dat de concentratie van middelbare scholieren sterk is afgenomen na een half uur luisteren naar een docent. Een interruptie door middel van een vraag zorgt voor voldoende afwisseling om de concentratie weer op te laden. Niet alleen het bedenken van een antwoord maar ook het behandelen van gegeven antwoorden heeft een positief eect op het leerproces. Als een leerling een fout antwoord geeft kan de docent uitleggen waarom dit antwoord fout is, zodat een foute gedachte gecorrigeerd kan worden. Minder voor de hand liggend is dat wanneer een leerling hoort dat hij een antwoord goed bedacht heeft, hij de toegepaste denkstappen beter onthoudt.
2.1 Conventionele interactiviteit Een veelvoorkomende vorm van interactiviteit is het stellen van een centrale vraag in de klas aan een leerling. De docent kan een willekeurige leerling aanwijzen of wachten tot iemand zijn vinger opsteekt. Kenmerkend voor deze methode is dat veelal dezelfde leerlingen hun vinger opsteken, waardoor een deel niet gestimuleerd wordt om over de vraag na te denken. Ook is het niet ongebruikelijk dat leerlingen dichtslaan wanneer zij de beurt krijgen om een antwoord te geven, waardoor er onterecht een signaal wordt afgegeven dat de leerling de stof niet begrijpt. Stimuleren om de gehele klas te laten nadenken wordt soms bereikt door alle leerlingen eerst over de vraag na te laten denken, eventueel het antwoord op te laten schrijven en vervolgens een aantal leerlingen aan te wijzen om hun antwoord te geven. Leerlingen worden hiermee beter gestimuleerd om na te denken en dichtklappen wordt veelal voorkomen. De docent ziet echter nog steeds maar een beperkt deel van de gegeven antwoorden, omdat het simpelweg niet mogelijk is om alle leerlingen per vraag een beurt te geven. Een alternatief om snel alle antwoorden te kunnen inzien is het stellen van een meerkeuzevraag of ja/nee vraag, waarna de leerlingen hun vinger op moeten steken. De docent kan nu in een opslag zien of het overgrote deel van de klas het antwoord juist heeft. Het nadeel van deze optie is dat de mogelijke antwoorden al gegeven worden, zodat de leerling mogelijk voor het meest logische antwoord gaat in plaats van het antwoord zelf te bedenken. Een ander probleem is dat leerlingen bij elkaar af kunnen kijken en bijvoorbeeld hun vinger omhoog steken omdat de buurman dit ook doet. Tot slot zijn er bij deze vorm van testen ook een aantal leerlingen die überhaupt hun vinger niet omhoog steken, omdat ze niet durven. De problemen die zich voordoen in de conventionele methoden zijn als volgt op te sommen:
•
•
Bij individuele vragen
•
Het zijn vaak dezelfde leerlingen die antwoorden
•
Niet alle leerlingen worden gestimuleerd om mee te denken
•
Leerlingen die de beurt krijgen kunnen dichtklappen
Bij klassikale meerkeuze vragen
•
De leerling kan het juiste antwoord uit keuzes a eiden
•
Leerlingen kijken bij elkaar af
•
Sommige leerlingen steken hun vinger niet op
5
Bewezen is dat de conventionele methoden een positief eect hebben op de resultaten van de leerlingen, maar het eect wordt nog niet maximaal benut[7].
2.2 Het huidige klaslokaal De conventionele methode van vragen stellen is gegroeid met de middelen die vroeger beschikbaar waren in de klaslokalen. Met de komst van nieuwe technieken zijn de klaslokalen moderner geworden. Bij een groot deel van de middelbare en hogescholen is het redelijk gewoon geworden dat er een digitaal schoolbord aanwezig is in de klas. Dit digitale schoolbord werkt met behulp van een beamer die de inhoud van het bord projecteert op het bord. Met behulp van een speciale pen kan de docent schrijven op het bord. De pen werkt als een normale muis, wat betekent dat de docent gewoon kan klikken op het scherm. De digitale schoolborden maken het mogelijk om bijvoorbeeld presentaties te maken met Microsoft PowerPoint, Apple KeyNote of Prezi. Ook wordt het eenvoudig gemaakt om een lm af te spelen of om een website te tonen. Grote leveranciers van digitale schoolborden zijn ActivBoard en SmartBoard. Beide bedrijven leveren software die het mogelijk maakt om te tekenen op het bord in een omgeving die veel weg heeft van bijvoorbeeld Microsoft Paint. Een recentere ontwikkeling is de introductie van tablet- en laptopklassen. Hier nemen de leerlingen hun eigen laptop of tablet mee naar de klas om deze tijdens de les te gebruiken. Deze ontwikkeling is op dit moment nog jong, maar breidt zich in snel tempo uit op vooral de middelbare scholen van Nederland.
2.3 Huidige digitale oplossingen Op dit moment zijn er enkele producten op de markt die, gebruikmakend van de nieuwe middelen in lokalen, oplossingen bieden voor verbeterde interactie voor studenten met de stof. In bijlage A.9 is een vergelijking gemaakt tussen de verschillende bestaande oplossingen met de functies die zij hebben en de functies die ontbreken. Deze sectie somt de belangrijkste eigenschappen op.
2.3.1 TurningPoint TurningPoint levert een oplossing waarbij alle leerlingen worden voorzien van een klein apparaat met een aantal drukknoppen. De docent kan een ontvanger in zijn laptop steken waarmee de apparaten van de leerlingen kunnen communiceren. De software oplossing biedt een integratie in PowerPoint en maakt het mogelijk om dia's toe te voegen waarop een meerkeuzevraag kan worden gesteld. De leerlingen kunnen op het apparaat een keuze maken en na het sluiten van de vraag worden de antwoorden op de vervolgdia getoond. Het grote voordeel van TurningPoint is dat het integreert met Microsoft PowerPoint, zodat de docent het kan gebruiken in een vertrouwde omgeving. Het nadeel aan dit systeem is dat het de docent verplicht om een apart apparaat aan te schaen, wat een snelle kostenstijging betekent voor scholen. Een ander nadeel is dat het niet integreert met de software die ActivBoard en SmartBoard leveren om op het bord te schrijven. Dit leidt ertoe dat de docent van programma moet wisselen om een vraag te stellen, wat de drempel wat hoger legt om een vraag te stellen. Tot slot vereist TurningPoint veel voorbereiding en biedt het geen mogelijkheden om ter plekke een vraag te stellen.
2.3.2 Microsoft Interactive Met Microsoft Interactive is het mogelijk om een virtueel klaslokaal te maken waar de docenten en de leerlingen in deelnemen. De docent kan met behulp van dit programma vragen stellen in zijn eigen softwarepakket, zoals Microsoft PowerPoint of Microsoft OneNote. Vragen beperken zich tot meerkeuzevragen. Het grote voordeel aan dit programma is dat er geen extra hardware aangeschaft hoeft te worden. Het werkt met laptops in laptopklassen en het digitale schoolbord van de docent. De ondersteuning van andere besturingssystemen dan Microsoft Windows is echter zeer matig, waardoor het gebruik vereist dat alle leerlingen een computer hebben met Microsoft Windows.
6
Net als TurningPoint heeft Microsoft Interactive geen ondersteuning voor de software die meegeleverd wordt door de genoemde digitale borden, wat inhoudt dat de docent tijdens het gebruik van applicatie moet wisselen.
2.3.3 Socrative Socrative is een nieuwe speler op de markt en introduceert een nieuwe methode die gebruik maakt van de computers en tablets van de leerlingen en docent. De docent kan een virtueel klaslokaal aanmaken en de leerling kan via zijn webbrowser inloggen op dit klaslokaal. De webbrowser kan geopend worden op een laptop, een tablet of een smartphone. Socrative maakt het mogelijk om met bestaande hardware te werken waardoor de kosten voor scholen laag zijn. Ook biedt het de mogelijkheid om tijdens de les een vraag in te typen die de leerlingen kunnen beantwoorden. De vragen beperken zich wel tot meerkeuzevragen. Socrative is een losse applicatie en integreert niet met bestaande presentatiesoftware.
2.3.4 SmartSync SmartSync is een softwarepakket dat kan worden aangeschaft bij het digitale schoolbord SmartBoard. De software is bruikbaar in combinatie met laptops van de leerlingen en is toegespitst op het gebruik in een computerlokaal. De hoofdfunctie van het softwarepakket is niet het stellen van vragen, maar het onder controle houden van de les. Het voordeel van SmartSync is dat het de controle van de computers van leerlingen over kan nemen, waardoor de docent kan voorkomen dat de leerlingen andere dingen gaan doen. Het programma is echter niet toegespitst op het stellen van vragen en biedt daarvoor dan ook relatief weinig functionaliteit.
2.3.5 ActiVote ActiVote is een softwarepakket dat aangeschaft kan worden bij het digitale schoolbord ActivBoard. Het vereist extra hardware in de vorm van stemkastjes. Het systeem heeft veel weg van het klikkersysteem van TurningPoint, maar integreert wel met het tekenprogramma dat ActivBoard levert. Het voordeel van ActiVote is dat het prima integreert met de tekensoftware van ActivBoard. Nadelig is de vereiste hardware en de beperking tot meerkeuzevragen.
2.4 Vraagsoorten Het stellen van vragen stimuleert het leerproces bij leerlingen en biedt tevens een mogelijkheid voor de docent om te zien of de gedoceerde stof goed is ontvangen. Bij het stellen van een vraag is het van belang om vooraf goed te bepalen wat je er als docent mee wilt bereiken. Een doel kan bijvoorbeeld zijn om te onderzoeken of leerlingen goed het verschil kunnen zien tussen bepaalde voorwerpen of stellingen, terwijl een andere test kan zijn om te controleren of een student bepaalde gegevens kan reproduceren. Vragen zijn op vele manieren onder te verdelen. Een van de manieren is volgens Bloom's taxonomie. Deze de nitie kent de volgende categorieën:
Kennisvragen
stimuleert de leerling om opgedane kennis concreet te reproduceren, bijvoorbeeld in de
vorm van het vertalen van een woord, het aanwijzen van een land op de kaart of het geven van het jaartaal van een gebeurtenis
Begrip
vereist dat de leerling bepaalde gegevens snapt, zoals het a ezen of voorspellen van een waarde
op een gra ek of het verband zien tussen getallen
Toepassing
het toepassen van opgedane kennis op een bepaalde situatie. Bijvoorbeeld het toepassen
van een formule op wat getallen of het in categorieën verdelen van vragen
Analyse
het komen tot een antwoord door gegevens te bestuderen. Bijvoorbeeld de gevolgen kunnen
inzien van een bepaalde gebeurtenis
7
Synthese
het creëren van iets nieuws op basis van een aantal gegevens.
Bijvoorbeeld het bedenken
van een liedje, het vinden van een substituut of het in eigen woorden opschrijven van iemand zijn mening
Evaluatie
het beoordelen van een bepaalde gebeurtenis of bepaald werk, zoals het schrijven van een
recensie De taxonomie van Bloom is zo oplopend gesorteerd in openheid. Bij de eerste drie typen vragen zijn de mogelijke antwoorden nog relatief beperkt, maar voor analyse, synthese en evaluatie lopen de mogelijke antwoorden al gauw uiteen en kunnen ze niet zo gemakkelijk worden aangemerkt als goed of fout. Deze verschillende typen vragen kunnen worden gesteld met behulp van meerkeuzevragen of met vragen waarop de leerling vrij kan antwoorden.
Wanneer de docent kiest voor meerkeuzevragen dan
zal automatisch het analytisch denkvermogen en het evaluerend denkvermogen van de leerling worden gestimuleerd, omdat deze de verschillende keuzemogelijkheden zal afwegen. Het stellen van vragen die synthese vereisen is met meerkeuze vrijwel onmogelijk en het stellen van vragen in de categorie begrip en toepassing zijn enkel tot op zekere hoogte mogelijk. Uit de huidige digitale oplossingen blijkt dat er al veel mogelijkheden zijn om meerkeuzevragen te stellen. Geen van deze oplossingen biedt echter een goede oplossing voor vragen waar leerlingen vrij op kunnen antwoorden. Een aantal voorbeelden van vragen die moeilijker haalbaar zijn met meerkeuze:
•
Wijs Zweden aan op de kaart van Europa (kennisvraag); er is een beperkt aantal landen, maar teveel om deze in een realistische meerkeuze te verwerken
•
Wijs de Rijn aan op de kaart (kennisvraag); soortgelijk als de vraag waar Zweden ligt. Het bieden van meerkeuzevragen zou hier bijvoorbeeld weggeven dat de Rijn een rivier is en niet een plaats. Ook beperk je de gedachtegang van leerlingen door slechts één goed antwoord te geven, terwijl de Rijn ook in Duitsland ligt en meerdere vertakkingen heeft
•
Corrigeer de spelfout in de zin (analytisch/kennis); het fout gespelde woord zou al getoond worden in de antwoordopties waardoor de leerling correct gespelde woorden weg kan strepen
•
Verbeter de grammaticale fout in de zin (analytisch/toepassen); zelfde argument als bij het corrigeren van een spelfout
Uit gesprekken met klanten is gebleken dat er wel degelijk vraag is naar het kunnen stellen van open vragen tijdens de lessen. Daarnaast is het wenselijk om naast voorbereide vragen ook ad hoc vragen te kunnen stellen. In het hoofdstuk Ontwerp wordt geschetst hoe onze applicatie beter in zal spelen op de wensen van de docent en leerling en hoe de applicatie inspeelt op de wens om open vragen te kunnen stellen.
8
3
Software ontwikkelproces
In dit hoofdstuk geven we een beschrijving van het ontwikkelproces van onze applicatie. bespreken we de toegepaste ontwikkelmethode 'Scrum' en het versiebeheersysteem 'Git'.
Allereerst Vervolgens
refereren we naar de requirements speci caties in de bijlagen. Tot slot verwijzen we naar ons vooronderzoek, waarbij voornamelijk de belangrijkste bevindingen uit gesprekken met potentiële klanten naar voren komen.
3.1 Scrum We hebben ervoor gekozen dit project via de Scrum methodologie te de nieerden. Vooraf speci ceerden we alle uiteindelijke functionaliteit van de applicatie en de nieerden hiermee de product backlog. Iedere sprint pakten we een gedeelte van deze product backlog en speci ceerden hiermee onze sprint backlog, een lijst met onderdelen die aan het eind van de sprint geïmplementeerd zijn. Hierbij hebben we een duratie aangehouden van 2 weken per sprint. De reden voor deze aanpak is dat we zo snel mogelijk een werkend prototype wilden ontwikkelen, zodat we zo vroeg mogelijk eindgebruikers (zowel docenten als leerlingen) in het ontwikkelproces konden betrekken.
We wilden ze zo snel mogelijk met een werkende versie kennis laten maken, om hiermee
feedback te verkrijgen. Naast het ontwikkelen van software in sprints, hebben we ook ons overleg zoveel mogelijk afgestemd op de manier die de Scrum methode voorschrijft. We hebben daarom een tweemaal dagelijkse Scrum sessie aangehouden waarbij in ongeveer 15 minuten ieder teamlid de volgende vragen beantwoordde: 1. Wat heb je sinds de laatste bespreking gedaan? 2. Wat ga je voor de volgende bespreking doen? 3. Wat zijn je problemen op dit moment? Hiermee bleef ieder teamlid goed geïnformeerd over waar we stonden en wat er nog te doen stond.
3.2 Git Om met meerdere programmeurs op hetzelfde moment aan hetzelfde project te kunnen werken, hebben we gekozen voor het versiebeheersysteem Git. Met Git kunnen meerdere personen werken aan dezelfde bestanden, waarbij wijzigingen aan bestanden worden opgeslagen in 'commits'. Deze commits kunnen vervolgens worden verstuurd naar de Git-server door te 'pushen'. Andere gebruikers kunnen dan deze aanpassingen binnenhalen door van de Git-server te 'pullen'. Fluxility heeft veel ervaring met het gebruik van dit versiebeheersysteem en het kreeg onder andere daarom de voorkeur boven andere systemen, zoals het populaire SVN (Subversion).
Ook was er bij
Fluxility reeds een development Git-server ingericht, wat het opzetten van een Git-repository vergemakkelijkte. Een andere reden voor de keuze voor Git is dat iedere gebruiker zijn eigen lokale repository heeft. Dit betekent dat wanneer er een con ict optreedt tussen commits van verschillende gebruikers, dit gebeurt in de lokale repository van de gebruiker die de con icterende commit (door te pullen) binnenhaalt. In tegenstelling tot SVN is het daarom met Git onmogelijk om con icten op de server te hebben. Ten slotte hebben we voor Git gekozen vanwege de uitstekende 'branching'-functionaliteit.
Een
branch is een aparte tak van de hoofdrepository, waarnaar gepushed kan worden. Wijzigingen binnen deze branch worden niet binnengehaald in een andere branch. Deze functionaliteit is vooral nuttig bij het implementen van grote nieuwe functies of bij experimenten, waarbij commits naar de hoofdbranch ('master') ongepast zouden zijn. Nadat een dergelijke functie in een branch compleet en stabiel is, kan deze worden opgenomen in de hoofdbranch.
3.3 Requirements De vereiste functionaliteiten van InterLectio zijn geconcretiseerd in de vorm van Requirements Speci cations, met behulp van standaard UML Use Cases.
Deze zijn vervolgens gebruikt om functies op te
nemen in de Product Backlog, en uiteindelijk in één (of meerdere) Sprint Backlog(s), zoals beschreven in
9
de Scrum-methode. Voor een overzicht van de vereiste functionaliteiten, verwijzen we door naar bijlage A.4.
3.4 Vooronderzoek Om aan de hierboven genoemde speci caties te komen, hebben we voor en tijdens de implementatie veel interactie gehad met potentiële klanten en andere mensen uit het onderwijs.
Ook zijn veel door ons
gespeci ceerde eisen verzwakt of aangescherpt aan de hand van deze gesprekken. Een ander aspect van ons vooronderzoek was het uitgebreid in kaart brengen van de programmeeromgevingen, frameworks en modules die we konden gebruiken voor de implementatie van InterLectio. Een overzicht hiervan is te vinden in bijlage A.3. De lijst van frameworks die uiteindelijk bij de implementatie gebruikt zijn, wordt gegeven in 5.1.
10
4
Ontwerp
In dit hoofdstuk geven we een uiteenzetting van de belangrijkste conceptuele en visuele ontwerpbeslissingen. Hierbij zijn meerdere aspecten in ogenschouw genomen, waaronder functionaliteit, gebruiksvriendelijkheid en doeltreendheid.
In het eerste gedeelte van dit hoofdstuk geven we een beeld van het
algemene concept van onze applicatie.
In 4.2 leggen we uit welke soorten vragen we ondersteunen in
onze applicatie. In het derde gedeelte zal het gaan over het tonen van voortgang van de resultaten, aan zowel student als docent. In het laatste gedeelte worden de criteria voor de user-interface uiteengezet.
4.1 Het algemene concept Zodra de docent zijn lokaal binnenkomt, kan hij onze applicatie opstarten op het digitale schoolbord. De docent kan direct schrijven en tekenen in de applicatie, net als op een conventioneel bord. Op het schoolbord verschijnt een unieke code voor deze les. De leerlingen kunnen naar de website van InterLectio gaan en deze code invullen. Zij worden nu een deelnemer van deze les en zien hetzelfde schoolbord als de docent, maar dan op hun eigen apparaat. De docent kan nu
slides (ook wel dia's genoemd) samenstellen met een overzichtelijke set aan teken-
tools. Op een gegeven punt kan de docent besluiten om over een speci eke slide een vraag te stellen. Leerlingen krijgen op dat moment de vraag te zien op hun eigen apparaat en kunnen een antwoord geven. De docent kan de vraag vervolgens sluiten, waarna de gegeven antwoorden door de applicatie worden verzameld en getoond op het grote scherm. De docent kan nu de antwoorden behandelen en beoordelen. Onze applicatie moet perfect integreren in de lessen zoals de docent deze geeft. Aangenomen is dat de docent (actief ) gebruik maakt van een digitaal schoolbord waarop hij schrijft en dat de leerling zijn laptop of tablet voor zich heeft. Met deze voorwaarden mag de applicatie geen extra handelingen vereisen tijdens de les. Met andere woorden, er mag geen tijd verloren gaan aan het starten van de applicatie of het uitdelen van extra hardware. Op deze manier wordt de drempel om het systeem te gebruiken zo laag mogelijk gehouden. Daarom is ervoor gekozen om naast de vraagmogelijkheden ook de standaard schoolbordmogelijkheden in te bouwen in de applicatie zodat de docent niet tussen verschillende programma's hoeft te wisselen. Dit betekent dat de docent slides kan toevoegen, kan schrijven op het bord en zo verder.
4.1.1 Aanmeldprocedure docent Om als docent een room te kunnen openen vanaf de centrale website, dient deze ingelogd te zijn als
Teacher. Als de docent nog geen Teacher-account heeft, kan hij zich bij ons registreren. Deze registratie verloopt volgens de meest gebruikelijke en betrouwbare registratiemethode, namelijk een activatielink via email. In het uiteindelijke product dient de registratie van een docent door Fluxility gecontroleerd te worden en kan Fluxility handmatig Teachers toevoegen voor deelnemende scholen.
4.1.2 Basiswerking In het basisproces van slides maken en vragen stellen zijn er drie states te onderscheiden.
De states
en overgangen zijn weergegeven in Basiswerking. De volgende subsecties beschrijven wat er gebeurt in iedere speci eke state.
Slide active
Bij het starten van de applicatie begint de docent op de actieve slide. De docent kan deze
slide vullen door erop te tekenen, te schrijven en door afbeeldingen toe te voegen (zie gure 4.2a). Op ieder gewenst moment kan de docent besluiten om naar de vorige of volgende slide te gaan. Als er geen volgende slide is wordt er een nieuwe slide ingevoegd.
Question open to answers
Een docent kan besluiten om over een slide een vraag te stellen. Deze
vraag kan genoteerd worden in de slide of simpelweg mondeling worden uitgesproken. De docent kan een slide omzetten naar een vraag door op Turn into question te klikken. De leerlingen kunnen nu direct antwoorden gaan geven op de vraag door een punt op de slide aan te wijzen en eventueel een opmerking bij het antwoord te typen (zie gure 4.2b). De docent ziet op het scherm hoeveel antwoorden er reeds
11
start
teacher opens room Room open /do AddSlide
teacher draws something
Slide active
teacher adds new slide close room
teacher turns slide into question
student adds answer
Question open to answers
teacher closes question
teacher marks answer correct
Discuss answers
teacher marks answer incorrect
Done discussing
student enters room Figure 4.1: State diagram voor het algemene systeem
12
TUD-1234
TUD-1234
3 van 5 deelnemers heeft antwoord gegeven
TUD-1234
Sluit vraag
Stel vraag
(a) Docent heeft afbeelding aan slide toegevoegd. Hij zal op 'stel vraag' drukken en de leerlingen vragen naar de positie van het hart
(b) De leerling wijst op zijn eigen scherm de plek van het hart aan
TUD-1234
(c) De docent ziet hoeveel antwoorden er gegeven zijn en kan de vraag sluiten
TUD-1234
TUD-1234
Goed Fout Klaar
Klaar
(d) Vraag is gesloten en antwoorden staan op het docentenscherm
Klaar
(e) Docent kan antwoorden selecteren, behandelen en behoordelen
(f) Docent heeft 4 antwoorden goed gerekend, dus de barometer is voor 80% gevuld
Figuur 4.2: Visualisatie van verschillende states
binnen zijn, maar de antwoorden worden nog niet op het scherm getoond (zie gure 4.2c). Leerlingen kunnen hun antwoord aanpassen totdat de docent de vraag sluit.
Discuss answers
Nu de docent de vraag gesloten heeft worden alle gegeven antwoorden verzameld op
het scherm van de docent getoond (zie gure 4.2d). De docent kan nu ieder antwoord, eventueel meerdere tegelijkertijd, markeren als goed of fout (zie gure 4.2e). Ook kan de docent er voor kiezen om alle nog niet beoordeelde antwoorden goed dan wel fout te rekenen. Zodra een antwoord gemarkeerd is als zijnde goed of fout, wordt de barometer aangepast met de juiste percentages goede en foute antwoorden (zie gure 4.2f).
Na het behandelen
Zodra de docent klaar is met het behandelen van de antwoorden kan hij of zij
de vraag afsluiten. De docent gaat nu terug naar een kopie van de slide die gebruikt was om de vraag te stellen. De docent kan nu op deze slide aanpassingen maken zonder de oorspronkelijke slide aan te passen. Vanaf hier kan het gehele proces van een vraag stellen opnieuw worden uitgevoerd.
4.2 Soorten vragen In klassikaal verband zijn er verschillende soorten vragen die gesteld kunnen worden zoals vragen waarbij de leerling iets moet aanwijzen en meerkeuze vragen. Wij geven hier een overzicht van soorten vragen die wij belangrijk vinden en hoe deze gesteld kunnen worden met onze applicatie.
4.2.1 Aanwijsvragen Bij een aanwijsvraag kan worden gedacht aan een docent die wil weten of een leerling kan aanwijzen waar een bepaald land ligt of waar een bepaald orgaan zich bevindt in het lichaam. De docent heeft een afbeelding, tekening of tekst op het scherm en vraagt de leerlingen om het juiste antwoord aan te wijzen (zie gure 4.2a).
13
TUD-1234
TUD-1234
A. Zoetermeer B. Boskoop C. Katwijk
A. Zoetermeer B. Boskoop C. Katwijk
Stel vraag
Klaar
Figuur 4.3: Docent schrijft antwoordmogelijkheden op het bord en leerlingen kunnen het juiste antwoord aanwijzen
Vanaf het moment dat de leerlingen de vraag op hun apparaat zien, kunnen zij een antwoord geven door een punt op hun scherm te zetten. Dit doen ze met een laptop door met hun muis op een bepaalde positie in het scherm te klikken. Met een tablet kunnen ze op een bepaalde positie in het scherm drukken. Het gegeven antwoord wordt gerepresenteerd door een bolletje en kan, zolang de vraag nog niet gesloten is, het punt worden verplaatst, door een andere locatie aan te wijzen (zie gure 4.2b). De docent kan bij het behandelen zien welke punten de leerlingen hebben aangewezen. Voor ieder punt, eventueel meerdere tegelijkertijd, kan de docent aangeven of dit goed is (zie gure 4.2e).
4.2.2 Meerkeuze en ja/nee vragen Bij een meerkeuze en ja/nee vragen wil de docent dat de leerling een antwoord kiest uit meerdere opties, eventueel beperkt tot de opties ja en nee.
In onze applicatie kan de docent deze opties op het bord
schrijven en kunnen de leerlingen het juiste antwoord aanwijzen door simpelweg op dit antwoord aan te wijzen zoals ook gebeurt in de aanwijsvragen. Dit wordt getoond in gure 4.3. Bij het behandelen van de antwoorden kan de docent alle puntjes op de juiste optie goedkeuren en de rest afkeuren.
4.2.3 Taalfouten ontdekken Taaldocenten hebben momenteel nog maar weinig mogelijkheden om klassikaal vragen te stellen over taal. Het is moeilijk om te zien hoeveel leerlingen de fout in een zin hebben ontdekt omdat de vraag te open is om collectief te behandelen. In onze applicatie bieden wij een oplossing voor dit probleem. De docent kan een zin op het bord schrijven (met pen of toetsenbord) en kan de leerlingen vragen om de fout te vinden. De leerling kan nu de fout aanwijzen. Er is nu een extra mogelijkheid ten opzichte van de vorige voorbeelden, de leerling kan namelijk een correctie invullen met zijn toetsenbord (zie gure 4.4b). Zodra de docent de vraagt sluit ziet hij op zijn scherm welke punten de leerlingen hebben aangeklikt. Hij kan nu een of meerdere punten selecteren en ziet dan ook wat voor commentaar of verbetering de leerlingen hebben ingevuld bij het aanwezen punt. Deze antwoorden kunnen worden gegroepeerd zodat de docent bijvoorbeeld ziet dat twintig leerlingen dezelfde alternatieve spelling hebben ingevuld (zie gure 4.4d).
4.2.4 Klassikaal behandelde open vragen Met dit type vraag kan de docent een open vraag stellen waarop de leerlingen een langer antwoord kunnen geven. Door de mogelijke lengte van deze antwoorden is het voor de docent niet haalbaar om alle antwoorden op het scherm te verzamelen en te behandelen; dit zou te lang duren. In plaats van dat de docent alle antwoorden ziet, krijgt iedere leerling het antwoord van een willekeurige andere leerling toegestuurd.
De docent behandelt nu centraal wat het goede antwoord zou moeten zijn en geeft de
leerlingen de opdracht om het antwoord van hun klasgenoot goed of fout te keuren. belangrijk dat de leerlingen niet weten om welke klasgenoot het gaat.
14
Daarbij is het
TUD-1234
TUD-1234
De man voldeed aan alle eisen en eistte dat hij onmiddellijk werd ingehuurd
De man voldeed aan alle eisen en eistte dat hij Opmerking: eiste onmiddellijk werd ingehuurd
Stel vraag
(a) Docent schrijft een zin op het bord
(b) Leerling wijst punt aan en voegt opmerking toe
TUD-1234
TUD-1234
De man voldeed aan alle eisen en eistte dat hij eiste 3 + onmiddellijk werd eisten 1 + Eiste 1 + ingehuurd
De man voldeed aan alle eisen en eistte dat hij onmiddellijk werd ingehuurd
leeg
1
+
-
Klaar
Klaar
(c) Punten die de leerlingen gegeven hebben worden aangewezen
(d) Docent selecteert antwoorden en ziet bijbehorende opmerking
Figuur 4.4: Taalvragen
15
4.3 Beeldvorming stofbeheersing In deze sectie geven we aan welke methoden de docenten hebben binnen ons systeem om inzicht te krijgen in de stofbeheersing van de klas.
Dit splitsen we op in twee vormen.
De eerste vorm is de algemene
stofbeheersing van de klas. De tweede vorm is de mate van stofbeheersing per afzonderlijke leerling.
4.3.1 Per klas Wij vinden het belangrijk dat docenten binnen onze applicatie een goed beeld kunnen vormen van de algemene stofbeheersing van de leerlingen. Zo kan hij in ons systeem per vraag zien hoeveel procent van de leerlingen de vraag goed had, om zo te bepalen of de leerstof goed is aangekomen. Zo kan de docent besluiten om over een onderwerp waarop slecht gescoord is, nog een vraag te stellen.
4.3.2 Per leerling In principe is de applicatie geheel anoniem om zo te stimuleren dat alle leerlingen volledige input geven. Het is echter wel mogelijk om anonieme resultaten per leerling weer te geven om zo te bepalen of er groepen zijn aan te wijzen die bepaalde onderwerpen niet beheersen.
In latere versies kan besloten
worden om de leerlingen niet langer anoniem te maken, zodat de docent wel per leerling kan zien of hij/zij de vragen goed beantwoord heeft. Voor nu is de visie dat de docent dan beter aan de leerlingen kan vragen wie het goed hadden of individueel langs een leerling kan lopen om op de computer de resultaten te bekijken.
4.4 Criteria voor user-interface In deze sectie worden de belangrijkste criteria voor de user-interface toegelicht. Allereerst zullen we de eisen voor de positionering van verschillende elementen opsommen en toelichten en vervolgens de gewenste kleurstellingen. Daarna komen in de derde sectie de beslissingen op het gebied van gebruikersgemak aan bod. Ten slotte geven we uitleg over bepaalde beslissingen die gemaakt zijn ten behoeve van de fysieke beperkingen van bepaalde hardware.
4.4.1 Positionering Een van de belangrijkste aspecten om rekening mee te houden, wanneer je uitgaat van het gebruik van een digibord, is de links- of rechtshandigheid van de docent.
Zo hebben wij onderzocht wat de
voorkeurspositie is ten opzichte van het bord, voor deze twee groepen. Hieruit bleek dat linkshandige docenten vaak rechts van het bord staan, en rechtshandige links van het bord. Dit heeft ermee te maken dat je op deze manier een open houding ten opzichte van je klas houdt, het schrijven het gemakkelijkst is en de draai naar de klas het korts is. Om deze reden hebben we ervoor gekozen dat de toolbar van kant moet kunnen wisselen.
4.4.2 Kleur Bij de keuzes voor kleuren is onder andere in ogenschouw genomen wat voor de leerlingen op grote afstand zichtbaar is en wat voor de docent op korte afstand prettig is om naar te kijken.
Hierbij is
rekening gehouden met het feit dat een docent gebruik zal maken van een digibord of een projectorscherm. Allereerst is ervoor gekozen om de achtergrondkleur wisselbaar te maken. Er kan worden gekozen voor een lichte achtergrond, met het uiterlijk van papier. Dit heeft als voordeel dat op projectoren met een lage lichtopbrengst, of in ruimtes met veel licht, het scherm beter zichtbaar is. Een andere keuzemogelijkheid voor de achtergrond is een donkere achtergrond, met het uiterlijk van een krijtbord. Deze achtergrond heeft het voordeel dat het prettiger voor de ogen is in donkere ruimtes en voor docenten die dicht op een digibord staan, welke vaak een hoge lichtopbrengst heeft.
4.4.3 Gebruikersgemak Op het gebied van gebruikersgemak hebben we rekening gehouden met verschillen tussen ervarenheid van docenten, zowel met onze applicatie als met hardware en software in het algemeen. Ook de snelheid van het gebruik in de les, zonder verplichte voorbereiding hebben we als uitgangspunt genomen bij
16
visuele beslissingen. Om deze redenen hebben we de mogelijkheid gecreëerd om het tonen van labels bij icoontjes te kunnen aan- en uitschakelen. Aangezien dit ruimte op het scherm kost willen we hiermee ervaren docenten de mogelijkheid geven de tekst te verbergen en alleen icoontjes weer te geven, zonder hiermee onervaren docenten informatie te onthouden. de applicatie zo klein mogelijk gehouden.
Om dezelfde redenen is het aantal knoppen in
Hiermee proberen we een zo klein mogelijke leercurve voor
docenten te creëren en tegelijkertijd de snelheid van gebruik hoog te houden.
4.4.4 Fysieke beperkingen Vanwege het feit dat onze applicatie gebruik maakt van niet-alledaagse hardware zoals digiborden en mobiele apparaten zoals tablets, hebben we in het ontwerp rekening moeten houden met het ontbreken van bepaalde knoppen en functies. Zo hebben we rekening gehouden met het feit dat docenten met een digibord alles moeten kunnen doen met één pennetje.
Een rechtermuisklik is daarom met de meeste
digiborden niet mogelijk. Zo verschijnt bijvoorbeeld de pop-up voor het beoordelen van een antwoord direct na het selecteren van antwoorden, waar een dergelijk menu doorgaans aan een rechtermuisklik wordt gekoppeld. Verder heeft het gebruik van een digibord als gevolg dat knoppen niet te hoog geplaatst mogen worden, aangezien hoger gelegen gebieden voor veel docenten moeilijk te bereiken zijn. Ook het gebruik van touch-apparaten legt bepaalde beperkingen op. Zo bestaat er net als bij het digibord geen rechtermuisknop en kan de schermgrootte variëren van net boven de 10 inch voor de meeste tablets tot onder de 4 inch voor smartphones. Er is daarom sterk gelet op de visuele schaalbaarheid van onze applicatie.
17
5
Implementatie
In dit hoofdstuk geven we weer hoe we aan de hand van het ontwerp uit het vorige hoofdstuk een werkend prototype hebben geïmplementeerd. In de eerste sectie geven we kort aan welke frameworks we hiervoor hebben gebruikt.
Het tweede gedeelte geeft een compleet schematische weergave van het
systeem, opgesplitst in client- en server-applicaties. Vervolgens laten we in het derde gedeelte zien hoe we aan de hand van de interface-speci caties uit het vorige hoofdstuk tot de gra sche user-interfaces zijn gekomen.
De zes secties die hierop volgen gaan allemaal over speci eke uitdagingen binnen de
implementatiefase en hoe we hiermee omgegaan zijn. Het laatste stuk gaat over de resultaten van de codebeoordelingen door de Software Improvement Group (SIG).
5.1 Gebruikte frameworks Bij de implementatie van ons prototype hebben we de volgende frameworks gebruikt, opgesplitst in serverside- en clientside-frameworks:
•
Serverside
Python De programmeertaal Django Het basisframework (geschreven in Python) dat ontwikkeld is om als basis op de serverside van websites te dienen
TastyPie
TastyPie is een module die draait op het Django framework.
De module maakt het
gemakkelijk om API-calls goed af te handelen
•
Clientside
JavaScript De scripttaal HTML5 De taal die de (GUI-)elementen beschrijft die beschikbaar zijn in de webbrowser Sketch Een JavaScript module die het mogelijk maakt om rasterafbeeldingen te tekenen in HTML5 canvas
SVG-canvas
Een JavaScript module die het mogelijk maakt om vectoren te tekenen in een SVG-
element
Backbone
Het JavaScript framework dat de basis legt om volgens het Model-View-Controller
model te ontwikkelen
[Backbone Relational]
Een extensie op Backbone die relaties tussen modellen mogelijk maakt.
Deze module is uiteindelijk niet gebruikt
jQuery
Een JavaScript framework om eenvoudig met de GUI-elementen op de pagina te kunnen
spreken Voor een uitleg van ieder framework verwijzen we door naar bijlage A.3.
5.2 Schematische weergave van het systeem Deze sectie geeft een schematische omschrijving van de implementatie van de applicatie en zal een onderbouwing geven voor de keuzes die hierbij gemaakt zijn. Voor gedetailleerde ontwerpinformatie en documentatie verwijzen we graag door naar de bijlagen en de docs folder van de applicatie. De applicatie zal voornamelijk gaan draaien op de eigen computers van de docenten en de leerlingen. Een centrale server zal het verdelen van data tussen de gebruikers faciliteren. Er is dus sprake van een client-server systeem. De server is verantwoordelijk voor het beheren van de data en geeft een verzekering van consistente data. De docent-applicatie (client 1) is verantwoordelijk voor het opzetten en instellen van de ruimte waarin de leerling-applicatie (client 2) kan deelnemen. Een schematische weergave van het systeem in te zien in 5.1. Dit hoofdstuk zal eerst een algemeen overzicht geven van de werking van de applicatie. Vervolgens wordt de implementatie van de docent-applicatie beschreven, gevolgd door de leerling-applicatie en het geheel wordt afgesloten met de indeling van de server.
18
Client 1
Docenten app
json
Server
MySQL
sql
Django (TastyPy)
Client 2
json
Leerling app
Figuur 5.1: Schematische weergave van het client - server sysstem
5.2.1 Model-View-Controller De applicatie werkt volgens een Model-View-Controller systeem. Deze methodiek is zowel op de server als op de client ingebouwd. De views en controllers verschillen per applicatie, maar de algemene modellen zijn voor beide systemen gelijk. Deze sectie zal daarom alleen in gaan op de algemene modellen. In guur gure 5.2 wordt een overzicht gegeven van de gebruikte modellenstructuur. In de volgende sectie wordt ieder model aan de hand van deze guur afzonderlijk toegelicht.
User
Het model User dient als superklasse voor de Teacher en Student en bevat alle benodigde gegevens
om een gebruiker te authenticeren, waaronder een gebruikersnaam en (versleuteld) wachtwoord. Tevens bevat de User een apikey welke bij iedere server-call meegestuurd zal worden, zodat de server kan bepalen of de gebruiker de bevoegdheid heeft voor de gewenste actie. Het prototype zal echter alleen voor de Teacher een accountsmanagement (registratie en login) bevatten. Voor het prototype geldt dat een Student geauthenticeerd wordt op basis van zijn browser-sessie. Dit houdt in dat het openen van een extra tabblad in een browser geen nieuwe Student oplevert, maar het openen van een andere browser wel.
Teacher
Als subklasse van User erft dit model alle authenticatie en authorizatie-eigenschappen. Verder
heeft de Teacher de mogelijkheid om als owner aan een Room gekoppeld te worden. In de uiteindelijke versie zal een docent zich moeten laten valideren als zijnde een docent, waarna hij als Teacher de database in gaat.
In het prototype zal echter iedereen zich als Teacher kunnen registreren, waardoor het voor
iedereen mogelijk is om de rol van docent of leerling aan te nemen.
Student
Voor het Student model gelden eveneens dezelfde eigenschappen als voor de User, behalve
dat de Student als participant aan een Room gekoppeld kan worden.
Room
In gure 5.2 is duidelijk te zien dat het Room model in onze applicatie het uitgangspunt is.
Hieraan worden één Teacher en meerdere Students gekoppeld. Verder kan de Room over meerdere Slides beschikken. Iedere room heeft een unieke token bestaande uit 7 tekens, welke door de studenten moet worden ingevoerd om tot de Room toe te kunnen treden. Deze token bestaat uit 2 letters of cijfers die uniek zijn voor de school, gevolgd door een koppelteken en 4 willekeurige letters of cijfers.
Slide
Een Slide behoort tot een speci eke Room en heeft een volgnummer. Een Slide heeft eventueel
een vraag aan zich gekoppeld en heeft meerdere GraphicalParts.
Question
Een Question kan worden gecreëerd op basis van een slide, waarna er Answers kunnen
worden gekoppeld aan deze Question. Ook heeft Question net als Slide een volgnummer. Verder bevat
19
Django Models (all inherit from django.db.models)
User
Teacher dropbox_acce ss_key : String dropbox_acce ss_key : String
Student Attribute Attribute generateToken () : String
1
Answer correct : bool x : int y: int comment : string
*
1
* *
owner
participants
*
*
Room token : string active : bool
1 1 active_slide
Slide order : int data_uri : TextField (base64) 1 svg : TextField *
1
generate_token() can_add() can_remove() get_next_order()
0...1
* 1
1
Question order : int
1
1 active_question
Figuur 5.2: Modellen in algemene systeem
het een boolean waarde die bepaalt of de vraag open staat voor antwoorden, en één die bepaalt of de vraag afgerond is.
Answer
Answers behoren tot één speci eke Student en één speci eke Question. Daarbij heeft het een
boolean waarde die aangeeft of het antwoord correct danwel incorrect is.
Folder
Een Folder is bedoeld om Pictures te bevatten en heeft een Teacher als eigenaar en kan een
parent folder (eveneens een Folder model) aan zich gekoppeld hebben. Door middel van een backlink kan dan voor een Folder zijn subfolders worden opgevraagd. Door de link vanuit een Picture naar dit model kan een lijst met Pictures worden opgevraagd. Verder heeft een Folder een dropbox-hash die de staat van de map op de dropbox-server bijhoudt. Hiermee kan bepaald worden of de database moet worden bijgewerkt.
Ook kent het een attribuut
die aangeeft of het model gesynchroniseerd is met dropbox, om bij een discrepantie tussen database en Dropbox onderscheid te kunnen maken tussen bestanden die uit Dropbox-map zijn verwijderd en bestanden die (nog) niet niet naar Dropbox zijn geüpload.
Picture
Iedere Picture is gekoppeld aan een Folder.
Gebruikmakende van de Django-extensie Im-
ageKit kent een Picture een original_image, formatted_image en thumbnail. Ook de Picture kent een synced_to_dropbox-attribuut om dezelfde reden als de Folder.
5.2.2 Docent-applicatie (client 1) Het gebruik van InterLectio als docent verschilt signi cant van het gebruik als leerling.
Zowel de
bevoegdheden, het gedrag van de applicatie en de interface verschilt dusdanig dat we voor een splitsing hebben gekozen. In deze sectie wordt de implementatie van de docent-applicatie, zowel qua strucuur als gedrag, toegelicht. Allereerst wordt gekeken naar de docent-speci eke views.
Views
In guur gure 5.3 wordt schematisch weergegeven hoe de docent-applicatie is opgebouwd uit
een hiërarchie van views. Hierin kan de overkoepelende RoomView gezien worden als de applicatie. In
20
de volgende sectie wordt iedere view aan de hand van deze guur afzonderlijk toegelicht.
RoomView
Deze view is de kern van de docentapp.
Hierin worden alle onderliggende views geïni-
tialiseerd en worden de Room-modellen als javascript-objecten ingeladen. Ook houdt deze view een state bij, welke bij iedere activering of verandering van een slide of question opnieuw wordt bepaald.
DashBoardView
Deze view rendert een overzicht van de volgende attributen:
•
het aantal participanten in de Room
•
de geactiveerde Slide
•
het totaal aantal Slides
•
het totaal aantal Questions
•
de Room-token
De DashBoardView luistert naar veranderingen van één van bovenstaande waarden, om het overzicht bij te werken en zo up-to-date te houden.
ToolbarView
Deze view rendert de knoppen die de docent kan gebruiken, afhankelijk van de state
van de Room. Beschouw de states 'Slide active', 'Question open to answers' en 'Discuss answers' zoals te zien is in gure 4.1. Hieronder volgt een overzicht van de verschillende knoppen in de ToolbarView, voor elk van deze states.
Slide active •
Turn into question
Question open to answers •
Close question
Discuss answers •
Mark rest correct
•
Mark rest incorrect
•
Done
SlideView
Deze view beschikt over een instantie van de QuestionView.
De SlideView rendert de
inhoud van de actieve slide, als deze nog geen vraag aan zich heeft gekoppeld. Als er wel een actieve vraag aan gekoppeld is (die nog niet voltooid is en openstaat voor beantwoording) wordt de QuestionView gerenderd.
QuestionView
Deze view beschikt over een instantie van de AnswersView. Als de vraag openstaat
voor beantwoording toont het de slide, en anders toont het de AnswersView.
AnswersView
Deze view bevat een lijst van AnswerView's, welke door deze view stuk voor stuk
gerenderd worden.
AnswerView
Deze view rendert één speci ek antwoord zoals dat gegeven is door een leerling.
manier waarop dit wordt weergegeven is afhankelijk van het type antwoord. simpelweg een aangestipte plek in de slide zijn.
21
De
In het prototype zal dit
RoomView DashBoardView
ToolbarView
Token
SlideView
BarometerView
QuestionView AnswersView AnswerView
AnswerView
AnswerView
AnswerView
AnswerView
SlideThumbView
SlideThumbView
SlideThumbView
SlideThumbView
SlideThumbView
SlidesOverview SlideThumbView
SlideThumbView
SlideThumbView
Figuur 5.3: Views hiërarchie in docent-applicatie
SlidesOverview
Alle slides binnen de Room worden getoond in het SlidesOverview.
Deze view
beschikt daarom over een lijst van SlideThumbView's.
SlideThumbView
Deze view rendert één speci eke slide in het SlidesOverview. De weergave van de
SlideThumbView verschilt voor slides die actief zijn, een vraag bevatten, of beide.
BarometerView
Het goed- of foutkeuren van een antwoord resulteert in het bijwerken van de Barom-
eterView. Deze vult van onder naar boven een gedeelte groen voor de goede antwoorden, rood voor foute antwoorden, en grijs voor nog niet beoordeelde antwoorden.
5.2.3 Leerling-applicatie (client 2) In deze sectie wordt het ontwerp van de leerling-applicatie toegelicht.
Zoals bij de docent-applicatie
beschouwen we nu alle leerling-speci eke views.
Views
In gure 5.4 wordt schematisch weergegeven hoe de leerling-applicatie is opgebouwd uit een
hiërarchie van views.
Zoals te zien lijkt deze sterk op de docent-applicatie.
Toch zijn er een aantal
belangrijke verschillen, die hieronder per view worden benoemd.
DashBoardView
Naast de genoemde attributen in de docent-applicatie rendert deze view in de
leerling-applicatie ook het aantal goed beantwoorde vragen.
ToolbarView
In tegenstelling tot de docent-applicatie beschikt de ToolbarView slechts over een 'Leave
room'-knop, onafhankelijk van de state van de Room.
QuestionView
In plaats van een SlideView beschikt de leerling alleen over een QuestionView, welke
slechts één AnswerView aan zich gekoppeld heeft (namelijk degene die zijn eigen antwoord representeert).
22
RoomView DashBoardView Token
ToolbarView QuestionView
AnswerView
QuestionOverview QuestionView
QuestionView
QuestionView
QuestionView
QuestionView
QuestionView
QuestionView
QuestionView
Figuur 5.4: Views hiërarchie in leerling-applicatie
QuestionsOverview
Overeenkomstig met de SlidesOverview van de docent-applicatie, toont de Ques-
tionsOverview alle questions binnen de Room. Deze view beschikt daarom over een lijst van QuestionThumbView's, welke equivalent is aan de SlideThumbView van de docentapp.
5.2.4 Server-applicatie Het centrale element in het systeem is de server-applicatie.
De server-applicatie is de spil tussen de
docent- en leerling-applicatie en moet ervoor zorgen dat de informatie consistent blijft en goed wordt doorgecommuniceerd naar de twee applicaties. Een belangrijk aspect van de server-applicatie is dat deze 'te vertrouwen' is.
De client-side appli-
caties draaien lokaal bij de gebruiker en kunnen derhalve aangepast worden door de gebruiker en zo ongewenst gedrag vertonen.
Denk bijvoorbeeld aan dat een leerling de applicatie lokaal zo aan kan
passen dat hij meerdere antwoorden op een vraag kan geven. De server moet hierop voorbereid zijn en alle gegevensstromen van de gebruiker valideren zodat de server altijd zeker is dat de gegevens die hij verstrekt juist zijn. Deze subsectie zal beschrijven hoe de server-applicatie is ingedeeld, hoe de client-applicaties kunnen communiceren met de server-applicatie en hoe de invoer van de gebruiker gevalideerd wordt om zo de gegevensstroom consistent te houden.
Architectuur
De server-applicatie is net als de clientside applicaties opgezet volgens het model-view-
controller principe. De modellen zijn zoveel mogelijk gelijk aan het algemene systeem zodat gegevens zoveel mogelijk een-op-een kunnen worden overgenomen tijdens de communicatie. De controller zorgt ervoor dat aanvragen om data aan te passen of op te vragen goed gestuurd worden binnen de applicatie en de views zorgen ervoor dat de gevraagde data worden verstuurd. Het Django framework zorgt ervoor dat alle data uit de modellen wordt opgevraagd en opgeslagen in een database protocol. Momenteel maken we gebruik van een MySQL database. Dit kan later worden omgezet naar een PostgreSQL database wanneer meer rekenkracht op database niveau vereist is. Dit heeft verder geen gevolgen voor de applicatie omdat het Django Framework de database communicatie voor haar rekening neemt.
23
Communicatie (API)
De clients moeten communiceren met de server-applicatie.
Met andere wo-
orden, er moet een API komen. We hebben ervoor gekozen om gebruik te maken van TastyPie. Deze Python-applicatie is ontwikkeld voor het Django Framework en vangt API-aanvragen van de client op en stuurt deze naar onze controllers. In de controller kan vervolgens worden aangegeven welke data moet worden opgevraagd op de modellen. Ieder model op de client heeft een corresponderende controller op de server.
TastyPie zorgt er-
voor dat een aanroep voor een bepaalde controller gebonden is aan een speci eke url van de vorm
/api/v1/modelnaam/.
Vervolgens kan er aan de aanvraag uit de client een dataverzoek meekomen.
Is het verzoek een
standaard GET-aanvraag dan zal de API een lijst van alle modellen teruggeven. Ook kunnen als requestvariabelen lters worden meegegeven in de GET-aanvraag, om bijvoorbeeld te kunnen lteren op alle slides behorend tot een bepaalde Room. Stuurt de client een POST-request mee met bijvoorbeeld een create argument en de bijbehorende waarden, dan zorgt de API ervoor dat dit model wordt aangemaakt. De TastyPie controller biedt de mogelijkheid om allerlei gegevens van de gebruiker en de aanvraag te bekijken. Bij de aanvraag kan bijvoorbeeld worden aangegeven welke gebruiker dit verzoek deed, vanuit welke Room dit verzoek gemaakt wordt etcetera. Zoals al gemeld in de inleiding is het mogelijk dat de client aangepast is door de gebruiker en derhalve aanvragen doet naar de server die niet toegestaan zijn. Met de gegevens die de API ontvangt moeten dus validatiechecks worden uitgevoerd.
Validatie
Alle gegevens die binnenkomen moeten worden gevalideerd. Deze validatie is op te splitsen
in controleren of de gegevens een goed formaat hebben (is iets een getal, een string, een object referentie) en controleren of de gegevens legitiem zijn. De eerste vorm van validatie wordt hoofdzakelijk al uitgevoerd door TastyPie en het standaard modellen framework van Django. Voor ieder veld dat kan binnenkomen is aangegeven wat het type is en dit wordt vervolgens gecontroleerd. De tweede check is lastiger. Een voorbeeld van een validatie is de validatie van het toevoegen van een antwoord:
•
Is de vragende gebruiker een leerling
•
Is het gegeven antwoord gekoppeld aan een vraag?
•
Bestaat deze vraag?
•
Is deze vraag open voor antwoorden?
•
Is deze vraag gekoppeld aan een ruimte?
•
Is deze ruimte gelijk aan de ruimte waarin de gebruiker actief is?
•
Heeft de gebruiker nog geen antwoord gegeven
Het is belangrijk om deze validatie defensief uit te voeren. Dit wil zeggen dat bij ongeldige antwoorden er niet gewoon een foutmelding mag komen maar dat de applicatie zoveel mogelijk moet proberen om toch nog een actie uit te voeren. De reden hiervoor is dat de client-applicatie zelf al validatie uitvoert en op dat moment foutmeldingen geeft naar de gebruiker. Als er dus een ongeldige actie wordt uitgevoerd komt dit doordat er iets gebeurde wat de client-applicatie niet verwachtte. Een van de redenen hiervoor zou kunnen zijn dat op het moment van versturen door de client een bepaalde actie nog wel toegestaan was terwijl dit niet meer het geval was toen de server de aanvraag ontving. Een andere reden kan zijn dat de client twee aanvragen heeft verstuurd na elkaar en dat de eerste aanvraag later op de server aankomt dan de tweede. Het is dan niet wenselijk dat de server een foutmelding teruggeeft omdat de client en de fysieke gebruiker eigenlijk niks fout hebben gedaan.
24
Figure 5.5: User-interface voor docent
5.3 Gra sche User-Interface In deze sectie krijgt u een indruk van de uiteindelijke implementatie van de gra sche user-interfaces (GUI's). Hierbij maken we wederom het onderscheid tussen de docent- en student-applicatie. Hierbij laten we de webpagina's in aanloop naar het openen van beide applicaties buiten beschouwing. Zoals aangegeven in 4.4, hebben we bij de implementatie van de GUI's rekening gehouden met positionering (links- of rechtshandigheid), kleurgebruik, gebruikersgemak en de beperkingen die mobiele apparaten en digiborden met zich mee brengen.
5.3.1 Docent GUI Het hoofdscherm van de docent, na het openen van een Room die gevuld is met slides, vragen en afbeeldingen, is te zien in gure 5.5. Door het aantal knoppen te beperken proberen we de interface zo eenvoudig mogelijk te houden. Dit hebben we op drie verschillende manieren gedaan: 1. Kritisch zijn: We hebben zeer kritisch gekeken naar welke knoppen daadwerkelijk nodig zijn en welke knoppen weg kunnen, of op een andere manier kunnen worden geïmplementeerd. Zo hadden we in de toolbar aanvankelijk de knoppen 'previous slide', 'next slide' en 'add slide'. De eerste twee hebben we uit de toolbar gehaald en vlak boven de actieve slide gezet zoals te zien in gure 5.6. De 'add slide' knop hebben we als '+-slide' in het slides-overzicht gezet, waardoor het niet voelt als een knop. 2. Knoppen standaard verbergen: Verder hebben we ervoor gekozen om zoveel mogelijk element in een menu te verbergen wanneer deze geen primaire functie dienen. Zo zijn de voorkeursinstellingen standaard verborgen onder de settings-knop ( gure 5.7).
Wanneer op deze knop gedrukt wordt
komt een drietal opties naar voren:
•
Toggle board: Deze knop wisselt tussen de lichte (papier) en donkere (krijtbord) achtergrond. In 4.4.2 hebben we uitgelegd dat deze keuze noodzakelijk is om ervoor te zorgen dat de applicatie goed bruikbaar is met verschillende hoeveelheden lichtopbrengst bij schermen en verschillende licht- en donkerheden in lokalen.
•
Switch side: Deze knop brengt alle elementen aan de zijrand, zoals de toolbar en tekentools, naar de andere kant. Alleen de settings-knop blijft linksbovenin, zodat het meerdere malen
25
Figure 5.6: Slide navigatie
Figure 5.7: Setting menu
wisselen tussen links en rechts geen fysieke positieverschuiving van de docent vereist. Zoals vermeld in 4.4.1 is deze functie noodzakelijk om aan de voorkeur van zowel links- als rechtshandige gebruikers te kunnen voldoen.
•
Toggle text: Hiermee wordt de tekst bij de knoppen in de toolbar en navigatiebalk gedeeltelijk ingeschoven, zodat alleen het icoontje zichtbaar blijft. Dit levert een ruimtebesparing op voor ervaren docenten die weten welke functie onder welk icoontje valt, maar houdt het begrijpelijk voor onervaren docenten. Hiermee voldoen we aan de eisen die we gesteld hebben in 4.4.3.
3. Verschillende states: Aangezien we werken met strikt gescheiden room-states, hebben we ervoor gekozen om alleen knoppen te tonen die van toepassing zijn binnen de huidige state. Om deze reden wordt de toolbarview aangepast bij het veranderen van de room-state, zodat alleen de knoppen die horen bij het maken van een slide, het stellen van een vraag of het beoordelen van antwoorden getoond worden.
Ook wordt de imagetoolbar pas getoond wanneer in de tekentools 'afbeelding
invoegen' geselecteerd is. Verder is bij de implementatie van de GUI geprobeerd de docent een zo naadloos en gestroomlijnd mogelijke ervaring te leveren. Dit houdt in dat vrijwel geen enkele knop of actie leidt tot een abrupte verandering in de GUI, maar alles met een vloeiende animatie gebeurt. Dit zorgt er ook voor dat het visueel duidelijker wordt of en waar in het scherm een actie plaatsvindt.
5.3.2 Student GUI Het hoofdscherm van de student, na het lid worden van een Room, is te zien in gure 5.8. Aangezien het scherm van de student in feite een beperkte versie van het scherm van de docent is, gelden hier grotendeels dezelfde interfacebeslissingen als voor de docent. Een belangrijke visuele beslissing die wel speci ek is voor de student-applicatie is dat direct zichtbaar moet zijn of er een vraag actief is, en zo ja welke vraag actief is.
Het systeem zal daarom direct
overspringen naar de actieve vraag en blokkeert de navigatie naar andere vragen ( guur gure 5.9)
26
Figure 5.8: User-interface voor leerling
Figure 5.9: Actieve vraag
5.4 Backbone en relaties Het Backbone-framework biedt de mogelijkheid om te ontwikkelen volgens de Model-View-Controller strategie. Er zijn legio mogelijkheden om modellen te de niëren, maar er is op dit moment nog geen eenduidige speci catie over hoe je relaties tussen modellen kunt de niëren. Binnen onze modellenstructuur bestaan er veel relaties, zoals tussen het Slide-model en het Question-model en tussen een Question en de Answers. Het is daarom van belang om een bestaande uitbreiding op het framework te zoeken of om deze uitbreiding zelf te ontwikkelen. In de oriëntatiefase kwamen wij op de open-source module `BackboneRelational', ontwikkeld door Paul Uithol.
De speci catie van het framework komt overeen met onze
wensen en integreert ook goed met het server-side framework TastyPie dat wij hanteren. Hoewel de implementatie van Backbone-Relational prima verliep en de relaties goed tot stand kwamen, kwam er later in het traject een probleem in Backbone-Relational boven water, waardoor wij het systeem niet konden gebruiken en alsnog zelf een oplossing hebben moeten ontwikkelen. In deze subsectie zullen wij kort illustreren hoe Backbone Relational werkt, wat goed werkte en waar het fout ging. Vervolgens geven wij een beschrijving van hoe wij een alternatieve afhandeling van de relaties hebben verwezenlijkt.
5.4.1 Backbone-Relational De applicatie kent een aantal relaties die terug te vinden zijn in 5.2. Een van de relaties betreft de relatie tussen een Room en de Slides binnen deze Room, waar op zijn beurt een eventuele vraag aan gekoppeld kan zijn. Door de relaties te de niëren in de modellen van Room en Slide wordt het mogelijk om een Roommodel te vragen naar zijn Slides.
Backbone kent hier de term `fetch()' voor en Backbone-Relational
kent voor de gerelateerde modellen de term `fetchRelated()'. Voor beide functies geldt dat de gegevens opgehaald worden van de server en worden verwerkt in het huidige data-model. Bij de verwerking wordt gekeken naar de volgende aspecten:
•
Zijn er nieuwe elementen in de collectie (van Slides)
27
•
Zijn er attributen veranderd voor het model (van Room)
•
Is de volgorde binnen de collectie veranderd (van Slides)
Wanneer er nieuwe elementen zijn toegevoegd aan de collectie of wanneer de volgorde van elementen binnen de collectie is veranderd, wordt een `reset' signaal afgegeven. Andere elementen binnen de applicatie, bijvoorbeeld een view, kunnen zich abonneren op deze signalen, zodat zij kunnen reageren op het feit dat er iets veranderd is aan de collectie. Verandert er iets aan het model dan wordt er een `change' signaal afgegeven welke ook weer kan worden opgevangen door andere elementen in de applicatie. Daarnaast is er ook een `add' signaal dat wordt afgegeven wanneer er een element is toegevoegd aan de collectie, zonder dat er een `reset' signaal is afgegeven. Dit laatste `add'-signaal wordt bijvoorbeeld gebruikt wanneer het framework gevraagd wordt om `de nieuwste berichten sinds de laatste keer controleren' op te halen. Dit is bijvoorbeeld toepasbaar wanneer je de laatste berichten van Twitter weer wilt geven. Dit werkt niet wanneer je een gesorteerde lijst van namen wilt weergeven die af en toe verandert.
Het toevoegen van nieuwe elementen zou er dan voor
zorgen dat ze op de verkeerde positie in de lijst komen te staan. Een `reset'-signaal is dan noodzakelijk. Het probleem met Backbone-Relational deed zich voor bij het synchroniseren van het Room-model. Het systeem synchroniseert iedere seconde het Room-model met de server. Hierbij wordt bijvoorbeeld gekeken naar wat het aantal deelnemers in de ruimte is en de server wordt op de hoogte gehouden van het wel of niet actief zijn van de ruimte. Bij het synchroniseren van het Room-model kijkt de server ook welke vragen er bij de Room horen. De lijst die hij terug krijgt is een lijst van primary keys. De code van Backbone-Relational bepaalt op basis van de gegeven primary keys of er een wijziging heeft plaatsgevonden in het Room-model. In de versie van Backbone-Relational zoals wij die hanteerden liep dit spaak, omdat de primary keys werden vergeleken met de fysiek ingeladen modellen. Met andere woorden, er werd een nummertje vergeleken met een object. Het programma concludeerde logischerwijs dat de collectie met Slides was veranderd en besloot derhalve om alle slides opnieuw in te laden en een `reset' af te geven. De `reset' werd opgevangen door onder andere het dia-overzicht aan de onderkant van het scherm van de gebruiker. Bij het ontvangen van een `reset'-signaal voegt het element alle dia's opnieuw in. Dit gebeurde op iedere synchronisatie, waardoor de applicatie alsmaar bleef hertekenen. Dit probleem konden wij na enkele dagen traceren, waarna we hiervan melding hebben gemaakt bij de maker [9].
Tevens hebben wij door bestaande meldingen gezocht en vonden dat hier soortgelijke
problemen vermeld stonden.
De discussies die op dat moment plaats vonden tussen de verschillende
ontwikkelaars gaf aan dat het gebruiken van een synchronisatie in combinatie met dit type relaties nog in de kinderschoenen stond en dat een oplossing niet eenvoudig te realiseren was [5]. Wij hebben enkele verwoede pogingen gedaan om het probleem op te lossen, met kleine successen. Helaas lukte het niet om geldige test-cases te produceren, zodat we niet met zekerheid konden zeggen dat onze aanpassingen geen andere problemen zouden veroorzaken. Daarom hebben wij besloten om dit framework voor dit prototype niet meer te gebruiken en een versimpeld systeem te schrijven wat voor ons voldoet, maar mogelijk in de toekomst van de applicatie vervangen moet worden. Meer hierover in
1
de volgende paragrafen.
5.4.2 Beperken van relaties Met het oog op de deadlines is besloten om een eigen oplossing te schrijven voor het hanteren van relaties. We hebben een nieuwe analyse gemaakt van het model en gekeken of het mogelijk was om alle relaties terug te brengen tot één niveau diep, zonder essentiële functionaliteit te verliezen. Tijdens deze analyse hebben wij bepaald dat alle elementen een relatie kunnen krijgen met het Roommodel en dat er tijdens het gebruik van de applicatie atlijd maar één Room-model actief is. Alle data die bij deze Room hoort (Slides, Questions, Answers, Students) is tijdens het gebruik van de applicatie allemaal nodig. Er is geen sprake van zinloos inladen van data wanneer wij al deze data aan het begin van de applicatie in één keer inladen. Dit zorgt er wel voor dat de applicatie wat langer bezig is om op te starten, relatief tot wanneer we de gegevens lazy in zouden laden (pas als ze nodig gaan zijn). De wachttijd is echter, gegeven een redelijke internetverbindingen, te verwaarlozen.
1 Op
25 juni 2012, 20 dagen na ons besluit om voor nu over te stappen, is er een bug x toegepast die een deel van ons probleem oplost [8]. 28
Met dit afgevlakte model veranderen de soort aanroepen ook. In plaats van dat een Question-model een lijst bevat van Answer-objecten, bestaat er nu een Answer-collectie die alle objecten teruggeeft die horen bij een Question. Het nadeel van deze methode is dat de collectie van antwoorden nu ge lterd moet worden, wat tijd kost. Deze tijdsduur is echter relatief klein en valt met behulp van caching te optimaliseren, waardoor de eindgebruiker niks zal merken bij normaal gebruik. De eerste snelheidsproblemen zullen merkbaar worden bij de set van antwoorden, omdat deze het snelste groeit doordat er per vraag voor iedere deelnemer een antwoord wordt bijgehouden.
Mocht
dit gebeuren dan is het mogelijk om alsnog voor iedere vraag een hash-table bij te houden naar de antwoorden. De ontwikkelde data-manager maakt gebruik van een data-de nitie. Voor ieder model kan worden opgegeven wat het corresponderende model is, wat de namen zijn van de modellen waarmee het verbonden is en met een aantal lterwaarden die meegegeven kunnen worden naar de server wordt enkel relevante data opgevraagd. De data-de nitie zit gebonden aan de basisviews van Room. Ieder type Room (Teacher en Student) kan deze data-de nitie overnemen, uitbreiden of overschrijven zodat de data voldoet aan de wensen van deze speci eke view. De data-manager van Room heeft vervolgens alle methoden in zich om de data bij te houden en de juiste signalen af te geven. De implementatie van deze nieuwe data-manager integreerde zonder problemen in de al bestaande code waardoor de invoering van een nieuwe data-systeem niet tot gevolg had dat de applicatie op wat voor manier dan ook herschreven hoefde te worden.
5.5 Freehand selectie Naarmate het aantal leerlingen in de klas toeneemt neemt het aantal antwoorden vanzelfsprekend ook toe. Het is dan van belang dat de docent snel meerdere antwoorden als goed of fout kan markeren. Bij aanwijsvragen is het wenselijk om een gebied te kunnen selecteren waarbinnen de antwoorden goed of fout zijn. Dit gebied is doorgaans een polygoon dus de applicatie moet een mogelijkheid bieden om een polygoonselectie te maken. Tijdens ons onderzoek hebben wij nog geen bestaande oplossingen gevonden voor het maken van een polygoonselectie in je webbrowser. De oplossingen die er bestonden beperkten zich tot vierkante selectie. Wij hebben daarom een eigen polygoonselectie geschreven. De ontwikkeling van de polygoonselectie bevatte twee uitdagingen.
De eerste uitdaging was het
tekenen van een polygoon in de webbrowser en de tweede uitdaging was het bepalen van de punten die binnen de selectie vielen. In HTML5 is er nog geen voorgede nieerde oplossing voor het tekenen van polygonen. De standaard elementen die getekend kunnen worden zijn rechthoeken en ellipsen. Om een polygoon te tekenen zouden we gebruik kunnen maken van de mogelijkheden die het canvas-element uit HTML5 biedt of met behulp van een Scalable Vector Graphics (SVG) element. Canvas biedt de mogelijkheid om rasterafbeeldingen te tekenen en een SVG biedt de mogelijkheid om vectorobjecten, waaronder een polygoon, te tekenen. De selectiefunctie gaat alleen gebruikt worden door de docent, dus kunnen we kijken naar de optimale oplossing voor de webbrowser Google Chrome. Tijdens een vergelijking van Canvas en SVG bleek dat er geen noemenswaardig verschil zit in prestatie tussen SVG en Canvas in deze webbrowser. Wij hebben de keuze op SVG laten vallen omdat deze uit zichzelf al meer gra sche functies bevat voor het tekenen van polygonen waardoor wij onze code compact kunnen houden. De selectiefunctie wordt actief zodra de gegeven antwoorden geselecteerd moeten worden. Voor de geselecteerde antwoorden komt er een menu tevoorschijn waar de gebruiker goed of fout kan kiezen. Hierbij is het belangrijk dat de gebruiker kan klikken op een speci ek antwoord of dat de gebruiker een selectie kan maken van meerdere antwoorden. HTML werkt met behulp van pointer-events, dit zijn bijvoorbeeld klikken van de muis en het bewegen van de muis. Er kunnen meerdere elementen over elkaar heen liggen en het bovenste element ontvangt alle signalen van de muis. Wanneer de gebruiker klikt op een antwoord moet er voor dit antwoord een menu uitklappen. De pointer-events moeten dus worden afgegeven aan een antwoord, wat betekent dat het antwoord het bovenste element moet zijn. In guur gure 5.10 is te zien dat de volgorde van elementen `slide', `svg',
29
Pointer events
Antwoord SVG Slide
Figure 5.10: In 'rust' staat de SVG achter de antwoorden
Pointer events Goed Fout
Menu Antwoord SVG Slide
Figure 5.11: Klikt de gebruiker op een antwoord dan wordt enkel dit antwoord geselecteerd en toont er een menu
`antwoord', `muis' is. Klikt de gebruiker op een antwoord dan wordt er een uitklapmenu voor dit antwoord getoond zoals te zien in gure 5.11. Klikt de gebruiker naast een antwoord dan wordt het pointer-event doorgegeven aan het SVG element. De selectiepolygoon moet over de antwoorden komen te liggen, dus vanaf het moment dat de gebruiker heeft geklikt op het SVG element en zijn muis heeft ingedrukt zorgen we dat het SVG element de bovenste laag is, zie gure 5.12. De gebruiker kan nu met zijn muis bewegen en het pad dat gemaakt wordt met de muis wordt gebruikt om een polygoon te tekenen.
Tijdens het tekenen wordt het huidige eindpunt van de muis
tijdelijk verbonden met het beginpunt van het pad, zodat de gebruiker goed kan zien welke antwoorden binnen de huidige selectie valt, zoals te zien in gure 5.13. Als de gebruiker de muis los laat worden de coördinaten van de selectie doorgegeven aan de lijst met antwoorden zodat deze kan gaan bepalen welke antwoorden geselecteerd moeten worden, wat in de volgende paragraaf wordt besproken. De SVG-laag wordt weer onder de antwoordlaag gezet zodat het systeem zich zo gedraagt als in de situatie in gure 5.10. De geselecteerde antwoorden lichten op en er verschijnt weer een uitklapmenu, zoals zichtbaar in gure 5.14. De coördinaten van de polygoon worden doorgegeven aan de lijst met antwoorden en voor ieder antwoord in deze lijst moet gekeken worden of het antwoord binnen de selectie valt of niet. Er zijn meerdere algoritmen bekend om te bepalen of een punt in een polygoon ligt.
We hebben
gekeken naar een oplossing met een even-odd algoritme, met winding numbers waarbij gebruik gemaakt
Pointer events
SVG Antwoord Slide
Figure 5.12: Klikt de gebruiker op de SVG-laag, dus naast een antwoord, dan komt de SVG naar de voorgrond zolang de muis is ingedrukt
30
Pointer events
SVG Antwoord Slide
Figure 5.13: De polygon wordt getekend langs het pad dat de muis ingedrukt a egt
Pointer events
Menu Antwoord Goed Fout
SVG Slide
Figure 5.14: De punten binnen de selectie worden geselecteerd en er verschijnt een menu
wordt van hoeken en naar winding numbers waarbij gebruik gemaakt wordt van kwadranten. Bij het even-odd algoritme trek je een rechte lijn door het punt waarvoor je wilt controleren of het binnen de selectie ligt. Vervolgens tel je het aantal doorkruisingen van de rechte lijn met zijden van het polygoon. Wanneer het aantal doorkruisingen even is ligt het punt buiten de polygoon, bij een oneven aantal doorkruisingen ligt het punt er binnen. Dit algoritme is uit te voeren in O(N) waarbij N het aantal punten in het polygoon is. Het algoritme heeft als valkuil dat het foute resultaten kan geven wanneer het polygoon zichzelf doorsnijdt en bij afrondingsfouten die zich voordoen wanneer een knoop van het polygoon op dezelfde lijn ligt als de lijn door het punt. Bij het winding number algoritme met behulp van graden kijken we of de punten van het polygoon ons antwoord geheel omringen. Dit kan worden bepaald door voor ieder punt te kijken wat de hoek is vanuit het antwoord naar het huidige punt ten opzichte van het vorige punt. Wanneer al deze hoeken worden opgeteld en het polygoon omringt het antwoord dan zal het resultaat ongeveer 360 graden zijn. Het voordeel van dit algoritme is dat het antwoord ruwweg berekend kan worden, eventueel kunnen er zelfs wat punten van het polygoon overgeslagen worden, omdat het antwoord heel dicht bij 360 graden zit of juist helemaal niet in de buurt. Het nadeel van de methode is dat het bepalen van hoeken een dure operatie is. Het winding number algoritme met behulp van kwadranten heeft veel weg van het winding number algoritme met graden. Het veld wordt verdeeld in vier kwadranten met het punt dat we valideren op de kruising. Vervolgens bekijken we in welk kwadrant het eerste punt van het polygoon ligt. Daarna
(a) Rode punt ligt in polygoon
(b) Rode punt ligt buiten polygoon
Figure 5.15: Raytrace algoritme
31
10
90 18
46 90
-114 -9
146 -12
95
(a) Rode punt ligt in polygoon
(b) Rode punt ligt buiten polygoon
Figure 5.16: Winding number algoritme met graden
2
1
2
+1
1 +0
+1
-2
-1
-1
+1
+1
+2
3
4
3
(a) Rode punt ligt in polygoon
+2
4
(b) Rode punt ligt buiten polygoon
Figure 5.17: Winding number algoritme met kwadranten
kijken we voor ieder volgend punt in welk kwadrant dit ligt. We houden in een teller bij hoe vaak we van kwadrant wisselen. Hierbij houden we aan dat als we met de klok mee bewegen we één verder teller en tegen de klok in tellen we één terug. Verder geldt dat als we de kwadranten schuin passeren (van 1 naar 3 of van 2 naar 4 en visa versa) we afhankelijk van de richting polygoon om het punt heen dan zal de optelsom uitkomen op is dat er geen hoeken berekend worden.
+4
+2 of
of −2 tellen. Is er sprake van een −4. Voordelig aan deze methode
Nadelig is dat de afhandeling van situaties waarbij binnen
het polygoon nogmaals een polygoon getekend wordt waardoor de score +8 wordt, er geen eenduidige de nitie bestaat. De keuze voor een algoritme is uiteindelijk gevallen op het winding number algoritme met kwadranten. De graden-variant viel af omdat deze aantoonbaar trager was. De even-odd mogelijkheid viel af omdat deze gevoelig is voor afrondingsfouten op de knopen van het polygoon die op de hoogte liggen van het punt. In onze situatie zal de polygoon bestaan uit veel knopen waarbij de kans groot is dat er een op de hoogte van het antwoord zit.
Dit probleem zal zich minder gauw voordoen voor het kwadranten
algoritme.
32
5.6 Tekenen op een dia Een van de belangrijkste elementen van de applicatie is het kunnen tekenen op dia's. De docent moet tijdens zijn lessen eenvoudig en intuïtief kunnen schrijven met een pen, maar ook bijvoorbeeld de mogelijkheid geboden krijgen om guren en afbeeldingen toe te voegen en ergens op de dia te plaatsen. In deze sectie beschrijven wij hoe het systeem werkt voor de gebruikers, wat voor implementatiekeuzes er gemaakt zijn en hoe deze functie is geïmplementeerd.
5.6.1 Voor de gebruiker Tijdens de analyse van de huidige schoolborden hebben wij vastgesteld dat docenten tijdens de les voornamelijk gebruik maken van hun pen en de mogelijkheid om te schrijven op het bord zoals zij ook gewend zijn op een analoog schoolbord. Wanneer de docent besluit om een guur (een vierkant, cirkel enzovoorts) of afbeelding in te voegen dan maakt de docent hier eventueel notities bij met zijn pen. Omdat de notities van de docent altijd over de ingevoegde elementen lijkt te gaan hebben wij met het oog op eenvoud van gebruik gekozen om de docent altijd bovenop de guren en afbeeldingen te laten schrijven. Voegt de docent later nog een guur in op de plek van een notitie dan blijft de notitie dus zichtbaar boven het guur. Tijdens de ingebruikname van het systeem zal blijken of docenten dit prettig vinden werken of niet.
5.6.2 Implementatiekeuzes Tekenen op een computer kan in principe op twee manieren, met vectoren of met rasterafbeeldingen. In het eerste geval teken je door een lijst van elementen te maken waarvoor gede nieerd is dat het bijvoorbeeld een lijn is van het ene naar het andere punt of een cirkel met een bepaalde radius en een middelpunt. Bij een rasterafbeelding wordt per pixel op het beeldscherm gede nieerd welke kleur deze heeft. Er bestaat in dit geval geen onderscheid tussen losse objecten. Het vectorformaat is zeer voor de hand liggend voor de guren en de afbeeldingen. Zodra een docent een dergelijk element invoegt wil hij of zij de mogelijkheid hebben om dit element te verplaatsen over de pagina of bijvoorbeeld om het element rond te draaien. Het is dan belangrijk dat het programma onderscheid ziet tussen de afbeeldingen, een eigenschap die rasterafbeeldingen niet hebben. Het is wel mogelijk om binnen je programma zelf de elementen bij te houden en deze vervolgens te tekenen op een raster zodat het vectoren lijken. Voor het vrij tekenen en schrijven met een pen is vectorformaat niet erg geschikt. Een vrije tekening zou bestaan uit allemaal kleine streepjes van het ene coördinaat naar het andere coördinaat. Dit levert al snel een grote lijst met elementen op terwijl een rasterafbeelding eenvoudig een kleinere lijst met coördinaten bij kan houden met de bijbehorende pixelwaarden. De lijst met elementen in vectorformaat zou verkleind kunnen worden door `smoothing'-algoritmen toe te passen, maar dit levert vaak een vervorming van het getekende op en maakt de applicatie aanzienlijk trager. Uit deze analyse blijkt dat het eigenlijk wenselijk is om een combinatie van vector- en rasterafbeeldingen te hebben. Wij hebben deze combinatie ontwikkeld door twee bestaande tekensets voor in de browser te ontleden en vervolgens samen te voegen tot een nieuwe tekenset met een rasterlaag en een vectorenlaag. De twee tekensets die we gebruikt hebben zijn SVG-edit en Sketch.
5.6.3 Implementatie SVG-edit is een simpel bewerkingsprogramma met vectoren dat gebruik maakt van het Scalable Vector Graphics formaat (SVG) element uit HTML. Het programma bestaat uit twee aparte modules die afzonderlijk van elkaar kunnen werken. De eerste module is verantwoordelijk voor het samenstellen van de user-interface door een tekentoolbar te initialiseren, het selecteren van kleuren en het starten van de andere module. Deze andere module is verantwoordelijk voor het afhandelen van tekenacties op het canvas. Bijvoorbeeld: Als de gebruiker heeft aangegeven dat hij een vierkant wil tekenen, zorgt deze module ervoor dat het vierkant getekend wordt zodra de gebruiker zijn muis over het canvas sleept. Sketch is een programma dat gebruik maakt van het canvas-element in HTML5. Dit element is een rasterafbeelding waarop pixels getekend kunnen worden. Het canvas-element accepteert argumenten als `lineTo' zodat je eenvoudig meerdere pixels tegelijkertijd in kan vullen.
33
SVG Toolset
SVG Edit
SVG Canvas
Select rectangle setMode('rect') setMode('rect') Actor
Interlectio Toolset
SVG Canvas
Raster Canvas
Select rectangle setMode('rect')
disablePointerEvents()
Actor
setMode('rect')
Figure 5.18: Sequence diagram van oude en nieuwe situatie
In gure 5.18 is een sequence diagram te zien van hoe SVG-edit werkt met zijn eigen twee modules. In onze aanpassing hebben we de edit-module vervangen door de GUI van onze eigen applicatie. Vervolgens leggen we hier een laag overheen met Sketch zonder achtergrond. Bij het klikken op een functie in de toolbar stellen we ook de modus van Sketch in. Kiest de gebruiker voor het tekenen van een vector dan negeert Sketch alle klikken op zichzelf, waardoor het signaal wordt doorgegeven aan het SVG Canvas. Kiest de gebruiker voor een rastermodus (bijvoorbeeld markeren) dan worden de signalen wel opgevangen door het rastercanvas en niet doorgegeven aan SVG. Dit proces is weergegeven in gure 5.18. Met behulp van een derde library genaamd `canvg' kunnen we op basis van een SVG-tekening en de rasterafbeelding een gecombineerde rasterafbeelding maken die gebruikt kan worden om naar de leerlingen te sturen of als kleine voorbeeldafbeelding onderaan het diaoverzicht. De server ontvangt per dia de gecombineerde rasterafbeelding, de SVG-data en de rasterafbeelding van alleen het Sketch document. Voor de gebruiker lijkt het nu alsof deze op een canvas tekent, maar in werkelijkheid liggen er twee canvassen over elkaar. Doordat we een extensie hebben kunnen maken op Sketch en SVG Edit zonder de code zelf aan te passen kunnen we meedraaien met de updates die uitgebracht worden voor deze twee systemen.
Ook is het hierdoor makkelijk om de Sketch module te vervangen door een ander
tekenprogramma.
5.7 Drag 'n Drop met afbeeldingen We hebben in het ontwerp van onze applicatie zoveel mogelijk focus gelegd op een naadloze intuitieve werking. Dit uit zich onder andere in de vorm van Drag 'n Drop (DnD) ondersteuning voor afbeeldingen. De gewenste situatie is als volgt: Een docent kan uit iedere denkbare locatie één of meerdere afbeeldingen in een slide of in de afbeeldingen-browser slepen. Daarbij hoeft de docent zich geen zorgen te maken over het formaat van de afbeelding. Wel is er een beperking opgelegd aan de grootte van de afbeeldingen, om de performance van de applicatie te garanderen.
5.7.1 Native HTML5 Drag 'n Drop Voor het implementeren van DnD wordt vaak gekozen voor jQuery of Javascript libraries. Wij hebben er echter voor gekozen om HTML5 te gebruiken voor DnD, aangezien deze over native browser support beschikt. Dit betekent snellere, meer responsieve DnD en ruimtebesparing vanwege het ontbreken van een noodzaak voor externe libraries.
34
Om DnD-support in HTML5 te benutten zijn twee elementen nodig[1]: 1. Een draggable element 2. Een dropzone element Een object draggable maken houdt in dat je er het html-attribuut
draggable = T rue aan toevoegt.
In de
meeste moderne browsers zijn tekstselecties, afbeeldingen en hyperlinks standaard draggable. Verder zijn in deze browsers de adresbalk en een formulier voor het uploaden van bestanden standaard als dropzones gede niëerd. Sommige browsers zoals Google Chrome beschouwen zelfs het desktop of een willekeurige lokale folder als dropzone. Het laten functioneren van beide typen DnD, vanuit de browser en vanuit een lokale folder, vereist iets verschillende stappen.
5.7.2 Vanuit browser In onze applicatie zijn de thumbnails in de afbeeldingentoolbar als draggable elementen gede niëerd en is de slide één grote dropzone.
Dit is echter nog niet genoeg om DnD te laten werken.
Hiervoor
moet allereerst naar het 'dragstart' event worden geluisterd, om daarin de dataTransfer eigenschap te de niëren.
Hierin dient de content van het versleepbare object samen met zijn mimetype bepaald te
worden, door
event.dataT ransf er.setData(f ormat, data) aan te roepen. Deze dataTransfer event.dataT ransf er.getData().
eigenschap
kan vervolgens worden uitgelezen in het 'drop' event met
5.7.3 Vanuit lokaal foldersysteem Voor het droppen van bestanden afkomstig van een lokale folder moet naar een andere variable van dataTransfer worden geluisterd. In plaats van
event.dataT ransf er.getData(), dient event.dataT ransf er.f iles
opgevraagd te worden om de gesleepte bestanden aan te spreken. Aangezien deze functionaliteit afhankelijk is van het besturingssysteem-speci eke bestandsbeheersysteem, kan niet worden gegarandeerd dat het slepen vanaf een lokale folder voor ieder OS zal functioneren.
5.8 Integratie met Dropbox Dropbox is een clouddienst voor het online opslaan van bestanden en het synchroniseren daarvan met verschillende apparaten. Daarbij is een belangrijk aspect van Dropbox dat online mappen gedeeld kunnen worden. Hiermee is Dropbox een van de populairste applicaties binnen de educatieve wereld. Vooral het delen van bestanden met groepsprojecten maakt het populair. Daarnaast krijgen leden die gebonden zijn aan een geregistreerde educatieve instelling meer online opslagcapaciteit. Dit alles zorgt ervoor dat Dropbox diep geworteld zit in veel scholen, zowel bij docenten als leerlingen. We hebben gekozen voor een dropbox-integratie in onze applicatie, speci ek voor afbeeldingen. Het uitgangspunt hierbij is dat een docent afbeeldingen in dropbox kan plaatsen, binnen een naar eigen wens samen te stellen folderstructuur. Zo kun je denken aan een folderstructuur gebaseerd op verschillende vakken, klassen, hoofdstukken uit een boek of speci eke lessen. We hebben het zo geïmplementeerd dat deze complete hiërarchie, 1-op-1 gesynchroniseerd wordt met de Folder- en Picture-modellen in onze database. Vanuit de javascript-applicatie voor de docent wordt elke 10 seconden een poll gedaan om te kijken of de database en dropbox synchroon zijn, of dat er een eventuele synchronisatie vereist is. Dit houdt in dat er gekeken wordt vanuit twee richtingen: 1. Zijn er modellen in de database die nog niet op de Dropbox server staan? 2. Zijn er bestanden/folders op de Dropbox server die nog niet vertaald zijn naar een model in de database?
5.8.1 Dropbox REST API Dropbox geeft ontwikkelaars de beschikking over een uitgebreide REST API[6], waarmee operaties voor het lezen en schrijven van bestanden van en naar Dropbox kunnen worden uitgevoerd. Voor het implementeren van een dergelijke koppeling heeft Dropbox verschillende development kits beschikbaar gesteld, voor de meest gangbare programmeeromgevingen. Aangezien ons main framework in Python opereert,
35
Algorithm 1 Voorbeeld van respons door API { " size ": " rev ":
" 2 2 5 . 4KB" , "35 e 9 7 0 2 9 6 8 4 f e " ,
" thumb_exists " : " bytes ":
" modified ": " path " :
false ,
230783 , "Tue ,
19
Jul
2011
21:55:38
+0000" ,
"/ G e t t i n g _ S t a r t e d . p d f " ,
" is_dir ":
false ,
" icon ":
" page_white_acrobat " ,
" root ":
" dropbox " ,
" mime_type " : " revision ":
" a p p l i c a t i o n / pdf " , 220823
}
hebben we voor onze koppeling gebruik gemaakt van de o ciële Python SDK. Deze SDK geeft ons de beschikking over alle benodigde methoden die nodig zijn om met de Dropbox API te kunnen spreken.
Vereisten
De Dropbox API de niëert een aantal eisen voor de aanvragen die er naar worden gemaakt.
Zo vereist het dat alle aanvragen over een beveiligde SSL verbinding worden gemaakt. iedere string van en naar de API geëncodeerd zijn in het UTF-8 formaat.
Verder moet
Verder heeft de API een
vaste set van aanroepen die gemaakt mogen worden, waaronder voor authenticatie, account-informatie, bestandsaanvragen en bestandsoperaties. Al deze aanvragen vereisen een bepaalde input en verzekeren een zekere output. Alle input aan de API wordt gegeven in de url, zoals hieronder: h t t p s : / / a p i − c o n t e n t . d r o p b o x . com / 1 / f i l e s /< r o o t >/
Hierbij dienen de elementen 'root' en 'path' als strings in de url te worden meegegeven.
Alle output
wordt gegeven in JSON formaat, zoals te zien in 1.
API foutmeldingen
Tenslotte geeft de Dropbox API nog een lijst aan gestandaardizeerde API fout-
meldingen, welke in de JSON-geformatteerde output worden meegestuurd. De volgende foutcodes kunnen door de API worden teruggegeven: Code 400
Beschrijving Foute input-parameter. Er wordt een foutmelding gegeven welke aangeeft om welke parameter het gaat.
401
Token is fout of verlopen. Dit kan voorkomen als de access token van de gebruiker verlopen of ingetrokken is. Opnieuw authenticeren van de gebruiker kan het probleem oplossen.
403
Foutief Oauth verzoek. Verkeerde sleutel, verlopen timestamp etc. Opnieuw authenticeren zal hier niet helpen.
404 405
Bestand of folder niet gevonden op het opgegeven pad. Verzoek methode onverwacht (in de meeste gevallen dient dit een GET of POST verzoek te zijn..
503
De app maakt teveel aanroepen naar de server en wordt in snelheid beperkt. Deze error kan voor de gehele app of per gebruiker gegeven worden.
507
De gebruiker is door zijn opslagcapaciteit heen.
5xx
Overige serverfouten.
36
Authenticatie
Het authenticatiesysteem van de Dropbox API werkt volgens de algemene OAuth-
speci caties, welke onder andere ook gebruikt wordt in Facebook, Twitter en LinkedIn.
De Oauth
authenticatie- ow werkt als volgt: 1. Iedere geregistreerde Dropbox-app krijgt een app-key en app-secret. Samen met het type toegang wat de app heeft (complete dropbox-folder of een aparte app-folder), wordt hiermee een DropboxSession opgezet. 2. Op basis van deze session kan een request-token worden aangevraagd. Deze request-token is nodig voor een aantal operaties, waaronder voor het maken van een unieke authorization-url. Deze url wordt in onze appicatie gebruikt voor het maken van de 'Connect to Dropbox'-knop. Het volgen van een dergelijke knop geeft een pagina zoals te zien in 5.19.
Figure 5.19: Authorizatie-pagina voor Dropbox-connectie
3. Aan deze authorization-url kan een backlink meegegeven worden waarnaar teruggekoppeld wordt nadat de authorizatie is voltooid. In deze backlink kan vervolgens een access-token aangevraagd worden (ook hiervoor is de request-token nodig), welke alleen teruggegeven wordt als de gebruiker de app toegang heeft verleend. 4. De ontvangen access-token slaan we op in de database, voor de actieve gebruiker. Deze is nodig om een DropboxClient te kunnen construeren op basis van de eerder genoemde DropboxSession. Vanaf dit punt is het mogelijk om vanuit de DropboxClient aanroepen te maken naar de Dropbox API en is de ow compleet.
5.9 Omgaan met schermafmetingen De applicatie heeft als speci eke eigenschap dat het werkt op verschillende apparaten. Naast verschillende besturingssystemen en software krijgt de applicatie ook te maken met verschillende schermafmetingen. De afmetingen kunnen verschillen met betrekking tot de resolutie (het aantal beschikbare pixels) en in fysieke afmetingen (de centimeters). Deze sectie bespreek hoe de applicatie ervoor zorgt dat de getekende afbeelding door de docent op een bepaald scherm, wordt omgezet naar de afmetingen van het scherm van de leerling. Ook beschri-
37
(a) Gelijke ratio
(b) Ongelijke ratio Figure 5.20: Afbeelding verkleinen
jven we hoe we ervoor zorgen dat de onnauwkeurigheid bij aanwijsvragen op een kleiner scherm wordt gecompenseerd wanneer het getoond wordt op een groter scherm.
5.9.1 Dia-inhoud op een ander formaat De docent zal tekenen op een digitaal schoolbord en de afmeting van dit schoolbord moet leidend zijn. De leerlingen krijgen het beeld van het digitale schoolbord door op hun eigen scherm en daarbij moet een transformatie worden toegepast op het beeld van de docent.
Hierbij houden we rekening met de
volgende verschillen:
•
Beeld leerling is groter
•
Beeld leerling is kleiner
•
Beeld leerling heeft een andere ratio (eventueel andere oriëntatie)
Als restrictie geven wij aan dat de docent een schermresolutie van minimaal 800x600 heeft. gangbaar voor alle standaard beamers.
Dit is
Bij een schermresolutie van 800x600 is de kans groot dat de
leerlingen een hogere schermresolutie hebben. Een logische oplossing zou zijn om de dia te vergroten. Voor een doelschermresolutie van 1280 breed zou er een vergroting van 1.6 plaats vinden. Het vergroten van de afbeelding zou een wazig resultaat tot gevolg kunnen hebben waardoor de afbeelding slechter zichtbaar wordt. Daarom is besloten om de afbeelding niet groter te maken voor een groter doelscherm. Wanneer de leerling een kleiner beeldscherm heeft is een transformatie noodzakelijk. Zonder verkleining zou een deel van de afbeelding buiten het scherm vallen. De afbeelding kan eenvoudig verkleind worden met behulp van ingebouwde algoritmen van de webbrowser. Deze projectie is te zien in gure 5.20a. Tot slot is er de situatie waar de leerling een andere ratio heeft dan de docent, bijvoorbeeld een breedbeeld waar de docent dit niet heeft.
De afbeelding zal in dit geval naar eigen ratio geschaald
worden waarbij er balken aan de lege ruimte worden toegevoegd in de kleur van de achtergrond zoals te zien in gure 5.20b.
5.9.2 Onnauwkeurigheid bij aanwijsvragen Op een kleiner scherm is het lastiger om nauwkeurig een punt aan te wijzen. scherm zo kunnen lijken dat een punt goed geplaatst is.
Visueel zou het op een
Stel nu dat het punt tien pixels naast het
doel staat dan is dit op een klein scherm nauwelijks te zien. Wordt dit punt nu getoond op het grote scherm dan worden zijn coördinaten vermenigvuldigd met het schaalverschil.
Stel dat het docenten
scherm nu vijf maal zo groot is dan staat het punt vijftig pixels naast het doel. Dit zou ervoor kunnen zorgen dat het punt naast het doel komt te staan en dus fout wordt gerekend. We geven de stip op het docentenscherm daarom iets groter weer dan op het leerlingscherm, zodat er voor deze onnauwkeurigheid wordt gecompenseerd.
5.10 Software Improvement Group Onderdeel van onze stageperiode was het tweemaal versturen van onze code naar de Software Improvement Group (SIG). SIG is een bedrijf dat gespecialiseerd is in het onafhankelijk beoordelen en inzicht
38
geven in de kwaliteit van software. In deze sectie geven we onze verwachtingen, de beoordeling van SIG en wat we hier vervolgens mee gedaan hebben, voor beide code-beoordelingen apart.
Eerste code-beoordeling
Onze eerste verzending van code naar SIG vond plaats op 10 juni.
Wij
waren aanvankelijk sceptisch over hoe onze code beoordeeld zou worden, aangezien een belangrijk onderdeel van de code structureel hervormd was, enkele dagen hiervoor. Het ging hierbij om het loslaten van Backbone-Relational en het bouwen van een eigen datamanager, met vergelijkbare functionaliteit. Voor een uitgebreide omschrijving van deze hervorming, verwijzen we door naar 5.4. Door deze hervorming waren vooral de nieuwe gedeeltes nog niet genoeg voorzien van commentaar. Op 17 juni ontvingen wij echter de volgende reactie van SIG: "De code van het systeem scoort net vijf sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code volgens onze score zeer goed onderhoudbaar is. Het enige punt waarop een lagere score wordt behaald is Duplicatie. Voor Duplicatie wordt er gekeken naar het percentage van de code welke redundant is, oftewel de code die meerdere keren in het systeem voorkomt en in principe verwijderd zou kunnen worden. Vanuit het oogpunt van onderhoudbaarheid is het wenselijk om een laag percentage redundantie te hebben omdat aanpassingen aan deze stukken code doorgaans op meerdere plaatsen moet gebeuren. In dit systeem is de duplicatie met name te vinden in de JavaScript, bijvoorbeeld tussen 'js/views/students/header.js' en 'js/views/teachers/header.js'.
In dit
speci eke geval lijkt het erop dat op beide plaatsen dezelfde functie wordt gebruikt.
Ook
tussen 'js/views/students/statistics.js' en 'js/views/teachers/statistics.js' is duplicatie te vinden. Het lijkt erop dat de code voor studenten en leraren zeer veel overeenkomsten vertoond. Het is aan te raden kritisch te kijken of deze duplicatie noodzakelijk is of dat er andere mogelijkheden zijn om de kleine afwijkingen tussen beide rollen te modelleren. Over het algemeen scoort de code zeer goed op onze score voor onderhoudbaarheid, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. Als laatste nog de opmerking dat er geen (unit)test-code is gevonden in de code-upload.
Het is sterk aan te
raden om in ieder geval voor de belangrijkste delen van de functionaliteit automatische tests gede nieerd te hebben om ervoor te zorgen dat eventuele aanpassingen niet voor ongewenst gedrag zorgen." We kunnen uit dit commentaar twee punten van verbetering extraheren: 1. Code-duplicatie tussen de docent- en student-applicatie 2. Het ontbreken van (unit)test-code
Code-duplicatie
We waren ons bewust van de grote overeenkomsten tussen de docent- en student-
applicatie. Echter hadden we het idee dat hoewel het nu veel gelijkenissen had, dit in latere versies steeds verder uit elkaar zou groeien, waardoor een abstractieklasse overbodig leek. We hebben daarom naar aanleiding van het commentaar kritisch gekeken naar beide applicaties en zijn er achter gekomen dat ondanks dat de code in de toekomst verder uiteen zal lopen, er een kern is die voor beide applicaties gelijk is en blijft. Dit heeft ertoe geleid dat we een collectie aan generic views hebben toegevoegd, waarvan docent- en studentviews kunnen extenden:
•
Header
•
HorizontalOverview
•
RoomView
•
Statistics
•
Statusbar
•
StatusdialogView
39
(Unit)test-code
Ook van het ontbreken van (unit)test-code waren we ons bewust. We hebben ervoor
gekozen om vooral functioneel te testen, om de volgende redenen: 1. De splitsing tussen een framework in Python en een aanzienlijk deel van de code in javascript, maakt het moeilijk om algemene test-code te schrijven voor het gedrag van de docent- en studentapplicatie. Daarnaast zit veel functionaliteit in een REST API, zowel intern (TastyPie) als extern (Dropbox), waar weer een andere vorm van tests voor nodig zijn. Het zou leiden tot een wildgroei aan test-code op zowel client als server. 2. De belangrijkste elementen van onze applicatie vallen niet of nauwelijks te testen aan de hand van test-code, omdat het alleen visueel waarneembaar is. Neem bijvoorbeeld het proces van antwoord geven in de student-applicatie en het kijken of een stip op de juiste plek in de docent-applicatie verschijnt. Ook de complete werking van alle tekentools zijn nauwelijks testbaar aan de hand van test-code. Om deze redenen hebben we het testen van onze applicatie volgens het principe van Exploratory Testing uitgevoerd, zoals te zien in 6.
40
6
Testen
Exploratory Testing
Voor het testen van InterLectio hebben we Exploratory Testing toegepast. Bij
Exploratory Testing worden eerst de test cases beschreven om vanuit daar de software te implementeren. Hierdoor wordt er tegelijk getest, geschreven en geleerd; de de nitie van Exploratory Testing. De scenarios die als test cases zijn gebruikt in ons project zijn te vinden in bijlage A.4. Deze manier van werken heeft als nadeel dat er bij het maken van verkeerde keuzes tijdens de implementatiefase, deze pas later in het proces worden gedetecteerd. Zo kan er een keuze gemaakt worden voor het gebruik van een bepaald framework, waarna er succesvol een stuk functionaliteit wordt geïmplementeerd. Dit kan vervolgens nog een tijd goed gaan tot er een punt bereikt wordt waarop de code met een ander framework in con ict raakt. Dit is ons overkomen tijdens het implementeren van de synchronisatie van modellen en relaties, zoals staat beschreven in 5.4. Er ging een hoop tijd verloren, maar door de kennis die werd opgedaan was een alternatief relatief snel geïmplementeerd. Een bijkomend voordeel was dat de alternatieve code ook nog eens overzichtelijker en e ciënter was. We hebben gebruik gemaakt van VirtualBox om onze software zo goed mogelijk te testen. Met VirtualBox is het mogeiljk binnen een bepaald besturingsysteem een ander besturingssysteem te ëmuleren. Dit maakt het mogelijk om verschillende browsers in combinatie met verschillende besturingssystemen te testen. Tijdens het implementeren is als browser voornamelijk Google Chrome gebruikt in combinatie met de besturingssystemen Ubuntu 12.04 LTS en Mac OS X Lion. Aangezien de variatie in browsers/besturingssystemen voor bij de studenten hoog ligt is het ook nodig te testen op tablets/smartphones. Hoewel het mogelijk is in VirtualBox een Android-systeem te emuleren stelde Fluxility hier tablets voor beschikbaar. Deze tablets beschikken over iOS (iPad) en Android (Asus Transformer). Het besturingssysteem van Blackberry is bewust niet gebruikt, omdat deze een te klein marktaandeel heeft in de tablet- en smartphonemarkt. Ook vereisen de meeste Blackberry's invoer voor knoppen, scrolling en touch. Dit heeft tot gevolg dat voor alle 3 die soorten input ondersteuning zou moeten worden geïmplementeerd.
Unit tests
Zoals gezegd in 5.10 hebben we geen gebruik gemaakt van geautomatiseerde unit tests.
In het project is voornamelijk tijd gestoken in het ontwikkelen van de client-side van InterLectio, die voor de studenten in elke browser moet werken.
Unit tests zijn niet geschikt om bijvoorbeeld vanuit
verschillende browsers te testen, laat staat vanuit verschillende besturingssystemen. Hierdoor zijn voor InterLectio unit tests alleen geschikt voor het testen van de dataverwerking in Django. Met Exploratory Testing konden we toch de applicatie blijven testen, echter niet geautomatiseerd.
41
7
Discussie
In dit hoofdstuk zullen we re ecteren op het verloop van het InterLectio-project binnen Fluxility en vooruitblikken op de toekomst van de applicatie. In het re ectiegedeelte maken we onderscheid tussen wat goed verliep en wat beter had gekund. In de sectie waarin we vooruitblikken maken we onderscheid tussen wat we zeker nog gaan bouwen voor de eindversie en wat we eventueel nog willen onderzoeken.
7.1 Re ectie In deze sectie geven we een overzicht van alle positieve en negatieve kanten aan het verloop van het project, zowel op persoonlijk vlak als op basis van de gebruikte software en methodieken.
Wat ging goed
Eén van de goed verlopen elementen binnen het project was een naadloze overgang
van onze wireframes van view-structuren ( gure 5.3 en gure 5.4) naar het ontwerp van de gra sche userinterface. Deze wireframes waren bedoeld om onszelf een beeld te geven van de structuur van Backbone Views in de client-based applicaties voor docent en student, maar stelden eveneens Fluxility's gra sch ontwerper Kilian Valkhof in staat een ontwerp te maken voor de applicaties. Een ander positief aspect van ons project was het onderzoeken en opzetten van een Jenkins-project. Jenkins is een web-based applicatie waarmee inzicht verkregen kan worden in de code-kwaliteit. Fluxility gaf aan hier al tijden behoefte aan te hebben omdat de omvang van projecten evenals het aantal werknemers en stagairs blijft groeien.
Doordat er tot nog toe geen tijd was om het systeem te onderzoeken
en uit te proberen, bleek onze stageperiode hier een ideale mogelijkheid voor. is tijdens het project nauw gelet op de code-conventies en code-kwaliteit.
Mede dankzij Jenkins
Inmiddels is op basis van
onze ervaring een Jenkins-installatie gedaan op de development-server van Fluxility en wordt hiermee inmiddels meerdere interne projecten gemonitord. Ons onderzoek naar een manier om object-geriënteerd te kunnen programmeren binnen de javascriptomgeving heeft geleid tot het gebruik van Backbone. Door ons project hebben we binnen het bedrijf een brede basis van kennis neergezet voor toekomstige projecten die gebruik maken van javascript. Verder hebben we tijdens onze stageperiode de kans gehad om met veel klanten te spreken over de applicatie en hebben we tal van pitches en demonstraties van ons werk gegeven. Hierdoor hebben we een goed beeld gekregen van de potentie van en interesse in ons product.
Ook hebben we een aantal
ideeën op kunnen doen aan de hand van feedback van klanten aan wie wij het product presenteerden. Een aantal van deze ideeën hebben we meegenomen in de implementatie van het prototype en een aantal ideeën nemen we mee in onze toekomstplannen. Ten slotte heeft Fluxility veel gestimuleerd tot het actief gebruik van StackOver ow. StackOver ow is een online platform, onderdeel van het Stack Exchange Network, waar programmeurs elkaar helpen bij het oplossen van programmeer-gerelateerde problemen. De visie van Fluxility is dat het kunnen oplossen van andermans problemen de beste manier is om zelf te leren.
Wat ging minder goed? verliepen dan gehoopt.
Ook waren er tijdens dit project een aantal processen die minder goed
Een duidelijke tegenvaller was de hoeveelheid tijd die we verloren hebben in
Backbone-Relational, die we uiteindelijk hebben vervangen door onze eigen data-manager, zoals te lezen in 5.4.
Voor we de beslissing hebben genomen om Backbone Relational uit onze implementatie te
schrappen, is er veel tijd gestoken in het doorgronden van de werking ervan en het oplossen van problemen binnen dit framework. Naast Backbone-Relational waren er in het algemeen veel problemen met frameworks, voortkomend uit het feit dat ze relatief jong zijn.
Zo zijn ook Tastypie, Lettuce, Sketch en SvgCanvas vrij jonge
applicaties en zijn ze nog vol in ontwikkeling. Dit betekent in de praktijk dat veel online documentatie en tutorials niet meer up-to-date zijn, waardoor gegeven oplossingen voor problemen vaak niet meer relevant zijn. Ook staan er voor jonge applicaties vaak relatief veel bugs open, mede vanwege het relatief kleine aantal gebruikers van dit soort frameworks.
7.2 Aanbevelingen In deze sectie stellen we vast welke functies nog voor de eindversie van het product moeten worden geïmplementeerd, alvorens het op de markt kan worden gebracht. Ook geven we aan welke mogelijkheden
42
er zijn voor toekomstige uitbreidingen en wat een projectgroep die met ons werk verder gaat zeker moet onderzoeken.
Te implementeren
Er zijn een aantal onderdelen die cruciaal zijn voor een uiteindelijke lancering
van het product. In de volgende opsomming staat beschreven welke onderdelen dat zijn en waarom ze noodzakelijk zijn: 1.
API Throttling:
Met throttling kan de hoeveelheid calls van een client naar de server tot een
opgegeven maximum worden beperkt. Onze client bevatten een scheduler die we om de zoveel seconden een call laten maken naar onze TastyPie-API. Desalniettemin mogen we er niet op vertrouwen dat er niet veel vaker een call gemaakt zal worden.
Zo is het mogelijk om een geautomatiseerd
systeem duizenden keren per seconde een aanroep te laten maken, wat een grote bedreiging kan vormen voor de server. Throttling is een mechanisme wat tussen de client en server een barrière opzet, wanneer een gegeven maximum aantal calls binnen een gegeven timeframe is bereikt. 2.
API Caching:
Het ontzien van de server kan, naast het beperken van het aantal calls, ook
door het aantal lookups in de database te beperken.
Caching is hiervoor de ideale oplossing.
TastyPie biedt directe ondersteuning voor caching op object-niveau. Dit houdt in dat TastyPie's ModelResources gecached kunnen worden als objecten buiten de database, welke dan dezelfde waarden blijft behouden tot een bepaalde timeout.
Pas wanneer deze timeout is bereikt en een
API-call het model opvraagt, wordt het object opnieuw uit de database gehaald. Dit ontziet niet alleen de server, maar voorziet ook in veel snellere API-responses. 3.
API Authentication/Authorization:
Op dit moment beschikt iedereen die communiceert met
onze TastyPie model-API over read/write access. Dit komt doordat ieder type HTTP-request naar de API doorgelaten wordt voor iedere gebruiker. Dit moet voor het eindproduct in twee opzichten veranderen: (a) Authorizatie: Er moeten restricties worden gesteld aan het type HTTP-request wat gemaakt wordt naar de API. Oftewel, er moet beperkt worden (b) Authenticatie:
wat een gebruiker mag doen.
Er moeten restricties worden gesteld aan welke speci eke gebruikers welke
API-calls mogen maken.
Oftewel, er moet beperkt worden
wie
iets mag doen.
Zo is het
belangrijk onderscheid te maken tussen de rechten die docenten en studenten hebben.
Te onderzoeken
In deze sectie geven we aanwijzingen voor toekomstige uitbreidingen en welke mo-
gelijkheden zeker onderzocht moeten worden. Zowel op technisch vlak als op functioneel en praktisch vlak.
Technisch
Om op technisch vlak te beginnen, kan allereerst onderzocht worden of CoeeScript
wenselijk zou zijn.
CoeeScript is een laag over JavaScript die 1-op-1 compileert naar equivalente
JavaScript-code. Het is bedoeld om code korter, leesbaarder en daarmee beter te onderhouden te maken. Wij denken dat dit zeker in de toekomst een waardevolle toevoeging kan zijn voor InterLectio, omdat
Het nadeel op dit moment is dat de documentatie veelal uitgaat van JavaScript waardoor bepaalde aspecten vertaald moeten worden naar CoeeScript wat tijdens het onderzoeken van nieuwe aspecten erg lastig kan zijn.
de applicatie in de toekomst snel zal groeien in omvang.
Een andere aanbeveling is het onderzoeken of het beter is om de tekentool te baseren op Chalk, in plaats van Sketch.
Het voordeel van Chalk is dat deze uitstekend werkt op de iPad.
is dat hij out-of-the-box niet werkt met andere platforms.
Het nadeel
Wij bevelen daarom aan om onderzoek te
doen naar de mogelijkheden om Chalk te porten naar een algemene HTML5-applicatie, zodat deze ook op Android-apparaten en non-touch apparaten werkt.
Hiervoor zal gekeken moeten worden naar een
manier om touch-events om te kunnen zetten naar equivalente mouse-events. Een mogelijke oplossing is het voorbeeld van Ross Boucher, waarin hij een touchHandler events laat simuleren[2]. Ook is het aan te raden onderzoek te doen naar een mogelijke integratie met bestaande presentatiesoftware, zoals Powerpoint en Prezi.
Op dezelfde manier als bij TurningPoint zou een InterLectio-
vraag gesteld kunnen worden vanuit een slide in bijvoorbeeld PowerPoint. Dit kan absoluut meerwaarde
43
hebben, zeker wanneer uit praktijktests blijkt dat veel docenten huiverig zijn om te schakelen tussen hun vertrouwde presentatiesoftware en InterLectio. Ten slotte is ons advies om de ontwikkeling van Backbone-Relational nauwlettend in de gaten te houden, zodat in een later stadium kritisch geoordeeld kan worden of het opnieuw geïntroduceerd kan worden. Het is namelijk actief in ontwikkeling en werkt op enkele punten na uitstekend. Deze punten zijn echter op dit moment te cruciaal voor gebruik in onze applicatie, zoals te lezen is in 5.4.
Functioneel
Qua functionaliteiten moet in de eerste plaats onderzocht worden welke vormen van
vragen er naast de vraagtypen gede nieerd in 4.2 nog meer wenselijk zijn.
We hebben de applicatie
met dit idee in het achterhoofd zo modulair mogelijk ontworpen, om zo het toevoegen van andere typen vragen eenvoudiger te maken. Verder is het aan te raden om kritisch te blijven kijken naar de mogelijkheden die een docent heeft met de tekenset.
Uit de praktijk zal moeten blijken of er behoefte is aan extra functionaliteit op dit
gebied.
Praktijkwensen en doeltreendheid.
Veel onderzoek moet gedaan worden op het gebied van gebruiksvriendelijkheid Zo zijn een aantal ontwerpbeslissingen gebaseerd op onze kennis en intuïtie, die
wellicht in de praktijk als onjuist kunnen worden ervaren. Zo zal moeten worden onderzocht hoe docenten het ervaren dat alle SVG-elementen achter Sketch worden getekend. Op dit moment blijft Sketch namelijk altijd op de voorgrond, aangezien wij ervan uit zijn gegaan dat Sketch gebruikt gaat worden als digitale equivalent van het krijtje. Hierdoor leek het ons onprettig voor docenten als geschreven content onder een ander element verdwijnt. Verder zijn er een aantal lesgerelateerde mogelijkheden waarvan uit de praktijk en uit gesprekken moet blijken of ze wenselijk en reëel zijn. Hieronder geven we een opsomming van deze mogelijkheden:
•
Individuele monitoring:
Er is tijdens ons ontwerp altijd uitgegaan van anonimiteit bij de leerlin-
gen, om iedereen te stimuleren om mee te doen. Uit een aantal gesprekken met potentiële klanten komt echter vaak de vraag of de individuele resultaten van leerlingen gemonitord kunnen worden door docenten. De applicatie beschikt al over de juiste data om anonimiteit op te heen, maar wij zijn er nog niet over uit of dit wenselijk is.
•
Toetsing:
Een andere optie waar vaak door potentiële klanten naar gevraagd wordt, is het maken
van toetsen via ons systeem. Aangezien we anonimiteit als uitgangspunt in ons originele ontwerp hadden, was toetsing voor de scope van ons project geen optie. Mocht uit de praktijk blijken dat meer gebruikers hier behoefte aan hebben, dan is dit goed in te bouwen binnen ons systeem. Er zal dan wel extra nadruk op beveiliging moeten komen om fraude te voorkomen.
•
Meerdere vragen:
Het stellen van meerdere vragen tegelijk is eveneens een optie, zodat leerlingen
in hun vragen-overzicht zelf de vrijheid krijgen om te navigeren. Dit is een mogelijke manier om de bovenstaande functionaliteit 'toetsing' te implementeren. Op deze manier kan een docent vooraf een collectie vragen creëren, waarbij deze allemaal tegelijk geactiveerd kunnen worden. Dit gaat tegen de wijze in die nu wordt gehanteerd, namelijk dat op het moment dat er een actieve vraag is deze op het scherm van de leerling wordt geforceerd (dat wil zeggen, de student kan de vraag niet wegklikken). Ook ligt de index van de actieve slide op dit moment vast in het database-model van de Room. Hier zou dan eventueel een lijst van gemaakt kunnen worden, waarna studenten door de lijst van actieve vragen kunnen navigeren.
•
Huiswerk:
Ten slotte zou het wenselijk kunnen zijn om InterLectio uit te breiden met de mogeli-
jkheid om huiswerk op te geven. In feite zou de huiswerk-functie op dezelfde wijze geïmplementeerd kunnen worden als de toetsing-functie, aangezien huiswerk kan worden gezien als een toets met een langere deadline. Er zou door middel van een cron-job, een server-side commando wat volgens een bepaald tijdschema wordt uitgevoerd, geïmplementeerd kunnen worden dat alle antwoorden op het verstrijken van de deadline worden opgehaald, waarna de vragen worden gesloten. Tot slot is het belangrijk dat de eectiviteit van InterLectio wordt geanalyseerd, en wordt vergeleken met andere educatieve software, zoals genoemd in 2.3. Ook moeten vergelijkingen worden gemaakt tussen klassen met digitale- en traditionele schoolborden.
Oftewel, de doeltreendheid van het product zal
geëvalueerd moeten worden en lessen moeten worden getrokken uit de feedback van gebruikers.
44
A
Bijlagen
A.1 Backlog Product Backlog #
Prio
Sprint
1
Beschrijving
Docenten applicatie
1.1
2
Slide toevoegen
1.2
2
Volgende / Vorige slide
1.3
3
Teken op slide (met pen / slepen muis)
1.3.1
3
Zwarte penstreken
1.3.2
4
Kleuren selecteren
1.3.3
3
Penstreken uitgummen
1.3.4
4
Dikte van penstreek instellen
1.3.5
4
Figuren invoegen
1.3.6
-
Tekenacties ongedaan maken
1.4
5
1.4.1
5
Drag 'n Drop
1.4.2
5
Bladeren door mappen en afbeeldingen
1.5
-
Tekst invoeren op slide
1.6
2
Vraag maken van een slide
1.6.1
-
1.7
2
Antwoorden tonen
1.8
3
Antwoorden goed of fout keuren
1.8.1
3
Selectie antwoorden goed of fout keuren
1.8.2
3
Barometer updaten
1.9
3
1.9.1
5
1.10.1
5
1.10.2
5
Inloggen
1.10.3
5
Synchroniseren tussen DB modellen en dropbox
1.10.4
5
Connecten met dropbox via API
1.11
4
1.11.1
4
Registeren op de site
1.11.2
4
Settings aanpassen
1.11.3
4
Account veri eren via email
2
Afbeeldingen invoeren op slide
Type antwoord selecteren (punt, lijn, vlak, tekst)
Thumbnails van de slides in the navigatiebalk Navigeren (scrollen) door de balk zonder de slide te selecteren Dropbox
Registratie
Student
2.1
3
2.1.1
-
Op basis van de vraag antwoord geven Tekst invoeren
45
2.1.2
4
3
Punt selecteren
Server
3.1
1
Room aanmaken
3.2
1
Slide aanmaken
3.3
1
Question aanmaken
3.4
1
User aanmaken
3.5
1
Answer aanmaken
Sprint Backlog #1 #
Af
30-04 t/m 12-05
Bijzonderheden
Wat wilden we doen?
Opzet van de database, geen bijzonderheden
3.1
3.2
3.3
3.4
+ +
Toevoegen model
+
Token laten genereren
+
Users in een lijst van participants zetten
+
Slide aanmaken
+
Toevoegen model
+
Koppelen aan een room
+
Question aanmaken
+
Toevoegen model
+
Koppelen aan een slide
+ +
3.5
Room aanmaken
+
User aanmaken Toevoegen model Answer aanmaken
+
Toevoegen model
+
Koppelen aan een question en user
Sprint Backlog #2 #
Af
14-05 t/m 25-05
Bijzonderheden
Wat wilden we doen? 1.1
+
Slide toevoegen
Wordt geüpdatet in de navigatiebalk
1.2
+
Volgende/Vorige slide
Simpele knoppen boven de navigatiebalk
1.6
+
Vraag maken van een slide
Er wordt alleen een vraag object aangemaakt met bijbehorende slide
1.7
+
Antwoorden tonen
Dit zijn dummy antwoorden, er worden er 10 random antwoorden per vraag gecreëerd
46
Sprint Backlog #3 #
Af
28-05 t/m 8-06
Bijzonderheden
Wat wilden we doen? 1.3
-
Teken op slide (met pen / slepen muis)
Niet alle teken tools zijn geïmplementeerd
1.3.1
+
Zwarte penstreken
Nog geen aanpassingen aan de pen-tool, alleen default zwart
1.3.3
+
1.8
+
1.8.1
+
Penstreken uitgummen Antwoorden goed of fout keuren
Student krijgt nog geen update
Selectie antwoorden goed of fout keuren
Lasso-tool werkt niet altijd in Firefox
1.8.2
+
1.9
+-
Barometer updaten Thumbnails van de slides in the navigatiebalk
Alleen SVG wordt geüpdatet in de thumbnail
2.1
+
Op basis van de vraag antwoord geven
Dummy objecten worden aangemaakt
Sprint Backlog #4 #
Af
25-06 t/m 6-07
Bijzonderheden
Wat wilden we doen? 1.3
+
Teken op slide (met pen / slepen muis)
1.3.2
+
Kleuren selecteren
1.3.4
+
Dikte van penstreek instellen
1.3.5
+
Figuren invoegen
1.11
+
1.11.1
+
Registeren op de site
1.11.2
+
Settings aanpassen
1.11.3
+
Account veri eren via email
1.9
+
Thumbnails van de slides in the navigatiebalk
2.1.2
+
Punt selecteren
Registratie
Beide SVG en Sketch
Sprint Backlog #5 #
Af
25-06 t/m 6-07
Bijzonderheden
Wat wilden we doen? 1.4
+
1.4.1
+
Afbeeldingen invoeren op slide Drag 'n Drop
Werkt nog niet optimaal in Mac OS x en andere browsers dan Chrome/Chromium
47
1.4.2
+
Bladeren door mappen en afbeeldingen
Folders en Pictures worden gesynchroniseerd met Dropbox, maar alleen voor de actieve Folder
1.9.1
+
Navigeren (scrollen) door de balk zonder de slide te selecteren
1.10
+
1.10.1
+
1.10.2
+
Dropbox Inloggen Synchroniseren tussen DB modellen en dropbox
1.10.3
+
Connecten met dropbox via API
48
A.2 Planning en agenda Week (Datum)
Sprint
1 (23-4/28-4)
-
Ma
Di
Wo
Do
Vr
Gesprek begeleider
2 (30-4/5-5)
1
Gesprek
Gesprek
Klant A
Klant B Gesprek Klant C
3 (7-5/12-5)
1
4 (14-5/19-5)
2
5 (21-5/25-5)
2
Gesprek Klant D
Documentatie
Gesprek
opsturen
begeleider Gesprek begeleider
6 (28-5/1-6)
3
7 (4-6/8-6)
3
8 (11-6/15-6)
4
Gesprek Klant E Documentatie opsturen Code naar SIG Gesprek begeleider
9 (18-6/22-6)
4
10 (25-6/29-6)
5
11 (2-7/6-7)
5
Feature freeze Documentatie opleveren Gesprek begeleider
12 (9-7/13-7)
De nitieve verslag
13 (16-7/20-7)
Eindpresentatie
-
-
-
Wo
Do
Vr
(a) Planning Week (Datum)
Sprint
1 (23-4/28-4)
-
2 (30-4/4-5)
1
3 (7-5/11-5)
1
4 (14-5/18-5)
2
5 (21-5/2-6)
2
6 (28-5/1-6)
3
Ma
Di
Hemelvaart Vrij 2e Pinksterdag
7 (4-6/8-6)
3
8 (11-6/15-6)
4
9 (18-6/22-6)
4
10 (25-6/29-6)
5
11 (2-7/6-7)
Nathan
Nathan
Nathan
tentamen
tentamen
tentamen
5
Dirk/Nathan tentamen
(b) Agenda Table A.7: Planning en agenda
49
A.3 Oriëntatieverslag In dit oriëntatieverslag wordt beschreven hoe bestaande software wordt gebruikt in ons project. Deze software is bijvoorbeeld een framework waar gebruik van wordt gemaakt of overkoepelende software. Ook staat beschreven naar welke software we hebben gezocht, welke zijn gekozen en welke zijn afgevallen. Van alle bestudeerde software wordt omschreven waarom deze wel of niet is gekozen.
Gebruikte software en programmeertalen Server side Django
Django is een framework geschreven in python. Dit framework is ontworpen om gestruc-
tureerd en overzichtelijk een website tot stand te laten brengen. houden aan het principe van DRY (Don't Repeat Yourself ).
Dit wordt gerealiseerd door vast te
Django biedt de mogelijkheid erg een-
voudig modellen op te zetten en deze te bewerken. Zo wordt er met 1 commando een MySQL database gegenereerd uit de tot dusver ontworpen modellen.
Doordat er aan deze modellen voorgede nieerde
functies zijn gekoppeld, is kennis van MySQL (bijna) niet nodig. Dit wordt volledig opgevangen door Django. Django kent ook een admin sectie dat de gebruiker in staat stelt de MySQL database uit te lezen in een overzichtelijke structuur. Deze admin pagina is ook naar wens in te stellen, zodat objecten die met elkaar gekoppeld zijn ook samenhangen op de admin pagina. Waar Django zorgt voor een MySQL input (vanuit de modellen), zorgt het ook voor de MySQL output (via admin). Een volgend aspect aan Django is het URL ontwerp. Zo zijn er verschillende 'formats' te creeren, waarbij elke format opgevangen dient te worden (bijv site.nl/jaar/maand/dag, maar ook site.nl/jaar is een optie).
Hierdoor blijft het
overzichtelijk, ondanks dat de gebruiker zich steeds 'dieper' in de site nestelt. Deze URL formats hangen samen met de templates, deze templates verwerken de opgevraagde URL. Zo heeft de URL site.nl/jaar/ een "show_year_view"-template en de URL site.nl/jaar/maand/dag een "show_day_view". Binnen ons project is Django vooral belangrijk op de achtergrond dat zorgt voor een beheersbare en overzichtelijke structuur. De functie van Django is daarom ook het verwerken van de data. Voor Django is gekozen omdat het binnen Fluxility gebruikt wordt voor vrijwel al haar producten. De ervaring en kennis die binnen het bedrijf over Django heerst is dan een groot voordeel.
Tastypie
Voor het synchroniseren van lokale modellen in JavaScript en de database modellen in
Django, hadden we behoefte aan een API. Voor Django kwamen we er achter dat Django-TastyPie een veelgebruikte en goed gedocumenteerde oplossing is.
Deze stelt ons in staat snel een naar onze
speci caties aan te passen API te creëren op basis van de modellen zoals we die in Django gespeci ceerd hebben. Tevens bevat TastyPie uitgebreide authorizatie en authenticatie mogelijkheden, welke gebruik kan maken van de ingebouwde Django authenticatie. Dit samen met de mogelijkheid tot authenticatie via een API-key maakt dit tot een geschikte applicatie voor ons project.
Client side framework
De applicatie zal voor een groot gedeelte werken vanuit de webbrowser van
de gebruiker. Het is daarom van belang om een framework te gebruiken dat goed kan schalen met de omvang van de applicatie.
Dit hoofdstuk zet eerst uiteen welke beschikbare talen er zijn, vervolgens
welke taal gebruikt zal gaan worden en tot slot gaan we in op de beschikbare frameworks.
Beschikbare talen
Er zijn vier grote clientside omgevingen beschikbaar op het web, te weten
Adobe Flash/Air, Microsoft Silverlight, Java (Oracle) en HTML5 met JavaScript. De eerste drie zijn applicaties die embedded draaien in de webbrowser. Dat wil zeggen dat het een los programma is dat kan draaien in de webbrowser. HTML5 met JavaScript is een protocol dat in de webbrowser geïntegreerd is. Belangrijk aspect is dat het een protocol is dat door verschillende webbrowsers is geïmplementeerd en daardoor mogelijk een beetje afwijkt in gedrag ten opzichten van de speci caties. De belangrijkste eisen aan de taal zijn alsvolgt: 1. Werken in de grotere (dekstop) webbrowsers (Microsoft Internet Explorer 7+, Google Chrome, Apple Safari, Opera) 2. Werken op de grote operating systems (Windows XP+, Mac OS Leopard+, Ubuntu 10.4+)
50
Omgeving / Eis
1
2
3
4
5
Adobe Flash/Air
++
+
++
-
Microsoft Silverlight
++
++
-
Java (Oracle)
+
++
-
+
-
HTML5
+
++
++
++
++
+
2
Tabel A.8: Mogelijkheden voor iedere omgeving
3. Werken op een redelijk aantal tablets (iPad 2+, Galaxy Tab) 4. Tekenmogelijkheden bieden in Google Chrome 5. Voorkeur: geen extra installaties vereist Uit bovenstaande tabel blijkt dat HTML5 het beste voldoet aan de eisen. Hier moet wel een notitie bij gemaakt worden dat HTML5 nog erg jong is en dat het mede daarom nog niet volledig in alle webbrowsers is geïmplementeerd. Dit vereist dat er extra wordt getest in verschillende webbrowsers omdat er niet aangenomen kan worden dat het overal werkt.
Javascript Framework
HTML5 werkt samen met JavaScript en biedt mogelijkheden om interac-
tiviteit te introduceren in de webbrowser. Een belangrijk aspect om rekening mee te houden is dat er niet langer sprake is van een website in een webbrowser, maar van een echte applicatie in een browser. Voor websites geldt dat zij volledig moeten functioneren in de browser, ook zonder JavaScript. Dit is niet het geval voor onze applicatie. Wij zullen dus werken met een totale afhankelijkheid van JavaScript. JavaScript is van oorsprong geen Object Georienteerde Programmeer taal, maar meer een functionele taal.
In de afgelopen jaren zijn er echter veel ontwikkelingen geweest die ervoor hebben gezorgd dat
JavaScript ook OOP gebruikt kan worden. Dit vereist wel een framework. Er zijn op dit moment twee grote JavaScript frameworks die zich bezig houden met OOP en meer speci ek met MV(V)C modellen. Dit zijn Spine.js en Backbone.js. Beide zijn zeer goede frameworks en beide zijn nog hevig in ontwikkeling. Binnen Fluxility is er meer ervaring met Backbone, onder meer omdat Backbone schaalbaarder is en beter samenwerkt met het server framework Django. Daarom gaan wij voor Backbone. Daarnaast zullen we gebruik maken van het jQuery framework. Dit framework ondersteund in de communicatie tussen de modellen in Backbone en de elementen op de website (DOM).
Code quality Jenkins
Jenkins is een Continuous Integration (CI) tool, vergelijkbaar met AnthillPro en Bamboo.
Bij het maken van een (daily) build gaat Jenkins als volgt te werk:
Het haalt de laatste versie van
ons project binnen van de git-server. Vervolgens voert het binnen deze repository een aantal Djangocommando's uit, welke een serie aan tests uitvoert.
Er wordt getest op:
unit tests, code coverage,
pep8 en pylint-tests (python syntax conventies), csslint en jslint (respectievelijk css en JavaScript syntax conventies). Ook wordt een SLOC (Source lines of Code) analyse uitgevoerd, wat een beeld geeft van de hoeveelheid code.
Deze tests genereren xml les met resultaten, welke vervolgens overzichtelijk in
Jenkins worden ingeladen. Zo geeft Jenkins bij iedere build een overzicht van de code quality en geeft het een inzicht in eventuele code regression. Het nadeel is wel dat het relatief veel tijd kost Jenkins te con gureren.
Django Test
Django heeft ook een eigen test suite waarvan gebruik gemaakt kan worden.
In
deze test suite is het vrij eenvoudig om een website te testen vanwege de uitgebreide webclient die is toegevoegd. Deze client simuleert een gewone webbrowser en de tester heeft volledige controle over deze browser. Het grote voordeel van deze test suite is dat het de mogelijkheid heeft samen te werken met Tastypie, zodat we ook de communicatie vanuit JavaScript met Django goed kunnen testen. Aangezien wij niet echt aan Test Driven Development (TDD) doen is het nog niet zeker dat Django + TastyPie worden gebruikt om te testen, hoogstwaarschijnlijk wel.
51
Lettuce
Behaviour Driven Development (BDD) zorgt ervoor dat eerst het gedrag van het project
wordt bepaald, waarnaar er vervolgens code wordt geschreven op basis van dit gedrag. In Lettuce worden features gede niëerd die zijn geschreven in 'mensentaal'. Zo is een feature bijvoorbeeld "Ik log in". Door eerst de features uit te schrijven kan er op basis van deze lijst een scenario worden geschreven. Ook deze scenario's worden beschreven in spreektaal. Per stap van het scenario, 'ik ben op de site', 'ik vul het formulier in', wordt een functie aangemaakt waarmee vervolgens die stap wordt uitgevoerd. Het is de bedoeling eerst deze feature lijst zo volledig mogelijk aan te maken en op basis daarvan het programma te maken. Doordat ons programma voornamelijk op JavaScript draait en slechts data commando's via de webbrowser verwerkt was Lettuce niet geschikt om uiteindelijk mee verder te werken.
52
A.4 Requirements Speci cations
Room Owner app
Participant app
Open lokaal
Neem deel in lokaal
<requires>
Navigeer door slides
Voeg slide toe
Wacht op vraag
Docent <uses>
<requires>
Stel vraag
Beantwoord vraag
Keur antwoord goed Behandel antwoorden
Zie of vraag goed is <requires>
Keur antwoord fout
Figure A.1: Use case diagram
Use case #D1 Titel
Open room
Samenvatting
Use case begint als de leraar is ingelogd. De docent maakt een room aan. Use case eindigt als de leraar in de room zit en kan gaan tekenen
Primaire actor
Docent
Secundaire actor
-
Precondities
Docent is ingelogd en heeft nog geen actieve room
Postcondities
De room is aangemaakt, geopend en leerlingen kunnen deze joinen
Main Flow
1. Sessie is niet gestart 2. Docent navigeert naar hoofdpagina 3. Docent klikt op knop "Create room" 4. Systeem valideert gebruiker, controleer of: 4.1. Gebruiker ingelogd is 4.2. Gebruiker docent-bevoegdheid heeft 4.3. Er geen room actief is voor deze docent 3. Unieke key aanmaken en weergeven
53
Leerling
Use case #D2 Titel
Slide aanmaken
Samenvatting
Use case begint als docent een room open heeft. Of er is nog geen slide aanwezig (D1 stap 5.3), of er wordt door de docent een nieuwe slide aangemaakt
Primaire actor
Docent
Secundaire actor
-
Precondities
Er moet een room actief zijn om de slides aan toe te voegen. De docent bevindt zich in deze actieve room
Postcondities
De slide is aangemaakt en wordt geseleceert als actieve slide
Main Flow
1. De sessie is gestart (D1) 2. Docent klikt op knop "Add slide" of klikt op "Next slide" terwijl er geen volgende slide is. 3. Systeem maakt slide aan in database met: 3.1. Actieve room als room 3.2. Volgnummer één meer dan de vorige slide 4. Applicatie maakt een nieuwe slide-thumbnail aan in het slide-overzicht 5. Systeem stuurt gebruiker door naar zojuist aangemaakte slide
Use case #D3 Titel
Vraag aanmaken
Samenvatting
Van de actieve slide wordt een vraag gemaakt, zodat de studenten deze kunnen beantwoorden
Primaire actor
Docent
Secundaire actor
Student
Precondities
Er moet een actieve slide in een actieve room zijn waarover een vraag gesteld kan worden
Postcondities
De vraag is aangemaakt en de studenten krijgen deze vraag op hun scherm (geforceerd)
Main Flow
1. Er is een slide aangemaakt en actief (D2) 2. Docent vult de slide met data, door middel van de tekentools 3. Docent plaatst een vraag mondeling of door deze in de slide te schrijven 4. Docent klikt op de knop "Turn into Question" 5. Systeem maakt vraag aan in database met: 5.1. Actieve slide als slide 5.2. Open voor beantwoording 5.3. Volgnummer één meer dan vorige vraag 5.4. (Prototype: Random gegeneerde antwoorden) 6. Applicatie laat zien dat huidige slide in question is veranderd (Prototype: vraagteken icoon in slide-thumbnail) 7. Applicatie van student herkent nieuw geactiveerde vraag 8. Vraag wordt getoond in scherm van student
54
Use case #D4 Titel
Antwoorden verkrijgen
Samenvatting
Er is een antwoord gegeven door een student en moet worden verkregen op de computer van de docent
Primaire actor
Docent
Secundaire actor
Student
Precondities
Er dient een antwoord te zijn gegeven door de student
Postcondities
Het antwoord wordt opgeslagen en kan worden verwerkt door de docent
Main Flow
1. Er is een actieve vraag open voor beantwoording (D3) 2. De studenten voeren in hun applicatie een antwoord in (S3) 3. Docent sluit de vraag (D5) 4. Systeem update question in database, zodat: 4.1. Alle gegeven antwoorden van alle participanten worden opgeslagen 5. Applicatie toont alle gegeven antwoorden van de vraag
Use case #D5 Titel
Sluit vraag
Samenvatting
Als de docent besluit dat er geen antwoorden meer gegeven kunnen worden en sluit de vraag
Primaire actor
Docent
Secundaire actor
Student
Precondities
Er is een room actief en een vraag actief voor beantwoording
Postcondities
Vraag is gesloten en er kunnen geen antwoorden meer worden gegeven
Main Flow
1. Er zijn antwoorden verkregen (D4) 2. De docent klikt op de knop "Close Question" 3. Systeem update question in database, zodat: 3.1. Vraag wordt gesloten voor antwoorden 4. Applicatie voor studenten blokkeert het geven van een antwoord
Use case #D6 Titel
Beoordeel antwoord
Samenvatting
De docent dient de gegeven antwoorden te beoordelen met goed/fout
Primaire actor
Docent
Secundaire actor
Student
Precondities
Er is een actieve room met een zojuist gesloten vraag
Postcondities
Het antwoord van de student is aangemerkt als fout/goed en is opgeslagen in de database
Main Flow
1. De vraag is gesloten (D5) en de antwoorden zijn verkregen (D4) 2. Docent selecteert (een) antwoord(en) door middel van een lasso-tool 3. Applicatie toont goed/fout venster na het beëindigen van de selectie (mouse-release) 4. Docent selecteert "Goed" of "Fout" 5. Systeem update alle antwoorden in database, zodat: 5.1. Antwoorden aangemerkt zijn als goed of fout 6. Applicatie voor studenten toont beoordeling gegeven antwoord (S4)
55
Use case #D7 Titel
Sessie sluiten
Samenvatting
De les van de docent is afgelopen en iedereen dient de room te verlaten
Primaire actor
Docent
Secundaire actor
Student
Precondities
Er is een actieve room die gesloten kan worden
Postcondities
De room is gesloten en enkel de docent kan er weer in om hem open te stellen
Main Flow
1. Er is een sessie gestart (D1) 2. Docent klikt op de knop "Close Room" 3. System update room in database, zodat: 3.1. Alle participanten zijn uit de room verwijderd 3.2. Room op inactief is gesteld 4. Applicatie stuurt docent terug naar hoofdscherm 5. Applicatie voor studenten toont melding dat de room gesloten is
Use case #D8 Titel
Slide aanpassen
Samenvatting
Een slide wordt aangepast/bewerkt
Primaire actor
Docent
Secundaire actor
Student
Precondities
Er is room actief met een actieve slide
Postcondities
Slide is aangepast en de thumbnail is bijgewerkt en opgeslagen in de database
Main Flow
1. Er is een slide aangemaakt en geactiveerd (D2) 2. Docent klikt op een tekentool uit de toolset (Vrij tekenen, vierkant, cirkel, afbeeldingen etc.) 3. Docent past de slide aan met de zojusit gekozen tekentool 4. Systeem update slide in database, zodat: 4.1. Afbeeldingen worden opgeslagen en gekoppeld aan de slide 4.2. Thumbnail wordt bijgewerkt op mouse-release
56
Use case #S1 Titel
Room joinen
Samenvatting
De student joint een room die beschikbaar is gesteld door de docent
Primaire actor
Student
Secundaire actor
Docent
Precondities
De docent heeft een room aangemaakt, geactiveerd en verstrekt de studenten de unieke token om te kunnen joinen
Postcondities
De student is toegevoegd als participant aan de room en zal de vragen van de docent op zijn scherm zien verschijnen
Main Flow
1. Sessie is gestart (D1) 2. Docent verstrekt unieke token 3. Student navigeert naar hoofdpagina 4. Student klikt op de knop "Join Room" 5. Applicatie toont een invulformulier 6. Student voert de token in 7. Systeem valideert token, controleer of: 7.1. Room voor gegeven token bestaat 7.2. Room actief voor deelname is 8. Systeem update room in database, zodat: 8.1. Student wordt toegevoegd aan participants 9. Systeem stuurt gebruiker door naar zojuist gejoinde room
Use case #S2 Titel
Vraag bekijken
Samenvatting
Als de docent een vraag stelt zal deze vraag tevoorschijn komen op het scherm van de student
Primaire actor
Student
Secundaire actor
Docent
Precondities
Er is zojuist door de docent een vraag geactiveerd
Postcondities
De student ziet de vraag op zijn scherm en kan deze beantwoorden
Main Flow
1. Er is een slide aangemaakt en geactiveerd (D2) 2. De docent maakt een vraag over deze slide (D3) 3. Applicatie van student merkt dat er een vraag geactiveerd is en: 3.1. Toont deze op het scherm 3.2. Disabled navigatie, zodat deze vraag ten alle tijden zichtbaar blijft
57
Use case #S3 Titel
Vraag beantwoorden
Samenvatting
De student geeft antwoord op de gestelde vraag
Primaire actor
Student
Secundaire actor
Docent
Precondities
Er is zojuist door de docent een vraag geactiveerd en deze is zichtbaar in het scherm
Postcondities
Het antwoord wordt opgeslagen en kan worden verwerkt door de docent
Main Flow
1. Er is een actieve vraag (S2) 2. Student geeft een antwoord: 2.1. (Prototype: Student klikt een punt aan in de slide) 3. Systeem maakt antwoord in database aan, met: 3.1. Actieve vraag als vraag 3.2. Student als actieve gebruiker 3.3. Antwoord in de vorm van tekst of x- en y-coördinaten (Prototype) 4. Applicatie van student toont gegeven antwoord in het scherm (Prototype: stip)
Use case #S4 Titel
Beoordeling ontvangen
Samenvatting
Als de docent een antwoord goed/fout keurt zal de student hiervan op de hoogte worden gesteld
Primaire actor
Student
Secundaire actor
Docent
Precondities
Het antwoord van de student is beoordeeld door de docent
Postcondities
De student weet of zijn/haar antwoord goed/fout is
Main Flow
1. Docent heeft vraag gesloten (D7) 2. Docent beoordeelt het antwoord van de student (D6) 3. Applicatie toont de beoordeling d.m.v. een groen/rood cirkeltje
58
A.5 Vergelijking bestaande digitale lesmiddelen
Invoermogelijkheden
Antwoorden
Turning-
Microsoft
Point
Interactive
Tekst
+
+
-
+
+
Vectoren
+
+
-
+
-
Afbeeldingen
+
+
-
+
-
Vooraf de nieren
+
+
+
+
+
-
-
+
+
+
-
+
+
+
-
Track students
+
+
+
+
-
Multiple Choice
Stapsgewijs
Socrative
SmartSync
Activote
behandelen Feedback naar student
Vraagsoorten
Conditional branching
+
+
+
-
+
Yes/No
-
+
+
-
+
Open vraag
-
+
+
-
-
+
+
+
-
-
-
+
+
+
-
Navigeren door wenselijke vragen
Adhoc vragen
Adhoc vragen stellen
Integraties
PowerPoint
+
+
-
-
-
OneNote
-
+
-
-
-
ActivBoard
-
-
-
-
+
-
-
-
+
-
-
-
+
-
-
- -
-
+
+
-
Laptop
-
+
+
+
-
Tablet
-
-
+
+
-
iPhone
-
-
+
+
-
- -
-
+
-
-
- -
-
+
-
-
software SmartBoard software Webbrowser Hardware
Geen extra hardware
Geen software installeren Multi-platform
(a) Tabel A.9: Vergelijking mogelijkheden van bestaande digitale lesmiddelen
59
A.6 Projectomschrijving De opdrachtgever Fluxility is in 2005 opgericht door drie ondernemende studenten.
Zij begonnen met het aanbieden
van kwalitatief goede websites en webshops voor een eerlijke prijs. Tegenwoordig werken zij met acht personen vanuit De Innovatiefabriek in Zoetermeer. Om een volledig dienstenpakket aan te bieden hebben zij iPad applicaties aan hun portfolio toegevoegd, alsmede de mogelijkheid om maatwerkopdrachten te programmeren.
In de loop der jaren is Fluxility qua techniek voorop blijven lopen.
Door elke keer
de nieuwste technologieën toe te passen en door altijd de doelgroep van hun klanten voor ogen te houden bij de ontwikkelingen van websites blijft Fluxility websites opleveren die een sterk onderscheidend vermogen hebben. Tot hun klanten behoren veel MKB ondernemingen, middelbare scholen en gemeenten. Daarnaast hebben zij ook multinationals als klant die hun applicaties op Europese schaal inzetten.
Contactpersonen Lars Blommers, mede-oprichter van Fluxility, zal als contactpersoon binnen het bedrijf fungeren.
Hij
is een van de vennoten van het bedrijf. In 2007 is Lars afgestudeerd aan de Erasmus Universiteit van Rotterdam. Binnen Fluxility is Lars de business analyst en accountmanager.
Probleemstelling Het ontwikkelen van een webapplicatie die het mogelijk maakt om klassikaal open vragen te stellen met behulp van een digitaal schoolbord.
De leerlingen kunnen de vragen beantwoorden met behulp van
laptop of tablets. De antwoorden die de leerlingen geven worden centraal verzameld en kunnen worden weergegeven op het digitale schoolbord.
Doelstelling Het creëren van een applicatie die het mogelijk maakt voor docenten om klassikaal open vragen te stellen, om vervolgens de juiste van de onjuiste antwoorden van elkaar te onderscheiden. Hierbij worden de gegeven antwoorden via slimme algoritmen gegroepeerd. Voordelen:
•
Geen voorbereiding vereist
•
Geen de nitie van wat goed en fout is vereist
•
Moment van vragen stellen kan zelf worden gekozen
•
Alle mogelijkheden zijn open, dus veelvoorkomende fouten komen beter naar voren
•
De docent kan alle antwoorden behandelen en hierdoor duidelijk in kaart brengen waar denkenfouten gemaakt zijn
Op te leveren producten Uitgebreide conceptbeschrijving, inclusief klassediagrammen, use-cases, etc. Het eindproduct: De webapplicatie.
Risicofactoren Onvoorziene moeilijkheden met voor ons nog onbekende programmeerprincipes en technieken.
60
Referenties [1] Eric
Bidelman.
[2] Ross
Boucher.
Native
html5
drag
and
http://www.html5rocks.com/en/tutorials/dnd/basics. iphone
touch
events
in
drop,
javascript,
February
August
2012.
URL
2008.
URL
http://ross.posterous.com/2008/08/19/iphone-touch-events-in-javascript/.
[3] Denise van Eyk Carl Binder, Elizabeth Haughton.
Precision teaching attention span.
Exceptional Children, 22(3):2427, 1990.
[4] Arthur W Chickering and Zelda F Gamson. education.
Teaching
Seven principles for good practice in undergraduate
Biochemical Education, 17(3):140141, 1989.
[5] chrisbraddock. latedmodel
Fetchrelated
key;
not
if
key
works
if
fetched()
relationalmodel from
server,
https://github.com/PaulUithol/Backbone-relational/issues/115. [6] Dropbox. Rest api. URL
init'ed
May
with
2012.
reURL
https://www.dropbox.com/developers/reference/api.
[7] Meredith D. Gall. The use of questions in teaching.
Review of Educational Research, 40(5):707721,
1970. [8] Paul
Uithol.
Try
to
load
updated
relations
from
`keysource`
as
well,
July
2012.
URL
https://github.com/PaulUithol/Backbone-relational/commit/7dcd7367ac75a2ce9c106de50d3680eabf3ee495.
[9] wkleinheerenbrink. June 2012. URL
Relational:change is always red by backbone.relationalmodel.updaterelations,
https://github.com/PaulUithol/Backbone-relational/issues/140.
61
