• No results found

Een bruikbaar interface voor geautomatiseerde online proctoring

N/A
N/A
Protected

Academic year: 2021

Share "Een bruikbaar interface voor geautomatiseerde online proctoring"

Copied!
35
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

Bachelor Informatica

Een bruikbaar interface voor

geautomatiseerde online

proc-toring

Steven Raaijmakers

June 26, 2018

Supervisor(s): Gosia Migut

Inf

orma

tica

Universiteit

v

an

Ams

terd

am

(2)
(3)

Abstract

Het onderwijs digitaliseert en daarmee stijt het aantal digitale tentamens. Belangrijk is dat bij deze digitale tentamens surveillance plaatsvindt om zo fraude te kunnen detecteren. Om digitale tentamens te surveilleren wordt online proctoring toegepast, waarbij meegekeken wordt op het computerscherm van de student. Deze vorm van digitale surveillance vindt plaats door een mens of door een algoritme (automatische proctoring). Momenteel bestaan er verschillende aanbieders van online proctoring applicaties, die nadelen kennen. In dit onderzoek wordt er een voorstel gedaan voor een interface van een automatische online proctoring applicatie die deze nadelen adresseert.

(4)
(5)

Contents

1 Introductie 7

1.1 Onderzoeksvragen . . . 8

2 Achtergrond 9 2.1 Digitaal onderwijs . . . 9

2.2 Fraude in digitale tentamens . . . 9

2.2.1 Werking online proctoring . . . 10

2.2.2 Nadelen . . . 12

2.3 Product ontwerp . . . 12

2.3.1 Front-end ontwerp . . . 13

2.3.2 Back-end . . . 15

3 Methodologie 17 3.1 UvA online proctoring . . . 17

3.2 Onderzoeksprotocol . . . 17 3.3 Product implementatie . . . 19 3.3.1 Front-end . . . 20 3.3.2 Back-end . . . 20 4 Resultaat 23 4.1 Producteisen . . . 23 4.2 Product design . . . 25 4.2.1 Front-end . . . 25 4.2.2 Back-end . . . 29

4.3 Evaluatie van het eindresultaat . . . 29

5 Conclusie en Discussie 31 5.1 Antwoord op onderzoeksvragen . . . 31

5.2 Voorgestelde experimenten . . . 32

5.2.1 Interface toepassen op andere data . . . 32

5.2.2 Incident defini¨eren . . . 32

5.3 Discussie . . . 32

5.3.1 Vervolgonderzoek . . . 32

5.3.2 Problemen . . . 32

6 Apendix 35 6.1 Aangepaste WEQ van Elling . . . 35

(6)
(7)

CHAPTER 1

Introductie

Wanneer buitenlandse studenten aan een universiteit een master willen volgen kan er van de student gevraagd worden of hij/zij eerst wil deelnemen aan een aantal vakken, in de vorm van een pre-master. Hiermee kunnen de vaardigheden van de student op voorhand getoetst worden. Ook de Universiteit van Amsterdam (UvA) maakt gebruik van dergelijke pre-masters. Omdat het studenten betreft die woonachtig zijn in een land anders dan Nederland wordt deze pre-master volledig digitaal aangeboden. Hierdoor kan de pre-pre-master op afstand gemaakt en voltooid worden. De vakinformatie, de college´s en de opdrachten zijn terug te vinden in de digitale leeromgeving BlackBoard1. Aan het eind van een vak wordt de opgedane kennis van de student getoetst middels een tentamen dat ook digitaal wordt afgenomen.

Belangrijk is dat hierbij gecontroleerd wordt of de resultaten op een eerlijke manier behaald zijn. Bij traditionele tentamens vindt deze controle plaats met behulp van surveillanten in een tentamenzaal waar studenten met pen en papier het tentamen maken. Hiermee wordt het aantal manieren waarop fraude gepleegd kan worden zoveel mogelijk beperkt. Omdat digitale tentamens via een computer worden gemaakt zijn er veel meer mogelijkheden om te kunnen frauderen, zeker wanneer het digitale tentamen op afstand plaatsvindt. Om dit toch te controleren wordt online proctoring toegepast. Met behulp deze digitale surveillance kan de authenticiteit en eerlijkheid van een student tijdens digitale tentamens worden getoetst ([25]).

Doordat online proctoring steeds beter kan worden uitgevoerd kunnen tentamens vaker dig-itaal worden afgenomen waardoor het onderwijs kan flexibiliseren. Digitale tentamens bieden namelijk de mogelijkheid tot het volledige aanbieden van digitale cursussen. Dit heeft tot gevolg dat er onderwijs kan plaatsvinden dat zowel tijds- als plaatsonafhankelijk is. Dit biedt een uitkomst voor gevallen waarbij studenten niet in staat zijn fysiek aanwezig te zijn doordat zij zich bijvoorbeeld in het buitenland bevinden of ziek zijn. Ook bieden digitale cursussen een oplossing voor studenten die eerder of juist later een tentamen willen afnemen.

Ook kan online proctoring worden ingezet worden bij digitale tentamens waar studenten wel fysiek aanwezig moeten zijn op een campus. Momenteel worden digitale tentamens afgenomen in speciale digitale tentamenzalen waarbij surveillanten meerdere computerschermen tegelijk moni-toren. Hierbij maken de studenten gebruik van computers die de tentamenzaal aanbiedt waarop software staat die bijvoorbeeld de toegang ontzegt tot bepaalde websites en de monitorbeelden live-streamt naar de surveillanten. Met de nieuwste ontwikkelingen op het gebied van online proctoring is het mogelijk om de studenten deze software op hun eigen pc te laten installeren waardoor de digitale tentamens volgens het Bring Your Own Device (BYOD) principe kunnen worden afgenomen. Hierdoor zullen onderwijsinstellingen niet meer afhankelijk zijn van digitale tentamenzalen maar kunnen eenvoudige klaslokalen ingezet worden, zolang deze toegang bieden tot stroom en een internetverbinding.

(8)

1.1

Onderzoeksvragen

In deze scriptie wordt onderzoek gedaan naar een interface voor automatiseerde online proc-toring. Het doel hierbij is de resultaten van het fraude detectie algoritme op een bruikbare manier presenteren aan de gebruikers, de surveillanten. Hierbij wordt de volgende definitie aan “bruikbaar” - beschreven in Nielsen, 2006 [19] - toegekend:

... a quality attribute relating to how easy something is to use. More specifically, it refers to how quickly people can learn to use something, how efficient they are while using it, how memorable it is, how error-prone it is, and how much users like using it.

De onderzoeksvragen van dit onderzoek luiden als volgt:

1. Hoe wordt een bruikbaar interface ontwikkeld voor geautomatiseerde online proctoring?

(a) Welke producteisen moet een interface voor geautomatiseerde online proctoring hebben? (b) Hoe kan door middel van feedback op een interface de kwaliteit verbeterd worden? (c) Wat is de kwaliteit van het verbeterde interface volgens potenti¨ele gebruikers?

(9)

CHAPTER 2

Achtergrond

2.1

Digitaal onderwijs

Het onderwijs digitaliseert [11]. Dit gebeurd op kleine schaal, waarbij colleges en opdrachten online kunnen worden teruggevonden, maar ook op grote schaal dankzij de Massive Open Online Courses (MOOCs) [27]. De afgelopen jaren hebben zich wereldwijd miljoenen studenten in-geschreven voor dit soort online cursussen [11]. Deze vorm van digitaal onderwijs biedt mensen over de hele wereld toegang tot hoogwaardig studiemateriaal van topuniversiteiten zoals Harvard

1.

Omdat MOOCs volledig digitaal worden aangeboden is het lastig te controleren op fraude, met name bij het afnemen van de tentamens. Het is belangrijk dat hierop gecontroleerd om zo de waarde van het diploma te behouden. MOOCs bieden verschillende oplossingen voor dit probleem. Zo bestaat de optie om de student het tentamen te laten maken op een hiervoor aangewezen plek. De student zal dan onder toeziend oog van een surveillant het tentamen afne-men op bijvoorbeeld een ambassade of een lokaal tentaafne-men-centrum. Dit is een relatief kostbare oplossing omdat men hierbij afhankelijk is van locaties en de beschikbaarheid van surveillanten. Daarom wordt online proctoring veel ingezet om fraude bij tentamens van MOOCs tegen te gaan.

2.2

Fraude in digitale tentamens

Doordat digitale tentamens op computers gemaakt worden ontstaan er veel nieuwe manieren om fraude te plegen. Een aantal hiervan worden benoemd in de whitepaper van Sietses, 2018 [25]:

• Internet toegang. Hierbij kunnen de antwoorden op de vragen opgezocht worden op het internet. Dit is echter makkelijk op te sporen door het scherm van de student gedurende het tentamen op te nemen en te bekijken.

• Het tentamen wordt gemaakt door een ander persoon. Met behulp van een webcamvideo zou de authenticiteit van de student [3] kunnen worden vastgesteld.

• Een tweede persoon speelt buiten het zicht van de camera antwoorden door. Dit zou gedetecteerd kunnen worden door het gebruik van een microfoon [9] of het gebruik van een camera waarbij de gehele ruimte is te zien [6].

• Gebruik van spiekbriefjes. Dit zou gedetecteerd kunnen worden door via de webcamvideo de richting van de ogen te volgen [7].

• Een tweede persoon controleert de computer op afstand en vult de antwoorden in voor de student. Dit is alleen te detecteren via een logger die kan controleren wat de toetsaanslagen zijn.

(10)

• Het gebruik van een virtual machine (VM). Hierbij start de student een virtual machine op, dit is niet te detecteren via een schermvideo. Wel zou een tweede camera op het scherm gericht kunnen worden zodat dit gedetecteerd kan worden.

2.2.1

Werking online proctoring

Er bestaan drie hoofdcategorie¨en bij online proctoring [25]:

1. Live online proctoring. Hierbij kijken de examinatoren tijdens het afnemen van het ten-tamen met de afnemers in real-time mee, zoals hierboven beschreven. Dit is de oudste en meest bekende vorm van online proctoring. Een nadeel hiervan is dat het tentamen niet tijdonafhankelijk kan worden afgenomen omdat er in real-time surveillanten beschikbaar moeten zijn.

2. Achteraf online proctoring. Hierbij wordt met behulp van logs en videobeelden van de student die het tentamen afneemt bepaald of er fraude wordt gepleegd. Voordeel hiervan is dat het tentamen zowel plaats- als tijdonafhankelijk kan worden afgenomen. Nadelig is dat de surveillant niet kan ingrijpen tijdens het tentamen wanneer bijvoorbeeld de camera’s verkeerd zijn gepositioneerd.

3. Automatische online proctoring. Hierbij wordt de fraude detectie deels door een algoritme overgenomen. Het algoritme detecteert fraude gevoelige momenten aan de hand van (au-diovisuele) data die vervolgens aan een surveillant gepresenteerd worden. Automatische online proctoring is daarom effici¨ent en tijdsbesparend. Het nadeel is dat dit algoritme gemanipuleerd zou kunnen worden en dat het algoritme niet 100% accuraat kan zijn. De nadelen lijken echter niet op te wegen tegen de voordelen.

Verschillende bedrijven leveren applicaties voor online proctoring. Een grote gelijkenis tussen de applicaties is het gebruik van een hardware opstelling die vaak tenminste ´e´en videocamera bevat. De taak van de aangeboden tools bestaat voornamelijk uit het filteren van grote hoeveel-heden (audiovisuele) data op fraudegevoelige incidenten. Sommige tools gebruiken hiervoor het menselijk oog, andere online proctoring tools claimen dit proces volledig te automatiseren. De beslissing of er in de incidenten daadwerkelijk fraude wordt gepleegd wordt uiteindelijk gemaakt door een menselijke gebruiker. Sterker nog, in Nederland is het volgens de Wet Bescherming Per-soonsgegevens (WBP) [25]2 verboden om dit soort beslissingen te automatiseren. Het

beoorde-len van de incidenten gebeurd door surveillanten van de onderwijsinstelling, zoals examinatoren, docenten of vakassistenten. Deze digitale surveillanten zijn de gebruikers de online proctoring tools.

Twee voorbeelden van bedrijven die online proctoring applicaties aanbieden zijn ProctorExam - dat gebruikt wordt op de UvA - en ProctorU. Daarnaast worden in de papers van Li, 2015 [16] en Atoum, 2015 [1] onderzoeken aangedragen naar online proctoring die geautomatiseerd is.

ProctorExam

ProctorExam3controleert op fraude in digitale tentamens door gebruik te maken van videobeelden.

Deze videobeelden betreffen ´e´en student tijdens het afnemen van het tentamen. Hierbij wordt gebruik gemaakt van verschillende video perspectieven (zie figuur 2.1):

1. Schermopname

2. Webcamvideo

3. Camera op afstand

In de meest basale versie wordt gebruik gemaakt van enkel het eerste video perspectief. In de meest uitgebreide variant worden alle drie de perspectieven in beschouwing genomen. Hierbij moet de student wel over de correcte hardware beschikken.

2WBP: http://wetten.overheid.nl/BWBR0011468/2018-05-01 3ProctorExam: https://www.proctorexam.com/

(11)

Figure 2.1: Verschillende video perspectieven van een student tijdens een tentamen

Aan de hand van de verschillende perspectieven wordt door een menselijk oog bepaald of er in de video’s fraudegevoelige momenten optreden. De fraudegevoelige incidenten worden vervolgens teruggekoppeld naar de gebruiker.

ProctorU

Een andere leverancier is ProctorU4. Ze bieden verschillende tools aan waarbij gebruik gemaakt

wordt van twee video perspectieven: een webcam en een schermvideo. Voordat het tentamen begint worden gevraag een aantal acties te ondergaan. Hierbij wordt de student geverifieerd middels het tonen van een ID kaart aan de webcam. Deze wordt vervolgens gematcht aan het gezicht van de student. Daarna moet de student zijn webcam 360 graden ronddraaien zodat de omgeving van de student gecontroleerd kan worden. Vervolgens kan het tentamen beginnen waarna er detectie over de schermvideo zal plaatsvinden. In ProctorU live gebeurd dit middels toeziend oog van een surveillant in dienst van ProctorU. Bij ProctorU auto vindt deze detec-tie geheel automatisch plaats. Tot slot zullen de bevindingen worden teruggekoppeld aan de gebruiker.

Li, 2015

In Li, 2015 [16] wordt een voorstel gedaan tot Massive Open Online Proctor (MOOP). Een on-derdeel hiervan is automatische online proctoring, waarbij gebruik gemaakt wordt van verschil-lende hardware componenten. Anders dan bij de eerdere genoemde oplossingen is de schermvideo geen onderdeel van deze opstelling. Wel wordt er gebruik gemaakt van vier andere componenten in de vorm van twee video’s: een webcamvideo en een video die gericht staat op het profiel van

(12)

de student, een EEG sensor5 en een gaze tracker6. Via de EEG sensor worden de hersengolven van de student vergeleken met patronen die verkregen zijn door big data analyse. Als de hersen-golven hiervan afwijken kan dit duiden op fraude. Dit kan gezien worden als een student die op voorhand de tentamenantwoorden heeft en zich bij het invullen van de antwoorden verdacht weinig inspant. Aan de hand van de gaze tracker kan gekeken worden naar de richting van de ogen zodat de student niet op een spiekbriefje kijkt of op zijn mobieltje.

Atoum, 2015

In Atoum, 2015 [1] wordt voortgeborduurd op onder andere het onderzoek van MOOP. Omdat de oplossing van MOOP slechts een beperkte set van fraude manieren kan detecteren stellen zijn Online Exam Proctoring (OEP) voor. Hierbij wordt gebruik gemaakt van drie verschillende componenten: de webcamvideo, een microfoon en een wearcam. De wearcam is een camera gemonteerd aan het frame van een bril die de student moet dragen. Hierdoor kan er gekeken worden wat er in het zichtveld van de student ligt. Middels het audiokanaal kan spraak gede-tecteerd worden en via de webcam kan de authenticiteit worden vastgesteld en het zicht worden gevolgd. Al deze detecties methodes vinden geautomatiseerd plaats, net als de fraude detectie in de schermvideo.

2.2.2

Nadelen

Aan het gebruik van de huidige online proctoring applicaties zitten enkele nadelen:

• Uit Brouwer, 2018 blijkt dat de terugkoppeling vanuit ProctorExam te wensen overlaat. Het fraude-rapport blijkt ondoorzichtig te zijn, en het navigeren door de incidenten om-slachtig. Daarnaast vindt de fraude detectie niet automatisch plaats waardoor het een kostbaar proces is.

• Via de automatische proctoring van ProctorU kunnen niet alle manieren van fraude gede-tecteerd worden doordat de dataset beperkt is tot een webcam- en de schermvideo. Hier-door is bijvoorbeeld mogelijk dat een tweede persoon in de ruimte aanwezig is die antwo-orden op de vragen voor het computerscherm houdt. Dit is niet te detecteren via de schermvideo en ook is niet te detecteren dat de student zijn ogen niet op het scherm heeft gericht.

• De hardware opstelling die gebruikt wordt in Li, 2015 is voor veel studenten niet haalbaar. Ze moeten hiervoor namelijk een EEG sensor en een gaze tracker aanschaffen, die enkele honderden euro’s kosten. Daarnaast richt het onderzoek zich op een beperkte set van fraude manieren.

• De hardware opstelling uit Atoum, 2015 lijkt niet voor iedereen toegankelijk. Er moet namelijk beschikking zijn tot een speciale wearcam.

Daarom wordt voorgesteld onderzoek te doen naar automatische online proctoring met behulp van een (voor de student) toegankelijke set van hardware componenten. Het onderzoek uit deze scriptie zal zich richten naar een bijbehorend interface.

2.3

Product ontwerp

Omdat mens en machine vooralsnog niet zonder probleem kunnen communiceren worden in-terfaces ontwikkeld. Inin-terfaces dienen als het communicatiemiddel tussen mens en machine. Hierdoor heeft de interface een prominente rol binnen een systeem en daarom een grote invloed op de bruikbaarheid [19] hiervan [12].

De gebruiker staat in de interface centraal [15] en daarom is belangrijk de interface te on-twerpen volgens de wensen van gebruikers. De wensen van gebruikers komen naar voren door

5Een EEG sensor kan hersengolven meten

(13)

gesprekken. De wensen kunnen vervolgens door productontwerpers omgezet worden naar een product. Om dit proces te versnellen wordt aangeraden met leadusers te spreken in plaats van reguliere gebruikers [13]. Leadusers zijn ervaren gebruikers van een product dat soortgelijk is aan het te ontwikkelen product en kunnen daarom meer informatie bieden dan reguliere gebruik-ers. Daarnaast kan er spraken zijn van een product eigenaar. De eisen van de product eigenaar worden door de product ontwerper voorgesteld aan leadusers om hierover feedback te krijgen. Hierdoor kunnen de eisen van de product eigenaar en de wensen van de leaduser in balans worden gebracht.

Er bestaan verschillende manieren om structuur te geven aan gesprekken met potenti¨ele gebruikers, die hieronder worden besproken.

Methode van Ulrich

Het extraheren van productwensen uit gesprekken met leadusers kan verlopen volgens een vijf-stappenplan beschreven in Product Design and Development [13]. Door deze stappen te volgen wordt er tevens structuur gegeven aan de productwensen zodat deze effici¨enter kunnen worden ge¨ımplementeerd. De methode heeft voornamelijk betrekking op het ontwikkelen van producten die nog niet bestaan.

Als de eisen zijn ge¨ımplementeerd is het belangrijk om feedback te krijgen vanuit de potenti¨ele gebruikers. Hierdoor kan het product waar nodig verbeterd worden.

Think Aloud Protocol

Een veelgebruikte methode om de bruikbaarheid van een product te testen is middels het gebruik van het Think Aloud Protocol [15]. Bij dit protocol wordt gebruikers gevraagd hardop te denken terwijl ze een set van taken uitvoeren met het product. Deze uitgesproken gedachtes zeggen vaak meer over de cognitieve capaciteiten van de gebruiker dan over het product zelf. Daarom is het de taak aan de product ontwerpen dezee opmerkingen objectief om te zetten om ze zo te kunnen relateren aan de bruikbaarheid van het product.

Op basis van feedback over de bruikbaarheid kan het product verbeterd worden waardoor de kwaliteit van het product verhoogd wordt.

Reflectie via enquˆetes

De kwaliteit websites kan worden getoetst aan de hand van enquˆetes. Het voordeel van enquˆetes is dat op een eenvoudige manier een groot publiek bereikt kan worden [8].

In de literatuur zijn er verschillende onderzoeken die technieken presenteren voor het afnemen van online enquˆetes omtrent de bruikbaarheid van websites, waarvan er drie de volgende zijn:

1. Website Analysis Measurement Inventory (WAMMI) [14]

2. Website User Satisfaction questionnaire (WUS) [18]

3. Website Evaluation Questionnaire (WEQ) [8]

Deze enquˆetes bestaan allen uit een set van vragen waarmee websites worden ge¨evalueerd aan de hand van verschillende componenten.

2.3.1

Front-end ontwerp

Het frond-end ontwerp van een interface is het gedeelte dat zichtbaar is voor de gebruiker. Het wordt daarom ook wel de userinterface (UI) genoemd. In de UI ontwerp wereld hebben de afgelopen 10 jaar drie grote stromingen plaatsgevonden. Typerend aan deze stromingen is dat ze ontstaan doordat grote technologiebedrijven bepaalde ontwerp-principes presenteren in het ontwerp van interfaces voor hun producten. Deze bedrijven worden gezien als trendsetters die gevolgd worden door duizenden, die deze principes overnemen bij het ontwerpen van hun eigen interfaces.

(14)

Figure 2.2: Het oude uiterlijk van Apple Note

Skeuomorphisme

De eerste grote digitale ontwerpstroming betreft het skeuomoprhisme die zijn bekendheid dankt aan Apple. Zij lanceerde met haar iPhone in 2007 een nieuw uiterlijk voor het besturingssysteem iOS. Het interface ontwerp van iOs was opvallend en werd als skeuomorphistisch [21] bestempeld. Hiermee doelde men op het feit dat een digitale omgeving kunstmatige eigenschappen krijgt toebedeeld uit de echte wereld, die geen functionaliteit bieden aan het systeem. Een voorbeeld hiervan is de oude interface van Apple Note (zie figuur 2.2), vormgegeven als een notitieblok zoals men deze kent uit de “echte wereld”. Waar de lijntjes op het papier in de echte wereld een functie dragen, zijn ze in de digitale wereld overbodig. Deze kunstmatige eigenschappen worden toegevoegd om de mens kennis te laten maken met digitale interfaces en om deze te laten begrijpen op basis van herkenning met producten uit de echte wereld. Het gebruik van het skeuomorphisme lijkt daarom een logische design aanpak te zijn aan het begin van de digitaal revolutie.

Tegenwoordig bestaat de gebruiker van de digitale wereld steeds meer uit de zogeheten Digital Natives [23]: personen die zijn opgegroeid in het digitale tijdperk. Een voorbeeld hiervan is een zeven-jarig kind dat de smartphone van zijn moeder moeiteloos kan bedienen. De transitie functie die skeuomorphisme biedt blijkt dus overbodig te worden.

Flat design

Met de lancering van Microsoft’s Metro desigomgeving - vanaf Windows 8 - lanceerde Microsoft een tegengeluid aan het skeuomorphistische interface ontwerp van Apple (zie figuur 2.3). Bij dit nieuwe type ontwerp wordt de digitale wereld omarmt zoals hij is [20]: twee-dimensionaal. Er is bij flat design daarom geen plek voor schaduwen en reli¨ef maar wel voor heldere kleuren en duidelijke lettertypes.

De invloed van flat design op de digitale design wereld was zo sterk dat Apple uiteindelijk ook omsloeg. Jarenlang werd Apple’s interface design gekenmerkt door het skeuomorphisme maar in 2013 introduceerde zij hun eigen interpretatie van flat design.

(15)

Figure 2.3: Windows 8 met Metro UI

De kritiek op het flat design luidde dat het ontworpen is voor designers en niet voor gebruikers [20]. Hiermee wordt bedoelt dat flat design in verhouding tot bijvoorbeeld het skeuomorphisme aantrekkelijk wordt gevonden, maar minder gebruiksvriendelijk is. Het is bij flat design interfaces vaak niet meteen duidelijk met welke objecten interactie kan plaatsvinden7.

Material Design

Material Design werd in 2014 aangekondigd door Google 2.4. Anders dan de eerder genoemde stromingen is Material Design afkomstig van een bedrijf (Google) die deze stroming reguleert. Deze regels beslaan de gehele digitale omgeving8. Material design heeft veel kenmerken van flat

design, en wordt daarom ook wel flat design 2.0 genoemd. Ook hier staan heldere kleuren en duidelijke lettertypes centraal, maar in tegenstelling tot flat design wordt bij Material Design gebruik gemaakt van een derde dimensie. Daarnaast ligt de focus van Material Design op re-sponsieve interactie. Een voorbeeld hiervan is bijvoorbeeld een knop die standaard een schaduw heeft zodat het duidelijk is dat hiermee interactie kan plaatsvinden. Wanneer de knop wordt aangeklikt zal de schaduw veranderen waardoor de illusie wordt gewekt dat de knop daadwerke-lijk is ingedrukt. Hiermee adresseert Material Design de tekortkomingen van flat design. Het wordt daarom steeds vaker gebruikt in UI design.

2.3.2

Back-end

Naast de UI bestaat er ook een back-end waarin onder andere de functionaliteiten van de user interface worden beschreven. Bij web interfaces wordt er gebruik gemaakt van verschillende back-end tools.

NginX

NginX is een webserver [24] die gebruikt kan worden als een reverse proxy server voor onder andere HTTP. Het dient hierbij als communicatie tussen de gebruiker en de computer waarop

7Flat UI Elements Attract Less Atftention and Cause Uncertainty: https://www.nngroup.com/articles/flat-ui-less-attention-cause-uncertainty/

(16)

Figure 2.4: Gmail app, ontworpen volgens de Material Design principes

de webserver zich bevindt. NginX werd ontwikkeld door Igor Sysoev met als doel het C10k 9

probleem op te lossen. Bij dit probleem wordt er een oplossing gezocht voor het optimaliseren van netwerk sockets zodat ze 10.000 connecties tegelijk aankunnen. Dit is een relevant probleem doordat steeds meer mensen toegang hebben tot het internet en grote websites vaak duizenden connecties met gebruikers tegelijkertijd hebben lopen. Igor Sysoev biedt met NginX een oplossing voor het C10k probleem.

NodeJS

NodeJS [26] is een door Ryan Dohl ontwikkelde Javascript omgeving die draait op de serverside, in tegenstelling tot andere Javascript applicaties die draaien op clientside. Hierdoor kan NodeJS lang-draaiende processen ondersteunen waardoor NodeJS zeer geschikt om een webapplicaties mee op te zetten. NodeJS biedt net als NginX een oplossing voor het C10k probleem.

MongoDB

MongoDB is een in 2009 ontwikkelde database die documenten opslaat in de vorm van BSON objecten [2]. BSON is een extensie van JSON en ondersteunt datatypes die JSON niet onders-teunt, zoals datums en kan objecten indexeren. Doordat MongoDB BSON objecten gebruikt is het een flexibele database. Het wordt dan ook gerekend tot de NoSQL databases [10].

(17)

CHAPTER 3

Methodologie

3.1

UvA online proctoring

Het onderzoek uit deze scriptie is onderdeel van een groep waarin onderzoek wordt gedaan naar de automatisering van online proctoring. Om dit proces te kunnen automatiseren maken we gebruik van audiovisuele data. Deze wordt verkregen door middel van een opstelling van drie hardware componenten in de vorm van een schermvideo, een webcamvideo en een camera die op afstand wordt gepositioneerd. Via deze drie perspectieven kan een grote set van digitale tentamen fraude worden gedetecteerd. Daarnaast kiezen we voor videobeelden omdat deze lastiger zijn te manipuleren dan bijvoorbeeld logs waarin browser-geschiedenis wordt bij gehouden. De gekozen opstelling is relatief toegankelijk voor gemiddelde studenten omdat het hardware betreft die in het bezit is van vele jongeren. Laptops hebben namelijk vaak een ingebouwde webcam en de beelden op afstand kunnen via een smartphone opgenomen worden.

Hoewel we uiteindelijk alle manieren van fraude automatisch willen detecteren hebben we ons bij dit onderzoek gefocust op het gebruik van ´e´en hardware component, de schermvideo. Hierdoor beperken we de set van fraude-manieren en daarmee de functionaliteit van het fraude-detectie algoritme. Hierbij stellen we volgende base case op:

“De student maakt op de campus op zijn eigen computer een tentamen waarbij com-municatie wordt gezien als fraude.”

Het fraude detectie algoritme zal dus voorlopig bestaan uit het herkennen van communicatie aan de hand van de schermvideo. Gebruik van alle websites is toegestaan zolang hier niet via gecommuniceerd wordt. Om het proces te versnellen wordt het algoritme niet uitgevoerd over de gehele video maar over een gefilterde versie hiervan. In de gefilterde versie zijn irrelevante frames weggegooid, zoals frames waarin nauwelijks tot geen activiteit plaatsvindt. Tot slot moeten de resultaten van het algoritme gerepresenteerd worden aan de gebruiker (de surveillant) middels een interface, waar het onderzoek uit deze scriptie zich toe richt (zie figuur 3.1).

3.2

Onderzoeksprotocol

Om een concreter beeld te krijgen van de interface zal eerst worden gesproken met de product eigenaar. Daarna zoeken we contact met leadusers. Dit betreft een groep docenten van de UvA die eerder met online proctoring applicaties hebben gewerkt. In alle gevallen gaat dit om ProctorExam.

We delen het onderzoek naar de interface op in drie momenten. Bij elk moment is er contact met leadusers waarbij steeds een andere methode uit de literatuur wordt gevolgd om data uit de leadusers te krijgen. De momenten bestaan uit:

(18)

Figure 3.1: Verschillende componenten van het online proctoring onderzoek

2. Middels feedback op het ontwikkelde interface het product verbeteren

3. Evaluatie van het eindresultaat

Methode van Ulrich

Volgens de methode beschreven in Ulrich, 2012 [13] wordt het eerst gesprek met leadusers gevoerd. Aan de hand van dit gesprek ontstaan gebruikerswensen die de product ontwerper omzet naar eisen voor het product. We kiezen voor de methode van Ulrich omdat deze beschrijft hoe eisen van een nog niet bestaand product kunnen worden opgesteld. Daarbij hebben we de volgende stappen gevolgd:

1. Gather Raw Data from Customers

Het verzamelen van raw data van gebruikers kan plaatsvinden op drie verschillende manieren: interviews, focus groups en observing the product in use. Ook bestaat de mogelijkheid een enquˆete af te nemen, wat echter wordt afgeraden omdat enquˆetes minder informatievoorzienend zijn. De leadusers is de optie tot een interview of een enquˆete aangeboden, die beiden dezelfde structuur kennen.

2. Interpret Raw Data in Terms of Customer Needs

Op basis van raw data die hieruit volgt kunnen eisen aan het product worden opgesteld. Een probleem hierbij is dat verschillende product ontwerpers de raw data op verschillende manieren kunnen interpreteren. Daarom is het belangrijk dat er zich meerdere ervaren product ontwerpers buigen over het omzetten van de raw data tot eisen.

3. Organize the Needs into a Hierarchy

De verschillende eisen moeten worden gecategoriseerd op basis van een hi¨erarchie. Eis Y kan onderdeel worden van eis X omdat ze betrekking hebben op elkaar en eis Y kan worden afgeleid uit eis X.

4. Establish the relative importance of the needs

De eisen moeten genummerd worden op relevantie. Deze relevantie kan bepaald worden door de product ontwerpers of de product eigenaar. Omdat ook hier sprake is van eigen interpretatie is het gebruikelijk de eisen terug te koppelen aan gebruikers zodat zij de relevantie bepalen.

(19)

Figure 3.2: Dimensie structuur van de WEQ

5. Reflect on the Results and the Process

Tot slot is het belangrijk te reflecteren op het resultaat en het proces, om eventuele toekom-stige processen beter te laten verlopen. Maar ook om de opgedane kennis in kaart te brengen.

Nadat de eisen zijn opgesteld worden deze ge¨ımplementeerd tot een product. Om het opgestelde product te verbeteren wordt nogmaals contact gezocht met de gebruikers om zo de voor- en nadelen hiervan in kaart te brengen.

Think Aloud Protocol

De bruikbaarheid van het ge¨ımplementeerde interface wordt getest volgens het Think Aloud Protocol. De gebruiker wordt onder andere gevraagd door de website te navigeren naar bepaalde omgevingen en daarbij zijn gedachtes over elke omgeving hardop uit te spreken. Op basis van deze uitgesproken gedachte zullen verbeteringen aan de interface worden opgesteld die vervolgens worden ge¨ımplementeerd. We kiezen voor het Think Aloud Protocol omdat het een simpel protocol is dat bruikbare informatie oplevert.

Evaluatie van het eindresultaat

Bij het derde moment wordt nogmaals contact gezocht met dezelfde leadusers, ditmaal via een online enquˆete. Deze online enquˆete wordt opgesteld volgens de WEQ van Elling [8] waarmee de bruikbaarheid van zeven verschillende dimensies wordt gemeten. De volledig WEQ meet negen dimensies 3.2 maar we kiezen ervoor om “search” en “speed” niet in beschouwing te nemen (zie apendix 6.1 voor de aangepaste versie). De WEQ is namelijk gericht op informatievoorzienende websites terwijl de interface voornamelijk een taakgerichte website zal zijn. We denken daarom dat er geen noodzaak is tot de implementatie van een zoek optie. Daarnaast is “speed” nog niet relevant omdat we de bruikbaarheid testen van een interface dat nog niet in gebruik is. Functies die invloed hebben op “speed” zullen nog niet gebruikt worden. De vragen worden beantwoord aan de hand van een vijfpunts-Likertschaal [17].

We kiezen voor deze enquˆete omdat de resultaten uit het bijbehorende onderzoek veelbelovend zijn. Daarnaast bestaat de WEQ uit relatief weinig vragen waardoor hij gebruiksvriendelijker is dan bijvoorbeeld de WAMMI, die uit 60 vragen bestaat. Dit is onder andere belangrijk omdat de we werken met gebruikers die vrijwillig deelnemen.

3.3

Product implementatie

Het proces van het daadwerkelijke ontwerpen en implementeren van de interface bestaat uit twee delen:

(20)

• De front-end • De back-end

De interface wordt web-gebaseerd, oftewel een website. Hiervoor hebben we gekozen omdat webinterfaces toegankelijker zijn dan bijvoorbeeld software applicaties, die gebonden zijn aan besturingssystemen. We focussen in eerste instantie op de front-end van de interface, ook wel de userinterface (UI) genoemd. Om de UI te ondersteunen met onder andere dynamische inhoud wordt er ook onderzoek gedaan naar een ondersteunend back-end.

3.3.1

Front-end

De front-end betreft alles wat grafisch en visueel is aan de webinterface. Hierbij zullen we gebruik maken van een bestaand front-end design framework zodat er gefocust kan worden op de bruikbaarheid van de interface. Het opzetten van een volledige layout is namelijk een traag proces. We maken gebruik van een interface dat ontwikkeld is volgens de Material Design principes framework1. Hiervoor is gekozen omdat Material Design de aantrekkelijkheid van flat design

combineert met de gebruiksvriendelijkheid van het skeuomorphisme.

Aan dit framework zullen we vervolgens meerdere design-elementen toevoegen ter onderste-uning van de informatierepresentatie. Dit doen we door het toevoegen van jQuery2scripts om de

webpagina interactief te maken, middels SASS3 waarin we opmaak van de interface beschrijven

en via Pug4 waarin de structuur van de UI wordt gedefinieerd.

3.3.2

Back-end

In de back-end zullen enkele functionaliteiten beschreven worden ter ondersteuning van de front-end van de interface. Omdat het een webinterface betreft wordt een webserver opgezet middels NginX. NginX verwijst gebruikers van de website door naar de port waarop we een NodeJS webapplicatie draaien. Hoewel NodeJS zelf ook HTTP kan ondersteunen is ervoor gekozen om NginX als reverse webproxy te gebruiken. NginX heeft namelijk een snellere uitvoering bij het weergeven van statische content dan NodeJS [4]. Dit zijn bestanden zoals afbeeldingen, video’s en de stylesheet. NodeJS is aan de andere kant sneller als het gaat om dynamische content zoals bijvoorbeeld gegevens die uit een database worden opgehaald. Door NginX te combineren met NodeJS worden kan geprofiteerd worden van de voordelen van beide applicaties.

Via NodeJS worden er twee verschillende processen gecre¨eerd. Het eerste proces betreft de eerder benoemde webapplicatie, waarop de visuele kant van de interface draait. Via dit proces kan worden gecommuniceerd met een database. Het tweede proces betreft een script dat het videofilter- en het fraude-detectie algoritme aan elkaar koppelt. Een combinatie van database gegevens en deze algoritmes zorgt ervoor dat er daadwerkelijk incidenten worden aangemerkt op basis van de schermvideo. Dit gaat als volgt te werk:

In de database staat een student, als onderdeel van een session, met de daarbij horende schermvideo, in afwachting van het fraude detectie algoritme. Over deze schermvideo worden eerst frames gefilterd waarna het fraude detectie algoritme wordt uitgevoerd. Het resultaat van dit algoritme zal een lijst zijn met framenummers en een daarbij horend percentage dat de fraude gevoeligheid aanduidt. Aan de hand van deze framenummers knippen we de video op in kleinere stukken. Deze kleinere stukken bestaan uit een video’s beginnend vanaf X seconde voordat een incident plaatsvindt tot een Y aantal seconde nadat het incident heeft plaatsgevonden. Hierdoor kan de gebruiker een duidelijk beeld krijgen over het desbetreffende incident.

Over de videobeelden kunnen naast het filteren en fraude detecteren ook andere algoritmes worden uitgevoerd. Middels Optical Character Recognition (OCR) [22] en Natural Language Pro-cessing (NLP) [5] zou kunnen gevolgd worden waar student X zich op moment Y mee bezighoudt. Met behulp van deze informatie kunnen we een tijdlijn cre¨eren.

1Material Admin Free: https://www.bootstrapdash.com/product/material-design-template-free/ 2jQuery: https://jquery.com/

3SASS: https://sass-lang.com/

(21)

Verder biedt de back-end ondersteuning aan de front-end in de vorm van de stylesheet omdat de SASS files gecompileerd moet worden tot een CSS file. Hetzelfde geldt voor de Pug bestanden die door de NodeJS webapplicatie worden omgezet tot HTML bestanden.

(22)
(23)

CHAPTER 4

Resultaat

4.1

Producteisen

Er is in totaal gesproken met een beperkte groep van drie personen, waarvan twee leadusers en ´

e´en productowner. Uit de gesprekken met hen en de product eigenaar zijn de volgende eisen aan het product opgesteld:

• De interface dient eenvoudig te bedienen zijn

– Het moet mogelijk zijn eenvoudig door de schermvideo te navigeren op basis van een tijdlijn

– De informatie moet logisch ingedeeld worden

• De interface dient een optie te hebben voor live online proctoring

– Het moet mogelijk zijn om te kunnen communiceren met de student tijdens het live tentamen

• De interface dient een optie te hebben tot achteraf online proctoring

– De interface dient statistieken van het tijdverbruik van het tentamen weer te geven – De interface dient statistieken van het tijdverbruik van een student per proctor sessie

weer te geven

• De interface dient voor elk fraude geval (incident) de mogelijkheid te bieden aan de ge-bruiker tot het reviewen hiervan.

– Per incident moet aangegeven worden wat de zekerheid is van het fraude detectie algoritme

De producteisen beslaan niet de gehele interface. Uit de gesprekken komt bijvoorbeeld niet naar voren welke informatie precies moet worden weergegeven naast de fraude inciden-ten. Gekozen is om deze details toe te voegen op basis van de interface uit Brouwer, 2018. Hieraan is informatie aan toegevoegd waarvan we denken dat die relevant is, zoals bijvoorbeeld het studentnummer en de vakcodes.

Uit de producteisen zijn de volgende componenten opgesteld:

Session

De interface bestaat uit verschillende sessions, waarbij elke session is gelinkt aan ´e´en digitaal tentamen. Een session beschikt over ´e´en of meerdere studenten en bevat informatie over de deadline en de duur van het tentamen.

(24)

• Achteraf: zodra het fraude detectie algoritme de videobeelden heeft geanalyseerd zullen deze bevindingen gerepresenteerd worden in de achteraf-omgeving. Deze bevindingen moeten per student beoordeelt worden door de gebruikers.

• Live: de live session wordt gebruikt wanneer het tentamen door de studenten op een vast tijdstip moet worden afgenomen. Door gebruik van deze optie ontstaat de mogelijkheid voor de examinatoren om live mee te kijken met de studenten. Wanneer een live session is afgelopen, ontstaat er voor een live session een achteraf-omgeving, waar naderhand alle incidenten bekeken kunnen worden. De live optie valt niet binnen de eerder benoemde base case omdat erbij wordt uitgegaan van een vast tijdstip. De live optie bleek echter een interessante toevoeging waardoor er is gekozen om deze functionaliteit toe te voegen.

Chat

Bij een live session moet de docent de mogelijkheid hebben om te communiceren met de afne-mers van het tentamen, zodat de docent eventuele vragen ter verduidelijking van tentamen kan beantwoorden. Hiervoor is een chat ontwikkeld binnen de live-omgeving.

Tijdlijn

De videobeelden zijn in eerste instantie net zo lang als dat de student aan het tentamen besteed heeft. Om makkelijk te navigeren door een video van enkele uren is een tijdlijn ontwikkeld. Hierop worden verschillende events van de video chronologisch weergegeven. Wanneer geklikt wordt op een event verschijnt de bijbehorende video. Deze events bestaan uit incidenten die worden opgemerkt uit het fraude detectie algoritme en andere gebeurtenissen die kunnen worden door OCR en NLP toe te passen op de videobeelden. Het automatiseren hiervan is echter niet toegepast omdat de gebruikte schermvideo een dermate lage resolutie had.

Statistieken

Omdat vanuit de events informatie over het tentamen van de student beschikbaar zou kunnen zijn is het ook mogelijk te achterhalen hoelang een student spendeert aan een vraag. Omdat deze mogelijkheid bestaat is bij de leadusers gepolst hoe zij hier tegenover staan waaruit bleek dat zij dit een interessante toevoeging vinden. De statistieken kunnen weergegeven worden per session, zodat gemiddeldes naar voren komen, of per student, zodat deze statistieken kunnen worden uitgezet tegenover het gemiddelde. Ook uit de statistieken zou fraude kunnen worden achterhaald wanneer bijvoorbeeld een student een hoog cijfer heeft gehaald maar opvallend snel klaar is.

Uit de combinatie van de producteisen en de functies zijn verschillende omgevingen gemaakt waarvan de volgende drie de belangrijkste zijn:

• Session overview:

In de sesion overview omgeving staat alle informatie met betrekking tot die session. Zoals bijvoorbeeld de studenten die hieraan deelnemen, de session gegevens maar ook de statistieken.

• Review student:

In de review omgeving wordt een student weergegeven uit de bijbehorende sessie. Hierbij zal een tijdlijn weergegeven worden met de daarin events. Door het klikken op events kan genavigeerd worden door de schermvideo. Deze omgeving bevat ook statistieken.

• Live session:

In de live omgeving is per sessie live te zien voor welke studenten incidenten optreden. Ook biedt de live omgeving een chat functie waarbij de studenten met een online surveillant kunnen communiceren.

(25)

Figure 4.1: Overzicht van een session

Naast deze hoofd-omgevingen zijn er enkele andere omgevingen ontwikkeld ter ondersteuning. Bijvoorbeeld voor het aanmaken van een session, het navigeren door verschillende sessions en een login- en registreer omgeving.

4.2

Product design

4.2.1

Front-end

Uit de gesprekken waarin het Think Aloud Protocol werd gevolgd twee bleek dat de leadusers over tevreden waren met versie 1, waardoor het verschil tussen versie 2 en versie 1 miniem is. Er wordt daarom enkel het resultaat van versie 2 weergegeven met hierbij telkens de veranderingen ten opzichte van versie 1.

De Material Design kenmerken komen terug in bijvoorbeeld de sidebar die een schaduw heeft. Deze sidebar kan worden ingeklapt zodat de rest van de pagina meer ruimte kan innemen. Ook hebben de knoppen animaties wanneer ze worden ingedrukt.

Session overview

In de session overview (figuur 4.1) wordt alle data weergegeven die betrekking heeft tot de desbetreffende sessie, zoals statistieken omtrent het gemiddelde tijdverbruik, welke studenten hebben deelgenomen aan deze session en andere data over deze session. Door middel van badges wordt extra belangrijke informatie uitgelicht, zoals de “review status” of het aantal “incidents”. De deelnemers zijn onder aan de pagina te vinden in een tabel die gesorteerd kan worden. Standaard wordt deze tabel gesorteerd op het aantal incidenten zodat de urgentie tot het reviewen hiervan duidelijk is. De “status” van een rij geeft weer of de gebruiker alle bijbehorende incidenten heeft beoordeelt. Totdat alle incidenten van alle studenten zijn beoordeelt zal de status van de session “Uncompleted” weergeven.

De jQuery effecten zijn terug te vinden in de functionaliteit van de tabel1en de tabs

waaron-der verschillende statistieken staan.

(26)

Figure 4.2: Review omgeving voor een student van een session

Verschil met versie 1

In de session overview worden aan de rechterkant de statistieken gerepresenteerd. Uit de gesprekken bij het tweede moment bleek echter voor een enkele leaduser het niet duidelijk dat er binnen de interface geen optie was tot het beoordelen van de antwoorden op de vragen. Dit lijkt te wijten aan het feit dat de statistieken in versie 1 ook betrekking hadden op het aantal behaalde punten per vraag. In versie 2 is er daarom voor gekozen een duidelijk scheiding hiertussen te maken door alle informatie die betrekking is op het cijfer van de student te verwijderen.

Student review

In de student review omgeving (figuur 4.2) kunnen de daadwerkelijke incidenten beoordeelt worden. Door de tijdlijn kan middels jQuery genavigeerd worden door de video. Het geselecteerde event op de timeline correspondeert met de video die aan de linkerkant wordt weergegeven. Incidenten worden op de tijdlijn weergegeven door middel van een badge, anders dan de normale events. Wanneer een incident geselecteerd is verschijnt de grijze box aan de onderkant van de tijdlijn. In deze grijze box kan het incident beoordeelt worden en kan er een verklaring hiervoor worden bijgevoegd. Rechtsboven is de optie tot het filteren van de events toegevoegd via jQuery. Tot slot is onder aan de pagina data te vinden over de student en statistieken omtrent het tijdverbruik.

De videospeler biedt de optie tot het afspelen van de video in fullscreen zodat er beter gekeken kan worden naar het event. Daarnaast kan de video ook versneld of vertraagd afgespeeld worden.

(27)

Figure 4.3: Live session omgeving

Verschil met versie 1

De informatiedichtheid op de tijdlijn bleek te hoog te zijn. Daarom is de optie tot het filteren van de events op de tijdlijn ontwikkeld, wat in versie 1 dus nog niet mogelijk was. Door de toevoeging hiervan is het mogelijk om slechts de incidenten weer te geven op de tijdlijn waardoor er eenvoudiger genavigeerd kan worden.

Ook bleek uit de het tweede moment van gesprekken dat de optie tot het verklaren van de beoordeling miste. Daarom is de “description” toegevoegd.

Live session

In de live session (figuur 4.3) is gekozen voor een soortgelijke structuur als de tijdlijn van de session overview. Aan de rechterkant zijn de events te zien, met daarin chatberichten en de berichten die het systeem meld zoals “connection with student X is lost”. Linksboven bevinden zich de videobeelden van studenten die het tentamen afnemen. Over deze beelden moet in real-time een algoritme uitgevoerd worden. Daarom is ervoor gekozen om links enkel de studenten weer te geven waarbij het algoritme fraude detecteert. De surveillant kan dan ingrijpen door middel van een chatbericht. Bovenaan de events wordt weergegeven hoeveel studenten er deelnemen aan het tentamen en hoeveel tijd er resteert.

Verschil met versie 1

In versie 1 bestond de optie tot het filteren van de events nog niet. Dit is toegevoegd nadat bleek dat de tijdlijn van de session overview te veel informatie bevatte. Een logische stap was daarom om de events in de live omgeving ook te filteren aangezien de informatiedichtheid zal toenemen naarmate de tijd vordert.

Andere omgevingen

Naast deze hoofd-omgevingen zijn nog een aantal andere omgevingen ontwikkeld ter onders-teuning van de interface, zoals het overzicht van alle sessions in figuur 4.4. In versie 2 zijn “uncompleted sessions” en “completed sessions” in ´e´en box weergegeven. Uit de feedback op versie 1 kwam namelijk naar voren dat het verschil tussen een “uncompleted”- en “upcoming sessions” niet duidelijk was. Ook is in versie 2 de knop “create a new session” toegevoegd aan “upcoming sessions” omdat hiernaar behoefte bleek te zijn.

De loginpagina (figuur 4.5) biedt de mogelijkheid de gebruikers in te loggen tot hun account. Zonder inloggen is het niet mogelijk de rest van de interface te bekijken. Ook biedt de loginpagina een registratiefunctie.

(28)

Figure 4.4: Overzicht van alle proctoring sessies

(29)

4.2.2

Back-end

UI web applicatie

Door het gebruik van Pug en SASS is de structuur van de webpagina overzichtelijk een gemakke-lijk aan te passen. We gebruiken een NodeJS web applicatie genaamd Express, die bepaalde GET- en POST-requests afhandelt. De UI web applicatie is op het internet geplaatst via een domeinnaam en een gehuurde server, zodat de leadusers op afstand om feedback gevraagd kan worden. Op de gehuurde server is NginX ge¨ınstalleerd die de domeinnaam doorverwijst naar het poort nummer (8080) waarop de UI web applicatie draait. We maken gebruik van een NodeJS process manager (PM2) die ervoor zorgt dat de web applicatie automatisch zal blijven draaien. Hierdoor kunnen we tegelijkertijd andere NodeJS applicaties draaien omdat we applicaties niet hoeven af te sluiten voordat we een andere kunnen opstarten.

Fraude detectie applicatie

De fraude detectie applicatie is een NodeJS proces waarbij twee verschillende pythonscripts wor-den aangeroepen. De verschillende pythonscripts bestaan uit respectievelijk het filter van de video en het daadwerkelijke detecteren van de fraude hieruit. In deze applicatie kunnen de algo-ritmes met elkaar communiceren. Op basis van de output van het filter-algoritme wordt namelijk het fraude-detectie algoritme aangeroepen. Als resultaat van het fraude-detectie algoritme krij-gen we per frame twee percentages die aangeven hoe groot de kans is dat het frame bij de klasse “geen fraude” of de klasse “wel fraude” hoort. De taak is aan de applicatie om vervolgens via een bepaalde drempelwaarde te bepalen wanneer we van een relevant incident spreken.

Over de schermvideo kon geen OCR worden toegepast omdat de resolutie te laag blijkt. Hierdoor konden we ook geen NLP gebruiken. Omdat het filter-algoritme filtert op basis van verandering van de scene kan de tijdlijn wel worden ingedeeld op de verschillende scenes, alleen is het niet mogelijk via een algoritme te zeggen wat de student precies doet in deze scene.

4.3

Evaluatie van het eindresultaat

De WEQ is ingevuld door respondenten in de vorm van de eerder gesproken leadusers. Aan de hand van de antwoorden hierop is de kwaliteit van de zeven dimensies in kaart gebracht:

1. Relevantie: de relevantie van de interface bleek goed te zijn. De relevantie slaat hier op onder andere de statistieken en andere toegevoegde informatie zoals de studentnummers of de vakcodes.

2. Comprehensibility: uit de antwoorden op de vragen van deze dimensie wordt aangetoond dat ook de taal en informatie begrijpelijk zijn en een ruime voldoende scoren.

3. Comprehensiveness: uit de antwoorden op de comprehensiveness vragen bleek dat de in-terface op dit vlak niet helemaal voldoet. Er blijkt dat bepaalde informatie mist in de interface.

4. User friendliness: op gebruiksvriendelijkheid scoort de interface een voldoende.

5. Structure: ook de structuur van de interface bleek voldoende hoewel er wordt aangegeven dat het niet altijd duidelijk is in welke omgeving de gebruiker zich precies bevindt.

6. Hyperlinks: de link teksten blijken ook representatief te zijn voor de omgeving waar ze naartoe verwijzen.

7. Layout: op het gebied van design scoort de interface goed. De gebruikers geven aan de layout aantrekkelijk te vinden.

Omdat het hierbij een enquˆete betreft en geen dialoog kan er niet concreet worden aangegeven door de gebruikers waarom sommige dimensies lager scoren. Doordat het dankzij de enquˆete nu duidelijk is welke dimensies goed scoren kunnen eventuele vervolggesprekken gestuurd worden

(30)

zodat de problemen uit lager beoordeelde dimensies worden toegelicht. Hierdoor zouden de vervolg gesprekken gestructureerd kunnen plaatsvinden waardoor de verbeterpunten effici¨enter benoemd kunnen worden. Er zou in een vervolggesprek dan niet worden gefocust op bijvoorbeeld de Layout maar op de Comprehensibility of de Structure.

(31)

CHAPTER 5

Conclusie en Discussie

Er is onderzoek gedaan naar een interface voor automatische online proctoring. Aan de hand van literatuur zijn gesprekken met gebruikers georganiseerd. Op basis van gesprekken met de product eigenaar en de eerste gesprekken met leadusers zijn vervolgens productwensen opgesteld. Deze zijn omgezet tot een functionerende interface. Hierbij is veel gebruik gemaakt van eigen interpretatie.

Deze interpretatie bleek goed te zijn want uit de tweede gesprekken met leadusers bleek dat zij tevreden waren met versie 1. Er bleken echter nog verbeteringen mogelijk te zijn die vervolgens in versie 2 naar voren komen.

Over versie 2 is uiteindelijk feedback gevraagd in de vorm van een aangepaste WEQ. Hieruit bleek dat de interface voldoende scoort maar dat er verbeterpunten zijn omtrent de Comprehen-siveness en de Structure.

5.1

Antwoord op onderzoeksvragen

De vraag hoe een bruikbaar interface ontwikkeld kan worden voor een geautomatiseerde online proctoring is beantwoord aan de hand van verschillen deelvragen.

Welke producteisen moet een interface voor geautomatiseerde online proctoring hebben?

We hebben als eerst producteisen opgesteld aan van een methode uit de literatuur. We hebben hierbij gesproken met leadusers die gebruikerswensen hadden. Deze zijn omgezet tot een interface waarin deze worden verwerkt. Omdat deze wensen niet het volledig interface beslaan zijn er veel dingen toegevoegd op basis van ervaring vanuit de product ontwerper.

Hoe kan door middel van feedback op een interface de kwaliteit verbeterd worden?

Aan de hand van de ge¨ımplementeerde interface hebben we dezelfde leadusers gevraagd hun gedachte hardop uit te spreken bij het uitvoeren van bepaalde taken bij de interface. Hieruit bleek dat er enkele functionaliteiten misten en de structuur verbeterd kon worden.

Wat is de kwaliteit van het verbeterde interface volgens potenti¨le gebruikers?

Op basis van een aangepaste WEQ [8] is getoetst wat de kwaliteit van de interface was binnen zeven verschillende dimensies. Hieruit bleek dat de interface een gemiddeld een voldoende scoort maar dat er ruimte is voor verbetering binnen de Comprehensiveness en de Structure van de interface.

Door het gebruik van verschillende methodes is de interface gemaakt waarna de kwaliteit en bruikbaarheid van de interface in kaart zijn gebracht. Hoewel door het volgen van deze methodes er veel informatie over de interface is verzameld dient deze data ge¨ınterpreteerd te worden door de ontwerper. Daarnaast dient de ontwerper dingen toe te voegen die relevant zijn voor het product op basis van eigen ervaring.

(32)

5.2

Voorgestelde experimenten

5.2.1

Interface toepassen op andere data

De videobeelden die we in dit onderzoek hebben gebruikt zijn schermvideo’s van twee personen die twee verschillende tentamens afleggen. Deze vier schermvideo’s zijn gebruikt om de interface mee te voorzien van (test)data. Via een experiment kunnen we aantonen dat de interface ook werkt voor andere schermvideo’s. Deze nieuwe schermvideo’s zullen worden gemaakt aan de hand van het opnemen van meerdere kandidaten terwijl zij een digitaal tentamen afnemen volgens een bepaald script. Hierdoor kunnen we de gebeurtenissen eenvoudig annoteren. Daarna kunnen we via de NodeJS applicatie - die de pythonscripts over de video’s runt - kijken of de interface ook voldoet bij nieuwe data. Hiermee testen we de werking van het filter algoritme, het fraude detectie algoritme en functie van het de interface hierbij.

5.2.2

Incident defini¨

eren

Het fraude detectie algoritme geeft resultaat terug in de vorm van een frame nummer met daar-bij twee percentages. De percentages slaan op de zekerheid waarmee gezegd kan worden of het framenummer bij de klasse ”geen fraude” en “wel fraude” hoort. Omdat deze percentages niet van elkaar afhankelijk zijn kan er worden ge¨experimenteerd naar bij welke percentages we iets beschouwen als een fraude gevoelig moment. Bij dit experiment zoeken we de juiste drempel-waarde waaraan beiden klassen moeten voldoen om ze te bestempelen als incident.

5.3

Discussie

5.3.1

Vervolgonderzoek

De testvideos die we hebben gebruikt bij dit odnerzoek betroffen het .mkv formaat. Het prob-leem bij dit formaat is dat het niet door HTML wordt ondersteund. Omdat de interface een webapplicatie is zouden de videobeelden van een formaat moeten zijn dat ondersteund wordt in HTML, zoals .mp4.

Hiernaast ontbreken enkele functies die onderdeel van de interface zijn maar vooralnsog niet zijn ontwikkeld. Zoals een applicatie waarmee de student zijn videobeelden verstuurt naar de interface. Hierin zouden we moeten zorgen dat de videobeelden van een formaat zijn dat door HTML wordt ondersteunt.

Bij dit onderzoek is alleen gebruik gemaakt van de schermvideo waardoor het aantal fraude manieren dat gedetecteerd kan worden beperkt is. Door het toevoegen van twee andere hardware componenten in de vorm van een webcam en een camera op afstand kan er in de toekomst meer audiovisuele data worden verzameld waaruit meerdere manieren van fraude kunnen worden gedetecteerd.

Daarnaast ontbreekt het proces dat moet plaatsvinden wanneer de gebruiker een incident als fraude markeert. Er zou bijvoorbeeld automatisch een rapport kunnen worden opgemaakt dat naar de examencommissie wordt verstuurd.

5.3.2

Problemen

Tijdens het onderzoek bleek de groep leadusers kleiner dan verwacht. Het aantal leadusers dat bereid was mee te werken aan het onderzoek bleek echter nog lager. In een vervolgonderzoek zou met meer leadusers gesproken moeten worden om zo uiteindelijk een grotere groep tevreden kunnen te stellen. Opvallend was dat uit de gesprekken met leadusers functionaliteiten naar voren kwamen waar in eerste instantie niet bij was stil gestaan, zoals de chatfunctie in de live-omgeving.

(33)

Bibliography

[1] Yousef Atoum et al. “Automated online exam proctoring”. In: IEEE Transactions on Mul-timedia 19.7 (2017), pp. 1609–1624.

[2] Kyle Banker. MongoDB in action. Manning Publications Co., 2011.

[3] Manuele Bicego et al. “On the use of SIFT features for face authentication”. In: Computer Vision and Pattern Recognition Workshop, 2006. CVPRW’06. Conference on. IEEE. 2006, pp. 35–35.

[4] Ioannis K Chaniotis, Kyriakos-Ioannis D Kyriakou, and Nikolaos D Tselikas. “Is Node. js a viable option for building modern web applications? A performance evaluation study”. In: Computing 97.10 (2015), pp. 1023–1044.

[5] Gobinda G Chowdhury. “Natural language processing”. In: Annual review of information science and technology 37.1 (2003), pp. 51–89.

[6] Navneet Dalal, Bill Triggs, and Cordelia Schmid. “Human detection using oriented his-tograms of flow and appearance”. In: European conference on computer vision. Springer. 2006, pp. 428–441.

[7] Andrew T Duchowski. “Eye tracking methodology”. In: Theory and practice 328 (2007). [8] Sanne Elling, Leo Lentz, and Menno De Jong. “Website evaluation questionnaire:

devel-opment of a research-based tool for evaluating informational websites”. In: International Conference on Electronic Government. Springer. 2007, pp. 293–304.

[9] Stefaan Van Gerven and Fei Xie. “A comparative study of speech detection methods”. In: Fifth European Conference on Speech Communication and Technology. 1997.

[10] Cornelia Gy˝or¨odi et al. “A comparative study: MongoDB vs. MySQL”. In: Engineering of Modern Electric Systems (EMES), 2015 13th International Conference on. IEEE. 2015, pp. 1–6.

[11] Starr Roxanne Hiltz and Murray Turoff. “Education goes digital: The evolution of online learning and the revolution in higher education”. In: Communications of the ACM 48.10 (2005), pp. 59–64.

[12] Monique WM Jaspers et al. “The think aloud method: a guide to user interface design”. In: International journal of medical informatics 73.11-12 (2004), pp. 781–795.

[13] Steven D. Eppinger Karl T. Ulrich. Product Design and Development. McGraw Hill, 2012. [14] Jurek Kirakowski, Nigel Claridge, and Richard Whitehand. “Human centered measures of success in web site design”. In: Proceedings of the Fourth Conference on Human Factors & the Web. 1998.

[15] Clayton Lewis and John Rieman. “Task-centered user interface design”. In: A Practical Introduction (1993).

[16] Xuanchong Li et al. “Massive open online proctor: Protecting the credibility of MOOCs certificates”. In: Proceedings of the 18th ACM conference on computer supported cooperative work & social computing. ACM. 2015, pp. 1129–1137.

[17] Rensis Likert. “A technique for the measurement of attitudes.” In: Archives of psychology (1932).

(34)

[18] Steve Muylle, Rudy Moenaert, and Marc Despontin. “The conceptualization and empiri-cal validation of web site user satisfaction”. In: Information & management 41.5 (2004), pp. 543–560.

[19] Jakob Nielsen and Hoa Loranger. Prioritizing web usability. Pearson Education, 2006. [20] David Oswald and Steffen Kolb. “Flat Design vs. Skeuomorphism–Effects on Learnability

and Image Attributions in Digital Product Interfaces”. In: DS 78: Proceedings of the 16th International conference on Engineering and Product Design Education (E&PDE14), De-sign Education and Human Technology Relations, University of Twente, The Netherlands, 04-05.09. 2014. 2014.

[21] Tom Page. “Skeuomorphism or flat design: future directions in mobile device User Interface (UI) design education”. In: International Journal of Mobile Learning and Organisation 8.2 (2014), pp. 130–142.

[22] Chirag Patel, Atul Patel, and Dharmendra Patel. “Optical character recognition by open source OCR tool tesseract: A case study”. In: International Journal of Computer Applica-tions 55.10 (2012).

[23] Marc Prensky. “Digital natives, digital immigrants part 1”. In: On the horizon 9.5 (2001), pp. 1–6.

[24] Will Reese. “Nginx: the high-performance web server and reverse proxy”. In: Linux Journal 2008.173 (2008), p. 2.

[25] Lex Sietses. “White Paper Online Proctoring: Questions and answers about remote proc-toring”. In: (2018).

[26] Stefan Tilkov and Steve Vinoski. “Node. js: Using JavaScript to build high-performance network programs”. In: IEEE Internet Computing 14.6 (2010), pp. 80–83.

[27] Jochen Wulf et al. “Massive open online courses”. In: Business & Information Systems Engineering 6.2 (2014), pp. 111–114.

(35)

CHAPTER 6

Apendix

6.1

Aangepaste WEQ van Elling

• Relevance

– The information in this website is of little use to me. – This website offers information that I find useful.

• Comprehensibility

– The language used in this website is easy to me.

– I find the information in this website easy to understand. – I find many words in this website difficult to understand.

• Comprehensiveness

– Certain information I was looking for was missing in this website. – The website provides me with sufficient information.

– I find the information in this website precise.

• User friendliness

– I find this website easy to use. – I consider this website user friendly

• Structure

– I know where to find the information I need on this website. – I always know where I am on this website.

– I find the structure of this website clear.

– The convenient set-up of the website helps me find the information I am looking for.

• Hyperlinks

– It is clear which hyperlink will lead to the information I am looking for. – Under the hyperlinks, I found the information I expected to find there.

• Layout

– I think this website looks unattractive – I like the way this website looks.

Referenties

Outline

GERELATEERDE DOCUMENTEN

 U moet motiveren en vastleggen waarom online proctoring voor bepaalde toetsen en tentamens noodzakelijk is..

That you’d descend from heaven and you would go through such great lengths That you would give the greatest gift to me: I’m free.. I live cause God send His

Leg uit hoe de relatieve atoommassa een decimaal getal (getal met cijfers achter de komma) kan zijn terwijl alle ijzer atomen bestaan uit deeltjes van exact 1u.. IJzer kan

• Binding is een kracht tussen twee dingen waardoor ze bij elkaar blijven.. • Atoombinding houdt twee atomen bij

• Twee plaatsen waar reacties plaats vinden (elektroden). • Een reactie die elektronen

• Tip: Maak voor jezelf een schets die je zelf herkent.. • Daniel’s cel, (flow)batterij, brandstofcel, … allemaal

• Met de verhouding van de aantallen kan geen uitspraak gedaan worden over de kansen. • Er kan wel een uitspraak gedaan worden over de verhouding van

– Maak opgaven uit het boekje (naar eigen inzicht) – Speel met de simulaties. – Maak