Wikinspire. En webbapplikation för visualisering av relationer mellan Wikipedia-artiklar baserad på tids- och platsinformation

Linköpings universitet Insitutionen för teknik och naturvetenskap Kandidatarbete Medieteknik Vårterminen 2016 LiU-ITN-TEK-G--16/019--SE Wikinspire En webbapplikation för visualisering av relationer mellan Wikipedia-artiklar baserad på tids- och platsinformation Sara Martin Sarah Fosse Albin Bergström Hanna Johansson Johanna Westberg Examinator: Karljohan Lundin Palmerius Linköpings universitet SE-581 83 Linköping 013 28 10 00, www.liu.se

Sammanfattning Wikinspire är en webbapplikation utvecklad för att visualisera data från artiklar på Wikipedia. Applikationen har utvecklats som ett medietekniskt kandidatarbete i kursen TNM094 vid Linköpings Universitet och all behandlad data är erhållen via Wikipedias publika API. Uppgiften som gruppen fick av kunden var att skapa en webbappliktion som visualiserar tid- och platsinformation från Wikipediaartiklar i länkade vyer och som tillåter filtrering och navigering av dessa data. Arbetet har utvecklats genom den agila utvecklingsmetoden Scrum med en tidsplan som schemalades i början av projektet där en överskådlig struktur av sprints och delmål var inplanerade. Det programspråk som använts för utvecklingen av applikationen har i huvudsak varit det objektorienterade programspråket JavaScript och i kombination med andra programspråk, så som D3, Bootstrap, AngularJS, HTML och CSS, resulterade projektet i ett objektorienterat system. Slutprodukten är en webbapplikation som visualiserar data från Wikipedia-artiklar i två olika vyer, en kartvy och en tidslinjevy. Den data som visas för användaren baseras på den sökta artikel som användaren angett. I kartvyn visas den sökta artikeln tillsammans med de artiklar som på något sätt relaterar till den, utplacerade som markörer på en världskarta. I tidvyn markeras den sökta artikeln tillsammans med alla relaterade artiklar som prickar på en tidslinje i kronologisk ordning. Det finns många andra visualiseringar av data från Wikipedia men få som är så allmänna som den som presenteras i denna rapport, där användaren själv kan välja artikel att visualisera. Kombinationen karta och tidslinje är inget som gruppen hittat tidigare. i

Innehåll Sammanfattning Figurer Tabeller i v vii 1 Inledning 1 1.1 Bakgrund........................................ 1 1.2 Syfte........................................... 1 1.3 Frågeställningar..................................... 2 1.4 Avgränsningar...................................... 2 1.5 Typografiska konventioner............................... 2 2 Relaterat arbete 3 3 Utvecklingsmetodik 4 3.1 Gruppkontrakt...................................... 4 3.2 Ansvarsområden.................................... 4 3.3 Projekthantering..................................... 5 3.3.1 Tidsplan..................................... 5 3.3.2 Kundkontakt.................................. 6 3.3.3 Kravhantering................................. 6 3.3.4 Mötesprinciper................................. 6 3.3.5 Dokumentation och versionshantering..................... 7 3.3.6 Kodkonventioner................................ 8 4 Teknisk redogörelse 9 4.1 Systemarkitektur.................................... 9 4.2 Utvecklingsplattform och enheter............................ 10 4.3 Utvecklingsverktyg................................... 10 4.4 Wikipedias API..................................... 11 4.5 Val av data att visualisera................................ 13 ii

INNEHÅLL iii 4.6 Implementation..................................... 13 4.6.1 Mapbox.js................................... 13 4.6.2 Tidslinje.................................... 13 4.6.3 Slumpknapp.................................. 13 4.7 Server och databas................................... 14 4.8 Refaktorering...................................... 14 4.9 Designval........................................ 14 4.10 Testning......................................... 15 4.10.1 Förstudie och användartester.......................... 15 5 Resultat 17 5.1 Utvecklingsmetodik................................... 17 5.2 Systemarkitektur.................................... 17 5.3 Gränssnitt och designval................................ 18 6 Analys och diskussion 24 6.1 Arbetssätt och teknikval................................. 24 6.2 Refaktorering...................................... 25 6.3 Testning......................................... 25 6.3.1 Systemtester.................................. 26 6.3.2 Förstudie och användartester.......................... 26 6.4 Gruppkontraktet och förhållningsregler......................... 27 6.5 Källkritik........................................ 28 6.6 Resultat......................................... 28 6.7 Arbetet i ett vidare sammanhang............................ 29 7 Slutsatser 30 7.1 Arbetssätt........................................ 30 7.2 Framtida arbete..................................... 30 7.3 Frågeställningarna.................................... 31 Litteraturförteckning 32 A Gruppkontrakt 34 B Kravspecifikation 36 C Stories 38 D Förundersökning 40

INNEHÅLL iv E Systemarkitektur 43 F Personligt bidrag 45 G Applikationens utseende vid genomförandet av användartesterna 46 H Resultatet av användartesterna 48 H.1 Testpersonerna..................................... 48 H.2 Ikonerna......................................... 49 H.3 Första intryck...................................... 50 H.4 Design.......................................... 53 H.5 Övrigt.......................................... 54

Figurer 3.1 Gantt-schema som visar tidsplaneringen för arbetsprocessen.............. 6 4.1 Use Case-diagram över applikationen.......................... 9 4.2 Aktivitetsdiagram för applikationen........................... 10 4.3 En skärmdump över hur Wikipedia API Sandbox ser ut................. 11 4.4 Ett exempel på en genererad JSON-fil efter att en sökning gjorts i Wikipedia API Sandbox......................................... 12 4.5 En förstorad bild av slumpknappen som används i webbapplikationen......... 14 5.1 En skärmdump av startsidan från slutprodukten..................... 18 5.2 En prototyp över designen för applikationens startsida................. 18 5.3 En skärmdump av kartvyn från slutprodukten...................... 19 5.4 Ett exempel på en textruta med information om en viss artikel, i det här fallet huvudsökningen Gräddost. Textrutan innehåller artikelns första paragraf, titeln och en tillhörande bild...................................... 20 5.5 Ett skärmklipp från en sökning på Gustav Vasa och den popup-ruta som då visas för den relaterade artikeln Lübeck.............................. 21 5.6 En skärmdump av tidslinjevyn från slutprodukten.................... 21 5.7 Ett skärmklipp av webbapplikationens slutgiltiga header................ 22 5.8 En prototyp av webbapplikationens header....................... 22 5.9 Ikonen för historik som finns till höger uppe i applikationens header.......... 22 5.10 Ett exempel på hur rutan för sökhistorik ser ut för användaren............. 22 5.11 Informationsrutan som finns tillgänglig på alla sidor i applikationen.......... 23 D.1 Åldersfördelningen bland de personer som deltog i förundersökningen......... 40 D.2 Enkätsvar gällande hur ofta personerna som deltog i förstudien besöker Wikipedias hemsida.......................................... 41 D.3 Enkätsvar från förundersökningen gällande om personerna som deltog i studien någon gång besökt Wikipedia utan att veta vad hen ska söka på................ 41 D.4 Enkätsvar från förundersökningen gällande om personerna som deltog i studien någon gång använt Wikipedias randomize-funktion...................... 42 D.5 Enkätsvar från förundersökningen gällande i vilket syfte personerna som deltog i studien använder Wikipedia................................. 42 v

FIGURER vi D.6 Enkätsvar från förundersökningen gällande om personerna som deltog i studien brukar använda sig av länkarna i Wikipedias artiklar.................... 42 E.1 En översikt över samtliga JavaScript-filer och dess funktioner............. 43 E.2 Objektet temparticle och dess variabler......................... 44 G.1 Startsidans utseende vid användartestets utförande................... 46 G.2 Tidslinjevyns utseende vid användartestets utförande.................. 47 G.3 Kartvyns utseende vid användartestets utförande.................... 47 H.1 Ålder på testpersonerna som deltog i användartestet................... 48 H.2 Utbildningar representerade bland testpersonerna i användartestet........... 49 H.3 Åsikter som framkom vid testpersonernas första intryck av sidan............ 50 H.4 Testpersonernas första intryck av kartvyn samt konstruktiv kritik............ 51 H.5 Testpersonernas första intryck av tidslinjevyn samt konstruktiv kritik......... 52 H.6 Åsikter om färgvalet gällande applikationens design.................. 53 H.7 Övergripande åsikter om applikationens design..................... 53 H.8 Svarsfrekvens på frågan om testpersonerna skulle tänka sig att använda vår applikation. 54

Tabeller 4.1 Webbapplikationens ikoner................................ 15 H.1 Testpersonernas åsikter om ikonen för kartvyn, innan de fick reda på vad den skulle symbolisera........................................ 49 H.2 Testpersonernas åsikter om ikonen för tidslinjevyn, innan de fick reda på vad den skulle symbolisera.................................... 50 H.3 Testpersonernas konstruktiva kritik om startsidan.................... 50 H.4 Testpersonernas åsikter om designen........................... 53 H.5 Testpersonernas åsikter gällande vad vår applikation har för fördelar gentemot Wikipedia........................................... 54 H.6 Övriga synpunkter och åsikter om applikationen.................... 54 vii

Kapitel 1 Inledning I den här rapporten behandlas utvecklingen av ett projekt som är en del av kursen TNM094, Medietekniskt kandidatprojekt vid Linköpings Universitet. Rapporten behandlar utvecklingen av ett projekt i kursen, vars mål har varit att visualisera artiklar från Wikipedia som relaterar till varandra. Kursens mål är att utveckla ett projekt enligt systemutvecklingsprinciper och en vald utvecklingsmetodik. Denna rapport beskriver utvecklingsprocessen och resultatet av projektet, det vill säga den slutgiltiga produkten. Projektet har utvecklats enligt arbetsmetodiken Scrum av en grupp på fem personer [16]. 1.1 Bakgrund Idag finns det miljontals artiklar på Wikipedia, som är ett mångspråkigt uppslagsverk på webben. Innehållet är i huvudsak fritt och öppet, det utvecklas och publiceras av sina användare och uppdateras kontinuerligt. Artiklarna innehåller ofta länkar till andra artiklar som är relaterade till ämnet, vilket gör att läsaren kan fördjupa sig i ämnet ytterligare. Hur dessa artiklar är relaterade, om de båda länkar till varandra eller om den ena bara länkar till den andra, visualiseras inte på något sätt. En negativ aspekt av detta är att det kan vara svårt för en användare att på Wikipedia hitta relevanta artiklar om användaren inte vet exakt vad den letar efter. Likaså kan det vara svårt för användaren att se relationer mellan en artikel och andra artiklar som kopplar till den. Grundtanken för det här projektet är därför att skapa en webbapplikation som tydligt visar hur olika artiklar är relaterade till varandra i tid och plats, vilket skulle kunna bidra till att användningsområdet för Wikipedia ökar. Utvecklingsgruppen strävar efter att ta fram en webbapplikation som gör det lättare för användaren att se hur artiklar är relaterade till varandra och som ger användaren en ny upplevelse gentemot Wikipedias hemsida, så som den ser ut idag. Genom att utveckla ett gränssnitt för denna typ av visualisering vill gruppen skapa en webbapplikation där användaren på ett intuitivt sätt kan navigera sig mellan olika artiklar. 1.2 Syfte Syftet med projektet är att med den agila utvecklingsmetoden Scrum skapa en webbapplikation för att visualisera relationer mellan Wikipedias artiklar. Webbapplikationen ska hämta data från Wikipedias artiklar och visualisera relationen mellan artiklarna på ett, för den valda målgruppen, begripligt och relevant sätt. 1

KAPITEL 1. INLEDNING 2 1.3 Frågeställningar I projektets början formulerade gruppen tillsammans med kunden ett antal vetenskapliga frågeställningar som under arbetets gång sedan skulle besvaras. Frågorna var följande: Det finns en risk att all information inte kan visas på grund av mängden data som ska hanteras. Hur kan data från Wikipedia filtreras utan att information går förlorad? Hur bestäms vilken data som ska visualiseras och inte? Hur kan applikationen tillföra något som Wikipedia inte redan erbjuder användaren? Kommer det att behövas någon form av databas för egen lagring av data? Om så är fallet vilken data? Går det att lägga över delar av beräkningarna på en server för att avlasta klienten? Är detta önskvärt ur ett prestandaperspektiv? 1.4 Avgränsningar Projektet har en bred målgrupp där vem som helst med tillgång till Internet ska kunna utnyttja webbapplikationen. Användaren bör dock vara läskunnig och ha grundläggande datorkunskaper. Uppskattningsvis är användaren mellan 10 och 60 år och är en nyfiken person som vill allmänbilda sig inom ett specifikt område eller upptäcka nya relationer mellan olika ämnesområden. Ytterligare en avgränsning är valet av skärmstorlek för slutprodukten. Slutprodukten kommer inte att vara anpassad för handhållna enheter, vilket gruppen räknar som enheter med en skärmyta mindre än 11 tum. Den kommer inte heller att vara anpassad för skärmar med ett bildformat som skiljer sig markant från 16:9 eller skärmar med en upplösning lägre än 1280x720 pixlar. I projektets början tog gruppen beslutet att enbart använda sig av svenska Wikipedia-artiklar i webbapplikationen. Svenska artiklar valdes före engelska då antalet engelska artiklar överstiger antalet svenska, och med ett för stort antal artiklar skulle det kanske bli nödvändigt att filtrera datan och riskera att relevant information gick förlorad. Beslutet fattades därför att börja med svenska artiklar och att i ett senare skede, om det skulle vara relevant, byta till att hantera engelska artiklar. 1.5 Typografiska konventioner Engelska ord skrivs kursivt och kommer förklaras kort i texten första gången de nämns. Orden agil, sprint och task är båda ursprungligen engelska ord, men kommer i denna rapport användas som svenska ord. Sprint kommer i plural benämnas som sprints, task benämns i plural som tasks och ordet agil böjs enligt svenska konventioner. Variabler som används i koden skrivs i typsnittet Courier.

Kapitel 2 Relaterat arbete Eftersom Wikipedias API är så lättillgängligt och väldokumenterat finns det en uppsjö av applikationer som på något sätt visualiserar olika data från Wikipedia att hämta inspiration från till ett projekt som detta. En sida som användes i projektets inledande fas var seealso.hatnote.com, där några utav de bästa visualiseringar av Wikipedia-data fanns samlade. Exempel är visualisering av olika musikgenrers popularitet genom åren eller en tidslinje med betydelsefulla händelser mellan Big Bang och nutid. Undersökningar gjordes inte enbart för att hitta inspiration utan även till att jämföra idéer gruppen hade mot vad som redan existerade, för att hitta en idé som var unik och inte redan hade genomförts. Det som framgick av undersökningen under sprint 0 var att det fanns en hel del visualiseringar av intern data från Wikipedia, så som redigeringshistorik eller data från diskussionstrådar mellan användare på Wikipedia. Det finns också en hel del visualiseringar av relativt specifik data från Wikipedia. Så som visualiseringar över Miles Davis liv eller Londons historia enligt Wikipedia. Något som särskiljer detta projekt från många andra visualiseringar är hur pass generell applikationen är som låter användaren visualisera valfri artikel och dess relationer i tid och rum. Under undersökningarna och under det första användartestet framgick även att Wikipedias hemsida uppfattas som tråkig och grå, vilket har legat till grund till en av frågeställningarna i kapitel 1.3. 3

Kapitel 3 Utvecklingsmetodik Det här kapitlet beskriver hur gruppen har arbetat med principer och rutiner inom systemutveckling, hur gruppen har arbetat med organisation, vilka arbetsuppgifter respektive gruppmedlem har haft och hur kommunikation och dokumentation har hanterats. Arbetet har organiserats genom att följa ett gruppkontrakt och fördela ansvaret och uppgifter enligt kapitel 3.2. 3.1 Gruppkontrakt I början av projektet skrevs ett gruppkontrakt för hela utvecklingsgruppen. Kontraktet skrevs gemensamt som en grund för gruppen att förhålla sig till under hela utvecklingsprocessen. Det innehåller förhållningsregler gällande möten, beslut, arbetsregler, frånvaro och gruppnormer. Hela kontraktet kan ses i Bilaga A. 3.2 Ansvarsområden Då utvecklingsmetoden Scrum används finns det inte några specifika roller inom programmering. Det finns dock roller för att hålla gruppen organiserad, vilka har varit desamma under hela projektets gång. De roller som funnits har tilldelats som följande: Produktägare - Karljohan Lundin Palmerius Scrum Master - Sara Martin Dokumentationsansvarig - Sarah Fosse Lokalansvarig - Hanna Johansson Testansvarig- Johanna Westberg Kundkontakt - Albin Bergström Produktägare: Produktägaren sammanställer och prioriterar önskemål om tillägg och ändringar främst utifrån affärsnytta. I ett webbprojekt är det vanligt att produktägaren är en projektledare hos beställaren. Scrum Master: Den som är Scrum Master guidar utvecklingsgruppen/teamet och ser till att allt rullar på smidigt. Scrum Mastern stämmer av mellan aktörer samt ser till att det inte finns några hinder för 4

KAPITEL 3. UTVECKLINGSMETODIK 5 teamet. Det är även Scrum Masterns uppgift att se till att de agila utvecklingsmetoderna följs och att hålla i Scrum-möten. Dokumentansvarig: Dokumentansvarig har det yttersta ansvaret för att anteckna vid möten och se till att alla dokument finns tillgängliga för gruppen. Det kan vara både protokoll från möten och bilder på prototyper etc. Lokalansvarig: Ansvarar för att gruppen alltid har en plats att arbeta på. Lokalen för arbetstillfället ska alltid skrivas in i den gemensamma kalendern i Google Calendar en dag i förväg. Testansvarig: Testansvarig har som uppgift att se till att tester utförs och att dessa dokumenteras för att gruppen ska kunna åtgärda buggar som hittas. Kundkontakt: Personen som är kundkontakt är gruppens länk till kund. Det är denne som alltid bokar möten med kund och sköter all mailkontakt. 3.3 Projekthantering Nedan följer en genomgång över hur tidsplanen för projektet lades upp, från början till slut, samt hur kontakt med kund och kravhantering har fungerat. 3.3.1 Tidsplan Projektet delades upp i fem sprints på ca två veckor vardera. Gruppen valde att inleda arbetet med en sprint 0 för att läsa på om Wikipedias API, informationsvisualisering och vilka språk och verktyg som skulle användas. Programspråken Dart.js och Angular.js var två programspråk som undersöktes under sprint 0 där Dart.js sedan uteslöts och Angular.js beslutades att användas i den slutgiltiga produkten [1]. Under den tiden genomfördes även en kravanalys utifrån den från kunden givna kravspecifikationen. Kravspecifikationen modifierades något utifrån utvecklingsgruppens personliga mål för projektet, hela kravspecifikationen kan ses i Bilaga B. Ett Gantt-schema visar de olika delarna som ingår i projektet och under vilken tid olika delar har arbetats med, se Figur 3.1. Implementeringen av front-end och back-end var möjlig att arbeta på samtidigt, därav lades dessa arbetsmoment parallellt i schemat. Testningen påbörjades först vecka 15 på grund av tentaperioden som inföll under vecka 12 och 13 och innan dess fanns inte tillräckliga leverabler att testa.

KAPITEL 3. UTVECKLINGSMETODIK 6 VECKOR: 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Sprint 0 Implementera: Front end Implementera: Back end Testning Implementera åtgärder Rapport Opponering Avstämningar + Redovisning TODAY Figur 3.1: Gantt-schema som visar tidsplaneringen för arbetsprocessen. Under arbetets gång fördelades arbetet i grupper om två och tre personer, så kallad parprogrammering. Ofta var det bara ett par som parprogrammerade medan de andra tre arbetade enskilt. Vilka som har parprogrammerat ihop har dock varierat och alla i gruppen har fått testa på att parprogrammera någon gång. 3.3.2 Kundkontakt Gruppen har kontinuerligt bokat möten med kunden efter varje sprint för att visa hur arbetet gått samt diskuterat framtida planering. Under dessa möten har gruppen fått återkoppling från kunden huruvida de arbetar i rätt riktning eller ej, samt diskuterat nästa steg i utvecklingen. 3.3.3 Kravhantering Arbetet med webbapplikationen skedde förhållandevis fritt med få krav från kunden. Ett antal stories, se Bilaga C, antecknades under det första kundmötet och efter det skapade gruppen en egen bild hur man skulle gå tillväga genom att dela upp stories i mindre tasks. Dessa stories från kunden samt information utifrån de vetenskapliga frågeställningarna, den tänkta systemarkitekturen och den givna projektbeskrivningen lades sedan upp på projektorganiseringssidan Trello för att hålla fokus på vad som behövde göras och vad som redan gjorts [20]. 3.3.4 Mötesprinciper Grupparbete schemalades till en början måndagar, onsdagar och fredagar 8:15-17:00 (lunch mellan 12:00-13:15). Innan varje sprint hölls ett Sprint Planning Meeting. Scrum Mastern avgjorde hur länge varje möte skulle pågå. Alla delade på ansvaret att hjälpa till att planera vad av The Product Backlog som skulle göras under den kommande sprinten. Dokumentansvarige antecknade under alla möten [15] [16]. Under tiden som sprinten pågick börjades varje dag med en Daily Scrum eller Stand Up Meeting som det också kallas, ett möte på 15 minuter som hölls stående för att hålla det kort och koncist. Under mötet berättade alla i utvecklingsgruppen vad som gjorts föregående arbetsdag, vad som skulle

KAPITEL 3. UTVECKLINGSMETODIK 7 göras under dagen samt ifall det hade uppkommit några svårigheter som förhindrade utvecklingen av projektet. Efter varje avslutad sprint hölls en Sprint Review där mötet fick pågå som längst i 4 timmar. Under mötet diskuterades vad som varit målet med sprinten och vad som faktiskt gjorts. The Product Backlog uppdaterades och dokumentansvarige antecknade vad som ändrats i den. Sprint Retrospective hölls efter Sprint Review-mötet för att utvärdera kommunikationen i gruppen och tekniken som använts under sprinten. Hela sprinten sammanfattades i ett dokument där alla mötesanteckningar från Sprint Planning, Sprint Review och Sprint Retrospective samlades. Gruppen hade även så kallade brainstormingmöten som inte var planerade i förväg. Dessa möten hölls då gruppen behövde fatta snabba, gemensamma beslut. Under dessa möten skrevs gruppens idéer och tankar upp på en whiteboard för att alla skulle ha en tydlig överblick. Detsamma gäller för de designmöten som hållts under projektets gång. Dessa möten fokuserade på slutproduktens design och allt vad det innebar från färgval till ikonplacering, men även gränssnittets funktionalitet diskuterades och hur navigationen skulle ske i applikationen. 3.3.5 Dokumentation och versionshantering Under Sprint Planning, Sprint Review och Sprint Retrospective samt kundmöten har det dokumenterats vad som sagts under mötet av den dokumentansvarige. Detta för att hela tiden ha planeringen att se tillbaka på under de olika sprintarna samt så att alla gruppens medlemmar har tillgång till vad som sagts. För att alla i gruppen skulle ha tillgång till dokumenten användes Google Drive [12]. På Google Drive delades även alla bilder och anteckningar som gjorts på whiteboard, från bland annat brainstorming-möten och designmöten. Bilderna har varit protyper gjorda i Photoshop, skärmdumpar från inspirerande sidor på Internet och fotografier av brainstorming på whiteboard. Det har varit den dokumentansvariges uppgift att dessa bilder och alla övriga dokumentfiler är väl strukturerade och tydligt namngivna. Bildfilerna döptes efter datum och ett kort, beskrivande namn. Versionshanteringssystemet Git användes tillsammans med GitHub [11] som är en lagringsplats för den versionshanterade koden. För att underlätta olika versioner av projektet valde gruppen att till en början använda sig av olika grenar (branches). Bara fungerande kod lades upp på GitHub och varje commit kommenterades väl på engelska. Kommenteringen skulle även ske enligt en mall så att alla medlemmar i gruppen fick förståelse för hur alla funktioner och filer fungerade. Språkvalet av kommentarerna valdes med hänsyn till utvecklingsmöjligheter utanför den svenska marknaden, samt för att göra det möjligt för icke-svensktalande att kunna utveckla koden. Kodmallen innefattade att alla kodfiler dokumenterades genom att överst ha en kort beskrivning av vad koden i filen gör, vem som skrivit koden i filen samt en lista över de funktioner som filen innehåller, läs mer i Kapitel 3.3.6. Målet under projektet har varit att koden ska vara välstrukturerad och lättläst, men att den ska kompletteras med kortare kommentarer. Gruppen ansåg att variabelnamn inte bör vara för korta, ska vara lättförståeliga och kopplade till det de används till. Längre tydliga variabelnamn föredras framför korta och otydliga variabelnamn. När en utvecklare implementerat kod som fungerar enligt kravspecifikationen och som uppfyller den task som arbetats med kunde denna kod läggas upp på Github. Detta möjliggjorde att alla i gruppen hade tillgång till den senaste versionen av programmet och kunde vidareutveckla varandras kod. När en branch sammanfogades (merge) med projektets master branch fick den som skrivit koden själv kontrollera att koden såg bra ut och att systemet fungerade i sin helhet. Utvecklingsgruppen valde att använda olika branches för olika delar av systemet, så som bland annat hanteringen av data, visualisering respektive användargränssnitt. På så sätt kunde olika personer i gruppen arbeta på varsin branch samtidigt. Senare under projektet togs dock beslutet att gruppen inte

KAPITEL 3. UTVECKLINGSMETODIK 8 längre skulle använda sig utav just branches utan enbart utveckla projektet på mastern. 3.3.6 Kodkonventioner För att koden skulle vara konsekvent och vara förståelig oavsett vem som skrivit den togs interna regler fram för hur implementering och namngivning skulle ske. Där funktioner har skapats har kamelnotationer använts för att tydligt visa vad dess syfte är. För variabler har istället understreck använts som skiljetecken för att öka läsbarheten. Globala variabler har skrivits i versaler och överst i varje fil har en kort sammanfattning funnits över innehållet i filen, vilka funktioner filen innehåller och vad deras syfte är. All kod som inte är självförklarande har kommenterats på engelska.

Kapitel 4 Teknisk redogörelse I det här kapitlet beskrivs hur gruppen har arbetat med de tekniska aspekterna av systemutveckling så som systemarkitektur, implementation, refaktorering och testning. Det beskrivs även mer detaljerat om vilka utvecklingsverktyg som använts och tekniker för att hantera data. 4.1 Systemarkitektur Programdesignen och systemdesignen gjordes med hjälp av grafiska diagram som skapades i programmet Astah Professional [3]. De diagram som gjorts är ett Use Case-diagram och ett aktivitetsdiagram. Use Case-diagrammet är ett diagram över hur användaren kan interagera med systemet. De båda diagrammen gjordes för att få en uppfattning gällande de olika relationerna som finns mellan användaren och systemet. Diagrammen kan ses i Figur 4.1 och Figur 4.2. Figur 4.1: Use Case-diagram över applikationen. 9

KAPITEL 4. TEKNISK REDOGÖRELSE 10 Figur 4.2: Aktivitetsdiagram för applikationen. 4.2 Utvecklingsplattform och enheter Applikationen ska fungera i de vanligaste webbläsarna: Google Chrome, Mozilla Firefox, Safari, Internet Explorer och Microsoft Edge [9]. Den ska fungera på skärmar med en storlek på 11 tum och uppåt och kommer därför inte kunna garanteras stöd på en del surfplattor eller smarta telefoner. 4.3 Utvecklingsverktyg De ramverk och programmeringsspråk som gruppen har använt sig av är JavaScript, HTML, CSS, Bootstrap, D3.js, Mapbox.js och AngularJS. JavaScript är ett av de mest använda språken inom webbutveckling och har ett flertal tillhörande bibliotek där funktionalitet som är användbar för webbapplikationen tillhandahålls. För att göra webbapplikationen dynamisk används ramverket AngularJS, ett opensource-ramverk som i huvudsak underhålls av Google. HTML är ett märkspråk för hypertext som ger möjlighet att ange dokumentstruktur, HTML hanterar dock inte dynamiska vyer, vilket är anledningen till att AngularJS används. För att köra AngularJS-projekt behöver man i vissa fall göra det via en lokal server. Ett exempel på ett program som genererar en sådan är MAMP [14] som användes utav delar av gruppen. Detta behövdes för att dynamiskt kunna ändra sidans webadress utan att ladda om sidan. CSS är det språk som använts för att hantera webbapplikationens stilmall. Bootstrap är ett ramverk för HTML, CSS och JavaScript som gör det enkelt att utveckla responsiva hemsidor [4]. Det innebär till exempel att webbapplikationen kan anpassa sig efter olika stora skärmar och kunna användas av olika webbläsare. Det var även viktigt att använda sig av procent när olika avstånd eller längder mellan olika

KAPITEL 4. TEKNISK REDOGÖRELSE 11 element som deklareras i CSS för att det skulle anpassas ännu bättre till olika skärmar och framförallt webbläsare. Vid implementering av ikoner användes Font Awesome som är ett bibliotek med skalbara vektor-ikoner. Ett sådant bibliotek är bra att använda vid utveckling av responsiva sidor och om man vill ha tillgång till skalbara vektor-ikoner utan att behöva designa dem själv. För att generera en karta har utvecklingsgruppen använt sig av Mapbox.js, som är en designplattform för kartor över hela världen med inbyggda verktyg för att exempelvis markera positioner eller zooma in på en särskild plats [13]. Plattformen använder sig i sin tur av Leaflet.js som är ett open source JavaScript-verktyg för interaktiva kartor, vilket tillför ytterligare funktionalitet till Mapbox.js. I Leaflet.js ingår ett eget API som går att hämta via biblioteket. D3.js som är ett JavaScript-bibliotek har använts för att placera ut prickarna i tidslinjevyn samt hantera animation och användarintegration med dessa. D3.js baseras på HTML, CSS och SVG (Scalable Vector Graphics) [8]. För att implementera kod användes Sublime Text, en textredigerare som lämpar sig väl för webbutveckling. Dock ingår ingen slags kompilator i Sublime Text utan eventuella fel i koden syns i konsolen i webbläsaren [19]. 4.4 Wikipedias API För att kunna hämta data från Wikipedia har gruppen använt Wikipedias publika API [2]. För att lära sig hur API:t fungerar och hur specifik information från Wikipedia hämtas har Wikipedia skapat ett verktyg, Wikipedia API Sandbox, där användaren genom ett enkelt gränsnitt (se Figur 4.3) kan välja vilken information som ska hämtas och i vilket format det ska levereras [2]. Exempel på information som kan hämtas är koordinater för en artikel, första paragrafen i en artikel eller en lista med länkade artiklar. En URL genereras i verktyget som med hjälp av ajax-metoderna GET eller POST kan användas för att skicka en fråga till Wikipedia och erhålla den efterfrågade informationen som svar. Informationen kan sedan sparas antingen i JSON- eller XML-format, där JSON valdes av gruppen eftersom det var ett mer bekant format. Figur 4.3: En skärmdump över hur Wikipedia API Sandbox ser ut.

KAPITEL 4. TEKNISK REDOGÖRELSE 12 Användningen av API:t I webbapplikationen skriver användaren in ett sökord i sökrutan som sedan skapar en sträng. Den strängen skickas sedan in i en funktion som justerar sökordet och skapar en länk, eller query som det kallas, som används för att kalla på Wikipedias öppna API. I länken beskrivs vilka egenskaper som ska hämtas från en Wikipedia-artikel där Wikipedia API Sandbox är ett användbart gränssnitt för att experimentera med Wikipedias syntax. Exempel på egenskaper att hämta för en artikel är koordinater, artiklar den länkar till, bilder, text eller artiklar som länkar till denna. Så här såg queryn ut för webbapplikationen: http://sv.wikipedia.org/w/api.php?action=query&format=json&titles=&prop= coordinates%7clinks%7crevisions%7cextracts%7cpageimages&indexpageids= 1&pllimit=max&rvprop=content&explaintext=1&list=backlinks&bllimit=max& bltitle=input_title&callback=? I länken kan man byta ut input_title mot ett sökord. När denna länk använts erhålls en JSON-fil som svar, förutsatt att användaren skrivit i Wikipedia API Sandbox att en sådan fil önskas. I Figur 4.4 visas den JSON-fil som genereras om man söker på Horse. Filen i detta fall ger bland annat titel och artikelns id. När JSON-filen är hämtad kan informationen hämtas och delas upp beroende på vilken information som önskas. I detta projekt sparades informationen tillfälligt i en global variabel som döptes till MAINARTICLE. För att få tillgång till artikelns titel skrivs variabeln MAINARTICLE.title. På samma sätt skrevs det för att få tillgång till artikelns första paragraf för att skicka texten till index.html genom document.getelementbyid. Figur 4.4: Ett exempel på en genererad JSON-fil efter att en sökning gjorts i Wikipedia API Sandbox.

KAPITEL 4. TEKNISK REDOGÖRELSE 13 4.5 Val av data att visualisera I början av sprint 1 höll gruppen ett gemensamt möte med brainstorming rörande vilken data från Wikipedia-artiklarna som skulle visualiseras. Från början diskuterades möjligheten att söka på olika kategorier så som Historia eller Geografi men efter efterforskningar i Wikipedias API och hur kategoriseringen av artiklarna på Wikipedia är uppbyggd visade det sig att det skulle krävas väldigt mycket arbete för att få ett sådant system att fungera. Efter möten med handledare och kund valdes istället att arbeta med den platsinformation som vissa artiklar har och att göra automatiska sökningar i artikel-texten efter tidsinformation. 4.6 Implementation I detta avsnitt beskrivs betydande delar av applikationen och hur dessa implementerades, vilka bibliotek som har använts och varför. 4.6.1 Mapbox.js För att generera kartan som finns i webbapplikationen användes Mapbox.js, ett verktyg som genererar kartor och har en hel del funktioner som finns att tillgå via dokumentering på Mapbox.js hemsida. Det övervägdes att använda Googles inbyggda karta men då var man tvungen att ordna en nyckel, vilket inte lyckades med, för att få tillgång till kartan. I kombination med Wikipedias API kan man kalla på till exempel variabeln article.coordinates och finna artiklar med koordinater och placera ut markörer för respektive artikel på kartan. I Mapbox.js dokumentation finns även en popup-ruta som kan fyllas med information och som visas när användaren klickar på en markör. I den lades kort information från artikeln i fråga samt titel. Mapbox.js gjorde det även möjligt att bestämma stil på kartan samt markörerna om så önskades. 4.6.2 Tidslinje I tidslinjen användes D3.js för att visualisera tids-markörer eftersom det eftertraktades att ha markörer som liknade Mapbox.js markörer men som ändå tillät kreativitet och egna justeringar. De artiklar som visualiserades var de artiklar som hade en tid beskriven i sin första paragraf. För att hitta en tidsangivelse gjordes en funktion som letade efter ett datum, det vill säga letade efter en månad i bokstäver. Om det förekommer en siffra innan en månad är det antagligen en dag och om det förekommer tre eller fyra siffror efter en månad är det antagligen ett år. När specifikationerna för ett datum funnits lades det in i en lista. Detta för att kunna jämföra datum i vilken ordning de förekommer. När användaren sedan väljer att visa tidsrelaterade artiklar genereras en ny prick med en tillhörande popup för varje artikel som relateras till huvudsökningen. För varje prick som genereras jämförs datumet och prickarnas avstånd mellan varandra justeras. Under tidslinjen med prickar finns ytterligare en tidslinje som visar det valda tidsintervallet. Denna tidlinje har handtag där användaren själv avgränsar mellan vilka årtal hen vill visa artiklar förutsatt att det är inom spannet av de artiklar som finns att välja på. 4.6.3 Slumpknapp Under projektets gång implementerades en slumpknapp. Den används för att inspirera användaren om hen inte vet vad hen vill söka på eller bara vill lära sig något nytt. Slumpartiklar finns inbyggt både på Wikipedias hemsida och i Wikipedia API Sandbox och går alltså att kalla på likt en vanlig sökning

KAPITEL 4. TEKNISK REDOGÖRELSE 14 med en query. Dock sker själva processen något annorlunda än en vanlig sökning. När användaren trycker på knappen hämtas en slumpgenererad JSON-fil. Från den hämtas JSON-filens titel och behandlar titeln som ett sökord som om en användare hade skrivit ordet i sökrutan. Sökordet läggs i sin tur i länken som genererar queryn på samma sätt som innan. Figur 4.5: En förstorad bild av slumpknappen som används i webbapplikationen. 4.7 Server och databas En av frågorna kring hur informationen från Wikipedia skulle hanteras var om det skulle krävas en egen databas eller server. En databas för att lagra någon typ av data och en separat server för att utföra tyngre beräkningar eller filtrering av data på innan denna sedan skickades till slutanvändaren. Efter att projektet fortlöpt en tid kunde det dock konstateras att de datamängder som erhölls från Wikipedia aldrig nådde sådana mängder att någon filtrering var nödvändig, och att de beräkningarna som utfördes var relativt lätta. Det och att implementationen av en egen databas eller server-lösning skulle ta ytterligare tid från utvecklingen av produkten gjorde att varken en egen databas eller server implementerades. 4.8 Refaktorering I mitten av projektet valde utvecklingsgruppen att refaktorera koden. Refaktorering innebär att en förändring görs i den interna strukturen för att göra det lättare att förstå och billigare att modifiera utan att ändra beteendet hos koden [10]. Variabelnamn byttes ut, funktioner och filer fick ändrade namn så att de blev tydligare, och funktioner placerades om så att de låg där de intuituvt och logiskt borde ligga. Kompletterande kommentarer lades till och det kontrollerades att alla filer följde en mall över koddokummentering som tidigare bestämts, läs mer i Kapitel 3.3.6. 4.9 Designval För att bestämma vilken layout och vilka färger webbapplikationen skulle ha hölls ett designmöte. Designmötet hölls med hela utvecklingsgruppen efter att förundersökningen gjorts i början av projektet. Utifrån resultaten av förundersökningen togs beslutet att designen för webbapplikationen skulle vara mer tilltalande än Wikipedias hemsida ( tilltalande definierat så som deltagarna i förundersökningen uttryckt det, se Bilaga D). Undersökningen visade att majoriteten av användarna uppskattar Wikipedias tydlighet men uppfattar sidan som trist och färglös. Efter designmötet fick en person i gruppen i uppgift att ta fram en prototyp för designen med tre grundfärger. De färger som valdes för denna prototyp var mörkblå, röd och ljusblå. Det gjordes även ikoner med de valda färgerna som var relaterade till tidslinjevyn respektive kartvyn, dessa ikoner visas i Tabell 4.1. Den framtagna designen gjordes som en PDF i programmen Adobe Illustrator och Adobe Photoshop och presenterades för övriga i gruppen. Målet med PDF:en var att ha ett mål att arbeta mot utseendemässigt för att tillslut få ett tilltalande slutresultat av webbapplikationen.

KAPITEL 4. TEKNISK REDOGÖRELSE 15 I den slutgiltiga produkten har dock den röda färgen bytts ut mot orange efter ett gemensamt beslut inom gruppen, men den mörkblå samt ljusblå färgen har förblivit densamma som i designförslaget/prototypen. Tabell 4.1: Webbapplikationens ikoner. Ikonen för kartvyn Ikonen för tidslinjevyn. 4.10 Testning För att säkerställa att programmet fungerar enligt kraven i kravspecifikationen krävs regelbunden testning av systemet. Det går antingen att testa hela systemet, för att säkerställa att alla komponenter av systemet fungerar tillsammans, eller att testa enskilda komponenter av systemet. I det här projeketet har främst testning av hela systemet skett. Varje gruppmedlem har själva fått avgöra huruvida den enskilda komponent som de arbetat med fungerar eller ej innan de sammanförde komponenten med hela systemet. En testningsprincip som tillämpades var parprogrammering. Vid parprogrammering kunde två personer direkt granska huruvida en funktion var välskriven och fungerande. Tester av hela systemet utfördes manuellt av testansvarige genom att navigera runt på sidan och testa olika scenarion. Buggar som hittades sparades i en lista på Trello. Det som kunde undersökas var bland annat att se i konsolen om någon funktion hade lång körtid och kunde effektiviseras. Det testades också om delar i systemet skrev över andra delar och om visualiseringen av datan fungerade som den skulle. Mot slutet av projektet utfördes HTML och CSS-validation av koden för att ta bort eventuella slarvfel i koden. Till det användes W3C (World Wide Web Consortium) [21]. 4.10.1 Förstudie och användartester Användartester skedde vid två tillfällen under utvecklingsprocessen; en förstudie vid projektets början och ett användartest i slutet av projektet, i sprint 5. Förstudien gjordes som ett underlag och en inledande undersökning inför utvecklingen av produkten. Förstudien utfördes via ett webbformulär med sju frågor kring nuvarande användandet av Wikipedia samt synen på Wikipedia. Resultatet av förstudien gav utvecklingsgruppen en bekräftelse på att Wikipedia används frekvent av den undersökta gruppen samt nya idéer och tankar som kunde användas under planeringen av produkten. Studiens resultat kunde också bidra till utformningen av kravspecifikationen. Resultatet från delar av förstudien kan ses i Bilaga D. I bilagan ingår ej resultatet från de frågor som besvarades med fritextsvar. Dessa diskuteras dock i Kapitel 6.3.2. Användartester genomfördes även i slutet av utvecklingsprocessen då en relativt färdig slutprodukt fanns att tillgå. Hur webbapplikationen såg ut vid tidpunkten för användartesterna kan ses i Bilaga G. Dessa tester utfördes av två personer ur utvecklingsgruppen tillsammans med en användare. Användaren fick den någorlunda färdiga slutprodukten framför sig och fick själv navigera i applikationen under testet. Användaren uppmanades tänka högt under hela testet och fick under testet svara på mer eller mindre specifika frågor kring applikationen. Resultatet av dessa användartester gav utvecklingsgruppen återkoppling på produkten, om den var lätt- eller svårhanterlig, tillräckligt intuitiv

KAPITEL 4. TEKNISK REDOGÖRELSE 16 och även huruvida den tilltalade användaren. Resultatet av användartesterna kan ses i Bilaga H. Förbättringsförslag lyftes fram och utvecklingsgruppen fick upp ögonen för saker som förbisetts under utvecklingsprocessen. Resultatet innefattade en hel del konstruktiv kritik gällande både sådant som testpersonerna ansåg bra med applikationen och sådant som de ansåg borde förbättras. Vissa saker som testpersonerna påpekade under testets gång var sådant som även utvecklingsgruppen funderat på och tänkt ändra. Det var dock bra med en bekräftelse från en grupp helt oberoende opartiska användare. De kunde uttrycka sina åsikter enbart baserade på den ofullständiga produkt de hade framför sig, utan influenser från utvecklingsprocessen - som gruppen själva hela tiden har med sig i åtankarna. Den kritik som gruppen främst tog till sig gällande startsidan var att flertalet testpersoner ansåg att den var tråkig, mörk och tom. Därtill också att någon typ av information om applikationen borde finnas att tillgå på startsidan. Som åtgärd ändrade gruppen därför bakgrunden på startsidan till en bild, istället för en enfärgad mörkblå bakgrund, samt lade till en informationsknapp. Kritiken gällande båda vyerna innefattade åsikter om färgerna på markörerna/prickarna, att man borde kunna komma till startsidan genom att klicka på applikationens logotyp samt att titelrutan och listan över relaterade artiklar var för stora. Efter testerna lades funktionen till att logotypen är klickbar och att den tar användaren tillbaka till startsidan, det var ändå något som utvecklingsgruppen planerat att göra till slutprodukten. Färgerna på markörerna/prickarna ändrades till att vara mer färgglada, höra ihop mer med de färger som valts för designen (blått och orange) och att de skiftar i mer liknande nyanser (en mörkblå färg och en ljusare blå färg). Rutan som innehåller den sökta artikelns titel gjordes mindre och så även listan över relaterade artiklar. I den listan lades även en beskrivning till över betydelsen av de olika färgerna på markörerna/prickarna. I båda vyerna önskades också en möjlighet att kunna läsa hela artikeln, vilket har lagts till. Möjligheten finns nu att i en ny flik öppna hela den önskade artikeln på Wikipedia. På tidslinjevyn önskades det bland testpersonerna att tidslinjen som begränsar tidsintervallet var av andra färger, så att den skulle synas tydligare. Utvecklingsgruppen valde därför att göra handtagen i orange, enligt de färgval som gjorts för designen. Det var även flera som påpekade att om man klickade på en artikel i listan över relaterade artiklar och denna artikel var utanför det nuvarande valda tidsintervallet så kunde man inte komma åt den artikeln. Efter användartesterna skapades därför en funktion som gör att tidsintervallet automatiskt ändras om användaren väljer en artikel utanför det valda tidsintervallet. Den valda artikeln i listan markeras också tydligare än tidigare då listelementet i slutprodukten får en annan bakgrundsfärg/ser intryckt ut. När användaren sedan klickar på en ny artikel markeras den nya artikeln både på tidslinjen och i listan över artiklarna. Ett övrig förbättringsförslag som kom fram under användartesterna var bland annat att testpersonerna önskade se sin sökhistorik. Det var något som utvecklingsgruppen inte funderat så mycket på, men som diskuterades och lades till efter användartesterna. Mer om sökhistoriken går att läsa i Kapitel 5.3. Vidare var majoriteten av testpersonerna eniga om att det är bra att användaren får återkoppling då sidan laddas genom någon form av laddningssymbol. Vid tillfället för användartesterna fanns en liten laddningssymbol i sökrutan, men den var inte så synlig och utvecklingsgruppen själva var inte helt nöjda med den. Efter testerna ändrades därför detta till att en orange linje längs med headern indikerar hur långt sidan har laddats, samt hur långt det är kvar tills sidan är färdigladdad. Avslutningsvis önskades någon form av knapp för att göra en slumpad sökning, vilken implementerades efter testerna. För att läsa mer om laddningsindikatorn och slump-knappen, se Kapitel 5.3.

Kapitel 5 Resultat Projektet resulterade i en webbapplikation med möjlighet att söka information om Wikipedias artiklar. När användaren har sökt efter en artikel visas de artiklar som är relaterade till sökningen i två vyer: en tidslinjevy och en kartvy. I tidslinjevyn är resultatet baserat på tidsangivelser i artiklarna och i kartvyn baseras resultatet på platsangivelser i artiklarna. I det här kapitlet beskrivs resultaten av såväl applikationen som utvecklingsprocessen. 5.1 Utvecklingsmetodik Under projektets start bestämdes det vilka rutiner gruppen skulle ha angående mötesprinciper. Gruppen har följt rutinerna men utvecklat dessa under projektets gång då utvecklingsmöjligheter har uppkommit vid utvärderingar av projektets sprints. En sak som förbättrats under projektets gång var användningen av Trello. Efter sprint 1 märkte gruppen att de tasks som fanns på Trello var generella och snarare delmål än enskilda tasks. Gruppen bestämde då att alla tasks skulle höra till målet för aktuell sprint och att alla tasks skulle vara tillräckligt specifika för att alla medlemmar skulle kunna välja en task och arbeta med den. Tasks som inte var specifika för sprinten lades under en egen board, en slags anslagstavla, på så sätt prioriterades rätt saker och om tid fanns kunde medlemmarna arbeta med de övriga tasks som fanns listade. 5.2 Systemarkitektur Vid utvecklingen av webbapplikationen delades programmerandet upp i tre delar - funktioner som behandlar datahantering, funktioner som rör tidslinjevyn och funktioner som hanterar kartvyn. De resulterande funktionerna som hanterar detta i slutprodukten finns listade i Bilaga E. I bilagan kan även ses i vilken fil funktionerna ligger och objektet temparticle finns också med tillsammans med alla dess variabler. Det är i objektet temparticle som varje Wikipedia-artikel sparas och för varje artikel finns därmed en rad olika variabler som används för att visualisera och hantera data i applikationen. Eftersom GET- och POST-metoderna som körs för att erhålla data från Wikipedia körs asynkront behöver applikationen anpassas så att inte funktionsanrop sker när ingen data har anlänt. Vid en sökning kör applikationen funktioner för att ladda in vyer och bakgrunder direkt och kallar på funktioner för att lägga in data först när den har anlänt. När data från Wikipedia anländer skickas denna först till en rad funktioner för att formatera om text och bilder till det format som önskas i applikationen och sparas sedan i en egen datastruktur. Sedan används denna datastruktur av funktioner för att visa 17

KAPITEL 5. RESULTAT 18 information i kart- och tidsvy. 5.3 Gränssnitt och designval Den färdiga webbapplikationen består av en startsida och två olika vyer för att visualisera sökresultatet. Dessa två vyer är en kartvy och tidslinjevy och i dessa vyer visas för användaren hur artiklar är relaterade till varandra. Användaren fyller i ett sökord på startsidan, se Figur 5.1, och hamnar sedan automatiskt på tidslinjevyn. Startsidan för slutprodukten kan jämföras med den prototyp för startsidan som visas i Figur 5.2. I prototypen är bakgrunden ljusblå, text och ikoner mörkblå och sökknappen är röd, dvs. den består av de tre grundfärger som togs fram då designprototypen gjordes. I den slutgiltiga produkten har dock rött bytts ut mot orange och bakgrunden består av en bild istället för enfärgad ljusblå bakgrund [5]. Figur 5.1: En skärmdump av startsidan från slutprodukten. Figur 5.2: En prototyp över designen för applikationens startsida. På kartan visas markörer i fyra olika färger, se Figur 5.3. Artikeln för det ord/den artikel som användaren sökt på är orange-röd, om artikeln har en koordinat, annars syns endast de relaterade artiklarna på kartan. De relaterade artiklarna har markörer i tre olika färger; mörkblått, ljusare blått och orange.

KAPITEL 5. RESULTAT 19 De mörkblå markörerna är artiklar som länkas från huvudartikeln användaren sökt på. De ljusare blå markörerna visar artiklar som länkar till huvudsökningen och de markörer i orange färg är artiklar som länkar åt båda hållen, t.ex. att artikeln Norrköping länkar till Campus Norrköping och Campus Norrköping länkar till Norrköping. Till höger på sidan finns även en lista med namnen på alla länkar. Listan har titeln Visade artiklar. Valet att ha med denna lista är för att det kan vara svårt att leta bland alla markörer och en lista gör det därmed mera överskådligt. När användaren trycker på antingen en markör eller ett av artikelnamnen i listan så visas en popup-ruta vid den tillhörande markören. I popup-rutan visas första meningen av artikeln och relationen till huvudsökningen. För vissa artiklar har ingen relationsmening (mening där artiklarnas relation till varandra presenteras) lyckats hämtas på grund av olika problem vid datahanteringen. I popup-rutan för dessa artiklar visas då enbart den första meningen av artikeln. Användaren kan från popup-rutan klicka på Mer info.. för att läsa första paragrafen av artikeln. Popup-rutan kan både ses i kartvyn i Figur 5.3 och på tidslinjevyn i Figur 5.6. Gör användaren valet att klicka på Mer info.. kommer en större textruta upp. Den här rutan innehåller som nämnt första paragrafen från den valda artikeln, men även artikeltiteln och en tillhörande bild. Med ytterligare ett klick kan användaren välja att ta sig vidare till hela artikeln på Wikipedia genom att klicka på Läs hela artikeln på Wikipedia. En ny flik öppnas då i användarens webbläsare med artikeln på Wikipedia. Den här textrutan går även att få fram för huvudartikeln genom att klicka i rutan med artikelnamnet, som ligger centrerad under headern. Ett exempel visas i Figur 5.4. Figur 5.3: En skärmdump av kartvyn från slutprodukten.

KAPITEL 5. RESULTAT 20 Figur 5.4: Ett exempel på en textruta med information om en viss artikel, i det här fallet huvudsökningen Gräddost. Textrutan innehåller artikelns första paragraf, titeln och en tillhörande bild. På tidslinjen visas artiklar i form av prickar, motsvarande markörerna i kartvyn. Prickarna har även i denna vy fyra olika färger - en orange-röd för den sökta artikeln, samt mörkblå, ljusare blå och orangea prickar för de relaterade länkade artiklarna, se Figur 5.6. Färgerna har i denna vy samma betydelse som i kartvyn, det vill säga att en mörkblå artikel är länkad från huvudartikeln, en ljusblå artikel länkar till huvudartikeln och en orange artikel länkar åt båda hållen. För att förtydliga vad som menas med länkar åt båda hållen, se Figur 5.5 där de så kallade relationsmeningarna presenteras i popup-rutan. Den ena meningen är tagen från huvudsökningens artikeln och är meningen i artikeln där den relaterade artikeln nämns. Motsvarande är den andra meningen tagen från den relaterade artikeln och är den mening där huvudsökningen nämns. På så sätt får användaren en bättre uppfattning om på vilket sätt, och i vilket sammanhang, som de båda artiklarna är relaterade. Återkommande i tidslinjevyn är alltså just popup-rutan, som för varje artikel visar första meningen av artikeln samt relationen till huvudsökningen. Likaså finns det till höger en lista över namnen på alla länkar, så att användaren på ett enkelt och snabbt sett kan leta i listan efter en viss artikel. Dessa artiklar är sorterade i bokstavsordning. För båda vyerna gäller också att användaren får återkoppling på hur sidan laddas, då en orange linje rör sig från vänster till höger längs med headern medan artiklarna laddas och placeras ut i den aktuella vyn. När linjen nått till höger kant av fönstret är sidan färdigladdad och allt innehåll på sidan visas som det är tänkt. Linjen kan ses för sökningen på Gustav Vasa i Figur 5.3, där sidan ännu ej laddad helt färdigt. Något som dock skiljer tidslinjevyn från kartvyn är en reglerbar tidslinje med handtag längst ner på skärmen. Med hjälp av det reglaget kan användaren reglera tidsspannet för tidslinjen och därmed styra vilka artiklar som ska visas på tidslinjen och inte. För att förtydliga för användaren vilket tidsspann som är valt, står de två årtalen som begränsar intervallet stort och tydligt i grått mitt i vyn. Bakgrunden för det valda intervallet på tidslinjen är dessutom vit, medan de artiklar på tidslinjen som ligger i de delar/årtal som är utanför intervallet placeras mot grå bakgrund. Dessa artiklar, som är utanför intervallet, går heller inte att klicka på.

KAPITEL 5. RESULTAT 21 Figur 5.5: Ett skärmklipp från en sökning på Gustav Vasa och den popup-ruta som då visas för den relaterade artikeln Lübeck. Figur 5.6: En skärmdump av tidslinjevyn från slutprodukten. För båda vyerna gäller det att det finns en header högst upp. Den ser i slutprodukten ut som i Figur 5.7 och kan jämföras med den prototyp som kan ses i Figur 5.8. Vid denna jämförelse kan även här ses färgändringen som gjorts från rött till orange. Den slutgiltiga headern är mörkblå och innehåller flera element och ikoner. Beskrivs headern från vänster till höger så är det första elementet som användaren ser en sökruta. Denna förtydligas med texten sök efter en ny artikel.. samt ett förstoringsglas. Användaren kan välja att klicka på förstoringsglaset för att genomföra sin sökning eller enbart genom att klicka på Enter-

KAPITEL 5. RESULTAT 22 knappen på tangentbordet på sin dator. Bredvid sökrutan finns en orange knapp med en tärning på. Med hjälp av den kan användaren välja att genomföra en slumpad sökning och får då upp resultatet för den slumpade artikeln. Vidare finns till höger om den knappen de två ikonerna för de två olika vyerna - ikonen för tidslinjevyn och ikonen för kartvyn. Ikonerna är vita om de är omarkerade, blir ljust orangea när användaren sveper med musen över dem och helt orangea när de är valda/klickade. Att ikonen är orange visar också för användaren på vilken sida hen befinner sig på i nuläget. Figur 5.7: Ett skärmklipp av webbapplikationens slutgiltiga header. Figur 5.8: En prototyp av webbapplikationens header. I mitten av headern ses namnet på webbapplikationen. Klickar användaren här kommer hen åter till startsidan. Till vänster sedan i headern finns slutligen två ytterligare ikoner. Den första ikonen är en knapp för användaren att klicka på om hen vill se sin sökhistorik, ikonen visas i Figur 5.9. Utifrån listan med tidigare sökningar går det inte att genomföra en ny sökning, men det presenteras vilka artiklar som användaren sökt på tidigare under samma användningstillfälle. Ett exempel på visad sökhistorik kan ses i Figur 5.10. Den sista knappen och ikonen, längst till höger i headern i webbapplikationens informationsknapp. Denna finns även på startsidan och klickas denna kommer en informativ textruta upp som informerar användaren om hur applikationen kan användas, vad ikonerna betyder och vilka som utvecklat applikationen. Informationsrutan kan ses i Figur 5.11. Figur 5.9: Ikonen för historik som finns till höger uppe i applikationens header. Figur 5.10: Ett exempel på hur rutan för sökhistorik ser ut för användaren. Avslutningsvis kan användaren när som helst göra en ny sökning i applikationen, oavsett vilken vy hen befinner sig på. Det går, som nämnt tidigare, även alltid att ta sig tillbaka till startsidan. I varje vy går det dessutom att skapa en ny sökning utifrån en relaterad artikel.

KAPITEL 5. RESULTAT Figur 5.11: Informationsrutan som finns tillgänglig på alla sidor i applikationen. 23

Kapitel 6 Analys och diskussion Det här kapitlet innehåller en diskussion kring olika val som gjorts i projektet, hur gruppen skulle kunna arbetat annorlunda och olika faktorer som påverkade resultatet. Kapitlet behandlar både tekniska diskussioner kring val av verktyg, problematik med vissa verktyg och hur gruppen har löst problemen. Det behandlar även diskussion kring systemutvecklingsprinciper och hur gruppen har arbetat enligt metodiken Scrum. 6.1 Arbetssätt och teknikval Under projektets start gjordes efterforskningar för att bestämma vilka språk som skulle användas för arbetet. Ett språk som gruppen läste på om var Dart, dock så togs beslutet att använda JavaScript istället då det är ett språk alla var bekanta med. Gruppen ansåg att det skulle ta för lång tid att lära sig ett nytt språk och att det skulle förhindra arbetet, samt att JavaScript lämpade sig bra för att nå målsättningen. Ramverket AngularJS undersöktes också och det beslutades att det skulle användas för att kunna skapa en dynamisk webbapplikation som kan växla mellan olika sidor utan att ladda om hela hemsidan. Dock upptäckte gruppen under projektets gång att det användes mindre än väntat eftersom mycket går att lösa genom att använda JavaScript, Bootstrap, HTML och CSS. Till gruppens hjälp för att lära sig de olika språken användes nätbaserade gratiskurser som Code School [7] och Codecademy [6] erbjöd, vilket var ett smidigt sätt att få snabb förståelse och inblick i om det var ett språk gruppen skulle kunna tänka sig att jobba med. Att arbeta med det responsiva ramverket Bootstrap är inte bara en fördel vid övergången mellan handhållna och stationära enheter. Det lämpar sig bra inom webbutveckling för olika webbläsare och olika storlekar på skärmar om det så handlar om 17 tum eller 11 tum. Under projektets gång upptäcktes det dock en skillnad mellan de olika datorerna ändå. Det som såg bra ut på en skärm kunde se annorlunda ut på en annan. För att lösa det problemet användes procent istället för pixlar i CSS:en för att olika element skulle anpassa sig bättre. I efterhand kan sägas att beslutet att använda sig av Bootstrap inte var särskilt genomtänkt då det samtidigt hade bestämts att applikationen skulle vara menad att användas på skärmar med en storlek på minst 11 tum, vilket till stor del lämnar verktyget outnyttjat. Dessutom bidrog den kod som behövs för Bootstrap till en mer svårläslig kod. I början av projektet gjordes mycket efterforskningar i hur Wikipedias API fungerar med hjälp av deras webbaserade verktyg Wikipedia API Sandbox. Efter en tid när mer förståelse för hur verktyget fungerade utvecklades ändrade dock Wikipedia utseendet på vertyget vilket ledde till att en del extra tid gick åt till att lära sig det nya verktyget. 24

KAPITEL 6. ANALYS OCH DISKUSSION 25 Att använda sig av Mapbox.js var ett bra beslut då Google Maps kräver en nyckel som var svår att få tag på. Generellt är API för kartor är gratis under en viss sidvisning men kommer man upp i ett högt antal sidvisningar så behöver man betala. Google Maps har 2500 visningar gratis medan Mapbox har 50 000. Mapbox är även mer transparent än Google Maps och använder sig av så kallad öppen plattform. Framförallt var Mapbox dokumentation mycket lättare att läsa och justera själv hur man ville att kartan skulle fungera. Det har inte upplevts som att något saknats för webbapplikationens bruk eftersom applikationen inte behövt så många funktioner som tillexempel rutter och avståndsmätning, det vill säga saker som man vill att en avancerad karta ska ha. Under hela utvecklingsprocessen har det varit mycket problematik med Git då alla i gruppen inte varit helt vana vid det sedan tidigare och begreppet branch var nytt för många. Det uppstod därför många problem som tog tid att lösa vid varje commit, även om det kanske bara var en liten förändring som gjorts. Senare togs beslutet att gruppen inte skulle använda sig av branches utan bara jobba med projektet på mastern, som nämnts i Kapitel 3.3.5. Innan detta beslut togs gick mycket onödig tid åt att lös konflikter vid en merge, krångel vid en commit och liknande svårigheter kopplat till Git. Det upplevdes att arbetet på och med Git fungerade bättre efter att beslutet om att enbart jobba på mastern tagits. Att läsa på om Git hur det fungerar så att alla låg på en jämn nivå under sprint 0 hade underlättat en del av de problem som uppstod under projektets gång. 6.2 Refaktorering Som nämnt i kapitel 4.8 genomfördes en refaktorering under mitten av projektet, i sprint 3. Denna refaktorering var förhållandevis omfattande och all kod granskades gemensamt på storskärm. Vid refaktoreringen bytte gruppen namn på variabler, funktioner och filer. Flera i gruppen upplevde variabler och funktionsnamn som otydliga och/eller för korta, vilket försvårade arbetet då det fanns brister i förståelsen av koden. Beslut fattades därför om att hellre ha längre och självbärande variabelnamn än för korta och oklara. Likaså placerades funktioner om i filerna vid refaktoreringen, även detta för att få en mer intuitiv och logisk filstruktur. Vidare lades kompletterande kommentarer till i filerna och kommentarer som skrivits på svenska under utvecklingen översattes till engelska. Sedan början av projektet beslutades att alla kommentarer skulle vara på engelska, ändå skrevs många kommentarer på svenska under utvecklingen av projektet. Till grund för detta ligger förmodligen att gruppen inte är van vid att kommentera på engelska. Tyvärr medförde detta extra arbete och det blev att onödig tid fick läggas på att översätta kommentarer från svenska till engelska. Med andra ord hade den tiden kunnat läggas på annat i projektet om kommentarerna skrivits på engelska från början. Det var även vid den här refaktoreringen som mallen över koddokumentering diskuterades och modifierades. I och med det såg gruppen även till att alla filer följde mallen. Alla i gruppen informerades och var delaktiga i de ändringar som gjordes under refaktoreringen. Efter detta upplevde gruppen att arbetet flöt på bättre, dokumenteringen blev tydligare och koden var generellt mycket bättre kommenterad och dokumenterad. Alla gruppmedlemmar kunde efter refaktoreringen lättare sätta sig in i kod som någon annan skrivit, tack vare den förbättrade strukturen. Det blev lättare att hitta funktioner och förstå deras funktion genom att bara läsa funktionsnamnet och tillhörande kommentarer. 6.3 Testning De testningsprinciper som gruppen använde sig av var systemtesning samt användartester. Systemtestning gjordes för att säkerställa att programmet uppfyllde de krav som specifierats. Systemtestning

KAPITEL 6. ANALYS OCH DISKUSSION 26 testade funktionaliteten och tekniken bakom applikationen. Användartester gjordes för att säkerställa att användargränssnittet var användarvänligt och för att kunna förbättra applikationen ur ett användarperspektiv. 6.3.1 Systemtester Systemtesterna började utföras under sprint 3 då det innan dess endast gick att göra tester på enskilda funktioner vid parprogrammering. Under testerna upptäcktes det att en del av datan från Wikipedia var trasig, till exempel så fungerade det ibland inte att ta ut första meningen eller så slängdes tecken och siffror in i texten som inte syntes i artikeln på Wikipedia. 6.3.2 Förstudie och användartester Förstudien som gjordes precis i början av projektet var väldigt generell och utvecklingsgruppen var medveten om att denna studie kanske inte skulle bidra nämnvärt till slutprodukten. Studien kunde dock fungera som en bekräftelse på flera av de antaganden som gruppen redan gjort. Dessa antaganden var till exempel att Wikipedia används av personer i alla åldrar, majoriteten av dessa besöker Wikipedia några gånger per vecka och anledningen till att besöka Wikipedia är av intresse och nyfikenhet. Utvecklingsgruppen kunde också ta till sig de svar som fåtts på fritextfrågan Beskriv Wikipedia med tre värdeord och utgå i planeringsfasen från vad användare idag förknippar med och anser om Wikipedia. De fem mest förekommande orden bland svaren var lätt, informativt, bra, snabbt och användbart. Dessa ord är positivt laddade och det var något utvecklingsgruppen kunde ta med sig och ha i åtanke när kravspecifikationen skrevs. Målet var att även slutprodukten för projektet skulle kunna få liknande respons bland användare. Gruppen noterade även de mindre positiva orden som dök upp som svar på frågan, så som osäkert/opålitligt, tråkigt, svartvitt, grått och fult. Osäkerheten kring huruvida data på Wikipedia går att lita på är inte något som utvecklingsgruppen kunde ta hänsyn till och påverka under projektet, men de övriga orden riktar sig främst till designen av Wikipedia. Utvecklingsgruppen kunde därför ha dessa ord i åtanke vid designmöten och planeringen av slutproduktens utseende och gränssnitt. Dessa mer negativt laddade ord blev därför ord gruppen ville jobba sig från för att undvika att den typen av återkoppling skulle fås på slutprodukten. Med färg och en mer estetiskt tilltalande och inspirerande design ville utvecklingsgruppen att slutprodukten skulle påminna om Wikipedias kunskapsbank men samtidigt ge ett inspirerande intryck som får användaren att stanna kvar på webbaplikationen och utforska. Vidare bör nämnas att utvecklingsgruppen är medveten om att förstudien till stor del utfördes på bara en viss del av målgruppen. Bland svaren på webbformuläret fanns alla åldersgrupper representerade (från 0-18 år till 50+), men av de 139 deltagande i studien var närmare 88 procent i ålderskategorin 19-25 år. Det innebär att svaren kanske inte överensstämmer med hela målgruppens åsikter och användarvanor. Beslut som tagits efter förstudien, och även användartesterna i slutet av projektet, har därför inte kunnat baseras helt på de resultat och slutsatser som dragits från testerna. Även vid användartesterna i slutet av projektet bestod deltagarna nämligen i största del av personer från ålderskategorin 19-25 år, närmare bestämt i åldrarna 21-24 år. Det selektiva urvalet av målgruppen föll sig naturligt då användartesterna utfördes på området för campus Norrköping, Linköpings universitet. Testpersonerna var därmed studenter i åldrarna mellan 21 år och 24 år.

KAPITEL 6. ANALYS OCH DISKUSSION 27 6.4 Gruppkontraktet och förhållningsregler I början av projektet skrevs ett gruppkontrakt, vilket nämns i kapitel 3.1 samt finns bifogat i Bilaga A. Tanken med kontraktet var att det skulle fungera som en grund med förhållningsregler och bestämmelser för hur gruppen skulle arbeta under projektet. Det har fungerat relativt bra att följa kontraktet under arbetet, men vissa punkter har förbisetts och/eller fungerat mindre bra. Gällande punkterna i kontraktet som rör möten och mötesregler har majoriteten av punkterna uppfyllts under utvecklingsprocessen. Bland annat har det fungerat bra med bokning av sal i god tid, alla protokoll har lagts upp på Google Drive och mötena har försökt hållas korta och produktiva. Det som gruppen dock inte följt, men som står i kontraktet, är att det i slutet av varje arbetsdag skulle hållas ett avstämningsmöte, men det anser gruppen bara varit bra då detta inte riktigt går hand i hand med arbetsmetoden Scrum. Morgonmöten däremot (Stand up meeting) har fungerat bra vid varje arbetsdags början och raster har tagits vid längre möten. Alla punkter som står i kontraktet under rubriken Beslut har uppfyllts, gruppen hade dock lite problem med att just fatta beslut i början av projektet. Gruppen hamnade i något utav en analysis paralysis. Det innebär att väldigt mycket tid lades på att fundera över saker gällande projektet, så som fördelning av arbetsuppgifter, design och prioriteringslista av uppgifter, men inga beslut kring detta fattades. Istället för att komma igång ordentligt med projektet och börja i någon ände av det gick därför mycket tid åt till planerande, samt spekulationer och diskussioner kring hur arbetet skulle genomföras. När gruppen väl insett sitt problem och den situation som den befann sig i blev det nödvändigt att ta vissa väsentliga beslut för att kunna komma vidare i arbetsprocessen. En liknande situation uppstod även senare i projektet då den slutgiltiga designen av produkten skulle bestämmas. Även vid detta steg i arbetet fastnade gruppen i beslutsvårigheter med många olika åsikter kring designval så som färger och placering av ikoner. Gruppen hade dock lärt sig av sitt misstag i början av projektet och insåg ganska snabbt att designmötet skulle kunna hålla på i timmar utan att något beslut skulle kunna tas. Mötet avbröts därför och ett beslut fattades att enbart en i gruppen skulle få ansvara för valet av design, vilket direkt förde projektet framåt och tid kunde läggas på andra uppgifter i projektet. Vidare angående gruppkontraktet listades det vissa arbetsregler i det att förhålla sig till under utvecklingsprocessen. Dessa har följts mer eller mindre bra under projektets gång. Gruppen har i stort sett under alla arbetstillfällen suttit tillsammans, även om arbete utförts enskilt, vilket har fungerat väldigt bra. Målet i början (enligt kontraktet) var också att i största möjliga mån tillämpa parprogrammering. Främst har det varit ett par som har programmerat och tre utvecklare som har jobbat enskilt. Alla i gruppen har någon gång parprogrammerat under utvecklingens gång. Att uppgifter (tasks) markerats i Trello har fungerat bra, men hade även kunnat förbättrats. Det har under projektets gång funnits uppgifter som legat på fel plats i Trello, t.ex. under To-do istället för Doing, eller att en person i gruppen markerat att den jobbar med tre-fyra uppgifter fast den i själva verket vid tillfället bara arbetar med en specifik uppgift. Raster och frånvaro är något som fungerat, men som ändå tagits upp under arbetet som ett mindre problem. Gruppen tog upp detta under ett möte för diskussion under slutet av sprint 3. Alla i gruppen upplevde då att det fungerat relativt bra med t.ex. raster, trots att raster inte tagits helt enligt bestämmelserna. Istället för en rast på 10-15 min varje timme har arbetet emellanåt fortsatt under uppåt 2-3 timmar utan rast och sedan har en längre rast tagits. Anledningen till det har varit så beror på att gruppen varit så fokuserad och känt ett flyt i arbetet och därför upplevt att en rast enbart skulle störa som ett avbrott istället för att ge positiv paus i arbetet. Det har dock hänt att raster tagits lite då och då osynkroniserat inom gruppen, vilket bidragit till mindre störningsmoment för de som inte tagit rast vid samma tid. Till exempel har gruppmedlemmar gått iväg för telefonsamtal mitt under arbetstid, svarat på personliga mejl eller suttit med sociala medier, vilket emellanåt distraherat övriga i gruppen.

KAPITEL 6. ANALYS OCH DISKUSSION 28 Gällande frånvaro har alla i gruppen missat hela arbetsdagar någon gång under arbetsprocessen på grund av sjukdom, andra åtanganden vid sidan av kandidatarbetet eller personliga anledningar. Frånvaro skulle enligt gruppkontraktet meddelats i så god tid som möjligt genom om markera detta i den gemensamma kalendern. Dock så har det flera gånger hänt att gruppmedlemmar varit frånvarande längre stunder utan att meddelat gruppen innan, detta har resulterat i att det har varit svårt att ha en översikt om någon varit borta mer eller mindre och hur fördelningen i gruppen varit. Förseningar har inte hanterats som i kontraktet, vilket gruppen också reflekterade över och diskuterade mot slutet av projektet (i början av sprint 4 av totalt 5 sprints). Med andra ord har förseningar inte skrivits upp eller egentligen uppmärksammats, påpekats eller straffats på något sätt. Först efter denna diskussion började förseningar att dokumenteras i ett dokument på Google Drive. Övriga punkter i kontraktet har fungerat bra och följts. Gruppdynamiken har känts bra och roller har fungerat. Alla i gruppen har gjort sitt bästa utifrån egen förmåga, bett om hjälp när det behövts och samarbetat för att nå det gemensamma målet - den slutgiltiga produkten. 6.5 Källkritik Under första sprinten, sprint 0, lades mycket tid på att analysera och testa olika programmeringsspråk. Dart.js var till exempel ett språk som diskuterades inom gruppen, men gruppen valde att inte använda sig av språket i projektet. Gruppen valde att välja bort Dart.js som programmeringsspråk efter att ha läst tidigare års projektrapporter samt läst diskussionsforum på internet. Det är svårt att avgöra huruvida ett programmeringsspråk är bättre än ett annat beroende på forum och andras åsikter. Med tanke på att en projektrapport från tidigare år, med ett projekt liknande det tilldelade, ansåg att Dart.js endast hade tagit mycket tid och snarare saktat ner arbetet än underlättat det, så togs beslutet att inte använda Dart.js. Den hemsida och programmeringsforum som gruppen främst använt sig av är stackoverflow.com. Varje gruppmedlem har själv fått avgöra huruvida det som står i forumet är tillförlitligt eller ej, men eftersom det är ett forum med flera personer som ger sina åsikter till olika programmeringslösningar är ofta koden granskad av flera personer. Många frågar sig hur tillförlitligt Wikipedia är, med tanke på att vem som helst kan gå in och ändra och lägga till artiklar. Med tanke på att själva artiklarnas innehåll inte påverkat projektet tekniskt har det inte tagits hänsyn till denna form av källkritik. Det som dock kan tänkas vara problematiskt ur en källkritisk synvinkel är det faktum att om en artikel innehåller felaktiv information kan det innebära att dens relationer med andra artiklar inte stämmer. Detta innebär för projektets del att felaktiga resultat för relationer mellan artiklar skulle kunna dyka upp. Det är dock inget som projektgruppen kan påverka, då projektets mål är att visualisera just Wikipedias data. 6.6 Resultat Resultatet av projektet blev en webbapplikation i 2D som har två vyer att växla mellan. Applikationen utvecklades främst i JavaScript. När gruppen i början bestämde sig för att använda D3.js som ramverk för visualisering av webbsidan var förväntningarna att koden främst skulle skrivas i detta programmeringsverktyg. D3 har dock endast behövt användas för tidslinjevyn, då kartvyn använder sig av Mapbox.js som är ett annat bibliotek. I övrigt har koden främst skrivits i JavaScript. AngularJS har främst använts för att hantera navigationen mellan de olika vyerna och sidorna i webbapplikationen, vilket var som förväntat. Gruppen har till viss del parprogrammerat, men inte så mycket som tänkt från början. Det har oftast

KAPITEL 6. ANALYS OCH DISKUSSION 29 endast varit två stycken i gruppen som parprogrammerat, medan de övriga tre jobbat enskilt. Då det inte funnits någon färdig designprototyp från början av projektet har det varit svårt att utveckla en tilltalande produkt från början. Denna process, att skapa ett tilltalande utseende, påbörjades först under sprint 3. När detta påbörjades hade redan så pass mycket kod skrivits så att det blev svårt att ändra layouten och interaktionsdesignen på sidan. Om gruppen hade haft en färdig prototyp från början av projektet hade tiden för att försöka lösa de tekniska problemen för att få den önskade designen antagligen minskat. Detta problem fick lösas av hela gruppen, då problemet berörde kod som alla på något sätt varit delaktiga i. 6.7 Arbetet i ett vidare sammanhang I en värld med ett överflöd av information är det högst intressant hur all denna information kan tillgängligöras på nya sätt. Information om hur olika Wikipedia-artiklar är relaterade till varandra är svårt få tag i om man som användare inte är insatt i Wikipedias API, och även då är informationen inte särskilt lättillgänglig. Genom att göra ny information tillgänglig eller existerande information mer lättillgänglig kan förhoppningsvis nya insikter ges som på sikt kan leda till bättre kunskap och beslutsfattande. En risk med en applikation som denna är att information utelämnas utan att användaren görs medveten om detta. Vid sökning på en artikel utelämnas exempelvis i nuläget alla artiklar som har en tidsangivelse innan år 0. Detta kan leda till att felaktiga slutsatser dras och att felaktig information skapas där det egentligen inte finns någon information. Wikipedia får ofta inte användas i skolsammanhang då det inte räknas som en säker källa, vilket i vissa fall är synd då många artiklar har bra källor. Med webbapplikationen som skapats finns en potential att den kan användas i tex skolsammanhang. Med mer kunskap om hur Wikipedia fungerar och vidareutveckling på webbapplikationen skulle de tillsammans kunna skapa en ny typ av informationssökning [17].

Kapitel 7 Slutsatser I detta kapitel beskrivs slutsatser kring hur gruppen har arbetat och vad som fungerade bra och mindre bra. Det beskrivs även hur arbetet skulle kunna vidareutvecklats i framtiden och vilka förbättringar som kan göras med systemet. Kapitlet innehåller även svar på frågeställningarna som ställdes i kapitel 1.3. 7.1 Arbetssätt Det mesta av arbetet har genomförts med hela gruppen närvarande, vilket har sina för- och nackdelar. Bland fördelarna är att gruppmedlemmar närsomhelst kan ställa frågor till varandra, ta upp viktiga beslut till diskussion och hålla varandra uppdaterade om var i arbetsprocessen de olika delarna befinner sig. En nackdel är att mycket tid går åt till att diskutera saker som alla i gruppen kanske inte behöver och bör vara delaktiga i. Samtidigt som det är en fördel att kunna ställa frågor till alla i gruppen när som helst så stör varje fråga arbetsprocessen för den tillfrågade, vilket gör det svårt att hålla fullt fokus på det personen i fråga arbetar med. Detta var ett större problem i början av projektet än mot slutet då problemet hade addresserats genom att låta en eller två personer sköta uppgifter som tidigare hela gruppen hade tagit sig an tillsammans. Dessa kan sedan lägga fram ett förslag som resten av gruppen kan ge återkoppling på och välja att godta eller neka. 7.2 Framtida arbete I ett framtida projekt skulle man kunna inkludera fler språk då detta skulle kunna vara möjligt men i detta projekt har vi valt att avgränsa eftersom vi ville undvika eventuella problem. Koden är dock kommenterad på engelska så det skulle vara möjligt för internationella programmerare att fortsätta på produkten i ett vidare sammanhang. Utöver detta är det små justeringar i back-end som krävs för att göra engelska sökningar tillgängliga och lite mer ändringar i front-end som behöver göras eftersom all text i front-end utöver det som följer med API:t är skriven på svenska. Idag använder många personer sina smarta telefoner (smartphones) till det mesta. Därför är det en brist att webbapplikationen passar bäst för skärmar i storleken 11 tum och uppåt. En vidareutveckling är att skapa en mobilanpassad sida där visualiseringen är lika tydlig på en liten skärm som på en större. Det är vanligt att hemsidor har en mobilanpassad sida som är strukturerad och fungerar annorlunda än den man ser i en webbläsare på datorn, man tappar till exempel hover-funktioner (det vill säga att man sveper med musen) när man använder touch-skärm (pek-skärm). Det är inte så oväntat att något som passar på en stor skärm inte alls fungerar på en liten skärm med andra proportioner. 30

KAPITEL 7. SLUTSATSER 31 En annan vidareutveckling är att inkludera fler artiklar från Wikipedia, t.ex. de på andra språk. Det är också önskvärt att kunna visualisera ytterligare relationer och inte bara tid och plats, till exempel vilka kategorier olika artiklar tillhör. Avslutningsvis skulle en vidareutveckling av projektet vara att koppla applikationen till Wikipedias startsida. Till exempel hade det varit roligt att någonstans på startsidan ha en länk eller ikon som tar användaren till webbapplikationen. På så sätt kan användaren använda applikationen som ett komplement eller alternativ till Wikipedia, genom att få ut önskad information från Wikipedia-artiklar på det sätt som passar användaren bäst. Tanken är att visualiseringen av tid- och platsinformation ska ge ett mervärde och en tydligare bild av sammanhang mellan olika artiklar. 7.3 Frågeställningarna Nedan följer en sammanställning av svaren på de vetenskapliga frågeställningar som ställdes i början av projektet och som även togs upp i början av rapporten. Det finns en risk att all information inte kan visas på grund av för stor mängd data som ska hanteras. Hur kan data från Wikipedia filtreras utan att information går förlorad? Då inga större mängder data behöver hanteras i nuläget blev det aldrig relevant att filtrera den. Om applikationen i framtiden skulle hantera engelska artiklar istället för svenska skulle det vara en relevant fråga att ta upp igen. Då skulle en diskussion behöva föras kring hur det avgörs vad som är relevant för användaren och vad som kan filtreras bort. Hur bestäms vilken data som ska visualiseras och vilken som inte ska det? Efter efterforskningar av Wikipedias databas och vilken information som går att få tag på från en artikel samt möten med kund och handledare beslutades att plats och tidsinformation för en artikel skulle visualiseras. Även artikel-kategorier fanns uppe som förslag på vad som skulle visualiseras men efter efterforskningar i Wikipedias API beslutades att den tid det skulle ta att implementera något sådant låg utanför det här projektets räckvidd. Hur kan applikationen tillföra något som Wikipedia inte redan erbjuder användaren? Webbapplikationen har utvecklats med mer visuellt tilltalande designval än Wikipedia för att ge en bättre användarupplevelse. De två olika vyerna för tid och plats gör det lättare för användaren att förstå vilken relation olika artiklar har och uppmuntrar användaren att utforska nya ämnen som hen från början kanske inte tänkt söka på. Kommer det att behövas någon form av databas för egen lagring av data? Om så är fallet vilken data? Begränsningen av artiklar som visas gör att datamängden är relativt liten och därför behövs ingen databas, utan artiklarna hämtas direkt med hjälp av Wikipedias API. Några efterforskningar på hur en databas skulle implementeras och vilka data som skulle lagras har av samma anledning inte heller gjorts. Eftersom användaren själv avgör vad för data som ska visualiseras är det svårt att avgöra vad för data som skulle kunna sparas i en egen databas. Går det att lägga över delar av beräkningarna på en server för att avlasta klienten? Är detta önskvärt ur ett prestandaperspektiv? Eftersom de beräkningar som utförs är relativt lätta såg gruppen inte något behov av att lägga ned tid på att implementera en separat server för att utföra beräkningar. Några efterforskningar på hur en sådan lösning skulle se ut har av samma anledning inte heller gjorts.

Litteraturförteckning [1] AngularJS. AngularJS by Google. 2016. Hämtad: 2016-05-12 https://angularjs.org/ [2] API Sandbox. API sandbox. 2016. Hämtad: 2016-05-06 https://en.wikipedia.org/wiki/special:apisandbox [3] Astah. Astah Professional. Hämtad: 2016-05-09 http://astah.net/editions/professional [4] Bootstrap. Bootstrap - The world s most popular HTML, CSS, and JS framework for developing responsive, mobile first projects on the web. 2013-07. Hämtad: 2016-05-09 http://getbootstrap.com/ [5] Ulf Brodin. Flickr 2014-04-18. Hämtad: 2016-05-27 https://www.flickr.com/photos/ulfbodin/16601495486 [6] Codecademy. Learn to code interactively, for free. 2016. Hämtad: 2016-03-04 https://www.codecademy.com/ [7] Code School LLC. Learn by doing. 2016. Hämtad: 2016-03-07 https://www.codeschool.com/ [8] D3. D3: Data-Driven Documents. 2015. Hämtad: 2016-05-11 https://d3js.org/ [9] Maximiliano Firtman. HTML5 compatibility on mobile and tablet browsers with testing on real devices. 2015-09-17. Hämtad: 2016-06-01 http://mobilehtml5.org/ [10] Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts. 1997. Refactoring: Improving the Design of Existing Code. New release 2002. The Addison - Wesley Object International Series. [11] GitHub, Inc. Where software is built. 2016. Hämtad: 2016-05-12 https://github.com/ [12] Google. Hämtad: 2016-05-12 https://www.google.se/intl/sv/drive/ [13] Mapbox. Mapbox: the next generation of map design. Hämtad: 2016-05-12 https://www.mapbox.com/ [14] Mamp. MAMP: My Apache - MySQL - PHP Hämtad: 2016-05-12 https://www.mamp.info/en/ [15] Shari Lawrence Pfleeger och Joanne M. Atlee, Software Engineering, Fourth Edition, International Edition, Pearson 2010 [16] Ken Schwaber och Jeff Sutherland. The Scrum GuideTM The Definitive Guide to Scrum: The Rules of the Game. Scrum.Org and ScrumInc. 2013-07. Hämtad: 2016-05-05 http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf [17] Tracy Polk, Worcester Preparatory School, Melissa P. Johnston, University of Alabama, Stephanie Evers, University of South Alabama Wikipedia Use in Research: Perceptions in Secondary Schools 2015. Association for Educational Communications and Technology 32

LITTERATURFÖRTECKNING 33 [18] Slack. Hämtad: 2016-05-05 https://slack.com [19] Sublime, 2013-07-08. Hämtad: 2016-05-05 http://www.sublimetext.com/2 [20] Trello, 2016. Hämtad: 2016-05-05 https://trello.com/ [21] W3C W3C Hämtad: 2016-05-23 https://validator.w3.org/

Bilaga A Gruppkontrakt Introduktion Ett kontrakt för grupp H (Wikipedia) som ett hjälpmedel för hur gruppen ska arbeta tillsammans under kandidatprojektet våren 2016. Då gruppkontraktet skrevs fick varje gruppmedlem också meddela övriga i gruppen om hur hen vill få kritik, hur hen beter sig när hen är trött/hungrig samt övriga åtaganden som tar upp tid parallellt med kandidatprojektet. Möten Ett möte hålls varje morgon, med akademisk kvart, 8:15. Ett kortare möte hålls i slutet av varje arbetsdag, ett avstämningsmöte. Ett möte hålls varje fredag eftermiddag för ett överblicksmöte, hur veckan gått och hur vi ligger till i planeringen. Detta möte protokollförs och läggs upp på driven. Extramöten kan sättas in om så behövs. Plats för möte bokas och meddelas en dag i förväg. I största möjliga mån bokas salar i Täppan. Samtliga protokoll läggs upp på Google Drive. Vid varje möte skall en runda genomföras där alla i gruppen meddelar vad man gjort sedan sist. Mötesregler Beslut Elektronisk utrustning ska hållas ljudlösa och ska ej användas på ett störande sätt under mötet. Vi bör eftersträva att möten hålls på ungefär en halvtimme, längre vid behov. Vill man ha en paus i mötet säger man till. Vid planerade längre möten bör det vara en paus på 10 minuter efter en timme. Är man tyst håller man med i det som sägs. Använd sunt förnuft. Beslut diskuteras fram i första hand. 34

BILAGA A. GRUPPKONTRAKT 35 Beslut ska fattas i tydligast möjliga mån. Tiger man räknas det som samtycke. Bör helst fattas när alla är närvarande. Arbetsregler/förhållanden Det är okej med en rast på 10-15 min per timme. Gruppen bör i största möjliga mån arbeta tillsammans på samma plats, i skolan, efter bestämda tider (dessa står i den gemensamma kalendern). Parprogrammering i största möjliga mån. Inte jobba på egen hand, utan samtycke från de andra. Bör meddelas vad man i så fall tänker jobba med. Markera din arbetsuppgift på Trello. Ta inte någon annans arbetsuppgift, men hjälp gärna till. Gå inte in och pilla! Frånvaro Vid frånvaro ansvarar man för att läsa igenom protokoll och hålla sig uppdaterad. Möten börjar på utsatt tid oberoende av allas närvaro. Planerad frånvaro skrivs in i den gemensamma kalendern, ex Hanna borta/frånvarande. Meddela om oplanerad frånvaro så snabbt som möjligt. Vid oanmäld försening skrivs namn och antal försenade minuter upp i ett dokument på drive. Minst uppskrivna försening är 5 minuter. Gruppnormer Alla ska göra sitt bästa/utföra arbetet på bästa möjliga sätt. Man ska be om hjälp i god tid av de andra om man inte anser sig kunna klara av uppgiften ensam. Problem som uppstår ska diskuteras. Kritik bör alltid vara konstruktiv samt påtalas så snart som möjligt. Alla ger varandra beröm och feedback. Vid kontraktsbrott ska kontraktbrottet tas upp till diskussion för att därefter bemötas på bästa sätt.

Bilaga B Kravspecifikation Hemsidans startsida ska ha ett sökfält där användaren skriver in ett eller flera ord. Från hemsidans startsida ska användaren även kunna göra en slumpad sökning, likt Wikipedias random-funktion. Sökresultatet visualiseras i två skilda vyer, en där artiklar med en platsangivelse visualiseras och en där artiklar med tidsangivelse visualiseras. Användaren skall efter att en sökning är gjord kunna växla mellan dessa två vyer. I båda vyerna finns längst ned en statisk tidsaxel med logaritmisk skala som användaren kan interagera med för att begränsa de artiklarna som visas med avseende på tid. Det ska tydligt framgå på denna tidslinje mellan vilka årtal användaren valt att visa sitt sökresultat. I båda vyerna visas artiklarna i form av prickar/cirklar. Huvudartikeln representeras av en något större prick/cirkel än resten av artiklarna. Cirklarna som representerar artiklar har olika färg beroende på vilken kategori de tillhör. När användaren klickar på en artikel kommer en liten faktaruta upp med kort information om artikeln. Likt en pratbubbla. Faktarutan innehåller: 1. Artikelns rubrik 2. Några meningar från första textstycket i artikeln 3. En knapp för att välja denna artikel som ny huvudartikel. 4. En knapp för att utöka faktarutan och läsa mer om artikeln, utan att byta sida. Faktarutan dyker vid en ny sökning automatiskt upp ovanför huvudartikeln som sökningen resulterar i. Vid byte av vy sker en animation där prickarna som representerar artiklarna åker till sin nya position i den nya vyn. En knapp/sökruta skall finnas i båda vyerna där användaren kan göra en ny sökning utan att behöva gå tillbaka till startsidan. 36

BILAGA B. KRAVSPECIFIKATION 37 I utkanten av skärmen finns ett område där artiklar som saknar tids- eller platsanknytning finns samlade, tydligt avskilda från artiklarna ute i den aktuella vyn. Dessa artiklar har samma funktionalitet som resterande artiklar. Om systemet tar lång tid på sig ska återkoppling ges till användaren i form av någon slags laddningssymbol. Det ska finnas en logotyp som är lätt att känna igen, den ska ha tydlig koppling till Wikipedia. Sidan ska ha ett inspirerande gränssnitt. Om användaren hittar ett intressant sökresultat ska den kunna dela detta, exempelvis genom en länk. Om sökningen ska presenteras i relation till plats: Artiklar med anknytning till en plats visas på en världskarta på sin respektive plats. Mellan den sökta artikeln och de relaterade artiklarna ska en linje synas. Användaren kan zooma in och ut på kartan med hjälp av scrollhjulet. Zoomnivån på kartan anpassas vid sökning efter artiklarnas position så att alla artiklar är jämnt fördelade över skärmytan. Om man klickar på en annan artikel kommer en ny textruta upp med information om den aktuella artikeln och den gamla textrutan försvinner. När man markerar en linje med muspekaren ska relationen mellan artiklarna presenteras, exempevis hur de länkar till varandra. Om sökningen ska presenteras i relation till tid: Artiklar visas på en dynamisk tidslinje som på samma sätt som den statiska tidslinjen har en logaritmisk skala. Den dynamiska tidslinjens minsta och största värde beror på vad användaren har satt för gränser på den statiska tidslinjen. Genom musen går en lodrät linje för att tydligt visa användaren vilket år/datum musen befinner sig på.

Bilaga C Stories Stories som rör ägaren: Som ägare av systemet vill jag att all kod ska vara väl dokumenterad. Som ägare av systemet vill jag att all kod ska vara testad. Stories som rör kunden: Som kund vill jag att hemsidan ska vara webbaserad. Som kund vill jag att en tydlig prototyp ska finnas av slutprodukten. Som kund vill jag att applikationen ska ha en tydlig startsida. Som kund vill jag kunna söka på alla Wikipedas svenska artiklar. Som kund vill jag få data för en artikel presenterad i två olika vyer - en beroende på tid och en beroende på plats. Som kund vill jag kunna välja om jag vill ha data visad beroende på relation i tid eller plats, det vill säga kunna växla mellan applikationens två olika vyer. Som kund vill jag i applikationen kunna se relationen mellan olika artiklar. Som kund vill jag att artiklar på tidslinjen visas i kronologisk ordning. Som kund vill jag kunna reglera tidsintervallet som styr vilken data som visas i tidslinjevyn. Som kund vill jag kunna zooma in och ut på kartan i kartvyn. Som kund vill jag ha möjligheten att kunna läsa en hel artikel. Som kund vill jag kunna läsa information om relaterade artiklar, inte bara den artikel jag sökt på från början. Som kund vill jag kunna ändra min sökning, det vill säga göra en ny sökning efter att en sökning redan gjorts. Stories som rör användaren: Som användare vill jag ha en lättnavigerad och tydlig webbsida. 38

BILAGA C. STORIES 39 Som användare vill jag ha en visuellt tilltalande webbsida. Som användare vill jag få återkoppling på det jag gör på webbsidan. Som användare vill jag kunna gå tillbaka till en föregående sida i applikationen.

Bilaga D Förundersökning I början av projektet utfördes en förundersökning med hjälp av ett webbformulär och i denna bilaga visas resultatet från förundersökningen. Webbformuläret hade även frågor med fritextsvar, dessa har inte tagits med i den här grafiska sammanfattningen. Figur D.1: Åldersfördelningen bland de personer som deltog i förundersökningen. 40

BILAGA D. FÖRUNDERSÖKNING 41 Figur D.2: Enkätsvar gällande hur ofta personerna som deltog i förstudien besöker Wikipedias hemsida. Figur D.3: Enkätsvar från förundersökningen gällande om personerna som deltog i studien någon gång besökt Wikipedia utan att veta vad hen ska söka på.

BILAGA D. FÖRUNDERSÖKNING 42 Figur D.4: Enkätsvar från förundersökningen gällande om personerna som deltog i studien någon gång använt Wikipedias randomize-funktion. Figur D.5: Enkätsvar från förundersökningen gällande i vilket syfte personerna som deltog i studien använder Wikipedia. Figur D.6: Enkätsvar från förundersökningen gällande om personerna som deltog i studien brukar använda sig av länkarna i Wikipedias artiklar.

Bilaga E Systemarkitektur I figuren nedan visas varje JavaScript-fil som ett block där alla funktioner som finns i filen är listade. Figur E.1: En översikt över samtliga JavaScript-filer och dess funktioner. 43

BILAGA E. SYSTEMARKITEKTUR 44 Figur E.2: Objektet temparticle och dess variabler.

Bilaga F Personligt bidrag Johanna Westberg Johanna har varit ansvarig för testning och har utfört tester manuellt på för att hitta buggar. Hon har tillsammans med Hanna och Albin arbetat med back-end och hämtat data med Wikipedias API. Hon har utfört användartester tillsammans med Hanna och gjort en del implementationer i CSS:en. Albin Bergström Albin har under projektet arbetat med back-end och hämtning av data. Han har även jobbat med front-end på de två vyerna och sammanfogat de olika delarna för att kunna visualisera datan som hämtats. Sarah Fosse Sarah har arbetat med de funktioner som finns i båda vyerna, såsom popup-rutan, modal-rutan där artikeln visas, hover-funktioner och funktionaliteten bakom slumpknappen. Hon har arbetat med visualiseringen på både tidslinjen och på kartan. Hon har även implementerat CSS och strukturerat sidan med Bootstrap. Hanna Johansson Hanna har tillsammans med Johanna och Albin arbetat med back-end och hämtat data med Wikipedias API. Hon har även utfört användartester tillsammans med Johanna, sammanställt dessa och även gjort vissa implementationer i CSS:en. Hanna gjorde UML-diagrammen i Astah. Sara Martin Sara har under projektet varit ansvarig för designen. Hon har skapat prototyper och sedan implementerat designen på hemsidan med CSS, HTML och JavaScript. Hon har även gjort så att förstasidan är en egen index-fil och kartvyn och tidslinjen som användaren kommer till sedan är dynamiska. 45

Bilaga G Applikationens utseende vid genomförandet av användartesterna I den här bilagan presenteras tre bilder över hur de tre olika vyerna i applikationen (startsida, tidslinjevy samt kartvy) såg ut då användartesterna i sprint 5 genomfördes. Vid genomförandet fungerade inte informationsknappen och det var heller inte möjligt att gå tillbaka till startsidan från tidslinjevyn eller kartvyn. Figur G.1: Startsidans utseende vid användartestets utförande. 46

BILAGA G. APPLIKATIONENS UTSEENDE VID GENOMFÖRANDET AV ANVÄNDARTESTERNA47 Figur G.2: Tidslinjevyns utseende vid användartestets utförande. Figur G.3: Kartvyns utseende vid användartestets utförande.

Bilaga H Resultatet av användartesterna I slutet av projektet utfördes användartester på elva slumpvis utvalda personer i åldrarna 21-24 år. Alla testpersoner var studenter vid Linköpings Universitet, från fyra olika utbildningar. De fick navigera fritt och tänka högt, men även svara på specifika frågor om applikationen gällande dess funktionalitet och design. Resultatet av användartesterna presenteras i den här sammanfattningen. H.1 Testpersonerna Figur H.1: Ålder på testpersonerna som deltog i användartestet. 48

BILAGA H. RESULTATET AV ANVÄNDARTESTERNA 49 Figur H.2: Utbildningar representerade bland testpersonerna i användartestet. H.2 Ikonerna Tabell H.1: Testpersonernas åsikter om ikonen för kartvyn, innan de fick reda på vad den skulle symbolisera. Ikonen för kartvyn: Vad tror du att den här ikonen står för? Platsinformation. En karta över var någonting befinner sig eller kommer ifrån. Någonting om plats på jorden. Sortera efter plats. Plats. Man lär förmodligen komma till en plats eller en stad. Plats. Var någonting befinner sig. Vart artiklarna kommer ifrån. Förmodligen kommer man till en karta, kanske en plats om man sökt på en plats, annars kanske man hamnar på platsen man är på. Antingen var man själv befinner sig eller var artikeln är. Den har någonting med plats att göra. Den har med min plats att göra,eller regionen jag vill ha artiklar ifrån.

BILAGA H. RESULTATET AV ANVÄNDARTESTERNA 50 Tabell H.2: Testpersonernas åsikter om ikonen för tidslinjevyn, innan de fick reda på vad den skulle symbolisera. Ikonen för tidslinjevyn: Vad tror du att den här ikonen står för? Tidsangivelse Kalender. Tid. När något hänt. Ser att det är en kalender och att det representerar tid, men förstår inte vad den ska ge/vad som ska hända om man klickar på den. Man kan sortera i tid. Det är en kalender. Den representerar tider. Kalender Kalender Information om när artikeln skrivits. Någonting med en kalender, kanske att man kan lägga till en händelse. Har att göra med när artikeln är publicerad. H.3 Första intryck Figur H.3: Åsikter som framkom vid testpersonernas första intryck av sidan. Tabell H.3: Testpersonernas konstruktiva kritik om startsidan. Konstruktiv kritik om startsidan Använd inte ordet Wikipediaartikel, hellre Wikipedia-artikel eller artikel på Wikipedia" Inte snyggt när det är så stort mellanrum mellan W och ikinspire Det ser inte bra ut när allt står i versaler Info-knappen, eller någon typ av information, borde finnas på startsidan Sökfältet borde vara högre upp och mer centrerat på skärmen/startsidan Sökfältet skulle kunna vara mycket större och ta mer plats Ha med lite mer info på förstasidan, om syfte och hur sidan kan användas.

BILAGA H. RESULTATET AV ANVÄNDARTESTERNA 51 Figur H.4: Testpersonernas första intryck av kartvyn samt konstruktiv kritik.

BILAGA H. RESULTATET AV ANVÄNDARTESTERNA 52 Figur H.5: Testpersonernas första intryck av tidslinjevyn samt konstruktiv kritik.

BILAGA H. RESULTATET AV ANVÄNDARTESTERNA 53 H.4 Design Figur H.6: Åsikter om färgvalet gällande applikationens design. Figur H.7: Övergripande åsikter om applikationens design. Tabell H.4: Testpersonernas åsikter om designen. Vad anser du om designen? (Förbättringsförslag) Man borde komma till startsidan när man klickar på loggan i headern. Titelrutan (över sökt artikel) borde vara mindre/placeras om. Listan för relaterade artiklar borde vara mindre. Tidslinjen som reglerar urvalet borde vara mindre. Ikonen för tidslinjevyn skulle kunna göras tydligare, inte så statisk. Vore kanske bra med olika symboler istället för färger för markörerna. Loggan i headern ser inte centrerad ut. Skulle vilja placera vy-ikonerna bredvid info-knappen. Hade önskat att man kunde gömma footern med färgförklaringarna. Hade önskat att sökrutan var till höger i headern eller centrerad.

BILAGA H. RESULTATET AV ANVÄNDARTESTERNA 54 H.5 Övrigt Figur H.8: Svarsfrekvens på frågan om testpersonerna skulle tänka sig att använda vår applikation. Tabell H.5: Testpersonernas åsikter gällande vad vår applikation har för fördelar gentemot Wikipedia. Fördelar med vår applikation gentemot Wikipedia? Roligt att kunna se relationerna mellan artiklar. De olika vyerna ger mer än enbart en lång text som på Wikipedia. Applikationen är lättare att använda om man vill hitta inspiration. Applikationen ger en annan dimension till hyperlänkar. Applikationen gör det lätt att få ut övergripande information. Kartan och tidslinjen fungerar som sammanfattningar, vilket är bra. Applikationen är mer lekfull och roligare. Applikationen är mycket mer visuellt tilltalande än Wikipedia. Det är lättare att söka sig vidare i applikationen. Man får en bättre helhetsuppfattning i applikationen än på Wikipedia. Användbar om man vill veta relationer som inte är så uppenbara. Tabell H.6: Övriga synpunkter och åsikter om applikationen. Övriga synpunkter Bra med en laddningssymbol medan data laddas. Bra att det blir en bock när laddningen är slutförd. Startsidan är lite för tom. Det vore bra om man först fick upp information om huvudartikeln, före man ser de relaterade artiklarna. Det hade varit kul med en random-knapp som på Wikipedia. Man vill att sökfältet ska rensas. Det är bra att man bara får läsa första paragrafen först, sedan kan välja att läsa hela artikeln. Det ger en kortfattat överblick. Ta bort stark relation"i färgbeskrivningen för den gröna markören. Det vore bra med mer information om applikationen på startsidan.