Twiz. En webbapplikation för geografisk visualisering av attityd emot populära ämnen på sociala mediet Twitter

Transkript

1 Linköpings universitet Insitutionen för teknik och naturvetenskap Kandidatarbete Medieteknik Vårterminen 2017 LiU-ITN-TEK-G--17/016--SE Twiz En webbapplikation för geografisk visualisering av attityd emot populära ämnen på sociala mediet Twitter Elin Lager Ola Steen Erik Rudhe Patrik Veges Jasmine Karlsson Sovanny Huy Nikkilä Examinator: Karljohan Lundin Palmerius Linköpings universitet SE Linköping ,

2 Sammanfattning Denna rapport beskriver och redogör utvecklingen av en webbapplikation som visualiserar användandet av Twitter. Projektet gjordes på uppdrag av Visualiseringscenter C och utvecklingsteamet bestod av sex stycken studenter vid Linköpings Universitet som en del av kursen Medietekniskt kandidatprojekt. Under utvecklingsprocessen användes agila metoder som följer Scrums grunder. Syftet med projektet var att skapa en interaktiv visualisering av information från användare på Twitter. Innehåll, geotaggar och meta-information skulle användas för att skapa ett underlag för visualisering baserat på spatial och temporal struktur. Projektet var tänkt att kunna ställas ut på Visualiseringscenter C. Projektet bestod av 6 sprinter och utfördes under 13 veckor. Under denna period ingick rapportskrivning som började under sprint 4. En sprint noll hölls i början av projektet för att ge tid åt efterforskning och utformning av en idé. Idén blev att applikationen skulle fungera med touch, och att applikationen skulle ha en världskarta som central del i användargränssnittet. Där skulle Twitter-data visualiseras geografiskt. Det skulle även finnas en tidslinje för att se Twitter-data från bakåt i tiden. För att hämta Twitter-data har Twitters egna API:er använts, som är gratis och tillgängliga för alla. För att skapa en interaktiv karta har API:t Mapbox använts. Ett API för analys av text användes för att bedöma attityd på Twitter-inläggen. Applikationen delades upp i en front end-del och en back end-del, där hämtningen och filtreringen av tweets sker på back end-delen. Front end-delen skrevs i Javascript och back end-delen i Python. Projektet resulterade i en applikation som består rent grafiskt av en världskarta och en sidopanel som agerar som meny. Användaren kan i menyn välja olika ämnen som är trendande på Twitter för tillfället. När ett ämne har valts startar ett flöde av Twitter-inlägg, som visas geografiskt som markörer på världskartan. Markörerna har olika färg beroende på innehållets attityd, och då användaren trycker på en markör visas det tillhörande Twitter-inlägget. Användaren kan också dra i en tidslinje för att endast visa tweets från en viss tidpunkt. i

3 Innehåll Sammanfattning Figurer Tabeller Typografiska konventioner i v vi vii 1 Inledning Bakgrund Syfte Frågeställning Avgränsningar Relaterat arbete One million tweets map Sentiment ordanalys Utvecklingsproccess Tidsplan Scrum Sprint noll Sprint Gruppkontrakt och ansvarsroller Dokumentation och versionshantering Arbetssätt Kvalitetsanalys och testning Användartest Kundkontakt och kravhantering Schema Expertmöten ii

4 INNEHÅLL iii 4 Tekniskt arbete Systemarkitektur Klasser Informationsflöde Utvecklingsmiljöer Twitters API REST API Streaming API Widgets-js Sentiment Text Analytics API GeoJSON Mapbox Användargränssnitt Resultat 21 6 Analys och diskussion Metod Användandet av Scrums grunder Dokumentation Versionshantering och testning Parprogrammering och koddesign Kravhantering Schema Kundkontakt Användartester Motgångar Begränsningar Touch-interaktion Namnet Twiz Val av språk Källkritik Resultat Arbetet i ett vidare sammanhang Slutsatser 30 Litteraturförteckning 32

5 INNEHÅLL iv A Gruppkontrakt 34 B Individuellt bidrag 36 C Resultat användartest 38

6 Figurer 3.1 Gantt-schema för projektet Sprint-schema för projektet Diagram över informationsflödet då sidan startas Diagram över informationsflödet då användaren väljer ett ämne Ett exempel på ett JSON-objekt som returneras när ett tweet analyseras med Text Analytics API. Tweetet anses vara positivt och skrivet på engelska Ett exempel på ett GeoJSON-objekt från ett tweet hämtat från Norrköping Första skissen på en design Första versionen av gränssnittet Startsidan från en version av gränssnittet från mitten av projektet Version av gränssnittet från mitten av projektet där ett ämne valts och ett tweet klickats på En version av applikationen där en sid-meny lagts till Slutversionen av applikationen Innan tweets har kommit visas en laddnings animation Del av karta som visar tweets som är positiva, negativa och neutrala Visar ett tweet på kartan Informationsruta som beskriver hur applikationen används Meny som visar vilka trender som är aktuella just nu v

7 Tabeller 1 Typografiska konventioner i rapporten vii 2 Ofta användna förkortningar vii 3 Ofta användna termer vii A.1 Övriga aktiviteter hos gruppmedlemmarna vi

8 Typografiska konventioner Utseende Kursiv text Courier Tabell 1: Typografiska konventioner i rapporten Förklaring Används då engelska termer nämns första gången. Används vid namn på funktioner, objekt eller klasser som används i koden. Tabell 2: Ofta användna förkortningar Förkortningar Förklaring API Application Program Interface CSS Cascading Style Sheets HTML HyperText Markup Language IDE Integrated Developer Environment JSON JavaScript Object Notation REST Representational State Transfer Termer Tweet Trendande Widget Tabell 3: Ofta användna termer Förklaring Inlägg på det sociala mediet Twitter. Betecknas som tweets i plural, men böjs annars enligt svenska skrivregler. En term som används för att beskriva en ökning i användning eller förekomst. Kommer ifrån engelskans trending. Engelsk term för grafiskt användargränssnittkomponent [1], används för att visa information från en annan applikation i form av till exempel knappar, ikoner eller dialogrutor [2]. vii

9 Kapitel 1 Inledning Detta är ett projekt som är en del av kursen Medietekniskt kandidatprojekt vid Linköpings Universitet. Kunden för projektet är Visualiseringscenter C i Norrköping, som är ett konsortium av olika företag. Centret har visualiseringsforskning som utgångspunkt och har bland annat forskning, utställningar och utbildning som del av deras verksamhet. Tanken med projektet är att det ska kunna vara utställningsmaterial för centret och visas på en av deras touch-skärmar, som är runt 25 tum stora. 1.1 Bakgrund Användandet av sociala medier ökar för varje dag som går och bland de största medierna finns den sociala nätverkstjänsten Twitter. Twitter fungerar som en mikroblogg där användare bland annat kan skriva meddelanden, så kallade tweets, som ej får överskrida 140 tecken. I dagsläget skrivs omkring 6000 twitterinlägg varje sekund runt omkring i världen [3]. Användaren väljer dock själv vilka personer den vill följa, vilket kan leda till att hen framförallt följer och gillar personer och sidor med liknande värderingar och tankesätt. Detta kan skapa en falsk bild över vad omgivningen egentligen har för ståndpunkt om ett ämne, eftersom användaren hamnar i en social bubbla. I slutprodukten ska användaren kunna se vad Twitter-användare utanför deras sociala bubbla säger om ett visst ämne. 1.2 Syfte Målet med projektet är att skapa en interaktiv webbapplikation som visualiserar information från användare på Twitter. Innehåll, taggar, geotaggar och meta-information används för att skapa ett underlag för visualisering baserat på spatial och temporal struktur, samt baserat på innehåll. Det ska genomföras genom att visualisera datan med en världskarta som underlag. Visualiseringen ska också kunna visa vilken attityd personer har till olika diskussionsämnen. Målgruppen till visualiseringen kommer vara besökare på Visualiseringscentret, främst i åldrarna 12 till 20 år. 1.3 Frågeställning Hur kan produkten designas så att den tillför något som Twitter inte redan erbjuder? Med tanke på mängden data som kommer hanteras, hur ska systemarkitekturen se ut för att optimera visualiseringen? 1

10 KAPITEL 1. INLEDNING 2 Vilka API:er är passande för utveckling av produkten? Hur kan applikationen designas för att anpassas till en utställning på Visualiseringscentret C? 1.4 Avgränsningar På grund av begränsningar i åtkomsten av data från Twitters API finns bara möjlighet att hämta tweets skrivna de senaste sju dagarna. Det finns tjänster för att hämta tweets från längre bak i tiden, men eftersom dessa medför en stor kostnad kommer de inte användas i projektet. Eftersom applikationen är tänkt att vara ett utställningsföremål och presenteras på en touch-skärm kommer ingen tid läggas på att anpassa den till mindre skärmar, som till exempel mobiltelefoner.

11 Kapitel 2 Relaterat arbete Nedan följer information om relaterade arbeten till applikationen. 2.1 One million tweets map Under efterforskningarna inför projektet hittades många tidigare Twitter-visualiseringar som gjorts. Utifrån dessa kunde gruppen få idéer om vad som är möjligt att genomföra. One million tweet map är en av visualiseringarna som inspirerade gruppen till sitt arbete. Sidan använder sig av Twitters streaming API för att visa den senaste miljonen tweets på en karta i realtid [4]. 2.2 Sentiment ordanalys Sentiment ordanalys som används i större delen av projektet är framtagen av Vivek Narayanan, Ishan Arora och Arjun Bhatia, och är en modifierad version av en Naiv Bayesiansk-modell som tränats med hjälp av filmrecensioner från hemsidan IMDB (Internet Movie Database) [5]. Den Naiv Bayesianskamodellen är en inlärningsmetod för klassificering [7]. Modellen bygger på Bayes sats och antagandet att datan är oberoende av varandra. Sentiment använder sig utav Laplace Smoothing för att jämna ut det statistiska resultatet. Utan detta hade det varit omöjligt att klassificera ord som inte fanns med vid träningen. Vilket hade lett till att påverkan av ett stort antal ord hade ignorerats. Den kan även hantera nekande ord i kombination med ord som vanligtvis hade klassificerats som positiva eller negativa och kan förstärka sannolikheten för en viss klassificering om stärkande adjektiv används ihop med ord som är positiva eller negativa [5]. Alla dessa egenskaper hos ordanalysen förstärker sannolikheten att ett tweet klassificeras korrekt. Detta verktyg valdes då det fanns vetenskaplig grund bakom dess funktionalitet och ett Python-baserat demo med tillgänglig kod som visar hur det kan användas. 3

12 Kapitel 3 Utvecklingsproccess I detta kapitel beskrivs hur gruppen har lagt upp och strukturerar arbetet. 3.1 Tidsplan Utvecklandet av produkten gjordes under en period på 13 veckor. Det bestämdes att dela in projektet i olika aktivitetsfaser för att få en övergripande bild över hur projektet skulle genomföras. Planeringen illustrerades i ett Gantt-schema där det presenteras när de olika aktiviteterna kommer att påbörjas, arbetas på och avslutas, se Gantt-schema i Figur 3.1. Figur 3.1: Gantt-schema för projektet. Planen var att efter sprint noll skulle tre faser implementeras samtidigt: implementering av front end, implementering av back end och testning. Under perioden mellan vecka 10 och 18 skulle utveckling av produkten pågå och en kontinuerlig testning av systemet skulle utföras så att produkten och programkoden skulle uppnå en viss kvalité. Det anlades även en åtgärdningsperiod för att korrigera eventuella problem som kunde upptäckas i det senare stadiet av utvecklingen. Det åsidosattes även tid för framtagning av projektrapporten i slutet av arbetsperioden, dock kunde utvecklingen komma att fortsätta om gruppen kände att det skulle vara behövligt. 4

13 KAPITEL 3. UTVECKLINGSPROCCESS Scrum Det arbetades på projektet enligt den agila utvecklingsmetodiken Scrum. Gruppen bestämde att dela in perioden i sex sprinter där varje sprint pågick i två veckor eftersom det passade tidsramen. Se fullständigt sprint-schema i Figur 3.2. Genom att hålla sprinterna korta tilläts indelning av produkten i mindre delar. Inför varje sprint hölls ett planeringsmöte där det diskuterades vad som skulle göras, hur det kunde utföras och hur lång tid det uppskattades att ta. Beskrivningarna var inte detaljerade utan var mest ett stöd för att kunna påbörja utvecklandet. Under varje sprint hölls också korta möten i början av varje dag. Under dessa möten redovisade gruppmedlemmarna vad som utfördes dagen innan och vad de planerade att göra under dagen. Dessa möten dokumenterades ej då deras huvudsakliga syfte var att se till så att alla gruppmedlemmar hade en uppfattning om hur arbetet gick. I slutet av en sprint hölls även ett retrospektiv där gruppen diskuterade hur arbetet hade gått och granskade koden tillsammans för att finna eventuella förbättringar som kunde göras inför nästa sprint. Figur 3.2: Sprint-schema för projektet Sprint noll Under sprint noll undersöktes det vilka liknande projekt som gjorts tidigare för att finna inspiration om vad som kunde göras inom området visualisering av sociala medier. Då kunden inte hade givit en konkret produktidé, lades större del av tiden på att diskutera i gruppen om vad som kunde göras, hur det kunde göras och om det var genomförbart med de begränsningar som fanns. När idén presenterats för kunden och den blivit godkänd påbörjades efterforskningar om vilka tekniska verktyg och API:er som kunde användas för att utveckla produkten. Det ägnades tid åt att undersöka ifall det skulle behövas användas verktyg som kostar eller om det räckte med tillgängliga gratisverktyg. I detta stadiet var det bestämt att använda Twitter som socialt medium och därför undersöktes mediets egna API:er som tillåter utvecklare att hämta och hantera data från deras databas. Tweepy valdes som verktyg för att hämta data från Twitter eftersom dess funktionalitet var väldokumenterad [6]. Då det i detta stadiet var bestämt att applikationen skulle presentera geografisk data bestämdes det att Mapbox skulle användas för detta ändamål. Verktyget har funktionalitet som stämde överens med vad projektgruppen hade för vision av hur systemet skulle se ut och fungera. Ovannämnda API:er kommer beskrivas mer ingående i kapitel 4.

14 KAPITEL 3. UTVECKLINGSPROCCESS Sprint 1-6 Sprint 1: Under den första sprinten hölls ett möte där det diskuterades hur uppdelningen av arbetet skulle utföras. Det bestämdes att projektgruppen skulle dela in sig i grupper om två eftersom det skulle hjälpa alla att komma igång med arbetet. Ett par påbörjade utveckling på back end-delen av systemet för att hämta tweets i realtid. Tester med en förutbestämd sökterm utfördes för att säkerställa hur Tweepy skulle kunna integreras i applikationen. Samtidigt jobbade två andra gruppmedlemmar på applikationens design och tog fram ett preliminärt användargränssnitt. Detta gjordes för hand genom att skapa anteckningar över vad som behövs vara med och skisser över hur det skulle kunna se ut. De sista två gruppmedlemmarna inledde arbetet med API:t Mapbox. Slutprodukten för denna sprint var ett skript som hämtar data från twitter, en applikation med en karta som har grundläggande användarinteraktion och ett koncept för användargränssnittets design. Under denna sprint hölls det också ett möte med elever från kursen TNM100 - Strukturerade metoder för användarupplevelser, hädanefter kallade UX-gruppen. Under mötet diskuterades projektidén samt hur arbetet skulle genomföras gällande användargränssnittet. Sprint 2: I början av sprint 2 skedde en rotation av sysselsättning. Detta gjordes för att alla gruppmedlemmar skulle få insikt i hur alla delar av programmet fungerar. Under denna sprint användes data, som hämtats med hjälp av back end-sidan och sparats i en fil, för att skapa och placera ut markörer på kartan. Anledningen till varför data sparades i en fil var för att ingen direkt koppling mellan back end och front end hade implementeras än. På back end-sidan gjordes ett byte från API:et Tweepy till Twython. Detta med anledning av att det hittades dokumentation om Twython som var lättare att följa vilket underlättade arbetet [8]. Ändringar gjordes till användargränssnittet som skiljde sig från första utkastet. Istället för att ha en fast meny skapades objekt som flöt omkring över kartan, som användaren kunde förflytta över skärmen. Slutprodukten i sprinten var en applikation med ett omdesignat användargränssnitt och möjligheten att presentera Twitter-data geografiskt. Sprint 3: Eftersom det inte fanns någon koppling mellan de olika delarna i systemet behövdes ett sätt att få front end och back end att kommunicera. Det lades ner mycket tid på att efterforska på hur kommunikationen skulle skötas, eftersom gruppen inte hade så mycket tidigare erfarenhet inom ämnet. Lösningen som användes var ramverket Flask. En startsida implementerades där användaren kunde välja ett trendande ämne att visualisera tweets utifrån. Funktionalitet för ordanalys av tweets lades till på back end-delen med API:t Sentiment. Syftet med analysen var att den skulle avgöra ifall en tweet är positiv, neutral eller negativ, detta markeras med en tillhörande färg på kartan. Under sprinten uppstod problem efter implementationen av kommunikation mellan back end och front end för några av medlemmarna i gruppen. Det lades ner mycket tid för att lösa detta problem, vilket bromsade utvecklingsprocessen något. Slutprodukten i denna fas var en applikation där en förfrågan görs när en användare klickar på ett trendande ämne. Därefter hämtas tweets utifrån ämnet och dessa skickas till front end som placerar ut färgade markörer på kartan baserat på platsinformation från hämtade tweets.

15 KAPITEL 3. UTVECKLINGSPROCCESS 7 Sprint 4: Under denna sprint hölls ytterligare ett möte med UX-gruppen. Under mötet visade de upp deras vision över hur gränssnittet skulle se ut. Det gjordes på en fullskalig prototyp i papper som representerade en touch-skärm på Visualiseringscentret. Efter detta möte beslutades det att ändra gränssnittet ytterligare. Det hölls även ett möte med kunden där det beslutades att försöka implementera en funktion för att hämta och visualisera tweets bakåt i tiden. Hälften av gruppen jobbade därför med det nya gränssnittet och andra hälften jobbade med att skapa en tidslinje. En primitiv version av en tidslinje implementerades där första steget var att hämta äldre tweets, istället för endast realtids-tweets som tidigare. Utöver detta påbörjades skrivandet av projektrapporten. Slutprodukten var ett omdesignat användargränssnitt. Dessutom tillkom möjligheten att kunna byta ämne och starta en hämtning av tweets baserat på det nya ämnet. En prototyp av en tidslinje fanns, men integrerades aldrig med resten av systemet. Sprint 5: I början av sprint 5 lades mest fokus på att färdigställa projektrapporten. Alla i gruppen jobbade med rapporten tills inlämningen. När rapporten var inlämnad fortsatte arbetet med applikationen. De delar som jobbades på var: tidslinjen, laddningsskärm samt justeringar på utseendet av menyn. Det lades även till att markörernas position slumpas ungefär en tusendels koordinat kring sin position för att förhindra att flera markörer hamnar på varandra. Många av dessa förändringar skedde i samband med att ett användartest hade gjorts, vilket gjordes direkt efter inlämningen av rapporten. Tidslinjen implementerades på det viset att när ett ämne har valts kan användaren dra i en slider för att se hur många tweets det var vid olika tidpunkter, sedan dess att ämnet valdes. En laddningsanimation tillades på front end, så att när användaren har valt ett ämne, körs laddningsanimationen tills det att ett tweet har dykt upp på kartan. Menyn till höger på skärmen gjordes om på flera sätt. En pratbubbla lades till kring det valda ämnet för att förtydliga att det är just det ämnet som är valt. Ämnena fick olika storlek beroende hur stor volume de har. volume är en parameter som följer med varje ämne, som bestämmer hur mycket det skrivs om det för tillfället. Ämnena fick även annat utseende. Ett cirkeldiagram tillkom även, som visar fördelning av positiva, negativa och neutrala tweets som visas för tillfället. En räknare som räknar antal tweets på kartan tillades även i menyn. En annan ändring som gjordes var att ordanalys-tjänsten byttes ut. Servern till den ordanalysen som användes innan var inte längre kontaktbar, varför en ny metod hittades och implementerades. Det som valdes var Text Analytics API från Microsoft Azure Cognitive Services[9]. Denna implementerades på back end. Slutprodukten var denna sprint ett första utkast på projektrapporten samt en fungerande tidslinje, en ordanalys från en Microsoft Azure och små justeringar av utseendet. Sprint 6: I början av sprint 6 skrev gruppmedlemmarna på sina individuella opponeringar samt implementerade de sista justeringarna på applikationen. När applikationen var klar satt gruppen med projektrapporten och ändrade det som var otydligt i rapporten efter den feedback som gruppen fått från opponeringen. I slutet av sprinten förberedde även gruppen en presentation inför slutseminariet. 3.3 Gruppkontrakt och ansvarsroller I början av projektet skrev gruppen tillsammans ett gruppkontrakt, se Bilaga A. I gruppkontraktet sammanställdes hur gruppen skulle arbeta, eventuella sidoprojekt eller aktiviteter gruppmedlemmarna hade parallellt med projektet samt vilka ansvarsroller som tilldelades vem. De roller som användes under projektets gång var följande:

16 KAPITEL 3. UTVECKLINGSPROCCESS 8 Kontaktansvarig Testansvarig Dokumentansvarig Salansvarig Scrummaster/mötesansvarig För att det skulle vara enklare att hålla reda på vem som kontaktade examinatorn, kunden och utvecklingsrådgivaren bestämdes det att tilldela rollen kontaktansvarig till Sovanny. För att försäkras om att tester görs utsågs en testansvarig som officiellt hade ansvaret att påminna gruppen om att testa det som gjorts. Den rollen tilldelades till Elin. Vid varje möte dokumenterades det som sades för att enkelt kunna gå tillbaka och se vad som bestämts. Ola var den som var ansvarig för att se till att detta blev nedskrivet. Då alla ville prova på att vara scrummaster/mötesansvarig valdes det att ha den posten roterande. Eftersom projektet blev indelat i 6 sprinter och det finns 6 personer i projektgruppen blev det naturligt att varje person fick vara scrummaster under var sin sprint. Den som var scrummaster var även ansvarig för att en sal bokades till arbetstillfället. Dessa roller roterade enligt ordningen: Ola, Jasmine, Erik, Sovanny, Patrik, Elin. 3.4 Dokumentation och versionshantering Under projektets gång dokumenterades allt arbete som utfördes eller skulle utföras till så stor grad som möjligt. Vid varje sprintplanering, sprintåterblick, sprintgranskning samt vid generella möten med kund eller examinator har dokumentansvarige dokumenterat vad som sagts och gjorts. Dokumenten delades i Google Drive, som är en molntjänst som tillåter delning av filer och gjorde det möjligt för alla medlemmar i gruppen att ta del av dem [10]. På Google Drive delades också anteckningar och ritningar som gjordes under de första mötena. All kod som skrevs i projektet kommenterades direkt i koden när den skrivits eller vid ett senare tillfälle. Detta minimerade tiden det tog för projektmedlemmarna att sätta sig in i kod som medlemmen inte skrivit själv. Ett verktyg som användes för att sätta upp delmål och organisera projektets sprintbacklogg var Trello. Trello fungerar som en portabel anslagstavla i webben där listor skapas och sätts upp av medlemmarna i projektgruppen [11]. Listorna som skapades av gruppen var ej påbörjade, påbörjade, avslutade, och avslutade tidigare sprinter. Inom listan ej påbörjade skapades nya uppgifter, som eftehand flyttades till respektive kolumn, beroende på dess status. I detta projekt användes Git för versionshantering. Hela gruppen arbetade på en master-gren för att undvika svåra sammanslagningar av grenar i slutet av projektet. För att undvika onödiga mergekonflikter skapades olika filer för olika delar av programmet. 3.5 Arbetssätt Gruppen jobbade varierande beroende på vilken del av systemet som arbetades på. Under planeringsfasen bestämdes det vilka delar som krävde mer uppmärksamhet på grund av dess svårighetsgrad. Vid identifieringen av olika delar som krävdes i en specifik sprint kunde gruppen dela in vilka som kan

17 KAPITEL 3. UTVECKLINGSPROCCESS 9 arbeta individuellt och vilka som bör parprogrammera. När en gruppmedlem fick arbeta individuellt fick denne ansvar för att koden fungerar och kan implementeras i systemet. Vid parprogrammering arbetade två gruppmedlemmar på samma dator där den ena skrev kod och den andra granskade koden i realtid. Uppgifterna roterades så att alla gruppmedlemmar skulle få vara delaktiga i alla delar. Bland annat var alla intresserade av att få jobba med Python, då ingen hade tidigare erfarenhet av det. Rotationen av uppgifterna medförde även att alla har bra koll på koden i hela projektet, då alla fått jobba med alla delar under något tillfälle. Vilka olika delar som gruppmedlemmarna har jobbat på redovisas i Bilaga B. 3.6 Kvalitetsanalys och testning För att upprätthålla kodkvalitet användes som ovan nämnt parprogrammering, individuellt ansvar samt kodgenomgång. Parprogrammering var fördelaktigt eftersom koden redan från början granskas av två utvecklare istället för en, vilket minskade risken för slarvfel. Vid individuellt ansvar får en gruppmedlem själv ansvara för att en standard uppehålls. Ifall medlemmen känner att det blir för svårt att själv granska koden kan denne be om en granskning från en annan gruppmedlem. Kodgenomgång hölls i samband med sprintavslut och begränsades till max 1 timme per sprint för att inte för mycket tid skulle tas ifrån utvecklingen. Vid kodgenomgång granskades hela koden tillsammans för att säkerställa dess standard. Dessutom innebar kodgenomgång att alla gruppmedlemmar fick en översikt och förståelse för alla delar av systemet. Innan varje push till Git, testades programmets funktionalitet i den mån att de funktioner som har implementerats i koden fungerar som tänkt. Knappar ska gå att trycka på och element ska vara på rätt plats i GUI:t. Inga avgörande felmeddelanden i webbläsarens konsol eller i back end-konsolen skall heller finnas. Dessa tester görs av den personen eller gruppen som har jobbat med förändringen. Ett kompatabilitetstest utfördes en gång varje sprint för att se hur applikationen fungerar på den tänkta plattformen touch-skärm. Eftersom att applikationen har utvecklats på persondatorer med mindre skärmar var det viktigt att kolla hur applikationen kördes på en större skärm med touch med jämna mellanrum, speciellt med tanke på att applikationens utseende och utformning ändrades under projektets gång. Mot slutet av detta projekt gjordes kompatabilitetstestet oftare för att säkerställa att produkten var brukbar. Koden skrevs enligt Google Style Guide för att det skulle bli enklare för gruppmedlemmarna att läsa den kod som de inte skrivit själva [12]. Genom att använda Google Style Guide blir koden mer konsekvent och därmed av högre kvalitet. 3.7 Användartest För att få återkoppling från utomstående utfördes ett användartest. Det utfördes genom att två gruppmedlemmar frågade ett antal utomstående personer, en och en, några frågor angående applikationen och bad personen använda applikationen utan hjälp. Ett formulär användes för att dokumentera testet. Följande frågor fanns i formuläret, de som är inom citattecken är frågor som ställdes till användaren: Vad är det första personen gör? Vad tror du att applikationen gör? Är det uppenbart för personen hur man använder applikationen?

18 KAPITEL 3. UTVECKLINGSPROCCESS 10 Vad tror du de olika färgerna står för? Vart klickar du om du vill veta mer?. Klickar hen på inforutan? Finns det något du saknar? Resultaten sparades och diskuterades inom gruppen, vilket ledde till ett antal ändringar på applikationen. Resultaten till testet finnes i Bilaga C. 3.8 Kundkontakt och kravhantering I början av projektet hölls ett möte med kunden för att diskutera projektet och dess slutmål. Under projektets gång hölls två till möten för att säkerställa att produkten mötte kundens förväntningar. Under dessa möten demonstrerades applikationen för kunden. Det diskuterades även hur den borde vidareutvecklas samt vilka funktioner som borde prioriteras. Kunden hade få specifika krav för projektet. På grund av detta fick gruppen sätta upp en egen prioriteringslista som kunden godkände innan arbetet påbörjades. Listan som skapades vid det skedet är som följer: Karta - få upp karta med hjälp av ett kart-api. Hämta tweets, samt platsdata. Sätta ut markörer baserat på tweets med plats. Ordanalys av tweets. Interaktion och användargränssnitt. Utökad statistik om sökämnet inom ett visst område. Tidslinje - möjlighet att lagra data om föreslagna nyckelord så att förändring över tid kan visas. Att få upp en karta med hjälp av ett kart-api innebar att gruppen skulle använda sig av ett lämpligt API som lät gruppen designa kartan efter eget tycke. Hämtning av tweets och dess platsdata var ett krav som innebar att hämta tweets från något av Twitters API samt lokalisera varifrån tweeten kommer ifrån. När de hämtade tweeten lokaliserats var nästa krav att sätta ut markörer på kartan utifrån var dessa tweets var skrivna samt göra en ordanalys på det skrivna tweetet. Ett krav som prioriterades högt från kunden var att applikationen skulle kunna gå att interagera med. Därför var ett av kraven interaktion och ett tilltalande användargränssnitt. I slutet av sprint 3 bortprioriterades utökad statistik om sökämnet då kunden hellre ville att fokus skulle ligga på att implementera en tidslinje. 3.9 Schema Gruppen bokade tidigt i projektet gemensamt in tider för att ses, för att gruppmedlemmarna skulle kunna planera in annat skolarbete och aktiviteter. Under första läsperioden läste gruppen kursen Modelleringsprojekt parallellt. Eftersom båda kurserna var projektkurser med få schemalagda moment kunde gruppen ofta arbeta heldagar, det vill säga 8.15 till 17.00, måndag, tisdag och onsdag. Torsdagar och fredagar bokades för Modelleringsprojektet. Under andra läsperioden läste gruppen kursen

19 KAPITEL 3. UTVECKLINGSPROCCESS 11 Datastrukturer parallellt med projektet. Denna kurs har många schemalagda moment och kräver mycket tid utöver det, för bland annat laborationsförberedelser. Gruppen bokade in mötestider tidigt under perioden för att förhindra krockar i schemat och ge möjlighet för gruppmedlemmarna att planera in tid för övriga studier. Gruppen tog regelbundna korta raster för att få lite paus i utvecklingen och kunna jobba effektivare under resten av tiden Expertmöten Gruppen har haft möten med en utvecklingsrådgivare och, som tidigare nämnts, en UX-grupp. Utvecklingsrådgivaren har gett råd och vägledning i olika val av verktyg i projektet, samt hjälpt gruppen vid tekniska hinder. UX-gruppen har hjälpt projektgruppen i utvecklingen av användargränssnittet genom att utföra användartester och diskutera olika idéer och lösningar.

20 Kapitel 4 Tekniskt arbete I detta kapitel redovisas det tekniska arbetet, det vill säga hur systemarkitekturen är uppbyggd och vilka verktyg som har använts för att bygga applikationen. 4.1 Systemarkitektur Programmet består av två huvuddelar. En back end som hämtar data från Twitter och hanterar datan och en front end som sköter visualisering av data samt hanterar användarinteraktion. Back end-delen är skriven i Python och det är där hämtningen av data från Twitters API sker med hjälp av Twython. I inledningsstadiet diskuterades det med utvecklingsrådgivaren vilket språk som var mest fördelaktigt att använda och gruppen fick då Python eller JavaScript och NodeJS rekommenderat. Gruppen valde att använda Python framförallt eftersom en ordanalys hittades med exempel på hur den kunde implementeras med Python, men också för att gruppen var intresserad av att lära sig språket. I front end-delen används JavaScript för att ta emot data från back end-delen, hantera användarinteraktioner och visualisera data. HTML och CSS används för att bygga upp och designa webbapplikationen Klasser Back end-delen har två huvusakliga klasser som används. Dels klassen TwitterStreamer, som är en subklass av klassen TwythonStreamer som tillhör Twython, och dels TwitterWatchDog. Utöver de variabler och funktioner som finns i TwythonStreamer innehåller TwitterStreamer en datakö där hämtade tweets lagras och två överlagrade funktioner on_success() och on_error(). on_success() lägger in tweets i datakön och on_error() skriver ut ett felmeddelande och bryter kopplingen till Twitter då fel uppstår. TwitterWatchDog har två variabler. En TwitterStreamer och ett objekt av typen Greenlet. En Greenlet gör det möjligt att köra kod oberoende av resten av programmet [13]. Detta används för att köra flödet från TwitterStreamer samtidigt som resten av programmet. TwitterWatchDog har även funktionen check_alive() som kollar om fel har uppstått hos TwitterStreamer och startar om flödet om så är fallet. 12

21 KAPITEL 4. TEKNISKT ARBETE Informationsflöde När applikationen startas hämtas de tio mest trendande ämnena på Twitter vid tillfället med hjälp av Twython och Twitters REST API. Dessa skickas sedan från servern med hjälp av Socket.IO till klienten och visualiseras för användaren i form av knappar. Detta visualiseras i Figur 4.1. Användaren kan sedan välja ett av de tio ämnena genom att klicka på tillhörande knapp. Det valda ämnet skickas då till servern med en AJAX POST förfrågning. När servern mottar det valda ämnet hämtas data för de tweets som innehåller det ämnet, med hjälp av Twython, Twitters streaming- och REST-API. Informationsflödet vid användning av streaming-api:t visas i figur 4.2.Samma behandling av tweet görs även på tweet hämtade med REST-API:t dock tas inte dessa tweets emot kontinuerligt utan hämtas i stället 100 stycken pt gången. Twython ger en stor mängd data för varje tweet som tas emot. För att inte skicka onödigt mycket data till klienten filtreras endast nödvändig data ut. Den data som behövs är Tweet-meddelandet för ordanalysen, tweetets unika ID för att kunna presentera tweetet, samt platsdata för att placera ut tweetet på kartan. Då inte alla tweet har platsdata implementerades metoden tweet_has_location(). Denna metod undersöker om det finns platsdata från tweetet. Ifall ingen platsdata finns undersöker den om den användare som publicerat tweetet har angett en hemplats. Då användare kan skriva in vilken hemplats som helst, vare sig den finns i verkligheten eller inte, utför den även en kontroll med hjälp av verktyget Geopy. Geopy är ett Python-bibliotek som använder externa källor för att hämta koordinaterna för olika platser, som gatunamn, städer eller länder [14]. Ifall koordinater kan hämtas antigen från Twython eller Geopy returneras dessa koordinater. Ifall inga koordinater kan hämtas returneras inga koordinater och tweetet skickas inte till klienten. Då samma koordinater returneras för samma stad förflyttas markören med ett värde mellan 1-9 tusendelar både i longitud och latitud. Detta för att markörerna inte ska hamna på varandra och därmed inte bli klickbara. En ordanalys görs av Twitter-meddelandet, med Microsofts Text Analytics API, för att avgöra om tweetet är positivt, negativt eller neutralt. Den hämtade datan, samt resultatet från ordanalysen görs om till GeoJSON-format och skickas till klienten med Flask-SocketIO, som är ett verktyg som erbjuder kommunikation med klienten via Socket.IO. På front end-sidan visualiseras tweetsen på en karta med hjälp av Mapbox GL JS. Mapbox GL JS är ett Javascript bibliotek som använder sig av webgl för att kunna göra interaktiva kartor [16]. Tweetsen visas som små markörer på kartan baserat på de hämtade koordinaterna. Markörerna färgas rött, oranget eller grönt beroende på om tweet-meddelandet ansågs negativt, neutralt eller positivt. Användaren kan sedan interagera med applikationen genom att zooma, byta ämne, trycka på markörerna för att visa det tillhörande tweet-meddelandet eller dra i tidslinjen för att endast visa tweets från en viss tid. Tweetet visas i form av en widget som hämtas med hjälp av tweetets ID. Figur 4.1: Diagram över informationsflödet då sidan startas.

22 KAPITEL 4. TEKNISKT ARBETE 14 Figur 4.2: Diagram över informationsflödet då användaren väljer ett ämne. 4.2 Utvecklingsmiljöer Projektmedlemmarna valde själva vilken IDE de ville använda. Chrome användes huvudsakligen som webbläsare för att köra programmet under utvecklingen. Dock testades även programmet i andra webbläsare: Safari, Firefox, Edge och Internet Explorer. För att underlätta för gruppen att köra applikationen på olika operativsystem så användes en teknik vid namn Virtual Environment eller också kallat virtualenv [17]. Det är ett program som installeras på datorn och sedan kan användas för att skapa isolerade kör-miljöer. En isolerad miljö skapas där alla bibliotek och program installeras lokalt i miljön. Mer specifikt installerades Python och dess tillhörande bibliotek som behövdes för att köra applikationen i denna miljö. Python-filen, servern för applikationen, körs i den virtuella miljön med den lokala Python-installationen. Genom att köra applikationen med Virtual Environment, kan konflikter relaterade till bibliotek- och

23 KAPITEL 4. TEKNISKT ARBETE 15 Python-versioner undvikas. Alltså, att versionerna i den virtuella miljön alltid är korrekta medan vad som är installerat på systemnivå på gruppmedlemmarnas datorer kan variera och vara inkorrekta för detta projekt. Biblioteksversionerna som behöver vara installerade i miljön sparas i en fil vid namn requirements.txt i projektet. För att installera versionerna körs ett kommando i den virtuella miljön, med filen som parameter. Denna metod gör det smidigt för projektmedlemmarna att alltid hålla sin miljö uppdaterad. 4.3 Twitters API För att hämta Twitter-data användes Twitters egna API. Twitter har flera olika API:er, varav två används i applikationen, ett REST API och ett Streaming API. Deras funktioner och skillnaden mellan dem förklaras senare i detta kapitel. Dessutom användes Twitters JavaScript-verktyg widgets-js för att visa enskilda tweets. För att få använda Twitters API måste det vara en verifierad användare som hämtar data från API:t. För att bli verifierad användare krävs ett Twitter-konto, samt att Twitter-kontot har registrerat en så kallad App på Twitters utvecklingsplattform. När det finns en App registrerad kan användaren generera OAuth-nycklar via ett App-hanteringsverktyg på plattformen. Det är dessa nycklar som gör att användaren ses som verifierad. Användaren i detta fall är en hemsida. Det är alltså hemsidan som blir verifierad tack vare Oauth-nyckeln och därmed får tillgång till Twitter-data. Oauth är en öppen standard för åtkomstdelegation [18] REST API REST API:er används när syftet är att göra enstaka förfrågningar, till exempel hämta trendande ämnen. Ett REST API fungerar genom att klienten gör en förfrågan till en server genom ett HTTPprotokoll [19]. Twitters REST API används i applikationen för att hämta de tio mest trendande ämnena globalt på Twitter. Vilka ämnen som trendar bestäms av en algoritm och baseras på hur många tweets det görs av ämnet i realtid. Algoritmen beräknar inte endast andelen tweets av ett ämne, utan väger även in andelen tweets av relaterande eller motsvarande ämnen [20] Streaming API Ett streaming API används för att få kontinuerlig realtids-data, till exempel för att få live uppdatering varje gång någon skriver ett tweet om ett visst ämne eller taggar en person. När en applikation kopplar upp sig mot ett streaming API måste HTTP-anslutningen hållas öppen. Förfrågningar kan inte göras från klienten utan förfrågningar sker kontinuerligt [21]. Twitters streaming API används i applikationen för att kontinuerligt hämta tweets om det valda ämnet Widgets-js När användaren trycker på en markör på kartan kommer en ruta upp som visar ett utvalt tweet. Detta gjordes genom att använda Twitters produkt Twitter for Websites, som gör det enkelt att integrera Twitter-innehåll i webbapplikationer. Till exempel finns möjlighet att skapa en knapp så att användare kan dela eller följa på Twitter, eller skapa widgets för att visa enskilda eller flera tweets. I projektet

24 KAPITEL 4. TEKNISKT ARBETE 16 används Twitters JavaScript-verktyg widgets-js och funktionen twttr.widgets.createtweet för att visa tweets [22]. Funktionen tar som argument in ett unikt Twitter-ID samt i vilket HTMLelement Twitter-inlägget ska skapas. 4.4 Sentiment Fram till och med sprint 5 användes Sentiment som ordanalys, men eftersom åtkomsten till servern efter det blev nekad byttes ordanalys. När Sentiment användes för att utföra ordanalysen skickades ett anrop till Viveks Sentiment Web API för varje inkommande tweet. Detta gjordes på back end precis efter att inläggens platskoordinater tagits fram och precis innan infomartionen omvandlas till GeoJSON och skickas till front end-delen. Anropet är ett POST-anrop och görs med hjälp ett Python-biblioteket Requests. I POST-anropet skickas en parameter; en variabel innehållandes en text-sträng som är tweetets innehåll. Ett JSON-objekt returneras innehållandes två fält: sentiment och confidence. Dessa två variabler används sedan i applikationen för att ge en färg åt markörerna på kartan. Sentiment kan ha tre värden: Negative, Positive eller Neutral. Confidence visar med hur stor säkerhet Sentiment stämmer, med ett värde mellan 0 och 1. En filtrering görs med hjälp av confidence-värdet, där gruppen har valt att markera twitterinlägg som neutrala, som från början har varit negativa, om confidence är under Text Analytics API Under sprint 5 implementerades Microsoft Azures ordanalys Text Analytics API. När ett tweet skickas till API:et returneras ett JSON-objekt med information om tweetet. Detta görs genom att skicka ett POST-anrop med hjälp av Python-biblioteket urllib2 till Microsofts Text Analytics API. Twittermeddelandet skickas med som argument i anropet. Objektet som returneras innehåller ett poäng med ett värde från 0 till 1, desto närmare 0 desto mer negativt anses tweetet och desto närmare 1 desto mer positivt anses det. Ett exempel på ett sådant objekt visas i figur 4.3. Projektgruppen valde att sätta alla tweets över 0,75 som positiva och alla under 0,25 som negativa, tweets med poäng mellan 0,25 och 0,75 sätts till neutrala. Analysen görs med hjälp av olika klassificeringstekniker [9]. Microsoft ger inte mycket information om hur ordanalysen faktiskt fungerar, men efter att ha testat analysen verkar den ge ett bra resultat. Figur 4.3: Ett exempel på ett JSON-objekt som returneras när ett tweet analyseras med Text Analytics API. Tweetet anses vara positivt och skrivet på engelska.

25 KAPITEL 4. TEKNISKT ARBETE GeoJSON När en förfrågan görs via Twython till Twitters API returneras tweets i JSON-format. Twython omvandlar sedan detta till ett Python-objekt. Ur detta objekt hämtas koordinaterna för tweetet, tweetets meddelande samt tweetets unika id. För att kunna visualisera den hämtade datan med Mapbox måste den skrivas om till GeoJSON-format. GeoJSON är ett format för att beskriva geografisk data [23]. Ett exempel på ett GeoJSON-objekt visas i Figur 4.4. Figur 4.4: Ett exempel på ett GeoJSON-objekt från ett tweet hämtat från Norrköping. Objektet beskrivs av tre egenskaper: type, geometry och properties, där geometry och type är obligatoriska. Geometry beskriver vilken typ av geografiskt objekt som objektet representerar samt vilka koordinater objektet har. I projektet används endast objekt som representerar punkter med en longitud och latitud koordinat. Egenskapen type är satt till Features vilket innebär att objektet har fler egenskaper än type och geometry, dessa listas i egenskapen properties. I egenskapen properties finns egenskaperna som beskriver tweetets åsikt och ID. 4.7 Mapbox Tidigt under arbetsgången implementerades en karta där visualiseringen av tweets skedde. När efterforskningar gjorts av olika kart-api:er valdes Mapbox GL då den var enkel att implementera samt att det fanns bra dokumentation för hur den kan användas [16]. Det var även enkelt att anpassa designen av kartan efter eget tycke, vilket sågs som en fördel för att kartan skulle passa till gränssnittet. Designen utformades genom att skapa en style med hjälp av Mapbox Studio som sedan länkas till i JavaScript-koden [24]. För att visualisera Twitter-data i form av markörer hämtades data som sagt från back end-sidan i form av ett GeoJSON-objekt. Objektet innehåller information om koordinater, åsikter och text för varje tweet. Informationen används för att sätta ut markörer på kartan med rätt position. Olika lager skapades för att ge tweets med olika åsikter olika färg. Grön, orange och röd färg valdes för att representera positiv, neutral och negativ åsikt. På detta sätt går det enkelt att se var människor är positivt eller negativt inställda till ett visst ämne. 4.8 Användargränssnitt Redan i ett tidigt stadium gjordes ett första utkast på hur det grafiska gränssnittet skulle kunna se ut, se Figur 4.5. Första tanken var att ha en toppmeny där användaren kunde söka på ett valfritt ord samt se relaterade ämnen. Under toppmenyn skulle en karta med markörer visas och till höger en meny som visade diverse statistik om ämnet. Längst ner på kartan skulle en tidslinje visas. En play-knapp

26 KAPITEL 4. TEKNISKT ARBETE 18 skulle finnas till vänster om kartan som skulle spela upp tweets över tid när den klickades på. Det skulle även gå att välja en tidsperiod på tidslinjen för att se hur många tweets som skrivits vid just det tillfället. Denna design började implementeras under sprint 1, se Figur 4.6. Figur 4.5: Första skissen på en design. Figur 4.6: Första versionen av gränssnittet.

27 KAPITEL 4. TEKNISKT ARBETE 19 Dock frångicks originaldesignen ganska tidigt i arbetsprocessen. Då streaming-api:et användes i början blev det få resultat om inte någon skrev om ämnet när sökningen inträffade. Därför valdes det att ha färdiga ämnen som användaren kunde trycka på. Tanken var även att applikationen skulle vara på en stor touch-skärm och då ansåg gruppen att det var bättre om menyn inte var fast, utan att ha de olika knapparna flytande över skärmen. På så sätt skulle flera personer kunna stå runt bordet och trycka och flytta runt på knapparna, se Figur 4.7 och 4.8. Figur 4.7: Startsidan från en version av gränssnittet från mitten av projektet. Figur 4.8: Version av gränssnittet från mitten av projektet där ett ämne valts och ett tweet klickats på.

28 KAPITEL 4. TEKNISKT ARBETE 20 Efter ett möte med kunden insåg gruppen att de övriga projekten på utställningen generellt hade raka vinkelräta linjer. Applikationen var heller inte utformad för att flera människor skulle kunna använda den samtidigt, som många andra projekt på Visualiseringscenter var. Därför valde gruppen att anpassa programmet till en mindre touch-skärm och gick tillbaka till den ursprungliga idén med en menyrad till höger, vilket går bra när det bara är en användare. Vid möte med kunden diskuterades även färger och då de övriga projekten på Visualiseringscenter har monotona, dova färger i bland annat svart, vitt och grått beslutades det att applikationen också skulle ha de färgerna. Färgerna valdes i en jämn nyans så inget på användargränssnittet utmärker sig mer än något annat och att fokuset dras till markörerna på kartan, se Figur 4.9. I slutprodukten ändrades utseendet på sid-menyn och ett cirkeldiagram med antalet tweets lades till. Dessutom implementerades en tidslinje som placerades längst ner på kartan. Figur 4.9: En version av applikationen där en sid-meny lagts till.

29 Kapitel 5 Resultat I Figur 5.1 visas slutversionen av applikationen där en sökning genomförts. Längst ner på kartan finns en tidslinje där användaren kan välja att visualisera ämnen från ett tidigare tillfälle. När ett ämne valts och tweets inte hunnit laddas visas en laddningsanimation som syns i Figur 5.2. Figur 5.3 visar en närbild på markörer med olika färger. I städer där det är många som tweetar finns fler markörer och därmed blir färgen intensivare där. Figur 5.4 visar ett tweet då en markör klickats på. Figur 5.5 visar ett pop up-fönster med information om applikationen. Figur 5.6 visar en närmare bild på menyn med tillhörande ämnen, en pratbubbla där det valda ämnet visas, samt ett cirkeldiagram som visar fördelningen mellan åsikterna för ämnet. De olika trendande ämnena som användaren kan välja att visualisera har olika fontstorlek beroende på hur mycket som skrivs om dem just nu. Längst ner i menyn finns även en informationsknapp om användaren vill ha mer information om applikationen. Figur 5.1: Slutversionen av applikationen. 21

30 KAPITEL 5. RESULTAT Figur 5.2: Innan tweets har kommit visas en laddnings animation. Figur 5.3: Del av karta som visar tweets som är positiva, negativa och neutrala. 22

31 KAPITEL 5. RESULTAT 23 Figur 5.4: Visar ett tweet på kartan. Figur 5.5: Informationsruta som beskriver hur applikationen används.

32 KAPITEL 5. RESULTAT 24 Figur 5.6: Meny som visar vilka trender som är aktuella just nu.