• No results found

En jämförande studie mellan olika JavaScriptbibliotek för visualisering: Prestandamätning av JavaScriptbibliotek för statistiska grafer och diagram

N/A
N/A
Protected

Academic year: 2022

Share "En jämförande studie mellan olika JavaScriptbibliotek för visualisering: Prestandamätning av JavaScriptbibliotek för statistiska grafer och diagram"

Copied!
88
0
0

Loading.... (view fulltext now)

Full text

(1)

EN JÄMFÖRANDE STUDIE MELLAN OLIKA JAVASCRIPTBIBLIOTEK FÖR VISUALISERING

Prestandamätning av JavaScriptbibliotek för statistiska grafer och diagram

A COMPARATIVE STUDY BETWEEN DIFFERENT JAVASCRIPT LIBRARIES FOR VISUALIZATION

Performance measurements of JavaScript libraries for statistical graphs and diagrams

Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng

Vårterminen 2018 Alice Carlström

Handledare: András Márki

Examinator: Henrik Gustavsson

(2)

Sammanfattning

Visualisering av statistik är ett tydligt sätt att presentera data som annars kan ses som svår att tyda och analysera. Med hjälp av visualiseringar på webben kan man nå ut till många och det är ett smidigt sätt att ta med sig och dela med sig av information.

Denna rapport bygger på ett experiment där olika JavaScriptbibliotek jämförs baserat på tiden det tar att rita ut diagram av olika storlekar och typer. Linjediagram, punktdiagram och stapeldiagram skapas med de olika biblioteken.

Vilka bibliotek som jämförs väljs ut utifrån ett antal kriterier och Chart.js, Google Charts och Plotly.js är de som uppfyller alla krav. Undersökningar där utritningstiden mäts genomförs och resultaten visar att Chart.js är snabbast på att rita ut diagram i de flesta mätningarna.

Det finns signifikanta skillnader mellan alla diagrammätningar förutom mellan Linjediagram 2 skapat med Chart.js och Linjediagram 2 skapat med Plotly.js samt Plotly.js Stapeldiagram 1 och Plotly.js Stapeldiagram 5.

Mätningarna visar också att diagram som baseras på större datamängd, i de flesta fall, också har längre utritningstid än diagram baserade på mindre datamängd.

Nyckelord: visualisering, diagram, prestanda, JavaScript, Chart.js, Google Charts, Plotly.js

(3)

Innehållsförteckning

1 Introduktion ... 1

2 Bakgrund ... 2

2.1 Visualisering ... 2

2.2 Statistik ... 2

2.2.1 Visualisering av statistik ... 2

2.2.2 Statistiska grafer och diagram ... 3

2.2.3 Förändringsmöjligheter – förändring i realtid ... 4

2.3 HTML, CSS och JavaScript ... 4

2.4 JavaScriptramverk och JavaScriptbibliotek ... 4

3 Problemformulering ... 6

3.1 Frågeställningar ... 7

3.2 Hypoteser ... 7

3.3 Delmål ... 7

3.4 Metodbeskrivning ... 7

3.5 Tillvägagångssätt ... 8

3.6 Etiska aspekter ... 10

4 Relaterad forskning ... 11

5 Genomförande... 12

5.1 Val av JavaScriptbibliotek... 12

5.2 Jämförelse av biblioteken ... 13

5.3 Experiment på biblioteken ... 13

5.4 Progression ... 19

5.5 Pilotstudie ... 21

6 Utvärdering ... 23

6.1 Analys ... 24

6.2 Slutsatser ... 34

7 Avslutande diskussion ... 36

7.1 Sammanfattning ... 36

7.2 Diskussion ... 37

7.2.1 Relaterad forskning... 37

7.2.2 Etiska och forskningsetiska aspekter ... 38

7.2.3 Samhällsnytta ... 39

7.3 Framtida arbete ... 40

Referenser ... 42

(4)

1

1 Introduktion

Visualisering genom bilder och former är lätt att tyda för många (Spence 2014) och i och med att man kan visualisera saker på många olika sätt, både statiskt och dynamiskt, samt med eller utan interaktionsmöjligheter (Fayyad, Grinstein & Wierse 2002) kan man få fram mycket information genom olika typer av visualiseringstekniker.

Statistik innebär att man systematiskt samlar ihop, visar upp och analyserar data så att man kan dra slutsatser från denna. När man visualiserar statistik gör man det ofta med olika typer av grafer och diagram. Det är dock viktigt att rätt typ av graf eller diagram används till rätt typ av data (De Veaux, Velleman & Bock 2016) för att på ett bra sätt kunna analysera och hantera informationen. En grundskillnad, som kan vara bra att känna till, är att det är skillnad på kvalitativa och kvantitativa data, alltså data som lätt kan kategoriseras, exempelvis kön, eller data som lätt kan jämföras, exempelvis pris på något (De Veaux, Velleman & Bock 2016).

HTML kombinerat med CSS och JavaScript lägger grunden för hemsidor (W3Schools JavasScript 2018) och visualisering på webben har blivit mycket smidigare sedan SVG och Canvas-funktioner implementerats i HTML5 (Hostinger Tutorials HTML and HTML5 2018).

För att göra programmeringen i JavaScript enklare finns det ett antal ramverk och bibliotek man kan använda sig av. Experimentet som förklaras i denna rapport bygger på JavaScriptbibliotek som är inriktade på just visualisering av statistiska grafer och diagram.

Det finns flera som använt sig av webben för att visualisera olika saker, bland andra McCoy, Austin och Slaughter (2010) som med hjälp av HTML, JavaScript och PHP visar hur tjock isen på Grönland är. Li, Eickhoff och de Vries (2014) jämför olika JavaScriptbibliotek för statistik men kommer fram till att de inte riktigt passar för det de vill använda dem till så de väljer att skapa ett eget program. Om man vill eller behöver använda ett befintligt statistikbibliotek, vilket ska man då välja? Rahman (2018) nämner ett antal olika statistikbibliotek i sin artikel och utifrån dessa har ett antal kriterier satts upp för detta experiment. De bibliotek som nämns i Rahmans (2018) artikel, och som stämmer överens med kriterierna, undersöks vidare.

Renderingstid för biblioteken är en viktig del för att de ska vara smidiga att arbeta med och att de ska gå att modifiera och interagera med (Ali, Gupta, Nayak & Lenka 2016) och för att det ställs mer och mer krav på prestanda för dagens webbsidor (Anttonen, Salminen, Mikkonen & Taivalsaari 2011).

Baserat på detta genomförs ett experiment där olika JavaScriptbibliotek för visualisering av statistik jämförs. Renderingstid mäts på olika stora diagram skapade med verktygen och en rekommendation ges efter en analys av resultaten. Experimentet genomförs för att få svar på frågorna om vilket av biblioteken som är snabbast på att rendera diagrammen samt om det är någon signifikant skillnad i renderingstider för diagram skapade av olika stora datamängder.

För att svara på frågeställningarna genomförs ett experiment i en miljö där mätningar,

förändringar och mätningar igen kan ske kontrollerat (Wohlin et al. 2012). Sidor med diagram

skapas med de olika JavaScriptbiblioteken och data från Bolin Centre for Climate Research

(Bolin Centre for Climate Research 2018). Tiden det tar att rita ut diagrammen mäts och

resultaten sparas externt och sammanställs för att jämföras och analyseras.

(5)

2

2 Bakgrund

I det här kapitlet förklaras grundläggande begrepp som kan ge mer förståelse för problemen och experimentet som tas upp i kommande kapitel.

2.1 Visualisering

Information kan tas in på flera olika sätt, med flera olika sinnen, exempelvis genom att läsa text, skriva, se på bilder, höra beskrivningar eller ljud, känslan att hålla i något eller att genomföra något med händerna. Vilket eller vilka sätt som fungerar bäst är ganska individuellt, men många tycker att förklarande och visande bilder underlättar både lärande och hur lätt det är att komma ihåg det man sett. Bilder och former är ett visualiseringssätt som är lätt och tydligt att använda och som fungerar för många (Spence 2014).

Människor tycker om att se mönster och hur saker hänger ihop (Fayyad, Grinstein & Wierse 2002) och att visualisera data gör det lättare att se dessa och visar även tydligare om något avviker från mängden. Visualiseringar kan innebära bilder, videor, former, ritningar, kartor, grafer, diagram och mycket mer. De kan vara statiska eller rörliga och i vissa fall kan man interagera med dem (Fayyad, Grinstein & Wierse 2002). Beroende på vad för data och information som ska visas passar olika visualiseringstekniker olika bra. Vad man vill få reda på eller vilka delar man vill kunna analysera påverkas också av hur de visas.

Att visa information grafiskt görs ofta och ett bra sätt att nå ut till många är genom webben.

För att det ska bli mer tilltalande används olika färger och former och precis som på många andra plattformar används bilder. Bilderna används för att göra presentationen snyggare men också för att lättare visa och beskriva saker samt för att man ofta kommer ihåg visuella bilder bättre.

2.2 Statistik

Att systematiskt samla ihop och visa upp data för att kunna analysera information och dra slutsatser från denna är det som kallas statistik. Den används inom många olika områden och alla kommer dagligen i kontakt med någon form av statistik. Statistik kan innebära både information om ett speciellt ögonblick eller förändring över tid och det finns många olika sätt att samla in data (SCB Det här är statistik 2018). Statistiska Centralbyrån (SCB Det här är statistik 2018) beskriver statistik enligt följande:

”Statistik beskriver verkligheten i siffror, exempelvis i form av tabeller. Med statistik menas också vetenskapen om metoderna som används för att samla in, bearbeta, analysera och redovisa data.

Välgjord statistik mäter och beskriver verkligheten så nära det går.”

Förr användes statistik främst till att samla information som kunde hjälpa till att styra ett land men idag har det många fler användningsområden (SCB Vad är statistik? 2018).

2.2.1 Visualisering av statistik

Det kan vara svårt att ha en övergripande blick över statistik om den inte visualiseras på ett

bra sätt. Vad som räknas som bra beror förstås på vilka data det är som ska visas (De Veaux,

Velleman & Bock 2016). Alla personer har eller kommer att ha användning för statistik på ett

(6)

3

eller annat sätt i sina liv och det är viktigt att man kan förstå vad som visas. Om man bara ser en tabell med en stor mängd data kan det vara svårt att få en bra överblick. Om man istället byter ut tabellen mot exempelvis ett linjediagram som visar förändringar över tid är det mycket lättare att se om eller hur något förändrats.

2.2.2 Statistiska grafer och diagram

Det finns många olika typer av statistiska grafer och diagram; punktdiagram, bubbeldiagram, linjediagram, stapeldiagram, histogram, cirkeldiagram och träddiagram är bara några, se Figur 1.

Figur 1: Fr. v. Punktdiagram, bubbeldiagram, linjediagram, stapeldiagram, histogram, cirkeldiagram, träddiagram

Något att tänka på är att det finns olika typer av data, kvalitativa och kvantitativa, och att dessa behöver hanteras på olika sätt (De Veaux, Velleman & Bock 2016). Kvalitativa data kan förklaras som data som kan kategoriseras och det kan vara både ord och siffror, exempelvis kön eller personnummer. Kvantitativa data är data som lätt kan jämföras och det handlar om siffror, ett exempel kan vara längd eller pris på något (De Veaux, Velleman & Bock 2016).

Beroende på vad man har för data kan olika diagram passa olika bra att använda. För kvalitativa data kan exempelvis cirkeldiagram eller träddiagram fungera bra medan kvantitativa data kan vara lättare att visualisera med exempelvis punktdiagram eller linjediagram.

I kvantitativa dataset kan det förekomma så kallade uteliggare, se Figur 2. En uteliggare är ett värde som avviker från de resterande i datamängden. Antingen kan avvikelsen bero på ett fel i mätningen eller datasamlingen eller så är det bara ett naturligt värde som av någon anledning skiljer sig från resten. Beroende på om det är ett korrekt men avvikande värde eller om det är ett felaktigt värde kan de hanteras på olika sätt. Om värdet är felaktigt kan man i vissa fall välja att ta bort det för att lättare kunna jämföra och analysera resterande datamängd. Om värdet däremot är korrekt måste det finnas kvar då det kan vara en indikering på att detta är extra betydelsefullt eller behöver undersökas vidare.

Figur 2: Uteliggare, här förtydligat med röd färg

(7)

4

2.2.3 Förändringsmöjligheter – förändring i realtid

Istället för att använda statistikprogram för att visualisera data och spara diagrammen som bilder att lägga ut på en hemsida kan det vara smidigt att skapa dem direkt på hemsidan.

Anledningen till att många vill lägga ut diagram på webben är ofta att man vill informera många eller göra information tillgänglig från flera olika platser och då är webben ett bra sätt att lyckas med detta eftersom det är både smidigt och snabbt.

Biologer, kemister och personer som arbetar med, och forskar inom, medicin använder ofta visualiseringsverktyg på webben för att visa data. Att rita ut genetiska kartor på webben för att smidigt kunna jämföra dem och att kunna se hur olika förändringar kan genomföras i realtid är ett exempel på hur det används (Holtz, David & Wanwez 2017).

2.3 HTML, CSS och JavaScript

HTML, CSS och JavaScript är de tre programmeringsspråk som lägger grunden för hemsidor och med dessa språk kan man göra väldigt mycket på webben. Med HTML bygger man upp grunden på sidan, det vill säga hur den ska vara uppbyggd innehållsmässigt. Med CSS stylas elementen som skapats i HTML och hur de olika elementen ska visas avgörs. Med JavaScript kan man sedan skapa funktioner och därmed mer bestämma hur sidan ska bete sig och reagera i olika situationer (W3Schools JavasScript 2018).

Liksom andra programmeringsspråk och program finns det i HTML olika versioner där uppdateringar gjorts. Några av funktionerna som implementerades i HTML5 var hantering av bland annat SVG och Canvas. Med tidigare versioner av HTML har man behövt använda andra verktyg för att rita ut vektorgrafik på webben, exempelvis Flash (Hostinger Tutorials HTML and HTML5 2018).

Canvas-funktionen i HTML5 gör att man kan rita ut grafiska element direkt i HTML med hjälp av JavaScript. Linjer, geometriska figurer, text och bilder kan nu enkelt ritas ut i Canvas (W3Schools HTML5 Canvas 2018).

2.4 JavaScriptramverk och JavaScriptbibliotek

För att underlätta arbetet med webben finns många olika ramverk och bibliotek för JavaScript.

Dessa underlättar olika delar av programmeringen och gör funktioner smidigare. Några av de vanligaste är jQuery, React och AngularJS (SitePoint Top JavaScript 2018).

Skillnaden mellan JavaScriptramverk och JavaScriptbibliotek kan förklaras enligt följande:

Ett JavaScriptramverk kan beskrivas som ett skelett eller ett skal (SitePoint Top JavaScript 2018), där grundfunktionalitet finns, såsom exempelvis hur saker lagras, men innehåll och specifik funktionalitet saknas och får skapas på annat sätt.

Ett JavaScriptbibliotek är som ett tillägg som kan användas för att få med extra funktionalitet till JavaScript. Det kan innehålla färdiga funktioner, element, animationer med mera (SitePoint Top JavaScript 2018) som kan underlätta skapandet av hemsidor.

Det är inte alltid lätt att skilja på ramverk och bibliotek, och det kanske inte alltid behövs, men

oavsett vilket, är de båda hjälpmedel som kan underlätta skapandet av hemsidor där

JavaScript används.

(8)

5

Det finns flera JavaScriptbibliotek som skapats för att visualisera statistiska data (SitePoint JavaScript Charting 2018):

Chart.js är ett open source JavaScriptbibliotek, under MIT-licensen, för diagram och grafer.

Det stödjer åtta olika diagramtyper och är responsivt för olika skärmstorlekar, det vill säga anpassar sig efter olika enheter (Chart.js 2017). Koden som används kan man hitta på deras GitHub-sida (GitHub Chart.js 2018).

Chartist.js är ett gratis diagrambibliotek som använder sig av SVG för att rita ut diagrammen på webben. Enligt deras hemsida är de flexibla och responsiva och de har riktat in sig på animationer. Animationerna fungerar dock endast i modernare webbläsare (Chartist.js 2018).

Chartist.js ligger under MIT-licensen (GitHub Chartist.js 2018).

EJS Chart är ett open source JavaScriptbibliotek som inte kräver några plugins. Enligt deras hemsida finns det ett antal inbyggda interaktiva funktioner och de stödjer XML-formatterad data. (EJS Chart 2018). Koden kan hittas på GitHub (GitHub EJS Chart 2018).

Google Charts är ett gratis diagrambibliotek som kan skapa flera olika diagramtyper.

Biblioteket ska fungera i många olika webbläsare, även lite äldre varianter. Diagram skapade med Google Charts bygger på HTML5 och SVG. Enligt deras hemsida är de även interaktiva och skalbara (Google Charts 2018). Google Charts ligger under Creative Commons Attribution 3.0-licensen (Creative Commons 3.0 2018).

Plotly.js är ett open source JavaScriptbibliotek, under MIT-licensen, för diagram och grafer.

Biblioteket är byggt på en grund av ett annat statistikbibliotek, D3.js, men det är inget som direkt märks när man använder Plotly.js. Plotly.js kan användas för 20 olika diagramtyper (Plotly 2017) och koden kan hittas på deras GitHub-sida (GitHub Plotly 2017). Företaget bakom biblioteket heter också Plotly (Plotly 2017).

Några av diagramtyperna som nämns på deras hemsida är linjediagram och cirkeldiagram, men de stödjer även mer komplicerade diagram såsom histogram, värmekartor och andra kartor av olika slag. Det går även att skapa 3D-grafer med hjälp av Plotly.js (Plotly 2017).

Smoothie Charts är ett open source-bibliotek som riktat in sig mot att visa smidiga tidslinjer

(Smoothie Charts 2018). Biblioteket ligger under MIT-licensen (GitHub Smoothie Charts

2018).

(9)

6

3 Problemformulering

Datavisualisering är något många arbetar med i olika former och utföranden. Kerren, Jusufi och Liu (2014) beskriver i sin artikel en prototyp de skapat i Java som visualiserar långsiktiga temperaturtrender och Ladstädter et al. (2010) presenterar även de väderdata, men de använder verktyget SimVis för att visualisera datan. Att visualisera data på webben är inte heller det ovanligt och det finns många olika sätt att göra detta på, bilder, HTML5 Canvas och SVG för att nämna några.

För att rita ut statistiska diagram och grafer på webben finns det ett antal JavaScriptbibliotek som fungerar på lite olika sätt och har lite olika inriktning. Beroende på vad man är ute efter och vad man vill göra kan biblioteken fungera olika bra (Li, Eickhoff & de Vries 2014). Li, Eickhoff och de Vries (2014) nämner i sin artikel några statistikbibliotek och jämför dem lite kort men kommer fram till att de befintliga biblioteken och ramverken inte är tillräckligt bra för det de vill använda dem till, så de väljer att skapa en egen variant. De nämner att vissa av de befintliga biblioteken är svåra att sätta sig in i och att man behöver en hel del programmeringskunskap för att riktigt kunna använda sig av dem. Ett annat problem de tar upp är att flera av biblioteken kräver att man matar in data manuellt, vilket de inte vill behöva göra. Detta för att ofta stora datamängder används med flera tusen värden. Till sist beskriver de också ett problem de har med att de gärna vill koppla ihop biblioteket med exempelvis Google Maps-funktioner, vilket de gör med hjälp av ramverket AngularJS. Av de bibliotek de undersökt finns det inget som helt uppfyller deras önskemål och krav.

Om man inte har tid, möjlighet eller kunskap att skapa sitt eget bibliotek kan man behöva eller vilja använda ett redan befintligt. Vad man då ska välja kan vara svårt att veta. Rahman (2018) nämner i sin artikel ett antal olika statistikbibliotek man kan välja mellan. Utifrån dessa har ett antal kriterier satts upp för JavaScriptbiblioteken som ska väljas och jämföras i detta experiment. Dessa kriterier är:

- Ska vara gratis att använda i fullversion.

- Ska vara relativt lätta att konstruera grafer i utan att vara en skicklig kodare.

- Ska kunna användas utan andra ramverk eller bibliotek.

Dessutom ska JavaScriptbiblioteken kunna jämföras för grafer skapade med samma dataset.

Att renderingstiden är relevant är för att det kan vara viktigt att kunna modifiera och interagera med diagrammen i realtid. Pris för både arbete och licenser kan vara avgörande i valet av bibliotek som ska användas. Kravet att fullversionen av biblioteket ska vara gratis är därför betydelsefullt. Arbetstid är också en betydelsefull del då det är viktigt att arbetet kommer framåt och även arbetstid kan räknas som pengar. Att biblioteket ska kunna användas utan andra ramverk eller bibliotek har satts som ett krav då det är en indikation på att biblioteket fungerar självständigt och det kan även vara en indikation på att det kräver mindre programmeringskunskap, vilket kan uppskattas av vissa användare.

Eftersom graferna ska gå att modifiera och interagera med i realtid ställs krav på

renderingstiden. Ali, Gupta, Nayak och Lenka (2016) nämner i sin artikel att det ställs mer och

mer krav på datavisualisering, bland annat på grund av mängderna data som finns. På grund

av detta kommer mätningar att genomföras för att se om det blir någon skillnad i hur lång tid

(10)

7

graferna tar att ladda beroende på hur mycket information som ligger till grund för grafen.

Liksom vad som nämns i deras artikel kommer en rekommendation ges gällande vilket bibliotek man bör välja utifrån renderingstid.

Det huvudsakliga målet med experimentet är alltså att jämföra olika JavaScriptbibliotek för visualisering av statistik för att kunna dra en slutsats om vilket av biblioteken som snabbast ritar ut diagram i allmänhet samt om det är några signifikanta skillnader i renderingstid beroende på datamängdens storlek, som ligger till grund för diagrammen. En rekommendation om vilket bibliotek man bör välja utifrån renderingstid ges också.

3.1 Frågeställningar

Frågeställningarna som besvaras genom experimentet är:

1. Vilket av biblioteken är snabbast på att rendera diagrammen?

2. Är det någon signifikant skillnad i renderingstider för diagram skapade av små respektive stora datamängder?

3.2 Hypoteser

Hypoteserna för experimentet och frågeställningarna är:

1. Det kommer inte att vara någon signifikant skillnad på renderingstiderna oavsett vilket bibliotek man använder.

2. Det kommer att ta signifikant längre tid för alla biblioteken att rendera diagram med stora datamängder.

3.3 Delmål

Ett antal delmål sätts upp för att följa experimentets gång och dessa delmål hjälper till att komma fram till experimentets stora mål och ge svar till frågeställningarna:

1. Identifiera möjliga JavaScriptbibliotek för utritning av statistiska diagram och grafer att jämföra samt utse JavaScriptbibliotek att utföra experiment på.

2. Identifiera sätt att jämföra prestation av biblioteken.

3. Utföra experiment på de valda JavaScriptbiblioteken och lagra resultat.

4. Sammanställa resultaten och presentera data från delmål 3.

5. Analysera resultatet från delmål 4 och dra slutsatser för att svara på frågeställningarna.

Genom att gå igenom och genomföra alla delmål fås svar till frågeställningarna och målet för experimentet nås.

3.4 Metodbeskrivning

Ett experiment kommer att genomföras där tiden det tar att rita likadana diagram byggda med

de olika JavaScriptbiblioteken mäts. Laddningstiderna kommer att jämföras och analyseras

för att se om någon signifikant skillnad kan ses och om detta experiment kan ge en bild av

vilket av de undersökta biblioteken som är snabbast på att rita ut diagrammen.

(11)

8

Anledningen till att just ett experiment ska genomföras är för att man i en kontrollerad miljö kan genomföra mätningar, göra någon typ av förändring och sedan mäta igen (Wohlin et al.

2012). I och med detta kan beroende och oberoende variabler mätas. På så vis kan man kontrollera de flesta delarna som påverkar genomförandet och på så sätt blir det också möjligt att utföra samma experiment flera gånger. Experiment är alltså bra att använda om man vill ta reda på varför något faktiskt är som det är, gällande kvantitativ forskning (Wohlin et al.

2012).

Om man jämför ett experiment med ett kvasiexperiment så finns det många delar som är lika, mätningar görs och något undersöks, exempelvis funktioner eller användning. Det som skiljer ett kvasiexperiment från ett experiment är att kvasiexperiment ofta sker när det inte är möjligt att genomföra ett vanligt experiment. Kvasiexperiment sker ofta i en naturlig miljö där det finns många faktorer som inte kan kontrolleras och som kan variera beroende på när studien genomförs (Wohlin et al. 2012). Detta kan medföra störningar i mätresultaten och om man kan undvika detta så gör man gärna det.

Andra undersökningsmetoder som skulle kunna användas är fallstudier och undersökningar (Wohlin et al. 2012). Dessa bygger dock oftast på personliga uppfattningar och preferenser, tidigare forskning och texter eller insamlande av data från situationer eller program som används och kan och får därför inte påverkas eller förändras.

Med andra typer av metoder än experiment kan värdefulla resultat fås, men i många fall är dessa kvalitativa snarare än kvantitativa och kan därför inte upprepas och få samma eller liknande resultat. För att få fram information om just renderingstider är därför experiment det som lämpar sig bäst då det leder till ett upprepningsbart resultat med kvantitativa data där miljön för experimentet kontrolleras.

Tilläggas ska att experiment inte helt och hållet kan bevisa att hypotesen som satts upp stämmer. Resultaten från experiment kan endast stödja hypotesen då det finns många delar som kan påverka processen (Berndtsson et al. 2008).

3.5 Tillvägagångssätt

För att kunna genomföra experimentet väljs först ett antal JavaScriptbibliotek ut baserat på kriterielistan som nämnts under Problemformulering. Sedan byggs hemsidor upp, en för varje JavaScriptbibliotek som testas, och efter det ritas de olika diagrammen ut.

Datan som ligger till grund för diagrammen kommer att skilja mellan punkt- och linjediagrammen jämfört med stapeldiagrammen då det är kvantitativ data som visualiseras med punkt- och linjediagram men det är kvalitativ data som visas med stapeldiagram.

Först skapas de minsta punkt- och linjediagrammen, med ca 30 punkter i sig, och de minsta stapeldiagrammen, med 12 staplar baserade på 365 värden, och mätningar sker. Sidorna laddas om många gånger, för att få så många mätresultat som möjligt att utgå ifrån för analysen, och mätresultaten lagras till dess i en extern fil.

Efter de första diagrammen skapas nästa i storleksordning, alltså punkt- och linjediagram

med ca 365 punkter och stapeldiagram med 12 staplar baserade på ca 730 värden. Likadana

mätningar sker för dessa diagram och resultaten lagras. Sedan görs samma procedur med

punkt- och linjediagram med ca 1 285 punkter och ca 9 125 punkter samt stapeldiagram med

12 staplar baserade på ca 36 500 värden och ca 73 000 värden. Även stapeldiagram med 24

(12)

9

staplar, baserat på ca 730 värden, 48 staplar, baserat på ca 36 500 värden, och 96 staplar, baserat på ca 73 000 värden skapas och mätningar genomförs även på dessa.

Mätningarna sker med hjälp av JavaScript. En starttid lagras strax före utritandet av diagrammet och när hela diagrammet är utritat lagras även en sluttid. Tiderna lagras i en extern fil på en server för att dessa data inte ska påverka resultaten alltför mycket.

Anledningen till att mätningen genomförs och att resultaten jämförs och analyseras är för att se om några slutsatser kan dras från experimentet. Om det blir signifikanta skillnader mellan de olika biblioteken kan det påverka eventuella val av vilket bibliotek man kommer att använda i framtiden för just det här användningsområdet.

Datasetet, som kommer från Bolin Centre for Climate Research (Bolin Centre for Climate Research 2018), som ligger till grund för diagrammen listar medeltemperaturer i Stockholm mellan åren 1756-2016. Medelvärdena för varje dag finns listade och då detta blir väldigt många värden kommer utdrag ur datasetet att användas i experimentet. Datasetet beskrivs och diskuteras mer i en artikel av Moberg, Bergström, Ruiz Krigsman och Svanered (2002).

För de små punkt- och linjediagrammen kommer en månads temperaturer att visas (ca 30 värden), för en lite större variant visas ett års medeltemperaturer (ca 365 värden), en ännu lite större variant tar upp fem års värden (ca 1 825 värden) och till sist kommer hela 25 års medeltemperaturer att visas (ca 9 125 värden). För stapeldiagrammen kommer ett års värden (ca 365 värden) att delas in i 12 kategorier som blir varsin stapel. Det andra stapeldiagrammet visar liknande data som det första men två års värden visas i samma diagram i totalt 12 staplar (ca 730 värden). Även i det tredje diagrammet visas 12 staplar, men det baseras på 100 års värden istället för bara ett års (ca 36 500 värden) och det fjärde är likt det andra diagrammet men för två 100 års-perioder visas ca 73 000 värden i 12 staplar. De femte, sjätte och sjunde stapeldiagrammen bygger på samma data som andra, tredje och fjärde stapeldiagrammen, men datan visas istället i 24 staplar, 48 staplar eller 96 staplar. Anledningen till att samma data används till flera stapeldiagram med olika antal staplar är för att undersöka om datamängden eller antalet staplar påverkar prestandan mest.

Samma månads värden kommer att användas för alla bibliotekens sidor och för de tre olika diagramtyperna. Anledningen till att samma värden används för de olika sidorna är för att det ska bli lättare att jämföra resultaten. Ju fler delar som är konstanta, desto lättare är det att påvisa att det är just en viss del som påverkar mätningen.

Varje diagram skapas alltså i de olika biblioteken. De olika diagramtyperna som skapas är:

- Punktdiagram - Linjediagram - Stapeldiagram

Varje diagramtyp skapas även i flera varianter, med olika antal punkter (olika stor

datamängd):

(13)

10 Punkt- och linjediagram:

- ca 30 punkter/värden - ca 365 punkter/värden - ca 1 825 punkter/värden - ca 9 125 punkter/värden

Stapeldiagram:

- 12 staplar (Baserat på ca 365 värden) - 12 staplar (Baserat på ca 730 värden) - 12 staplar (Baserat på ca 36 500 värden) - 12 staplar (Baserat på ca 73 000 värden) - 24 staplar (Baserat på 730 värden) - 48 staplar (Baserat på 36 500 värden) - 96 staplar (Baserat på 73 000 värden)

Renderingstiden mäts för varje diagram. Tiden startas före utritningen och stoppas så fort diagrammet är helt utritat. Tidsresultaten sparas i en extern fil.

Tidsresultaten jämförs och analyseras.

3.6 Etiska aspekter

Många mätningar genomförs för att tydligare kunna påvisa statistiska mönster (Wohlin et al.

2012) och alla mätresultat sparas och redovisas innan eventuella utstickande värden, som tydligt visar sig vara felvärden, sållas bort. Är det inte tydligt att det är felvärden så sparas de.

Inga antaganden gällande värden eller resultat görs utan tydliga grunder och motiveringar (Wohlin et al. 2012).

All kod som används för experimentet sparas, och kan hittas på GitHub (GitHub Examensarbete 2018), och tillvägagångssätt och resultat beskrivs vilket medför att experimentet blir upprepningsbart och visar också att resultaten inte manipulerats för någon typ av vinning (Cai et al. 1998). I rapporten refereras även all text som är hämtad eller inspirerad från andra källor för att ge lämplig uppskattning till dessa.

Datasetet som ligger till grund för diagrammen i experimentet kommer från Bolin Centre for Climate Research (Bolin Centre for Climate Research 2018) och det används för att det ger stora mängder data som faktiskt har en verklig koppling till något samtidigt som det inte har något att göra med någon personlig information. Datasetet ligger på centrets hemsida och är därför redan öppet för allmänheten, men de har även kontaktats för att säkerställa att informationen får användas och publiceras i samband med det här arbetet. Diagram med olika stora datamängdsgrunder skapas också för att få mer bredd i experimentet och resultatet.

För att diagrammen ska vara lätta att tolka är dessa färglagda med olika färger. Detta kan

eventuellt vara svårt att uppfatta för färgblinda. Om hänsyn ska tas till det i alla diagram blir

arbetet mer begränsat men diagrammen och färgvalen försöker göras så tydliga som möjligt.

(14)

11

4 Relaterad forskning

Det är många som forskar om liknande problemområden, både gällande visualisering och statistik, och det är många som använder liknande mätmetoder. Detta arbete baseras till viss del på tidigare forskning och i detta kapitel nämns några relevanta artiklar och arbeten.

McCoy, Austin och Slaughter (2010) beskriver i sin artikel hur de använt HTML, JavaScript och PHP för att visa hur tjock isen på Grönland är. De har valt att utgå ifrån mätdata från CreSIS och har utifrån dessa skapat en sida där de, med hjälp av bland annat Google Maps, visualiserar istjocklek. Experimentet som genomförs i detta arbete utgår ifrån en liknande idé.

Istället för istjocklek på Grönland visas lufttemperaturer i Stockholm och då visualiseras inte geografisk position. McCoy, Austin och Slaughter (2010) har också implementerat en interaktionsdel där de har lagt till en funktion som gör att man kan välja vilket år och vilken dag man vill se istjockleken på Grönland för.

Även Kerren, Jusufi och Liu (2014) visualiserar väderrelaterad data. De beskriver i sin artikel en prototyp de skapat i Java som visualiserar långsiktiga temperaturtrender. Programmet är interaktivt och tänkt att kunna användas till olika typer av väderdata. Ladstädter et al. (2010) skriver också om visualisering av väderdata och de tar upp att man kan se mönster i visualiseringen och ta fram hypoteser om datan utifrån detta. De har haft en relativt innovativ inställning till data och visualisering av dessa och har använt sig av verktyget SimVis för att visa upp informationen. Ladstädter et al (2010) nämner även vikten av analyser av uteliggare och att dessa kan berätta mycket viktigt om datamängden.

Aigner, Miksch, Müller, Schumann och Tominski (2008) beskriver i sin artikel hur olika tidsramar för insamling av data kan påverka visualisering av dessa. De nämner även hur olika visualiseringsmetoder passar olika bra till olika typer av data. De stora mängder data som finns ställer mer och mer krav på datavisualisering vilket nämns i Ali, Gupta, Nayak och Lenkas (2016) artikel. De tar även upp och jämför några olika program som kan användas för att visualisera data.

Li, Eickhoff och de Vries (2014) jämför, som nämnts i tidigare kapitel, olika JavaScriptbibliotek för visualisering av statistiska data men väljer att skapa en egen variant då de befintliga biblioteken inte lever upp till deras krav. Några av problemen de stöter på är att biblioteken kan vara svåra att sätta sig in i, att data behöver matas in manuellt och att de inte går att koppla ihop med Google Maps-funktioner.

Anttonen, Salminen, Mikkonen och Taivalsaari (2011) tar i sin artikel upp hur webben har

förändrats under åren och att det i dagsläget ställs mer och mer krav på prestanda, att det

används fler och fler applikationer och plug-ins samt att interaktion på sidorna blir vanligare

och allt mer viktigt. Att renderingstid är viktigt beskriver även Takama, Niibori, Okamoto,

Kamada och Yonekura (2012) i sin artikel där de tar upp hur man kan lära barn att

programmera och hur spel kan hjälpa inlärning. De beskriver hur barn har fått skapa spel,

exempelvis ett där man ska klicka för att släppa ner vatten på en eld som brinner.

(15)

12

5 Genomförande

För att få svar på frågeställningarna, nämnda i 3.1 Frågeställningar, genomförs ett experiment utifrån delmålen och tillvägsgångssättet nämnt i tidigare kapitel, 3.3 Delmål och 3.5 Tillvägagångssätt. I detta kapitel beskrivs mer exakt hur experimentet genomförs.

5.1 Val av JavaScriptbibliotek

De bibliotek som nämns i Rahmans (2018) artikel och som stämmer överens med de grundläggande kriterierna, se 3 Problemformulering eller Tabell 1, är Google Charts, Chart.js, Chartist.js, Smoothie Charts, EJS Charts och Plotly.js.

Tabell 1: JavaScriptbibliotek kopplat till kriterier för experimentet

JavaScriptbibliotek Ska vara gratis att använda i fullversion

Ska vara relativt lätta att konstruera grafer i utan att vara

en skicklig kodare

Ska kunna användas utan andra ramverk

eller bibliotek

D3.js Ja Nej Ja

Google Charts Ja Ja Ja

Chart.js Ja Ja Ja

Chartist.js Ja Ja Ja

n3-charts Ja Nej Nej

Ember Charts Ja Nej Nej

Smoothie Charts Ja Ja Ja

Chartkick Ja Nej Nej

ZingChart Nej Ja Ja

Highcharts JS Nej Ja Ja

Fusioncharts Nej Ja Ja

Flot Ja Nej Nej

amCharts Nej Ja Ja

EJS Chart Ja Ja Ja

uvCharts Ja Ja Nej

Plotly.js Ja Ja Ja

Ett kriterium till som nämns är att JavaScriptbiblioteken ska vara jämförbara med samma

dataset. Detta presenteras i Tabell 2. Chartist.js har valts bort då det är inriktat på

animeringar, Smoothie Charts har valts bort på grund av dess inriktning på realtidsdata och

(16)

13

EJS Charts har valts bort för att det behöver laddas ner för att användas. Kvar är tre av de bibliotek de även nämner i Li, Eickhoff och de Vries (2014) artikel. Dessa tre är Google Charts, Chart.js och Plotly.js.

Tabell 2: JavaScriptbibliotek jämförbara med samma dataset JavaScriptbibliotek

Jämförbara med

samma dataset

Google Charts Ja

Chart.js Ja

Chartist.js Nej

Smoothie Charts Nej

EJS Chart Nej

Plotly.js Ja

5.2 Jämförelse av biblioteken

Experimentet som genomförs jämför renderingstid för de tre biblioteken för olika diagramtyper av olika storlek. Hur detta görs beskrivs nedan:

För varje diagram lagras två starttider som variabler. Den ena är i början av hela koden och mäter alltså hur lång tid det tar att genomföra alla funktioner. Den andra starttiden är för utritningen och startar alltså precis innan utritningen börjar. Så fort utritningen är klar lagras även en sluttid som en variabel och när alla funktioner i hela koden genomförts lagras även en sluttid för det. Alla fyra variablerna sparas sedan i en extern fil. När en mätgenomgång är avslutad laddas sidan om och proceduren upprepas. Detta sker så många gånger som möjligt, så många gånger som hinns med under en viss tid. Detta görs för att få så många mätresultat som möjligt att basera analys och slutsats på. Anledningen till att tid för både utritning och hela koden mäts är för att se om det är själva utritningen som tar längst tid eller om det är andra delar, så som exempelvis att hämta data att visualisera från XML-filen.

5.3 Experiment på biblioteken

Först skapas grafer med de tre olika biblioteken, Plotly.js, Google Charts och Chart.js, för att

se vilka skillnader som finns mellan dem. Kodexempel visas i Figur 3, Figur 4, Figur 5 och

Figur 6. För de första graferna som skapas läggs data in för hand för att se att allt fungerar

som det ska. Som kan ses i figurerna nedan skiljer sig de tre biblioteken lite från varandra och

vissa anpassningar görs i hur data från XML-filen hämtas och används.

(17)

14

Figur 3: Plotly.js kodexempel

Figur 3 visar ett exempel där Plotly.js används för att skapa ett linjediagram som visar

temperaturdata från Stockholm januari 1900. Detta är samma data som ligger till grund för

Linjediagram 1, se Appendix A.

(18)

15

Figur 4: Google Charts kodexempel (Del 1 av 2)

(19)

16

Figur 5: Google Charts kodexempel (Del 2 av 2)

Figur 4 och Figur 5 visar hur Google Charts kod för samma sak som Figur 3 ser ut. Hur

diagrammet som skapas ser ut syns i Linjediagram 1 i Appendix D.

(20)

17

Figur 6: Chart.js kodexempel

Figur 6 visar kod som med Chart.js visualiserar temperaturdata för Stockholm under januari 1900, precis som Figur 3 gör i Plotly.js och Figur 4 och Figur 5 gör i Google Charts.

Diagrammet som skapas med koden i Figur 6 visas i Linjediagram 1 i Appendix G. När de tre figurerna jämförs kan man se att de olika biblioteken, trots att de visar samma data, använder olika format på data för visualiseringen.

De olika diagrammen, som beskrivs i 3.5 Tillvägagångssätt, alltså linjediagram, punktdiagram och stapeldiagram, skapas alltså med Plotly.js, Google Charts och Chart.js. Data som ligger till grund för diagrammen hämtas direkt från en XML-fil. Hur alla diagram ser ut visas i Appendix A till Appendix I och koden kan hittas på GitHub (GitHub Examensarbete 2018).

Linjediagram 1 och punktdiagram 1 visar temperaturskillnader i Stockholm för januari 1900.

Linjediagram 2 och punktdiagram 2 visar temperaturskillnaderna för Stockholm år 1900.

Linjediagram 3 och punktdiagram 3 visar temperaturer under åren 1900-1905 i Stockholm.

Linjediagram 4 och punktdiagram 4 visar temperaturförändringen under åren 1900-1925.

(21)

18

Stapeldiagram 1 visar antalet dagar under år 1900 som ligger i respektive temperaturintervall.

Stapeldiagram 2 visar antalet dagar som ligger i respektive temperaturintervall både under år 1900 och år 2000.

Stapeldiagram 3 visar antalet dagar som ligger i respektive temperaturintervall under tidsperioden 1900-2000.

Stapeldiagram 4 visar antalet dagar som ligger i respektive temperaturintervall för tidsperioden 1800-2000.

Stapeldiagram 5 visar antalet dagar som ligger i respektive temperaturintervall för år 1900 och år 2000.

Stapeldiagram 6 visar antalet dagar som ligger i respektive temperaturintervall för år 1900- 2000. Staplarna är uppdelade så att de visar 25-års-intervall.

Stapeldiagram 7 visar antalet dagar som ligger i respektive temperaturintervall för år 1800- 2000. Staplarna är uppdelade så att de visar 25-års-intervall.

Vilka årtal varje stapel visar presenteras i Tabell 3, Tabell 4 och Tabell 5.

Tabell 3: Stapeldiagram 5 - beskrivning

Stapeldiagram 5 Chart.js Google Charts Plotly.js

1900 Röd Grön Blå

2000 Turkos Lila Orange

Tabell 4: Stapeldiagram 6 - beskrivning

Stapeldiagram 6 Chart.js Google Charts Plotly.js

1900-1925 Röd Grön Blå

1925-1950 Orange Blå Orange

1950-1975 Grön Röd Grön

1975-2000 Mörkturkos Orange Röd

Tabell 5: Stapeldiagram 7 - beskrivning

Stapeldiagram 7 Chart.js Google Charts Plotly.js

1800-1825 Röd Grön Blå

1825-1850 Orange Blå Orange

1850-1875 Grön Röd Grön

1875-1900 Mörkturkos Orange Röd

1900-1925 Ljusröd Turkos Lila

1925-1950 Ljusorange Ljusblå Brun

1950-1975 Ljusgrön Ljusröd Rosa

1975-2000 Turkos Ljusorange Grå

(22)

19

Enligt dokumentationen på Chart.js hemsida (Chart.js Scatter Chart 2018) ska punktdiagram kunna skapas med hjälp av att sätta diagramtypen till ”scatter” men resultatet av det visas i Figur 7. Då det som visas i Figur 7 inte är ett punktdiagram och det inte heller har efterfrågad färg skapades istället punktdiagram genom att sätta diagramtypen till ”line”, precis som ett linjediagram. För att få det att visas som ett punktdiagram göms linjerna och punkterna fylls i mer för att göra dem tydligare. Linjediagrammen i Chart.js, som visas i Appendix G, har även de små punkter för att visa datapunkterna tydligare men de är inte lika markerade som i punktdiagrammen, som visas i Appendix H.

Figur 7: Chart.js Ej punktdiagram

5.4 Progression

Först skapas testdiagram i de olika biblioteken för att se så att allt fungerar bra. I dessa skrivs värdena in för hand vilket snabbt blir arbetsamt och tidskrävande vilket leder till att en XML- fil skapas utifrån textfilen med data från Bolin Centre for Climate Research (2018). Med hjälp av XML-filen hämtas sedan data automatiskt till diagrammen.

Stapeldiagrammen skapas till en början på samma sätt som punkt- och linjediagrammen

vilket resulterar i att diagrammen ser ut som nedan. Då stapeldiagram inte vanligtvis ritas så

här görs en ändring och nya diagram skapas, se tidigare stapeldiagram. De första

stapeldiagrammen, Figur 8, Figur 9 och Figur 10, ser mer ut som konstiga, kantiga och ifyllda

linjediagram. Eftersom det finns begränsat med utrymme för diagrammen minskas

mellanrummen mellan staplarna och de ser inte längre ut som tydliga stapeldiagram utan mer

som ifyllda linjediagram, vilket visas tydligast i Figur 10 om man inte ser det i ett

sammanhang, alltså ihop med Figur 8 och Figur 9.

(23)

20

Figur 8 visar temperaturförändringar i Stockholm för januari 1900.

Figur 9 visar temperaturskillnaderna för Stockholm år 1900.

Figur 10 visar temperaturförändringen under åren 1900-1925.

Figur 8: Stapeldiagram 1 före förändring

Figur 9: Stapeldiagram 2 före förändring

Figur 10: Stapeldiagram 3 före förändring

Stapeldiagrammen förändras, än en gång, för att bättre kunna jämföra och utvärdera om det är skillnader i mättider för de olika diagrammen. Om skillnader förekommer är det då datamängden som bygger upp diagrammen eller antalet staplar som har störst påverkan på mättiderna.

Utritningstiden mäts med hjälp av två variabler, en som lagrar starttid och en som lagrar

sluttid. Detta var först det enda som mättes men då en tydlig laddningstid syntes med

(24)

21

användarens blotta öga lades även två variabler till som mäter hela processen, alltså även hämtning av data från XML-filen och liknande. Detta görs för att lättare se om det är själva utritningen som tar tid eller om det är någon annan del i processen.

5.5 Pilotstudie

En pilotstudie genomförs för att se till så att alla filer är som de ska vara och så att mätningarna fungerar och kan jämföras. I pilotstudien görs korta mätningar och resultaten från de olika Plotly.js-diagrammen slås ihop, liksom alla Google Charts-mätningar och mätningarna på Chart.js. Detta resulterar i tre delar som jämförs här.

Utritningstiderna för de olika biblioteken jämförs med ett ANOVA-test (en faktor) baserat på 90 mätresultat från varje bibliotek. Resultatet från ANOVA-testet presenteras i Tabell 6.

Utifrån ANOVA-testet skapas även diagram där standardfel och konfidensintervall visas, se Figur 11 och Figur 12. Konfidensintervallen visar var kommande mätningars resultat borde hamna utifrån denna mätning. Notera att variansen för Plotly.js är stor och att fler mätningar behöver genomföras för att få stabilare och bättre värden. P-värdet, som är mindre än alfavärdet 0,5 visar att det är en signifikant skillnad mellan biblioteken i pilotstudien. För att undersöka detta vidare och ta reda på vilket eller vilka av biblioteken som skiljer sig från resten görs ett Tukey-test. Resultatet från det presenteras i Tabell 7, där sant visar på signifikant skillnad och falskt visar ingen signifikant skillnad. Tukey-testet för pilotstudien visar att Chart.js skiljer sig från både Google Charts och Plotly.js.

Tabell 6: Pilotstudie - ANOVA

ANOVA: En faktor Alfa 0,05

SAMMANFATTNING

Grupper Antal Summa Medelvärde Varians

Chart.js 90 9 869,600 109,662 18 751,399

Google Charts 90 25 097,500 278,861 39 780,755

Plotly.js 90 22 495,200 249,947 131 594,870

ANOVA

Variationsursprung KvS fg MKv F p-värde F-krit

Mellan grupper 1 474 321,034 2 737 160,517 11,632 1,43392E-05 3,030

Inom grupper 16 921 305,149 267 63 375,675

Totalt 18 395 626,183 269

(25)

22

Figur 11: Medelvärde med standardfel baserat på ANOVA-test för pilotstudien

Figur 12: Medelvärde med konfidensintervall baserat på ANOVA-test för pilotstudien

Tabell 7: Pilotstudie - Tukey-test

Tukey-test Chart.js Google Charts Plotly.js

Chart.js - - -

Google Charts SANT - -

Plotly.js SANT FALSKT -

0,000 50,000 100,000 150,000 200,000 250,000 300,000 350,000

Chart.js Google Charts Plotly.js

Tid (ms)

Medelvärde med standardfel

0,000 50,000 100,000 150,000 200,000 250,000 300,000 350,000

Chart.js Google Charts Plotly.js

Tid (ms)

Medelvärde med kondidensintervall

(26)

23

6 Utvärdering

Mätningar genomförs likt beskrivet i avsnitt 5 Genomförande, där varje mätsession har fortgått i minst 3 timmar. Som minst har 1 895 mätpunkter lagrats för en mätsession och som mest har ca 20 300 resultat lagrats för en mätning. Resultaten för de olika mätningarna har lagrats och eventuella uteliggare, alltså enstaka utstickande och felaktiga värden, har tagits bort. Endast mycket utstickande värden har tagits bort, och endast om de varit ett fåtal som inte visat på något mönster. Mindre än en procent av de insamlade värdena har tagits bort då de ansetts tillräckligt avvikande. Ett exempel på hur borttagningen av uteliggare, även kallade spikar, kan se ut visas i figurerna nedan. Figur 13 visar hur en mätning kan se ut och Figur 14 visar hur samma mätdata kan se ut efter att uteliggare tagits bort.

Figur 13: Mätresultat original

Figur 14: Mätresultat efter borttagning av spikar 0

100 200 300 400 500 600 700 800 900

1 186 371 556 741 926 1111 1296 1481 1666 1851 2036 2221 2406 2591 2776 2961 3146 3331 3516 3701 3886 4071 4256 4441 4626 4811 4996

Tid (ms)

Mätning

Utritningstid

0 10 20 30 40 50 60

1 186 371 556 741 926 1111 1296 1481 1666 1851 2036 2221 2406 2591 2776 2961 3146 3331 3516 3701 3886 4071 4256 4441 4626 4811 4996

Tid (ms)

Utritningstid

(27)

24

Beskrivande statistik tas fram baserat på den nya resultatsammanställningen med bland annat medelvärden, standardavvikelse, varians, maximum- och minimumvärden samt konfidensnivåer och ett ANOVA-test görs. Utifrån dessa skapas två varianter av stapeldiagram som visar medelvärden med standardavvikelser och medelvärden med konfidensintervall.

Dessa stapeldiagram presenteras i Appendix J till Appendix L. Utifrån mätdatan görs jämförelser och resultaten analyseras.

Post-hoc t-test genomförs för alla jämförelser, som presenteras i diagrammen i Appendix M till Appendix P, för att se om det är några signifikanta skillnader mellan de olika JavaScriptbiblioteken. Tabellerna för dessa presenteras i Appendix M till Appendix O. ”SANT”

innebär att det är signifikant skillnad i utritningstid och ”FALSKT” innebär att det inte är någon signifikant skillnad.

6.1 Analys

Baserat på diagrammen i Appendix J till L har följande diagram skapats för att få en bättre överblick. Figur 15 och Figur 16 visar en sammanställning av medelvärden av mättider för linjediagram 1-4. Som graferna visar kan man tydligt se att utritningstiderna ökar för alla tre biblioteken för linjediagram med större datamängd.

Figur 15: Linjediagram (medelvärde med standardavvikelse) 0

50 100 150 200 250 300 350 400 450 500

Linje 1 Linje 2 Linje 3 Linje 4

Tid (ms)

Linjediagram (medelvärde med standardavvikelse)

Chart.js Google Charts Plotly.js

(28)

25

Figur 16: Linjediagam (medelvärde med konfidensintervall)

Figur 17 och Figur 18 visar utritningstider för punktdiagram och för dessa följs samma mönster som för linjediagrammen, även här ökar alltså utritningstiderna för diagram baserade på större datamängd för alla tre JavaScriptbiblioteken.

Figur 17: Punktdiagram (medelvärde med standardavvikelse) 0

50 100 150 200 250 300 350 400 450 500

Linje 1 Linje 2 Linje 3 Linje 4

Tid (ms)

Linjediagram (medelvärde med konfidensintervall)

Chart.js Google Charts Plotly.js

0 200 400 600 800 1000 1200 1400

Punkt 1 Punkt 2 Punkt 3 Punkt 4

Tid (ms)

Punktdiagram (medelvärde med standardavvikelse)

Chart.js Google Charts Plotly.js

(29)

26

Figur 18: Punktdiagram (medelvärde med konfidensintervall)

Figur 19 och Figur 20 visar medelvärdena för stapeldiagrammens utritningstider.

Stapeldiagrammen skiljer sig dock lite från linje- och punktdiagrammen då de är skapade med andra datamängder. Stapeldiagram 1 till 4 har samma antal staplar, 12 stycken, men olika stor datamängd som ligger till grund för dem, från ca 365 värden upp till ca 73 000 värden.

Stapeldiagram 5 till 7 å andra sidan har olika antal staplar, 24, 48 respektive 96 stycken, men samtidigt ökar datamängden, från ca 730 värden upp till ca 73 000 värden.

Figur 19: Stapeldiagram (medelvärde med standardavvikelse) 0

100 200 300 400 500 600 700 800 900 1000

Punkt 1 Punkt 2 Punkt 3 Punkt 4

Tid (ms)

Punktdiagram (medelvärde med konfidensintervall)

Chart.js Google Charts Plotly.js

0 50 100 150 200 250

Stapel 1 Stapel 2 Stapel 3 Stapel 4 Stapel 5 Stapel 6 Stapel 7

Tid (ms)

Stapeldiagram (medelvärde med standardavvikelse)

Chart.js Google Charts Plotly.js

(30)

27

Figur 20: Stapeldiagram (medelvärde med konfidensintervall)

För att lättare kunna jämföra stapeldiagrammen baserat på antal staplar kontra datamängd och försöka avgöra vilket som påverkar utritningstiden mest skapas diagrammen i Figur 21 och Figur 22. Till skillnad från linje- och punktdiagrammen ses inte några direkta samband mellan de olika mätningarna i Figur 21. I Figur 22 däremot syns samma utveckling som för linje- och punktdiagrammen för Chart.js och för Plotly.js syns en liknande utvecklingskurva.

Figur 21: Stapeldiagram 1-4 (medelvärde) 0

20 40 60 80 100 120 140

Stapel 1 Stapel 2 Stapel 3 Stapel 4 Stapel 5 Stapel 6 Stapel 7

Tid (ms)

Stapeldiagram (medelvärde med konfidensintervall)

Chart.js Google Charts Plotly.js

0 20 40 60 80 100 120 140

Stapel 1 Stapel 2 Stapel 3 Stapel 4

Tid (ms)

Stapeldiagram (medelvärde)

Chart.js Google Charts Plotly.js

(31)

28

Figur 22: Stapeldiagram 1 + 5-7 (medelvärde)

Som kan utläsas från Post-hoc t-test-tabellerna (som kan ses i Appendix M till Appendix P) finns det signifikanta skillnader mellan de olika JavaScriptbiblioteken för de olika diagramtyperna i alla fall förutom mellan Chart.js Linjediagram 2 och Plotly.js Linjediagram 2 och för Plotly.js Stapeldiagram 1 och Plotly.js Stapeldiagram 5.

Utifrån de jämförande stapeldiagram som presenteras i Appendix J till Appendix L (notera att skalan varierar på de olika diagrammen) har följande tabell sammanställts:

Tabell 8: Renderingstider sammanställning

Chart.js Google Charts Plotly.js

Linje 1 1 3 2

Linje 2 1 2 1

Linje 3 2 3 1

Linje 4 2 3 1

Punkt 1 1 2 3

Punkt 2 1 3 2

Punkt 3 1 3 2

Punkt 4 1 2 3

Stapel 1 1 3 2

Stapel 2 1 3 2

Stapel 3 1 3 2

Stapel 4 1 2 3

Stapel 5 1 3 2

Stapel 6 1 2 3

Stapel 7 1 2 3

1 innebär snabbast tid, 2 näst snabbast tid och 3 långsammast utritningstid.

0 20 40 60 80 100 120 140

Stapel 1 Stapel 5 Stapel 6 Stapel 7

Tid (ms)

Stapeldiagram (medelvärde)

Chart.js Google Charts Plotly.js

(32)

29

Som Tabell 8 visar har Chart.js snabbast utritningstider för de flesta diagramtyper och storlekar, Plotly.js är näst snabbast och Google Charts är långsammast av de tre.

För att se hur utritningstiden ökar för de olika diagramtyperna skapas Figur 23, Figur 24, Figur 25, Figur 26, Figur 27, Figur 28, Figur 29, Figur 30, Figur 31, Figur 32, Figur 33 och Figur 34. Linjediagram och punktdiagram skapade i Chart.js, Google Charts och Plotly.js (Figur 23 till Figur 28) följer alla en exponentiell trendlinje.

Figur 23: Chart.js Linjediagram (medelvärde med exponentiell trendlinje)

Figur 24: Google Charts Linjediagram (medelvärde med exponentiell trendlinje) 0

50 100 150 200 250 300 350 400

Linje 1 Linje 2 Linje 3 Linje 4

Tid (ms)

Chart.js - Linjediagram

0 100 200 300 400 500 600

Linje 1 Linje 2 Linje 3 Linje 4

Tid (ms)

Google Charts - Linjediagram

(33)

30

Figur 25: Plotly.js Linjediagram (medelvärde med exponentiell trendlinje)

Figur 26: Chart.js Punktdiagram (medelvärde med exponentiell trendlinje) 0

20 40 60 80 100 120 140 160 180 200

Linje 1 Linje 2 Linje 3 Linje 4

Tid (ms)

Plotly.js - Linjediagram

0 50 100 150 200 250

Punkt 1 Punkt 2 Punkt 3 Punkt 4

Tid (ms)

Chart.js - Punktdiagram

(34)

31

Figur 27: Google Charts Punktdiagram (medelvärde med exponentiell trendlinje)

Figur 28: Plotly.js Punktdiagram (medelvärde med exponentiell trendlinje)

Stapeldiagrammen visar, till skillnad från linje- och punktdiagrammen, inte samma koppling och utveckling. Figur 29 visar ingen direkt trend i utritningstid. Figur 26 visar en ökning i renderingstid för diagram med fler staplar. Ökningen verkar dock inte följa samma exponentiella kurva som linje- och punktdiagrammen.

0 100 200 300 400 500 600 700 800

Punkt 1 Punkt 2 Punkt 3 Punkt 4

Tid (ms)

Google Charts - Punktdiagram

0 100 200 300 400 500 600 700 800 900 1000

Punkt 1 Punkt 2 Punkt 3 Punkt 4

Tid (ms)

Plotly.js - Punktdiagram

(35)

32

Figur 29: Chart.js Stapeldiagram 1-4 (medelvärde med trendlinje)

Figur 30: Chart.js Stapeldiagram 1 + 5-7 (medelvärde med trendlinje)

Figur 31 och Figur 32 visar inte heller någon trend i renderingstid men de två diagrammen är relativt lika varandra i utformning.

0 2 4 6 8 10 12 14 16

Stapel 1 Stapel 2 Stapel 3 Stapel 4

Tid (ms)

Chart.js - Stapeldiagram 1-4

0 5 10 15 20 25 30

Stapel 1 Stapel 5 Stapel 6 Stapel 7

Tid (ms)

Chart.js - Stapeldiagram 1 + 5-7

(36)

33

Figur 31: Google Charts Stapeldiagram 1-4 (medelvärde med trendlinje)

Figur 32: Google Charts Stapeldiagram 1 + 5-7 (medelvärde med trendlinje)

Figur 33 visar en ökning i renderingstid baserat på mängden data som ligger till grund för diagrammen. Dock avviker Stapeldiagram 3 (i Figur 33 visat som Stapel 3) från mönstret.

Figur 34 visar även den en ökning i renderingstid för diagram skapade med större datamängd där även fler staplar presenteras. Stapeldiagram 5 (i Figur 34 visat som Stapel 5) avviker något från trenden.

0 20 40 60 80 100 120 140

Stapel 1 Stapel 2 Stapel 3 Stapel 4

Tid (ms)

Google Charts - Stapeldiagram 1-4

0 20 40 60 80 100 120 140

Stapel 1 Stapel 5 Stapel 6 Stapel 7

Tid (ms)

Google Charts - Stapeldiagram 1 + 5-7

(37)

34

Figur 33: Plotly.js Stapeldiagram 1-4 (medelvärde med trendlinje)

Figur 34: Plotly.js Stapeldiagram 1 + 5-7 (medelvärde med trendlinje)

6.2 Slutsatser

För att slutligen återkomma till, och svara på, frågeställningarna från 3.1 Frågeställningar:

1. Vilket av biblioteken är snabbast på att rendera diagrammen?

2. Är det någon signifikant skillnad i renderingstider för diagram skapade av små respektive stora datamängder?

Som tydligt ses i Tabell 8, på sidan 28, är Chart.js snabbast på att rendera diagrammen, vilket svarar på frågeställning 1. Näst snabbast är Plotly.js och Google Charts kommer på sista plats.

0 20 40 60 80 100 120

Stapel 1 Stapel 2 Stapel 3 Stapel 4

Tid (ms)

Plotly.js - Stapeldiagram 1-4

0 10 20 30 40 50 60 70 80 90

Stapel 1 Stapel 5 Stapel 6 Stapel 7

Tid (ms)

Plotly.js - Stapeldiagram 1 + 5-7

(38)

35

Gällande frågeställning 2 syns en ökning i renderingstid för diagram skapade med stora datamängder jämfört med diagram skapade med små datamängder. Detta verifieras också av post-hoc t-testerna som presenteras i Appendix M till P.

För att återkoppla till de ursprungliga hypoteserna kan nämnas att hypotes 1, ” Det kommer

inte att vara någon signifikant skillnad på renderingstiderna oavsett vilket bibliotek man

använder”, inte stämmer; Det var signifikanta skillnader på renderingstiderna för de olika

biblioteken. Däremot stämmer hypotes 2, ”Det kommer att ta signifikant längre tid för alla

biblioteken att rendera diagram med stora datamängder”.

(39)

36

7 Avslutande diskussion

I detta kapitel kopplas hela studien ihop. Problemformulering, frågeställningar, hypoteser, delmål och genomförande leder till en utvärdering med jämförelser och en analys av resultaten. Hur arbetet genomförts diskuteras, eventuella funderingar tas upp, etiska frågor berörs och idéer för framtida arbete nämns.

7.1 Sammanfattning

Målet med denna studie var att undersöka vilket JavaScriptbibliotek som snabbast ritar ut statistiska grafer och diagram och att undersöka om det är någon skillnad i renderingstider för diagram skapade med olika stor datamängd. För att få svar på frågeställningarna sattes fem delmål upp.

Delmål 1, ”Identifiera möjliga JavaScriptbibliotek för utritning av statistiska diagram och grafer att jämföra samt utse JavaScriptbibliotek att utföra experiment på”, har genomförts genom att ta fram bibliotek som överensstämmer med kriterierna som satts upp. De som utsågs var Chart.js, Google Charts och Plotly.js.

Delmål 2, ”Identifiera sätt att jämföra prestation av biblioteken”, uppfylls genom mätningen av utritningstid, och därigenom prestanda, som genomförts för diagram skapade med de olika biblioteken.

Delmål 3, ”Utföra experiment på de valda JavaScriptbiblioteken och lagra resultat”, har gjorts genom att lagra en starttid och en sluttid för utritningen av olika diagram, linjediagram, punktdiagram och stapeldiagram av olika storlek. Dessa mätresultat har skickats till externa filer.

Delmål 4, ”Sammanställa resultaten och presentera data från delmål 3”, har uppnåtts genom att resultaten från mätningarna sparats i textfiler som sedan har sammanställts i Excel för att lättare kunna jämföra resultaten.

Delmål 5, ”Analysera resultatet från delmål 4 och dra slutsatser för att svara på frågeställningarna”, är det sista delmålet som satts upp. Resultaten ska där analyseras för att kunna ge svar på frågeställningarna, ”Vilket av biblioteken är snabbast på att rendera diagrammen?” och ”Är det någon signifikant skillnad i renderingstider för diagram skapade av små respektive stora datamängder?”.

Från resultaten som samlats in har uteliggare tagits bort och resterande mätresultat har jämförts mellan de tre biblioteken, Chart.js, Google Charts och Plotly.js, och mellan de olika diagramtyperna. Biblioteken har också jämförts baserat på olika datamängder som byggt upp de olika diagrammen.

Analysen av mätningarnas resultat visar att Chart.js är snabbast av de tre

JavaScriptbiblioteken på att rendera diagram i allmänhet. Näst snabbast är Plotly.js och sist

kommer Google Charts. Analysen visar också att större datamängd som ligger till grund för

linje- och punktdiagram leder till längre renderingstid för alla tre biblioteken. Även för

stapeldiagrammen var det signifikant skillnad för de olika diagrammen men ytterligare

undersökningar behövs för att se om någon trend kan urskiljas.

References

Related documents

Den kategoriseringsprocess som kommer till uttryck för människor med hög ålder inbegriper således ett ansvar att åldras på ”rätt” eller ”nor- malt” sätt, i handling

En av förskolans väsentliga uppgifter är att ta tillvara utvecklingsmöjligheter och anlag hos barn från alla slags miljöer och låta dem komma till fullt uttryck i

Men public service skiljer sig från de kommersiella kanalerna när det gäller tittarsiffror som en variabel för utbudet på så sätt att det inte behöver vara styrande

Dessutom anser hälften av alla som svarar på enkäten att processverktyget skulle underlätta deras arbete i detta projektet genom att skapa en bättre förståelse

Syftet med arbetet var att ta fram ett verktyg till Swepos användare för att se kvaliteten på referensstationerna och detta ledde in på frågeställningen hur stationsrörelser

De varumärkeselement som finns hos Sia är enligt oss och vår undersökning av Sias medier namnet Sia, musiken, peruken, rosetten i kombination med peruken,

Det analysförfarande som beskrivs i ovanstående exempel har skett genomgående i alla de avsnitt där läroboken utifrån introduktion och hänvisningar hävdar att

the more common term diversity is, however, used exclusively.. 1 Introduction 3 The most renowned ensemble techniques are probably bagging, boosting and stacking, all of