Utvärdering och förslag för a

Transkript

1 Linköpings universitet Institutionen för datavetenskap Examensarbete på grundnivå, 16hp Datateknik LIU-IDA/LITH-EX-G--2018/002--SE Utvärdering och förslag för a skapa e effek vare administra- onsverktyg i AES Evalua on and sugges ons for crea ng a more effec ve and efficient management tool in AES Johan Frimodig Handledare : Erik Nilsson Examinator : Torbjörn Jonsson Linköpings universitet SE Linköping ,

2 Upphovsrä De a dokument hålls llgängligt på Internet eller dess fram da ersä are under 25 år från publiceringsdatum under förutsä ning a inga extraordinära omständigheter uppstår. Tillgång ll dokumentet innebär llstånd för var och en a läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och a använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrä en vid en senare dpunkt kan inte upphäva de a llstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För a garantera äktheten, säkerheten och llgängligheten finns lösningar av teknisk och administra v art. Upphovsmannens ideella rä innefa ar rä a bli nämnd som upphovsman i den omfa ning som god sed kräver vid användning av dokumentet på ovan beskrivna sä samt skydd mot a dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens li erära eller konstnärliga anseende eller egenart. För y erligare informa on om Linköping University Electronic Press se förlagets hemsida h p:// Copyright The publishers will keep this document online on the Internet or its possible replacement for a period of 25 years star ng from the date of publica on barring excep onal circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educa onal purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are condi onal upon the consent of the copyright owner. The publisher has taken technical and administra ve measures to assure authen city, security and accessibility. According to intellectual property law the author has the right to be men oned when his/her work is accessed as described above and to be protected against infringement. For addi onal informa on about the Linköping University Electronic Press and its procedures for publica on and for assurance of document integrity, please refer to its www home page: h p:// Johan Frimodig

3 Sammanfattning Detta arbete har som syfte att visa vad administrationsverktyget i Authentic Examination System kan förbättra för att uppnå högre effektivitet. För att hitta vad som kan förbättras utifrån effektivitet har metoden Think aloud använts tillsammans med mätvärden som ofta används för att mäta effektivitet. En prototyp har också utvecklats där hänsyn har tagits till de delar som hittats under analysen av administrationsverktyget. Prototypen och administrationsverktyget har sedan jämförts för att se hur de potentiella förbättringar som implementerats i prototypen påverkat effektiviteten. Slutligen sammanställs ett resultat som pekar på vad som kan effektiviseras i administrationsverktyget.

4 Författarens tack Detta arbete har tagit sin tid att utföra och det hade inte varit möjligt utan det stöd jag fått från så många att alla inte kan nämnas vid namn. Jag vill rikta speciellt stort tack till min examinator Torbjörn Jonsson och handledare Erik Nilsson för att de visat stort tålamod och alltid ställt upp när jag behövt hjälp. Jag vill också tacka de testpersoner som ställt upp och hjälpt till att göra detta arbete möjligt. iv

5 Innehåll Sammanfattning Författarens tack Innehåll Figurer Tabeller iii iv v vi vii 1 Introduktion Motivation Mål Frågeställning Begränsningar Teori Användbarhet Användargränssnittsdesign Att utvärdera användbarhet Användargränssnittsmetrik Metod 9 4 Resultat Utvärdering administrationsverktyg i AES Utveckla prototyp av administrationsverktyg Jämförelse mellan verktyg Diskussion Resultat Metod Arbetet i ett större sammanhang Slutsats 23 Litteraturförteckning 24 v

6 Figurer 3.1 Illustration kopplade sessioner Klarat per scenario Tid per scenario Gamla och nya systemstrukturen Klarad uppgift Tid per session vi

7 Tabeller 4.1 Vilsenhetvärde per scenario Vilsenhet, scenario Vilsenhet, scenario vii

8 1 Introduktion 1.1 Motivation En rapport som beskriver arbetstidsfördelningen på svenska universitet och högskolor 2011 [13] visar att ca 30% av arbetstiden för en anställd inte används till de två huvudsysslor som de är anställda för, det vill säga undervisning och/eller forskning. Inom dessa 30% visas att 11% används till administration som ej har med undervisning eller forskning att göra. För att hålla en god standard inom högskolor och universitet i Sverige är det viktigt att de anställda har möjlighet att utföra det arbete de är anställda för att uträtta. På Linköpings universitet har ett tentamensystem utvecklats för att låta studenter skriva programmeringstentamina i sin rätta miljö vid datorn och inte på papper. System har utvecklats under ledning av Adjunkten Torbjörn Jonsson som har en vision att förbättra både studenters och examinatorers arbete under och efter examinationen [7]. Flera olika faktorer bidrog till att ett digitalt tentamensystem skapades. Många kurser tog emot fler studenter än vanligtvis vilket ledde till långa rättningstider och därmed längre väntetid på resultatet från en examination. Det ökade även examinatorernas arbetsbelastning när det handlade om rättning efter en examination. Att examinera programmering på papper sätter studenter i en situation där de flyttas från den miljö (dator) där de lärt sig programmera och tvingas bekanta sig med en ny miljö under examinationen. Även fast de ska utföra samma uppgift, kan den nya miljön bidra till en orättvis och svår bedömning av studenten. Utifrån de här anledningarna skapades Authentic Examination System (AES). AES ger även studenter möjlighet att ställa frågor direkt till examinatorn via datorn istället för att examinatorn ska spendera tid på att gå runt i salen. Att ställa frågor via datorn gjorde det även möjligt för studenter att fråga frågor under hela examinationen istället för vid en specifik tid. AES tillåter så kallad live-rättning vilket innebär att tentander får skicka in färdiga uppgifter och få dem kommenterade och rättade under pågående tentamen. Det gör att fokus kan flyttas från att enbart handla om syntax eller teoretiska frågor till problemlösning med hjälp av programmering. 1

9 1.2. Mål AES har varit i drift sedan 1995 och har totalt examinerat över studenter, varav studenter är examinerade med nuvarande version 3. AES har fått allt mer uppmärksamhet under de senaste åren, då digitalisering blivit mer och mer påtaglig. I en bestämmelse från universitetsledningen [18] har Linköpings universitet beslutat att 25% av tentamina ska vara digitala 2017 och att 50% ska vara digitala Beslutet har tillsammans med den allmänna viljan att digitalisera arbetsuppgifter ökat belastningen för systemet. Systemet tar allt mer tid att administrera vilket gör att tid som borde användas för undervisning och forskning istället behövs till administration. På grund av att belastningen ökat på tentamensystemet och att de som sköter systemet måste lägga ner mer tid för att administrera, önskas en utvärdering av administrationsverktyget i AES som används vid uppsättning av en tentamen. Med uppsättning av tentamen menas de inställningar och konfigurationer som behövs utföras för att en starta en tentamen. Syftet med detta arbete är att utvärdera administrationsverktyget i AES genom att skapa en prototyp med likvärdig funktionalitet. Prototypen och administrationsverktyget utvärderas sedan mot varandra utifrån ett effektivitets perspektiv. 1.2 Mål Målet med detta arbete är att visa på förbättringar som kan göras i designen av administrationsverktyget så att effektiviteten hos användaren ökar utan att korrektheten minskar. 1.3 Frågeställning 1. Hur kan administrationsverktyget i AES förbättras för att uppnå en högre grad av effektivitet för användarna? 2. Hur förhåller sig den nya prototypen av administrationsverktyget till det som används i AES vad det gäller effektivitet för användarna? Med effektivitet menas kategorierna efficency och effectiveness som ingår i standarderna ISO/IEC 25010:2011. Där effectiveness beskrivs som: noggrannhet och fullständighet som en användare kan uppfylla ett specifikt mål. Efficency beskrivs som: resurser spenderade i relation till noggrannhet och fullständighet som en användare kan uppfylla ett specifikt mål. 1.4 Begränsningar Prototypen testas/valideras inte i vanlig mening, utan endast i förhållande till det nuvarande administrationsverktyget. Prototypen innehåller enbart funktionalitet som täcker de scenarion som har skapats. Enbart det grafiska utseendet ska fungera i prototypen all bakomliggande funktionalitet är ej i fokus. Utvärdering och tester under utveckling av prototypen ingår inte i arbetets tidsramar och är därför ej utfört. 2

10 2 Teori För att skapa förståelse och visa på de delar som är av extra vikt vad det gäller detta arbete kan teorin delas upp i fyra olika delar. Tillsammans ger dessa delar stöd åt utförandet av metoden. Det första som beskrivs är Användbarhet i ett mer generellt perspektiv, vad det handlar om och vad det innebär. Därefter beskrivs Användbarhetsdesign, här beskrivs hur ett användargränssnitt bör se ut enligt litteraturen och vilka tillvägagångsätt som kan användas för att utveckla ett gränssnitt mot användbarhet. För att ha möjlighet att jämföra och undersöka om ett system är användbart sker en utvärdering av systemet. Sektionen Utvärdera användbarhet beskriver hur användbarhet kan utvärderas, vilka metoder som kan användas och varför de är bra att använda. Sektionen Användargränssnittsmetrik beskriver vilka mått som är intressanta och kan användas för att skapa data utifrån användbarhetstester. Utifrån den data som samlats in kan jämförelser och slutsatser dras kring hur utvärderingar på olika system vägs mot varandra. Teorikapitlet beskriver stegvis vad användbarhet är, hur det uppnås, utvärderas, verifieras och jämförs. 2.1 Användbarhet Användbarhet är nödvändigt för att ett program ska vara konkurrenskraftigt och användbart under en längre tid [10]. Samlingsnamnet användbarhet används för att beskriva de olika kvalitéer som ett användargränssnitt behöver ta hänsyn till för att göra verktyget attraktivt för användarna. Det finns många olika standarder som används för att beskriva användbarhet [3]. Användbarhet gäller inte enbart interaktionen med datorprogram utan beskriver i ett bredare perspektiv hur en person upplever att använda en artefakt som kan uppnå det som användaren försöker uppnå. En artefakt eller mer specifikt en designartefakt är något som en människa skapat för att utföra ett specifikt syfte. Följande standarder försöker definiera vad användbarhet innebär och betyder. 1. ISO 25010:2011 Degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use Hur en produkt eller ett system kan används för att användare ska uppnå fastställda mål inom effektivitet, produktivitet och nöjdhet inom en specifik kontext. 3

11 2.2. Användargränssnittsdesign 2. ISO/IEC/IEEE 24765:2010 a) A measure of an executable software unit s or system s functionality, ease of use, and efficiency. Ett mått på ett systems eller programs enkelhet, funktionalitet och effektivitet. b) The ease with which a user can learn to operate, prepare inputs for, and interpret outputs of a system or component. Hur enkelt en användare kan lära sig använda, förbereda indata och tolka utdata för ett system eller komponent. c) The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Den utsträckning en produkt kan användas av specifierade användare för att åstadkomma ett specifikt mål med effektivitet och nöjdhet inom en specifierad kontext. d) Capability of the software product to be understood, learned, used and attractive to the user, when used under specified conditions. Hur en mjukvaruprodukt kan bli tolkad, inlärd, använd och attraktiv för en användare under specifika förhållanden. De standarder som beskrivs ovan använder till stora delar liknande begrepp och försöker definiera det som människan upplever som användbart. En sammanställning av användbarhetsstandarder [2] visar att användbarhet är ett samlingsnamn för olika kategorier som en användare medvetet eller omedvetet bedömer ett visst verktyg utifrån. Dessa kategorier bryter ner användbarhet så det blir mer begripligt vad som kan mätas eller utvärderas när användbarhet ska testas. Följande kategorier anses ingå i användbarhet. Effectiveness Denna kategori beskriver användbarhet utifrån hur effektivt en användare av systemet kan utföra en viss uppgift. Det kan både innebära i tidsenheter och resurser förbrukade. Efficiency Fokuserar också på effektivitet men mer på hur ofta en användare utför korrekta ageranden utifrån en viss uppgift. Satisfaction Nöjdhet, känner användaren sig glad, frustrerad eller något annat när en uppgift utförs. Security Hur upplevs systemet av användaren utifrån ett säkerhetsperspektiv. Learnability Hur snabbt kan en användare känna sig bekväm med systemet och ta till sig de funktioner som ingår i systemet. Varje kategori bidrar till att skapa ett bra användargränssnitt utifrån användbarhet. Då en design skapas måste ofta en användbarhetskategori prioriteras över en annan då de kan säga emot varandra. Därför är det viktigt att förstå vad det är som är viktigast för användarna av systemet. Utgångspunkten i frågeställningen för detta arbete är effektivitet. Det innebär att kategorierna effectiveness och efficiency är de som är i fokus. 2.2 Användargränssnittsdesign Med användargränssnitt menas sådant som en användare av ett system ser, hör eller känner [8]. För att utveckla ett användargränssnitt krävs det inte mycket av en programmerare, 4

12 2.2. Användargränssnittsdesign men för att utveckla ett bra användargränssnitt krävs tester med användare och kunskap inom psykologi, ergonomi eller andra kunskapsområden kring hur människor interagerar med system eller artefakt. Majoriteten av människor idag har någon gång kommit i kontakt med ett användargränssnitt. Det har gjort att många kan identifiera och återanvända element som ofta används i användargränssnitt [19]. Dessa element förutsätts fungera på ett visst sätt och därför känner sig användare bekväma med att använda dem. En uppdelning kan utföras utifrån syftet med elementen. Inmatningskontroll Denna kategori innefattar sådant som en användare kan interagera med för att utföra en funktion eller tillföra information till systemet. Exempel på element kan vara kryssrutor, listrutor, textrutor eller knappar. Navigationskontroll Navigationskontroller används för sådant som ska hittas eller hjälpa användaren att veta var i systemet användaren befinner sig. Exempel på element kan vara sidokarta, sökruta eller sidnumrering. Informationskontroll Precis som namnet antyder används informationskontroller för att informera användaren om saker som hänt som antingen har initierats av användaren eller som har initierats av systemet. Exempel på sådana typer är ikoner, notifikationer eller meddelanderutor. Behållare Behållare är element som kan innehålla andra element. Användaren har även kontroll över hur mycket av en behållaren som ska visas. Det gör att användaren kan få en bättre överblick och själv välja vad som är relevant att få mer information om. En typisk behållare är en dragspelslista som innefattar visa-och-dölj funktionalitet som användaren kan använda sig av. För att utveckla ett användargränssnitt bör det finnas en klar bild kring vad som ska skapas [20]. Det är viktigt att användbarhet och design tas upp tidigt i utvecklingen för att se till så det gränssnitt som utvecklas kommer tas emot väl av användarna. För att underlätta utvecklingen av ett bra användargränssnitt finns flera utvecklingsmetoder att följa. Tre av de vanligaste metoderna beskrivs nedan. Användarcentrerad design Innebär att användarna av systemet är de som systemet designas för. Användarna har ett stort inflytande under utvecklandet och är med och diskuterad vid olika beslut kring designen. Utvecklingsmetoden innefattar tre steg: designundersökning, designutveckling och designutvärdering. Designundersökningen innefattar att förstå vem användaren av systemet är och vad de behöver. Typiska aktiviteter som används under designundersökning är intervjuer med användare och att följa med och se när liknande system används. I fasen designutveckling används det material som tagits fram under designundersökningen. Det är under denna fas som designen ska visuellt skapas och diskuteras. Designen visualiseras med hjälp av skisser eller olika former av prototyper och diskuteras för att nå fram till det bästa alternativet. Efter designutvecklingen utförs designutvärderingen. Här valideras och verifieras den design som skapats för att se till att de krav som ställts har blivit uppfyllda. Målinriktad design Metoden målinriktad design beskrevs först av Alan Cooper[4]. Syftet med designmetoden 5

13 2.3. Att utvärdera användbarhet är att designen ska fokusera mot det mål som en användare försöker uppnå. Det är viktigt att förstå skillnaden på mål och uppgift. Mål är det som användaren vill ska hända oavsett om hen kan formulera detta eller inte. Uppgifter är det som utförs för att nå målet. Ett exempel på mål är om en familj vill flytta. Familjen kan fokuserar på att snabbt hitta ett hus som är inom deras budget och eventuellt inom ett speciellt område. Familjen kan också fokusera på att hitta ett hus där de kommer trivas och vara lyckliga. Beroende på vilket mål som används kommer programmet som ska utvecklas ha olika fokus. Antingen är fokuset på att snabbt hitta ett hus som är inom budget eller på att hitta ett hus som familjen är nöjd med. Denna metod kräver mycket undersökning kring användare och vad de verkligen vill. Aktivitetcentrerad design Aktivitetcentrerad design och användarcentrerad design utgår från samma princip, skillnaden är att aktivitetscentrerad design sätter själva aktiviteten en användare utför i fokus. Principen fokuserar på att utvecklingen ska utgå från en djup förståelse för aktiviteten som ska utföras [12]. Samma metodsteg som finns i användarcentrerad design används också i aktivitetcentrerad design. Skillnaden är hur designern tänker och lyssnar på användaren. Både användaren och själva aktiviteten vägs in i designen men det är aktiviteten som är den viktigaste delen. Denna designmetod utgår från att användaren inte själv har svaret på en bra design utan det är gränssnittsdesignern som väger in flera alternativ som har sista ordet. 2.3 Att utvärdera användbarhet Testmetoder eller inspektionsmetoder är två av de vanligaste sätten att utvärdera användbarhet hos en designartefakt [6]. En inspektionsmetod är en analytisk utvärdering som appliceras direkt på en designartefakt [14]. Det som gör inspektionsmetoder användbara är att de går att applicera på en designartefakt under utveckling. En testmetod använder sig är testpersoner för att utvärdera och testa ett system. Eftersom testpersoner används krävs det att det som testas är tillräckligt färdigt för att kunna testas. Det som är inte är klart ska inte påverka den del som utvärderas. Därför används ofta testmetoder när en prototyp har blivit färdigställd och en inspektionsmetod under tiden en prototyp utvecklas. Användartester är den vanligaste formen av utvärdering av användargränssnitt [9]. Tester mot användare ger direkt kunskap kring problem med användargränssnitt. Genom att analysera hur användare navigerar och använder ett system kan förbättringar utformas för att effektivisera och göra systemet mer användarvänligt [6]. Utvärdering kan ske som frågeformulär efter användaren har använt systemet eller genom att observera användaren medan systemet används. En testmetod som ofta används och beskrivs som den mest värdefulla testningsmetoden för användbarhetstestning är Thinking aloud (THA) [11]. THA går ut på att ett antal testpersoner får utföra ett eller flera testscenarion på en designartefakten. Testpersonen som utför scenariot ombeds prata högt kring tankar och känslor som dyker upp medan scenariot utförs. Målet är att testpersonen helt själv ska utföra scenariot som är givet utan någon inblandning av utomstående hjälp. Medan testet pågår antecknar testledaren de ord som testpersonen säger och om testpersonen har särskilda problem med någonting. En av de mest citerade förslagen av Thinking aloud föreslogs av Ericsson och Simon s. De beskrev ett sätt att använda en användares verbala kommentarer som data för att utvärdera användbarhet [5]. Metoden bygger på att testpersonen utför ett scenario på det objekt som ska testas. Testpersonen ombeds uttrycka högt vad som utförs, vilka tankar som testpersonen får och vad hen tycker om objektet. Verbal data kan delas in i tre nivåer av tillförlitlighet. När ett THA-test har genomförts utförs en genomgång av all data som samlats. Under genomgången utförs uppdelningen utifrån de tre nivåer som använts. 6

14 2.4. Användargränssnittsmetrik Beskrivningen om hur ett THA-test ska utföras i teorin är något som visat sig inte användas i praktiken. En senare rapport skriven av Boren och Ramey visar att få håller sig till de regler som Ericsson och Simon s föreslog [16]. Boren och Ramey påvisar att det som beskrivs i teorin och det som används i praktiken ej stämmer överens. Ett exempel som tas upp är om ett datorprogram kraschar under ett test måste testledaren ha möjlighet att gå in och hjälpa testpersonen. Det är något som bryter de regler som Ericsson och Simon s beskriver. Ett sådant fall som ovan gäller speciellt när Thinking aloud tester utförs i ett tidigt stadium i utvecklingen då buggar eller stora fel kan uppstå. Enligt Ericsson och Simon s model får en testledare aldrig aktivt ingripa i testet. Boren och Ramey föreslår istället en metod som mer följer den som används i praktiken. En testledare ska ha möjlighet att ingripa och hjälpa en testperson om något oväntat händer med programmet. Det finns dock en risk att testledarens ingripande förhindrar att viktig data kommer med. Därför är det testledarens uppgift att enbart ge tillräckligt med hjälp så att testpersonen kan ta sig vidare själv. Testmetoder och inspektionsmetoder kan användas som summativ eller formativ utvärdering [1]. Beroende på i vilken fas under utvecklingen en designartefakt är måste testledaren välja om en formativ- eller summativstudie ska utföras. Formativ - En formativ studie innebär att data hämtas under pågående utveckling. Meningen med formativa studier är att identifiera möjlighet till förbättringar. Summativ - En summativ studie hanterar enbart den slutgiltiga produkten. Summativa studier används för att verifiera att kriterier uppfyllts. Testansvarige måste bestämma om det ska utföras en summativ eller formativ studie utifrån vad som ska uppnås med utvärderingen. Valet påverkar också vilken typ av test och mätdata som ska inhämtas och analyseras från testerna. 2.4 Användargränssnittsmetrik För att göra användartester jämförbara måste data samlas in för att kunna utföra en analys. Det finns många olika mått som kan användas inom användbarhet [17]. Frågeställningen för detta arbete fokuserar på effektivitet, det är viktigt att veta vad som är målet med testningen så att rätt data samlas och rätt metrik används. Följande punkter beskriver tre olika mätvärden som kan sammanställas för att analysera effektivitet. Tid per uppgift Beskriver ett mått för hur lång tid en uppgift tar att utföra av en testperson. Enheten för tid bestäms utifrån hur lång tid uppgiften uppskattas ta. Klarad uppgift Beskriver om en testperson klarar av att slutföra en uppgift eller inte. Den data som arbetas fram kan vara binär eller definiera olika typer av slutförande såsom korrekt, korrekt med hjälp, testpersonen gav upp eller misslyckades. Vid användning av detta mått bör användare kategoriseras för att tydligare förstå vilka som klarar uppgiften. Kategorier som kunskapsområde, erfarenhet eller ålder är typiska exempel sådant som kan användas. Vilsenhet Måttet vilsenhet utformades för att beräkna om en testperson effektivt kan navigera ett verktyg för att utföra en uppgift [15]. Måttet mäter det kognitiva arbete som en testperson utför när hen navigerar i ett verktyg. Det reflekterar direkt hur mycket en testperson måste tänka för att utföra en uppgift. Måttet mäter de steg en användare tar 7

15 2.4. Användargränssnittsmetrik för att utföra en uppgift mot det beräknat optimala antalet steg som behöver utföras för att klara uppgiften. Formeln för att beräkna slutvärdet är följande: L = (N/S 1) 2 + (R/N 1) 2 N: Antalet vyer som testpersonen har besökt. S: Totala antalet vyer som testpersonen har besökt, även återbesök. R: Det minimala antalet vyer en användare måste besöka för att uppfylla uppgiften. L: Vilsenhet, det bästa värdet som kan uppnås är noll vilket innebär att användaren gjorde alla vägval perfekt. De tre typerna av mått ovan mäter alla olika typer av effektivitet [17]. Tid per uppgift ger ett mått på hur snabbt en användare kan hantera att utföra en uppgift. Klarad uppgift visar på hur bra en användare klarar av att utföra en uppgift. Vilsenhet visar på hur mycket kognitiva resurser en användare behöver utnyttja för att genomföra en uppgift. Med dessa mått kan olika aspekter av effektivitet jämföras och utvärderas. 8

16 3 Metod Systemintroduktion och problematik För att få förståelse över den prototyp som ska testas utförs en genomgång av administrationsverktyget i AES tillsammans med en administratör. En administratör är en person med god kunskap av verktyget och ofta arbetar med detta. Med session menas det specifika tidpunkt då en examination utförs. En examination kan bestå av flera sessioner av olika anledningar. Den oftast förekommande är att platserna i salen är slut och därför måste examinationen innehålla flera sessioner. All funktionalitet som verktyget innehåller visas och förklaras i detalj av administratören. Ett av de mer abstrakta koncepten som används i administrationsverktyget är koppla tentamen. Detta är en funktion som kommit till för att ha flera separata examinationstillfällen för en och samma tentamen. Syftet med funktionen är att se till så studenter inte kan gå på två olika examinationstillfällen för samma tentamen. Funktionen bidrar också till att vissa inställningar kan appliceras direkt på en samman kopplad tentamen. Figur 3.1 visar hur tre tentamen är sammankopplade och således räknas som en tentamen. Figur 3.1: Illustration kopplade sessioner 9

17 Utifrån genomgången av administrationsverktyget skapas användarfall. Varje användarfall inkluderar en inställning eller uppgift som ska utföras. Då administrationsverktyget upplevs som ineffektivt är det viktigt att få fram det som bidrar till att verktyget upplevs ineffektivt. För att hitta potentiella förbättringar av administrationsverktyget genomförs en formativ studie [1]. Då administrationsverktyget existerar och används i en produktionsmiljö är det lämpligt att använda sig av en testmetod för att utvärdera systemet. En testmetod ger direkt återkoppling från användarna medans en inspektionsmetod visar om systemet fungerar som det är tänkt. Den testmetod som används är think aloud detta är för att think aloud kan analyseras mer konkret mot begrepp som ingår i användbarhet. Fokuset för utvärderingen är effektivitet vilket är en del i användbarhet. Ett alternativ som övervägdes var frågeformulär. Problemet med frågeformulär är att det krävs många testpersoner för att kunna dra relevanta slutsatser. Det ger också en mer generell utvärdering där det är svårt att peka på exakt vad som är effektivt och inte. Resultatet av denna undersökning används sedan som underlag för vad som kan förbättras i den prototyp som ska utvecklas, se resultat 4.1. Ett stort problem enligt undersökningen är repetition av uppgifter. För att skapa en tentamensuppsättning där flera olika kurser ska delta krävs lika många uppsättningar av samma tentamen som kurskoder. Finns det dessutom personer som får tillstånd till utökad tid på tentamen måste dessa sättas upp separat utöver de sessioner som redan skapats. Ett annat problem är navigationen och ordningen som uppgifter behöver utföras. Beroende på om en viss inställning utförs innan eller efter en annan hjälper administrationsverktyget mer eller mindre till att automatiskt slutföra inställningen. Om ordningen av inställningar utförs i fel följd kan det i värsta fall göra så att en uppsättning fick göras om från början. Efter utvecklandet av prototypen utförs en summativ studie för att avgöra om de förändringar som genomförts förbättrar effektiviteten för verktyget Den summativa studien baseras på samma test som den formativa studien. I studien ligger extra vikt på jämförelse av måtten Tid per uppgift, Klarad uppgift och Vilsenhet. Skapa tester Tillsammans med en administratör genomförs en genomgång av administrationsverktyget. Utifrån genomgången diskuteras två scenarion fram som ska ge en bred användning av hela verktyget. Nedan beskrivs de två scenarion som skapas. Scenario 1 Beskriver det enklaste sättet att skapa en digital tentamen med administrationsverktyget. Med enklaste menas minsta möjliga inställningar som ska utföras för att ha skapat en digital tentamen. Scenario 2 Beskriver en uppsättning som innehåller fler parametrar än scenario 1. Scenario 2 innehåller problem och specialfall som är återkommande då uppsättning sker med administrationsverktyget. Exempel på detta är förlängd skrivtid för vissa studenter, flera kurser ska skriva samma tentamen eller en tentamen som sträcker sig över flera tentamenstillfällen. Varje scenario beskrivs i löpande text med en sammanfattning av speciell information i form av en punktlista. Tanken med punktlistan är att fungera som en checklista så att det ska bli tydligare vad som ska utföras. Testpersoner väljs utifrån deras kunskapsområde. Totalt 10

18 väljs fem personer, två som har mycket erfarenhet med administrationsverktyget, en med lite erfarenhet och två som aldrig arbetat med administrationsverktyget men förstår kontexten i vilken det används. Förberedelse av administrationsverktyget utförs så att testerna ej ska påverka något som används i daglig verksamhet. För att samla in all data som behövs ska både skärmen och ljud spela in när testpersonerna utför testet. Detta utförs för att enklare analysera data till den formativa studien och så att testansvarige ska ha möjlighet att fokusera på att anteckna det som personen säger och utför. Utförande av tester Innan varje test skapas testmiljön. Testmiljön består av två scenariobeskrivningar för att testpersonen skall veta vad som ska utföras under varje scenario. Varje scenario har en tillhörande textfil med studenter, textfilen representerar den e-post som normalt sätt innehåller alla studenter som ska delta under examinationen. Det verktyg som ska testas startas och navigeras till den gemensamma startpunkten. Ljud- och bildupptagning konfigureras för att vara redo när testet startas. Varje test startas med att testpersonen blir informerad om vad Think aloud-metoden innebär och hur de ska göra under testet. Här är det viktigt att poängtera att det är verktyget som är under utvärdering och inte testpersonen då de inte ska känna att det är jobbigt att misslyckas eller ha jobbigt med att utföra någon uppgift [16]. När testpersonen förstår hur testet ska gå till tilldelas de scenario 1. De får läsa igenom hela scenariot och ställa frågor kring det som de inte förstår innan testet startas. Då scenario 1 är avklarat sparas inspelningarna och scenario 2 tilldelas testpersonen. Därefter repeteras testet för scenario 2. Medan en testperson utför ett scenario finns det en testledare som sitter bredvid. För att testpersonen ska uttrycka så många tankar och åsikter som möjligt påminns hen med jämna mellanrum av testledaren att beskriva åsikter och upplevelser. Testledaren antecknar kommentarer och specifika tillfällen då testpersonen har problem medan testet pågår. Testledaren svarar på eventuella frågor kring uppgiften men vägleder aldrig testpersonen. I fall där tekniska problem uppstår får testpersonen hjälp så att testet kan fortsätta. Den sista uppgiften i testet är att skicka ett e-post via verktyget med alla inställningar. Då den sista uppgiften är utförd stänger testledaren av inspelningen av ljud och bild. Analys av tester Formativ studie - grund för utveckling av gränssnitt För att förstå vad som fungerar bra och vad som inte fungerar bra med administrationsverktyget, används den verbala data som samlas under testsessionerna. Genom att jämföra vad de olika testpersonerna fastnade vid och vad som tog lång tid så bestäms två saker att åtgärda. Navigationen av verktyget är för svår. Det är ofta som upprepningar behövs även om testaren har erfarenhet av administrationsverktyget. Det andra problem är den ordning som olika konfigurationer ska utföras i. De utan erfarenhet genomför inte hela det andra scenariot. De med erfarenhet kan utföra hela eller majoriteten av inställningarna korrekt men behöver gå tillbaka och göra om eller lägga till inställningar. Det som behöver förbättras är följande: Upprepning av arbetsuppgifter Navigering i verktyget Dessa tillsammans med teori inom användargränssnitt används för att utveckla prototypen. Då alla testpersoner har testat båda verktygen används skärminspelningen för att få ut data till den summativa analysen. För att mäta effektivitet har tre olika mått valts ut. Detta görs för att få en bredare analys och se om prototypen verkligen förbättrar effektiviteten eller inte. 11

19 1. Tid per uppgift Varje skärminspelning undersöks och den totala tiden som varje scenario tog sparas för varje testperson. Anledningen till att mindre uppgifter ur scenariot inte används är för att det är svårt att få en jämförelse mellan de två olika användargränssnitten. Då de båda verktygen är olika finns det ingen naturlig start och slutpunkt för varje uppgift. Dessutom utförs olika uppgifter i olika ordning av testpersonerna vilket också bidrar till problem kring när en uppgift startar respektive slutar. Utifrån det resonemanget ska enbart totala tiderna på hela scenariot jämföras. 2. Klarad uppgift För att samla in data för klarad uppgift används skärminspelningen. I detta fallet delas ett scenario in i olika inställningar som ska utföras. Anledningen till detta är för att en jämförelse kan utföras direkt mellan de både verktygen då samma inställningar ska utföras. Varje inställning delas upp i delmål där en inställning kan vara avklarad eller inte. Inställningarna som används är tagna direkt från scenariot, en inställning motsvarar en punkt i scenariot. För att vara säker på att alla resultat är korrekta används den genererade konfigurationen och skärminspelningen för att verifiera inställningarna. 3. Vilsenhet För att beräkna måttet vilsenhet behövs noga övervakning av hur en användare navigerar i verktyget. Med hjälp av skärminspelningen kan varje navigering verifieras och sparas för att få ut den data som krävs. En vy definieras till ett gränssnitt som ger möjlighet att mata in eller se data för användaren, fråntaget att det är en pop-up ruta. Sedan räknas antalet unika vyer, totala antalet vyer (inklusive återbesökta) och minsta antalet vyer som måste visas för att genomföra scenariot. Utifrån den data som formats appliceras formeln för att beräkna Vilsenhet (se Avsnitt 2.4). Utveckling av nytt verktyg Utvecklingen av den alternativa designen som ska utvärderas startade med att skapa digitala bilder som representerar olika vyer. Dessa används som diskussionsunderlag för att bestämma vad som behövs och vad som inte är bra. Detta utförs tillsammans med de som ansvarar för administrationsverktyget. Då själva utvärderingen utförts under den första mer officiella testsessionen fick ingen involverad i själva utvecklingen se prototypen i förväg. Istället fortsatte diskussionen kring koncept och hur olika data är sammankopplat med varandra. Här inkluderas också mycket av det första testfallet där den verbala data som används låg till grund för att försöka åtgärda de problem som upplevs finnas i det första verktyget. Under utvecklingen används litteraturen som stöd för att utforma de olika vyerna och designen. Välkända element som användare kommit i kontakt med förut är en viktig grund för att de enkelt ska känna igen och förstå vad de behöver utföra [19]. Den designmetod som följs är användarcentrerad design. Anledningen till detta är för att det finns en bred förankring kring metoden i litteraturen. Det krävs inte heller lika mycket erfarenhet eller djupgående undersökningar av vad användarna egentligen vill. Användarcentrerad design utgår från att användaren vet vad som är bäst för hen och låter användaren vara mer involverad i designen. Först utförs en designundersökning, intervjuer och diskussioner utförs kring systemet och hur det används. Genomgång av uppsättningen utförs och förklaringar kring koncept och hur olika tentamina fungerar och hänger ihop på Linköpings Universitet. Under designfasen används de anteckningar som skrivits under designundersökningen, resultatet från formativa analysen och den teori som samlats kring design och användargränssnitt utveckling. Utifrån 12

20 detta skapas en prototyp som följer de ramar som tagits fram under designundersökningen. Utvecklingen av prototypen, följer den design som skapas under designundersökningen. Då det finns tekniska problem med designen eller då något ej är fullständigt tydligt utförs nya värderingar och beslut kring designen. För att följa teorin kring användargränssnitt används enbart välbekanta element, inmatning, navigation, information och behållare kontroller. Prototypen följer också den stil som används i administrationverktyget för att behålla likheter mellan de båda verktygen. Detta då det minskar skillnaderna mellan verktyget och framhäver det som faktiskt har förändrats baserat på den återkoppling använts. 13

21 4 Resultat Utifrån den metod som följts genomförs tester på två verktyg. Resultatkapitlet innehåller först en beskrivning kring vilka resultat som framkom utifrån de test som genomfördes på administrationsverktyget. Sedan beskrivs resultatet från skisser och utveckling av prototypen. Därefter jämförs resultatet från testet av administrationsverktyget mot prototypen. 4.1 Utvärdering administrationsverktyg i AES För att utvärdera administrationsverktyget utförs fem testsessioner med metoden Think aloud. De testpersoner som utfört testerna har alla olika erfarenhet som varierar från att ha mycket erfarenhet med det nuvarande verktyget till ingen erfarenhet alls. Utifrån varje testpersons muntliga återkoppling utförs en sammanställning med vad i det nuvarande verktyget som fick kritik av testarna. Sammanställningen utförs genom att jämföra de anteckningar som noterats under testet och sedan leta efter gemensamma ord eller tankar kring verktyget. Utifrån det första scenariot var följande de delar som fått mest kritik av testpersonerna. Navigationen i verktyget Att det inte gick att ångra en inställning Det andra scenariot som innehöll en mer komplicerad uppgift fick följande sammanställd kritik. Bristfällig översikt av inställningar och information Arbetet blev repetitivt Navigationen i verktyget Att det inte gick att ångra en inställning Ett generellt problem som påpekades under scenario 1 och 2 var att vissa inställningar saknade funktioner som att ångra eller ta bort. Det gjorde att en felaktig inställning kunde göra att ett scenario behövde omarbetades då det inte gick att ångra inställningen. Detta påverkar direkt effektiviteten. 14

22 4.1. Utvärdering administrationsverktyg i AES I Figur 4.1 syns hur varje testperson baserat på erfarenhet klarade av varje scenario. Det blir tydligt att erfarenheten spelar en stor roll när ett mer komplext scenario används för att klara av att göra alla inställningar korrekt. Administrationsverktyg 100. Scenario. 1. Scenario. 2 Klarade inställningar (%) Erfaren. Erfaren Använt Oerfaren Oerfaren Figur 4.1: Klarat per scenario Som fig. 4.1 visar så är det stora skillnader på hur många inställningar som genomförs korrekt mellan testpersonerna. Scenario 1 som är det enklast möjliga klarar alla testpersoner av till 100%. Det är i scenario 2 som de utan erfarenhet får stora problem med att genomföra inställningar korrekt. I scenario 2 är upprepning av uppgifter en stor del. De som är helt oerfarna förstod inte var alla inställningar skulle finnas. Scenario 2 är också speciellt då samma inställning behövs utföras på olika ställen i programmet. Det märktes att de oerfarna testpersonerna inte hittade till de olika ställena och till slut gav upp. De med mer erfarenhet har inte det problemet i samma utsträckning då de har kännedom om verktyget. Problemet för de erfarna testpersonerna innefattar att hålla all information om inställningar i huvudet och att inte glömma något. De med erfarenhet har också försprånget att veta om funktionaliteten som innebär att arbete kan undvikas genom att koppla samman sessioner. Detta innebar att ett de med erfarenhet ha vetskap om ett alternativ som tillåter att den inställning som nyligen blivit utförd kan appliceras på de kopplade sessionerna. Även med denna funktionalitet upplevs återupprepning av uppgifter även från de med erfarenhet. Detta beror på att funktionaliteten inte finns för alla inställningar och att det finns problem där vissa inställningar inte utförs i en viss följd. Att navigera i administrationsverktyget är ett problem som testpersonerna har till största del i scenario 2. Utifrån de kommentarer som testpersonerna gav tyckte flera att det var omständligt och inte alltid självklart var i verktyget varje inställning finns. Det visar direkt scenario 2 då det var ett mer komplicerat scenario med fler inställningar och fler förflyttningar mellan vyer. För att vara effektiv i sitt arbete är det en förutsättning att veta var en uppgift kan utföras och hur. Eftersom navigering är ett så stort problem för alla som testat ger sammanställningen av måttet vilsenhet en bra fingervisning. Syftet bakom att använda vilsenhet som ett måttt är att avgöra hur effektivt en användare navigerar i verktyget. Om en användare navigerar optimalt ska det beräknade värdet vara 0. Då vilsenhet beräknas för hela scenariot uppstår naturliga upprepningar och återkommande 15

23 4.1. Utvärdering administrationsverktyg i AES vyer vilket resulterar i ett högre värde. Tabell 4.1 visar den beräknade vilsenhet som varje testperson uppnått. Administrationsverktyg Erfaren Erfaren Använt Oerfaren Oerfaren Scenario Scenario Tabell 4.1: Vilsenhetvärde per scenario De som var helt oerfarna med administrationsverktyget har större problem än de med erfarenhet. Det syns både i scenario 1 och scenario 2. De som har erfarenhet utför navigationen i scenario 1 likvärdigt vilket tyder på viss rutin kring hur inställningar kan genomföras. De utan erfarenhet behöver leta lite bland olika inställningar och hitta vart de ska ändra innan de blir klara med scenario 1. Från scenario 1 till scenario 2 stiger värdet för vilsenhet drastiskt. Anledningen till detta är det stora antalet återbesök till olika vyer som krävs för att slutföra scenario 2. Skillnaden mellan scenario 1 och 2 i tabell 4.1 visar på att navigationen av mer komplexa inställningar kan avsevärt förbättras. Det mått som oftast används i utvärdering av användbarhet och mer specifikt delområdet effektivitet är tid per uppgift. De mätningar som utförs under testen utförs över hela scenariot. I fig. 4.2 syns den tid som varje scenario tog att utföra i minuter uppdelat utifrån testpersonernas erfarenhet. Som både tabell 4.1 och fig. 4.1 visar hade de oerfarna stora problem med scenario 2. Den tid som visas i fig. 4.2 är den tid som de försökte utföra scenario 2 eller trodde de var klara Administrationsverktyg. Scenario. 1. Scenario. 2. Ej klarade inställningar. (%) Minuter Erfaren Erfaren Använt Oerfaren Oerfaren Figur 4.2: Tid per scenario Grafen visar den totala tiden varje testperson spenderat under respektive scenario och hur många procent av inställningarna som blev genomförda. En helt fylld bar visar att alla inställningar har genomförts. Tid är en viktig aspekt då effektivitet testas men om det inte blir korrekt så spelar tiden ingen större roll i sammanhanget. Precis som grafen ovan visar sker en dubblering av tid från scenario 1 till scenario 2. Det stämmer överens med de åsikter som testpersonerna har uttryckt vad det gäller navigering och återupprepning av uppgifter. 16

24 4.2. Utveckla prototyp av administrationsverktyg Den slutsats som går att dra från Figur 4.2 är att erfarenhet med administrationsverktyget spelar stor roll då mer komplicerade scenarion ska utföras. Det syns speciellt då de utan erfarenhet får mycket låg procent på genomförda inställningar utifrån hur mycket tid de spenderade under scenariot. Figur 4.2 bekräftar tillsammans med tabell 4.1 de åsikter som testpersoner uttryckt kring navigationen i administrationsverktyget. Då vilsenhet ökar mellan scenario 1 och 2 ökar även tiden det tar att utföra ett scenario. Det innebär att effektivisering inom navigation kan påverka effektiviteten i verktyget. 4.2 Utveckla prototyp av administrationsverktyg Användarcentrerad design används i stor utsträckning under utvecklandet. I denna metod utförs ofta flera iterationer för att till slut ta fram en färdig produkt. Enbart en iteration utfördes för att utveckla prototypen. Den grund som används för utvecklingen bygger på resultat från utvärderingen av administrationsverktyget, diskussioner och idéer från användare av administrationsverktyget. Tabell 4.1 tillsammans med den muntliga återkopplingen under testerna visar att navigeringen i verktyget är en stor del av de problem som finns i administrationsverktyget. Förbättra tydlighet och navigation Utifrån den vetskapen omformades sättet som sessioner används i prototypen. Administrationsverktyget ser varje session som en separat tentamensuppsättning där varje session kan kopplas till andra sessioner. Prototypen hanterar tentamensuppsättningen som en tentamen som sedan består av olika sessioner. Det innebär att varje gång en tentamensuppsättning skapas kan flera sessioner skapas och är ihopkopplade implicit se fig Figur 4.3: Gamla och nya systemstrukturen Det tar bort det mellansteg som finns i det nuvarande administrationsverktyget för att föra samman sessioner. I administrationsverktyget är varje session enskild. Det speglas också i gränssnittet som inte har möjlighet att visa information från flera sessioner samtidigt. Det innebär att för att verifiera inställningar som genomförts måste varje session kontrolleras separat. I scenario 2 innebär det att totalt åtta sessioner som måste kontrolleras. Genom att se allt som en examinationsuppsättning kan inställningar som är gemensamma visas utan att någon extra navigering behövs. 17

25 4.3. Jämförelse mellan verktyg Upprepning av uppgifter För att förbättra det upplevda upprepandet av inställningar som krävs för administrationsverktyget skapades ett nytt sätt att se på gemensamma inställningar. Istället för att varje session har egna inställningar så använder sig prototypen av konfigurationer. En konfiguration är en samling med inställningar som kan delas mellan flera sessioner. Då varje session är ett enskilt examinationstillfälle i administrationsverktyget behöver många inställningar utföras en gång för varje session. Syftet bakom att införa konfigurationer i prototypen diskuterades fram tillsammans med de som använde verktyget ofta och utgick då från de resultat som sammanställts ovan. Varje session som skapats i prototypen kan få sin egen konfiguration för att flexibelt kunna ge olika inställningar till olika tillfällen. För att enkelt kunna ändra på konfigurationer utan att behöva skriva om dem infördes möjligheten att klona en konfiguration. Vilket innebär att en kopia skapas med alla inställningar så att ändringar kan utföras utan att påverka den klonade konfigurationen. Design och användargränssnitt För att utveckla en prototyp som användarna lätt kan ta till sig användes enbart redan kända kontroller. Innan prototypen började utvecklas hade analysen av administrationsverktyget genomförts. Genom att ta till vara på det resultat som den analysen av användbarhet gav kunde prototypen utvecklas mot att försöka förbättra det som visat sig skapa problem i administrationsverktyget. Då administrationsverktyget redan har utvärderats och planer kring hur det eventuellt kan förbättras diskuterats fram kunde utvecklingen flyta på. Designval under och innan utvecklingen bygger till stora delar på administrationsverktyget men då det behövs en ny lösning användes stödet från litteraturen och kommunikation med användarna. 4.3 Jämförelse mellan verktyg För att jämföra prototypen mot administrationsverktyget utförs samma testscenarion på prototypen som tidigare utförts på administrationsverktyget. Utgångspunkten för jämförelsen mellan prototypen och administrationsverktyget är det mätdata som sammanställts utifrån de utvärderingar som gjort av de båda verktygen. En första jämförelse mellan verktygen kan ses i Figur 4.4. Här visas hur många av inställningarna som var korrekta i slutet av varje scenario. 18