Ett scoutingverktyg åt Linköping Hockey Club

Linköpings universitet/Linköping University | Institutionen för datavetenskap Kandidatexamen | Datateknik Våren 2021| LIU-IDA/LITH-EX-G--21/058—SE

Ett scoutingverktyg åt Linköping Hockey Club

Jesper Persson

Rasmus Rynell

Handledare: Niklas Carlsson Examinator: Patrick Lambrix

Linköpings universitet/Linköping University | Institutionen för datavetenskap Kandidatexamen | Datateknik Våren 2021| LIU-IDA/LITH-EX-G--21/058—SE

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida

https://ep.liu.se/ .

Copyright

The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page:

https://ep.liu.se/.

iii

Sammanfattning

Linköpings hockey club (LHC) arbetar idag tillsammans med Sports Analytics Group vid Linköpings Universitet, de har tillsammans bett oss ta fram ett verktyg för att underlätta LHC:s scoutingprocess. Arbetet inleddes med flera möten tillsammans med LHC där vi diskuterade hur arbetet skulle drivas framåt och vad som behövde göras. Under mötena fick vi reda på att fokus låg på jämförelsen mellan spelarna, dels att hitta liknande spelare för att kunna ta reda på rimliga löner, dels att kunna hitta nya spelare. Electron valdes som ramverk dels på grund av tidigare erfarenheter, dels för att i framtiden ha stöd för många olika enheter. Vi arbetade sedan agilt med kontinuerlig kontakt med LHC varje vecka för att utveckla just den funktionalitet som just de var ute efter. Tillslut fick verktyget funktionalitet såsom att hitta och jämföra spelares löner kontra dess spelarstatistik, en detaljjämförelse där spelares statistik kan jämföras mer noggrant samt en lagbyggesfunktion för att ge en överblick över alla ens valda spelare. Även designen på verktyget arbetades kontinuerlig fram och blev tillslut en minimalistisk sådan. I slutet av arbetet besvarade även personal på LHC på en enkät enligt “The System Usability Scale (SUS)” angående användbarheten, användarvänligheten, och önskvärdheten för verktyget. Svaren blev väldigt positiva och vi anser därför att detta är ett optimerat och näst intill optimalt verktyg för just LHC.

Linköpings universitet/Linköping University | Institutionen för datavetenskap Kandidatexamen | Datateknik Våren 2021| LIU-IDA/LITH-EX-G--21/058—SE

Förord/Acknowledgement

Författarna vill tacka både examinatorn Patrick Lambrix och handledaren Niklas Carlsson för deras stöd, vägledning och delad kunskap under arbetet.

Personal på LHC och framförallt Mikael Vernblom förtjänar också ett stort tack för både ett roligt och utmanande arbete men också en bra kund.

Linköping i juni 2021

7 Innehållsförteckning Upphovsrätt ... ii Copyright ... ii Sammanfattning ... iii 1. Inledning ... 9 1.1 Motivering ... 9 1.2 Syfte ... 9 1.3 Frågeställning ... 9 1.4 Avgränsningar ... 9 1.5 Översikt ... 10 2. Bakgrund ... 11 2.1 Ishockey ... 11

2.2 Teknologi inom Sportvärlden ... 11

2.3 Analyseringsprogram ... 11

2.4 Utvecklingsplattformar ... 12

2.5 Utveckling för webben ... 12

2.5.1 HTML ... 12

2.5.2 Cascading Style Sheets ... 12

2.5.3 JavaScript ... 13

2.5.4 Bootstrap ... 13

2.5.5 Chart.js ... 13

2.6 Applikationsutveckling med hjälp av webbutveckling ... 13

2.6.1 Node.js ... 13 2.6.2 Electron ... 14 2.7 Systemutveckling ... 14 2.7.1 Programutvecklingsmetodik ... 14 2.7.2 Versionshantering ... 15 2.8 Övrigt ... 15 2.8.1 Python ... 15 2.8.2 CSV-filer ... 15 3. Teori ... 16 3.1 Användarvänlighet ... 16 3.2 Datapresentation ... 16 3.3 Ranking av atleter ... 17 3.4 Scrum ... 17 4. Metod ... 18 4.1 Möten ... 18 4.1.1 Inledande möten ... 18 4.1.2 Slutmötet ... 18 4.2 Datafiler ... 19 4.3 Arbetsmiljö... 19 4.4 Arbetsmetodik ... 19 5. Resultat ... 20 5.1 Nyckel/diskussions-frågor ... 20 5.2 Spelarjämförelse ... 20 5.2.1 Överblicksjämförelse: ... 20 5.2.2 Detaljjämförelse: ... 21 5.3 Lagbygges-funktionen ... 21 5.4 Design ... 21 5.4.1 Visuellt ... 21 5.4.2 Intern design ... 27

5.5 Den avslutande feedbacken ... 27

8 6.1 Resultat ... 28 6.1.1 De inledande mötena ... 28 6.1.2 Funktionalitet... 28 6.1.3 Design ... 29 6.1.4 Feedback ... 29 6.2 Metod ... 29 6.2.1 Arbetsmiljö ... 29

6.2.2 Det agila arbetssättet ... 29

6.3 Etik i arbetet ... 30 6.4 Källkritik ... 30 7. Slutsats ... 31 7.1 Scoutingprocessen idag ... 31 7.2 LHC:s scoutingverktyg ... 31 7.3 Slutord... 31 8. Referenslista ... 32

9

1. Inledning

Linköpings Hockey Club (LHC) är idag Linköpings största hockeyklubb. De spelar i Svenska Hockeyligan, SHL, vilket är högsta ligan i Sverige.

Sports Analytics Group vid Linköpings Universitet är en grupp forskare som tillsammans arbetar med att på olika sätt analysera sporter, däribland även ishockey.

1.1 Motivering

Likt andra lag, även i andra sporter, är LHC ständigt ute efter att värva nya talanger, detta för att hela tiden försöka ligga i topp. De använder sig idag av flera verktyg för att hämta hem och analysera olika typer av spelardata och vill nu även utforska möjligheten att med hjälp av datan underlätta spelarrekrytering.

Något man ofta inte tänker på är att alla idrottsföreningar/klubbar även kan ses som företag, detta då de inte bara vill vara bäst utan för att de även måste tänka på sin ekonomi och hur den utvecklas. Hittar man en bra spelare som passar in i laget vill man självklart köpa in spelaren, detta kostar pengar, pengar som klubben måste tillhandahålla. LHC och Sports Analytics Group, som idag samarbetar, vill därför utforska möjligheten att tillsammans ta fram ett scoutingverktyg. För att få ett användbart och användarvänligt program behövs relativt mycket funktionalitet, därför valdes det att två grupper om två personer tillsammans bygger upp grunden och att de två grupperna sedan utvecklar varsina specifika delar.

1.2 Syfte

Syftet med arbetet är att utveckla ett verktyg som med hjälp av spelarstatistik från förgående säsonger underlättar LHC:s scoutingprocess.

1.3 Frågeställning

Denna rapport utreder dessa två frågeställningar:

1. Hur utvärderar LHC idag hockeyspelare utifrån deras tidigare prestationer och vilken data som är mest relevant för detta ändamål?

2. Hur kan ett optimalt scoutingverktyg för LHC se ut?

1.4 Avgränsningar

Den avgränsning som görs är att verktyget utvecklas specifikt åt LHC, dvs med de krav och specifikationer som just de är ute efter. Verktyget behöver därför inte vara lika omfattande och visa all den data som finns. Exempelvis kommer endast spelardata för anfallare och försvarare att tas hand om medan målvakter lämnas utanför.

10

1.5 Översikt

Efter introduktionskapitlet kommer bakgrunden, där förklaras de underliggande delarna av arbetet. Efter det följer teorikapitlet som handlar om den tidigare forskning som gjorts inom området. Kapitlet om metod kommer sedan och där beskrivs hur arbetet gick till samt hur planeringen följdes. I resultatet, det nästkommande kapitlet, följer sedan en förklaring på de resultat som arbetet gav, däribland även bilder på verktyget. Efter resultatet kommer diskussionen vilket innefattar våra tankar kring de arbetssätt och resultat som arbetet gav. Sist kommer slutsatsen som sammanfattar svaren på frågeställningarna samt hur både vi och LHC ser på verktyget.

11

2. Bakgrund

Verktyget utvecklas i två grupper om två personer vardera, grupperna satte tillsammans upp en grund och delade sedan in arbetet i mindre delar.

2.1 Ishockey

Ishockeyns ursprung är omdebatterad men det sägs att en liknande sport förekommit i Nederländerna redan under 1500-talet. Ishockeyn har sen dess fortsatt att etablera sig och är idag en av världens största sporter [1]. Idag har sporten utvecklats så att två lag med 5 utespelare och 1 målvakt varderas möts på isen. Utespelarna spelar i något man ofta kallar för femmor och är den grupp av spelare som är på isen samtidigt (exklusive målvakten). Under de tre perioder (kan bli fler vid förlängning osv) byts dessa femmor av för att alltid få ett så bra spel som möjligt. I varje femma finns positionerna forward och back som spelarna kan ha, dessa positioner kan även fördelas vidare genom vilken sida av isen de spelar på, en spelare kan då exempelvis vara VF (vänster forward).

Idag finns det ligor i många länder och Sverige är inget undantag, SHL, svenska hockeyligan, har även som många andra ligor varje år något som kallas för ett transferfönster, detta är en period där lag kan både köpa och sälja spelare, alternativt låna. Trots att det bara är under en viss tid som klubbarna har tillstånd att köpa och sälja spelare så pågår ständigt interna diskussioner och utredningar för att hela tiden hålla koll på vilka spelare man tycker är intressanta för sitt lag.

2.2 Teknologi inom Sportvärlden

Användningen av teknologi inom sportvärlden är idag vanligare än någonsin. Men det är inte bara för åskådarnas skull, i nästan alla sporter används teknologi även av de tävlande och deras coacher, exempelvis används kameror för att kunna gå tillbaka och analysera de tävlandes prestationer. Inom flera sporter, exempelvis fotboll, har även både kameror och GPS använts för att samla in data om spelarnas position, hastighet med mera [3]. Detta både för lagen att använda senare samt för att användas i exempelvis TV.

I National Hockey League (NHL) har de även testat så kallat “puck and player tracking technology”, dvs att installera olika sensorer i både pucken och spelare för att kontinuerligt kunna samla in data via. Som Gulitti skriver i artikeln ”NHL plans to deploy Puck and Player Tracking technology next season” [4] kan systemet samla in data om spelarna samt puck 200 respektive 2000 gånger per sekund, detta med så lite som ett par centimeters noggrannhet. Datan som fångas upp används sedan av ligan för att dels enklare kunna avgöra vad som hände i matchen, hur spelarna presterade och för att enkelt presentera statistik i sina sändningar.

2.3 Analyseringsprogram

Nuförtiden finns många analyseringsprogram som både analyserar och presenterar olika typer av data. Beroende på vilken sorts data det är man arbetar med så passar olika presentationstekniker olika bra. Handlar det exempelvis om att visualisera data från många olika matcher över flera säsonger kan det vara mycket givande att visualisera det inte bara i form av siffror utan även i bilder och diagram [6]. Gör man detta, får man ofta en bättre överblick över datan och dess faktiska betydelse. Har man istället spelardata från en enda match, exempelvis antal mål gjorda, antal passningar och liknande så kan det vara mer givande att endast presentera siffrorna och skillnaderna mellan dem, istället för att försöka göra det till bilder eller diagram.

Nu på senare tid har även tekniker som maskininlärning blivit alltmer populär, detta för att den otroliga mängd data som behövs nu finns tillgänglig [7]. Med hjälp av maskininlärning och den data som nu finns kan man exempelvis låta en dator rangordna spelare utifrån hur de tidigare har presterat.

12

Även om detta låter bra så har tekniken fortfarande sina problem, i “Prediction of tiers in the ranking of Ice Hockey Players” skriver Persson et al. [5] om hur deras modeller var bättre på att klassificera anfallare än försvarare, detta för att den data som modellen använder sig av ofta är mycket mer optimerad för anfallare. Det kan även uppstå problem när spelare med olika positioner ska rangordnas mot varandra, detta då den information man har kanske inte är direkt jämförbar.

2.4 Utvecklingsplattformar

Idag finns många olika plattformar att utveckla emot, olika enheter som körs på olika operativsystem med olika versioner. Exempelvis så körs Iphone, Ipad och Mac-datorer alla på operativsystemet Mac OS medan andra liknande produkter så som Windows-läsplattor och Android-telefoner istället körs på Windows respektive Android. Utvecklar man mot datorer finns även operativsystemet Linux att tänka på. Då de olika operativsystemen i grunden inte är byggda på samma sätt är det inte alltid enkelt att utveckla till alla samtidigt och på ett smidigt sätt. Om man sedan även måste tänka på att de olika plattformarna kan visas på olika sätt, genom olika skärmstorlekar, bildförhållanden osv, blir det snabbt mycket som måste tas i hänsyn [22].

2.5 Utveckling för webben

Webben är idag tillgänglig på nästintill alla tänkbara plattformar, anledningen är att det nu för tiden nästan alltid finns någon form av webbläsare till nästan alla plattformar.

2.5.1 HTML

HTML står för HyperText Markup Language och har utvecklats ända sedan tidigt 90-tal, språket har genomgått flera olika uppdateringar där den senaste versionen, HTML5, framförallt gjort det enklare att både skriva och läsa HTML-kod. Som namnet antyder används HTML för att ge struktur till en webbsida, detta genom att införa så kallade element, elementen kan exempelvis omsluta text för att sedan få denna text att se ut och bete sig på ett speciellt sätt [13]. Elementen kan tyvärr inte återanvändas utan om man exempelvis vill ha två likadana menyer på två olika stället på webbsidan måste man ta till andra tekniker. Idag ligger HTML som grund för alla webbsidor och det ser inte heller ut som att det kommer bytas ut inom snar framtid.

2.5.2 Cascading Style Sheets

Cascading Style Sheets eller mer känt som CSS används i kombination med HTML. Istället för att som HTML gör, strukturera upp en hemsida, har CSS i uppgift att designa och beskriva själva HTML-elementen. CSS kan bland annat användas för att byta typsnitt, färger och lägga till animationer på exempelvis text eller knappar. CSS introducerades redan år 1994 men det var dock inte förrän år 2000 som den första webbläsaren faktiskt stödde det fullt ut. Tekniken är anpassad så att den alltid ska fungera oavsett datortyp, skärmupplösning och andra specifikationer man kör på. Den nuvarande versionen av CSS, år 2021, är CSS3 [14].

13

2.5.3 JavaScript

JavaScript, ofta förkortat JS, är ett programmeringsspråk först utvecklat för webben. Språket kompilerar under körning, är svagt typat och används framförallt för att skapa mer dynamiska och interaktiva webbsidor [15]. Svagt typat innebär att en variabel inte är bunden till en specifik datatyp som till exempel en sträng eller ett heltal, utan kan ändras under programmets körning [16]. JavaScript används främst till klient-sidan av en webbapplikation men kan idag även användas mot server-sidan med hjälp av plattformar så som Node.js. JavaScript introduceras år 1995 och är idag ett av de mest använda programmeringsspråken världen över [15].

2.5.4 Bootstrap

Bootstrap är ett open-source ramverk som innehåller färdiga CSS- och JavaScript-mallar. CSS-mallarna kan användas för att snabbt och enkelt strukturera upp responsiva rutnät men innehåller även färdigdesignade tabeller, knappar med mera. JavaScript-mallarna kan användas för att göra sidan mer interaktiv och innehåller bland annat bildspel och meny-navigationer. Bootstrap släpptes år 2011 och är idag inne på version 5.0 [18].

2.5.5 Chart.js

Chart.js är ett open-source JavaScript-bibliotek avsett för klientsidan som handlar om datavisualisering. Biblioteket stödjer 8 interaktiva typer av diagram, bland annat stapel-, cirkel- och radardiagram som alla kan anpassas efter eget behov [23].

2.6 Applikationsutveckling med hjälp av webbutveckling

Node.js är en open-source plattform/servermiljö som tillåter en att med hjälp av V8 JavaScript motorn exekvera JavaScript-kod utanför en webbläsare. Node.js är även nära integrerat med operativsystemet det körs på, vilket ger utvecklare en rad nya möjligheter som inte tidigare varit tänkbara, exempelvis att genom JavaScriptkod komma åt och visa information om den dator som koden körs på. Node.js kan idag köras på många olika plattformar såsom Windows, Linux, Mac OS, etcetera [17]. Nu för tiden finns även många olika paket skrivna för att underlätta utveckling i Node.js, paketen kan hämtas och hanteras med Node.js egna pakethanterare npm, Node Package Manager [19].

14

2.6.2 Electron

Electron är ett open-source ramverk som ger utvecklare möjligheten att ta fram lokala skrivbordsapplikationer med hjälp av Node.js som ”backend” och webbläsaren Chromium som ”frontend”. Backend är den del av koden som i vanliga fall körs på serversidan, dvs ofta tunga beräkningar eller uppslag i databaser osv, medan frontend istället är den del av koden som körs i användarens webbläsare, dvs ofta den del av koden som användaren ser. Chromium använder samma JavaScript motor, V8 engine, som Node.js använder och fungerar därför precis som en vanlig webbläsare. Det är därmed Chromium som gör det möjligt att rendera HTML och CSS för antigen en webbläsare eller som i Electrons fall till en fristående applikation. Produkten utav dessa teknologier blir då något som för användaren ser ut som en helt vanlig lokal applikation men som i bakgrunden utvecklas som en hemsida med en lokal server.

Då både Chromium och Node.js är anpassat för att kunna köras på flera plattformar har även Electron samma egenskap. Men med fördelarna att kunna snabbt och enkelt utveckla en applikation för flera plattformar samtidigt kommer även nackdelar. Den första nackdelen är att Electron i grunden inte är helt optimerat för att vara en lokal skrivbordsapplikation, detta gör att applikationen inte är lika effektiv på resursanvändning som den skulle kunna vara, detta gör att beroende på vart man kör applikationen kan det gå olika snabbt för olika användare. Att istället utveckla mot endast en plattform ger därför ofta istället en snabbare, mer optimerad applikation som dock endast kan köras på just den plattformen. Den andra nackdelen och kanske den lite viktigare är att vid användning av Electron höjer man sin egen säkerhetsrisk jämfört med andra mer ”traditionella” tillvägagångssätt. Detta då Electron egentligen inte är något mer än en webbläsare med mer tillgång till hårdvaran, (genom node.js), än vad en vanlig webbläsare har. Detta gör att säkerhetsbrister i webbläsaren nu även kan ha tillgång till mer hårdvara, vilket i sin tur kan leda till värre konsekvenser. Genom att använda Electron använder man även ofta många andra bibliotek som alla kan ha sina egna säkerhetsbrister. Trotts dessa nackdelar finns det idag flera stora applikationer som bland annat Visual Studio Code, Skype, Discord och många mer som alla har utvecklats med hjälp av eller helt i Electron [20].

2.7 Systemutveckling

Vid utveckling av programvara finns ett antal olika tillvägagångssätt, flera olika metodiker att följa, den mest klassiska kallas för vattenfallsmetoden [21]. Vattenfallsmetoden beskrivs av McCormick i texten ”Waterfall vs. Agile Methodology” [24] som en modell som alltid följer en fast plan, arbetet tas i faser och det är inte förrän föregående fas är helt färdig som man börjar arbeta på nästa.

Utöver vattenfallsmetoden finns även ett gäng andra metoder som tillsammans brukar kallas för agila-metoder, med agila menas att metoden är väldigt anpassningsbar med snabba utvecklingscyklar. I dessa agila metoder arbetar man ofta väldigt tätt med kunden och man ser hela tiden till att man endast arbetar på relevanta saker [25]. McCormick [24] beskriver även hur det finns både för- och nackdelar med de olika alternativen samt att de fungerar olika bra beroende på om man arbetar på ett stort, medelstort eller litet arbete. En nackdel är exempelvis hur det ofta är svårt för nybörjarprogrammerare att arbeta agilt då de själva snabbt behöver ta beslut om saker och ting, en fördel med denna nackdel är dock att dessa programmerare snabbt blir vana vid att ta beslut och blir därmed snabbt mer självständiga.

En nackdel som finns med den agila metoden i större arbete är att kunden ofta inte vet exakt vad denna vill ha, att då arbeta agilt och ställa många frågor (som man då antagligen inte får rimliga svar på) kan bli väldigt fel. Att då istället köra på vattenfallsmetoden kan vara att föredra.

15

2.7.2 Versionshantering

Ett versionshanteringssystem är ett system som ger utvecklare möjligheten att arbeta mot en centraliserad kodbas på en server. Detta skapar möjligheten för flera utvecklare att arbeta mot samma kodbas samtidigt, när ändringar görs sparar även systemet dessa som olika versioner och skapar möjligheten att sedan i efterhand gå tillbaka och se vilka ändringar som gjorts av vem. Idag har Git växt fram som det mest använda versionshanteringssystemet, det fungerar på både små och stora arbeten och används av både stora företag och ensamma utvecklare [26].

Git stödjer även något som kallas för förgreningsutveckling, vilket betyder att man som utvecklare kan förgrena kodbasen så att när man själv gör ändringar och lägger upp dem i kodbasen görs dessa endast till ens egen gren och inte på den gemensamma sådana. Detta ger en utvecklare möjligheten att testa och utveckla helt isolerat från andra utvecklare på samma arbete. När man sedan vill/är klar med sina ändringar kan man sammanställa dessa med den gemensamma grenen på en och samma gång.

Eftersom de arbeten som hanteras av Git måste sparas på en server men antalet personer med tillgång till en egen server är låga har flera företag som utger detta som en tjänst växt fram, ett av dessa företag är GitHub [27].

2.8 Övrigt

Programmeringsspråket Python är när arbetet genomförs det näst mest använda programmeringsspråket i världen [31]. Språket är ett så kallat högnivåspråk vilket innebär att det ligger flera abstraktionsnivåer ifrån hårdvaran och har även väldigt många olika användningsområden. Språket kan nämligen användas till allt från modern webbutveckling till dataanalysering till Machine Learning och hela vägen till olika typer av scripting. En annan anledning till språkets stora räckvidd är att det har stort fokus på läsbarhet av kod, detta gör att språket idag ofta är ett av de första som nya utvecklare lär sig. Språket är dynamiskt-typat och ett så kallat interpreterat sådant, med detta menas att språket inte kompileras i början innan det körs utan istället omvandlas till maskinkod under programmets körning. Det finns idag många olika versioner av Python där den nyaste heter Python3 [32].

2.8.2 CSV-filer

CSV, ”Comma-separated values” används för att spara undan lika typer av data i textfiler genom att separera värden med separatorer. Som namnet antyder är kommatecken den vanligaste separatorn men även tab, semikolon och vertikalstreck är förekommande. För att separera cellerna i en rad används just separatorn medan en rad ofta separeras med radbrytning [30].

16

3. Teori

I detta avsnitt kommer den tidigare relevanta forskning som gjorts inom ämnet att presenteras, målet med detta kapitel är att läsaren ska få en bra förståelse för ämnet.

3.1 Användarvänlighet

Som Gualtieri [11] skriver i rapporten ”Best Practices In User Experience (UX) Design” finns ett antal punkter att ta hänsyn till vid utvecklandet av en tilltalande applikation. Applikationen bör vara enkel att använda, estetiskt tilltalande, känslomässigt tillfredsställande och tillföra något av värde. Med andra ord så för att övertyga användaren bör applikationsupplevelsen inte bara vara användarvänlig men även användbar och önskvärd. Med användbarhet menas att användaren ska kunna uppfylla de mål denna har med besöket. Användarvänlighet bygger istället på att göra användarens upplevelse av applikationen så friktionslös som möjligt. Medan önskvärdhet istället handlar om att användaren på olika sätt känner att de vill använda applikationen, detta kan förhöjas genom exempelvis applikationens användande av språk, bilder, användbarhet och användarvänlighet.

3.2 Datapresentation

Som Weissgerber et al.[9] skriver i rapporten ”Beyond Bar and Line Graphs: Time for a New Data Presentation Paradigm” är en av de viktigaste delarna av forskning hur den data som tas fram presenteras, anledningen till detta är att den data man representerar ofta är de resultat som man kommit fram till. På samma sätt kan även datapresentation inom mjukvaruutveckling vara mycket viktigt. Detta tillsammans med att hur datan tolkas ligger i författaren eller författarnas förmåga att representera den gör att presentationstekniken för datan kan vara minst lika viktig som datan själv. Missrepresenteras datan finns även chansen att man inte bara försämrar hur datan ser ut utan att man rentav råkar vrida läsarens förståelse i motsatt riktning.

Genom att använda sig av rätt presentationsverktyg för just den data man själv vill presentera hjälper man därmed både läsaren och sig själv. Är det siffror som ska presenteras används ofta både tabeller och diagram, är det istället mer komplex data eller relationer mellan olika datapunkter så kan andra presentationsverktyg användas. Att använda en tabell är ofta att föredra om datan inte har något att förhålla sig till, det vill säga om datapunkterna inte jämför sig med varandra, detta är ofta fall när man har data som inte är siffror. Ett exempel är att presentera vad olika länder har för olika lagar inom ett visst ämne, här har datan ingen relation till varandra förutom att de är lagar i olika länder. Har man istället data på hur något står i förhållande till en absolut mängd är ett tårtdiagram att föredra. Ett exempel på detta skulle kan vara hur mycket av olika produkter som har sålts inom ett visst intervall i en matvarubutik, använder man då ett tårtdiagram så ställer man datan i förhållande till både varandra och hela datasetet. Om man istället har data som presenteras över tid såsom förändring i temperatur under en dag är ett linjediagram ett bra presentationsverktyg. Självklart finns det många fler olika presentationsverktyg att använda sig av men dessa är de vanligaste [10].

17

3.3 Ranking av atleter

Som Kondratev et al.[2] beskriver i “How should we score athletes and candidates: geometric scoring rules” är att rangordna folk, i de allra flesta situationer, mycket simpelt. De beskriver hur det är just enkelheten med att rangordna något eller någon som kan ligga till grund till dess breda användningsområden. Att välja rätt sätt att rangordna något eller någon är dock inte lika enkelt, det alla olika sätt dock har gemensamt är att jämförelsen mellan attribut som subjektet har summerats ihop till en enda rank. Det svåra blir därmed att välja vilka attribut som spelar roll för just den typ av rank man vill ha, exempelvis om skott på mål i eller skapade chanser spelar mest roll när man rangordnar en forward i fotboll.

Inom just ishockey har mycket tidigare forskning gjorts inom området att rangordna spelare enligt deras tidigare prestationer, traditionellt har mått såsom skott, assist, (+/-)-statistik osv använts i flera olika modeller. På senare tid har även flera nya mått såsom Corsi (ett mått beroende på lagets skott på mål samt skott mot eget mål) och xG eller ”expected goals” används med varierande resultat. Dessa mått kan antigen som i fallet med xG försöka analysera fram medan på mått som Corsi tas fram genom redan befintliga data. I artikeln ”Not all goals are equally important - a study for the NHL” skriver Vik et al.[33] om hur de har undersökt möjligheten att bättre mäta olika typer av mål för senare forskning. Många olika typer av modeller såsom regressionsmodeller [39, 40, 41, 46], Markov-gamemodeller [33, 36, 37, 42, 44, 49], olika typer av reinforcement learning-modeller [45, 48], Bayes-modeller, olika typer av trädmodeller osv [5,8, 47, 50] har idag använts flitigt. Utvärderingar har även gjorts på andra sätt, exempelvis genom att använda tidigare matchhändelser och resultatet för att försöka utvärdera spelarna [38, 43].

3.4 Scrum

Som Kondatev et al.[28] beskriver i texten ”SCRUM Model for Agile Methodology” är Scrum-metoden idag den mest populära agila utvecklingsScrum-metoden. Modellen beskrivs som ett agilt och lättviktigt ramverk som kombinerar den iterativa processen med den inkrementella utvecklingsmodellen.

I Scrum-modellen finns flera roller för utvecklare att inta, först och främst en Scrum-master vars jobb är dels att leda möten och ha främsta kontakten med kunden/produktägaren (även det en roll). De återstående utvecklarna är ofta experter/tar ansvar för ett visst område i arbetet, beroende på hur vida Scrum-master vill/kan delta som utvecklare kan denna också göra det. Modellen innefattar även att utvecklingsprocessen delas in flera så kallade ”sprints”, en sprint omfattar ofta ca 1–3 veckors arbete och är den tid som utvecklarna har på sig att utveckla. De olika sprintarna kan omfatta olika saker, exempelvis så är ofta den sista sprinten en uppsamlingssprint som används för att fixa buggar, allmän kodstädning med mera. De olika delarna av arbetet som finns att jobba på finns i något som brukar kallas för en ”backlog”, backloggen är en gemensam samlingsyta som hela tiden innehåller de olika delarna i arbetet som ska göras, har gjort eller måste göras om [29].

Srivastava et al.[28] skriver även att den ideala gruppstorleken för ett Scrum-team ligger någonstans runt 4 till 9 medlemmar, detta på grund av att större grupper ofta börjar agera mot Scrums grundprinciper och mindre grupper ofta har svårt att arbeta individuellt.

Enligt Matera. et al.[12] är denna typ av metod även mycket bra för applikationsutveckling där användarvänlighet ligger i fokus. Detta för att då kontakt och demonstration inför kunden sker ofta är det enkelt för denna att komma med förslag och förbättringar som bör hanteras.

18

4. Metod

I detta kapitel följer en beskrivning av de metoder som användes under arbetets gång.

4.1 Möten

4.1.1 Inledande möten

Arbetet inleddes med ett antal möten med LHC:s personal, inledningsvis handlade dessa möten om ett par nyckelfrågor om hur LHC:s scoutingprocess ser ut i dag, dessa var nyckelfrågorna:

1. Hur ser er scoutingprocess ut idag?

2. Vilken data tillhandahåller ni som ni använder er av i scoutingprocessen? 3. Hur används den data idag?

4. Använder ni idag några datorprogram för att underlätta processen? 5. Vilka problem med scoutingprocess finns idag?

Även mer generella diskussionsfrågor kom upp på mötena, exempel på dessa är:

1. Vad har ni för generella krav/önskemål på verktyget, har ni data som måste eller som inte ska visas?

2. Har ni krav/önskemål för hur eller med vilken teknik som verktyget bör utvecklas med? 3. Har ni krav/önskemål på vart verktyget ska kunna köras, dvs på vilka operativsystem?

Anledningen till att dessa frågor diskuterades var för att få en bra grund och förståelse för hur LHC:s scoutingprocess ser ut idag och vad som de tyckte skulle kunna förbättras. Möten med LHC hölls även minst en gång i veckan kontinuerligt genom hela arbetet.

4.1.2 Slutmötet

När arbetet började gå mot sitt slut lät vi LHC själva testa verktyget, vi gav dem två veckor att hitta buggar, förbättringar och komma med allmän feedback. När de två veckorna var slut hade vi ett slutmöte där feedbacken diskuterades. Vi ställde även dessa rangordningsfrågor (1 för om man inte samtycker och 5 är att man samtycker helt) om användningen av verktyget med hjälp av “The System Usability Scale”:

1. Jag använder gärna applikationen

2. Jag drar mig för att använda applikationen, den är onödigt komplicerad 3. Jag tycker att applikationen är lätt att använda

4. Jag behöver ofta hjälp av en kollega eller fråga någon teknisk person för att kunna använda applikationen

5. Jag tycker att funktionerna i applikationen är väl organiserade och tydliga

6. Jag tycker att det finns för mycket inkonsekvens och ologiska vägar i applikationen 7. Jag kan tänka mig att de flesta skulle lära sig att använda applikationen mycketsnabbt 8. Jag tror att många tycker att applikationen är mycket besvärligt att använda

9. Jag känner mig väldigt säker på hur jag skall använda applikationen 10. Jag behövde lära mig mycket innan jag kom igång med applikationen

Som Bangor et al.[34] nämner i “An Empirical Evaluation of the System Usability Scale“ är “The System Usability Scale (SUS)” en undersökningsskala som tillåter en användare att avgöra användbarheten av en produkt. Det som gör SUS till ett bra val till skillnad från andra undersökningar

19

är att den är tekniskt flexibel vilket innebär att den går att använda till att bedöma många olika produkter, allt ifrån en webbplats till hårdvaruprodukter. Den är också relativt kort och är enkel för både en användare och deltagare att utföra. Utöver det är den enkel att förstå då undersökning ger en sammanlagd poäng som lätt går att utläsa på skalan.

Som Sauro [35] nämner i “Measuring Usability with the System Usability Scale (SUS)” bedöms alla udda frågor med att man subtraherar 1 från det deltagaren angivit, jämna frågor subtraheras istället från 5. Detta resulterar i att varje svar kan få en poäng mellan 0–4, där 4 är det bästa. Alla svar summeras sedan ihop och multipliceras med 2.5 som ger den slutliga poängen, poängen sträcker sig mellan 0–100. För att få högsta betyg bör poängen vara över 80.3, det är även här användaren tenderar att rekommendera produkten till en vän. Medelpoängen ligger på 68 och under 51 betyder att produkten får underkänt.

4.2 Datafiler

Den data som vi fick från LHC kom i form av både CSV-filer och en Excel-fil, den sistnämnda filen gjordes dock snabbt om till en CSV-fil för att internt kunna behandlas likt de andra filerna. Filerna bestod av både spelarstatistik och uppskattade spelarlöner för lagen i SHL år 2018. Tanken var även att i framtiden kunna använda andra säsongers spelardata och spelarlöner på samma sätt.

4.3 Arbetsmiljö

Den arbetsmiljö som valdes att arbeta i blev ramverket Electron, anledningen till detta var dels att få möjligheten att använda våra redan befintliga kunskaper inom webbutveckling, dels för att ge framtidens utvecklare av verktyget möjligheten att snabbt och enkelt även kunna migrera till andra plattformar om så önskas. Webbutvecklingskunskaperna som användes var HTML, CSS, JavaScript och Bootstrap för att bygga den interaktiva delen av arbetet, dvs den del som användaren ser och interagerar med. Biblioteket Chart.js användes för att enkelt kunna ta fram och visa grafer och diagram för användaren. JavaScript användes även för backenden där i Node.js körs. Även programmeringsspråket Python användes för att skriva ett skript som genererade repetitiv HTML-kod för menyer.

Eftersom vi till en början var fyra på arbetet användes versionshanteringssystemet Git för att hålla en gemensam kodbas med historik. När arbetet sedan delades in i två olika delar delades det även upp i två olika grenar, varje vecka sattes dessa grenar ihop så att det alltid fanns en komplett version att visa upp.

4.4 Arbetsmetodik

På grund av den tidsrestriktion som fanns för arbetet kände vi att en bra arbetsmetodik var viktig för att hinna ta fram en bra produkt. Vi valde därför att ta lärdom av vad Srivastava et al.[28] skrev om Scrum och arbeta iterativt och nära vår kund. Detta genomfördes genom att ha vad vi ser som små sprintar varje vecka, i början av sprintarna diskuterades vad som skulle göras den veckan och vilka som skulle göra det. Genom att sedan ha en ständig dialog med både kunden och utvecklarna sinsemellan arbetade vi fram de olika delarna som sprinten skulle innehålla. I slutet av sprinten, det vill säga i slutet av veckan, hölls även ett möte för att få input om denna veckas framsteg och kunna ställa frågor om nästkommande veckas sprint. Kontakt via mejl hölls även med kunden för att kunna få svar på snabba och enkla frågor som dök upp i mitten av en sprint. I slutet av arbetet användes även en av de sista sprintarna till att hitta och fixa buggar samt utveckla en så bra och användarvänlig applikation som möjligt. Sedan valde vi även att överlåta verktyget till LHC så att de själva fick möjlighet att utvärdera samt hitta möjliga förbättringar innan den slutliga produkten helt lämnades över.

20

5. Resultat

I detta avsnitt presenteras resultatet av arbetet.

5.1 Nyckel/diskussions-frågor

Under de första mötena med LHC ställdes som sagt ett antal frågor, dessa frågor besvarades antigen direkt eller diskuterades fram, frågorna var som följande:

1. Hur ser er scoutingprocess ut idag?

2. Vilken data tillhandahåller ni som ni använder er av i scoutingprocessen? 3. Hur används den data idag?

4. Använder ni idag några datorprogram för att underlätta processen? 5. Vilka problem med scoutingprocess finns idag?

Även mer generella diskussionsfrågor kom upp på mötena, exempel på dessa är:

1. Vad har ni för generella krav/önskemål på verktyget, har ni data som måste eller som inte ska visas?

2. Har ni krav/önskemål för hur eller med vilken teknik som verktyget bör utvecklas med? 3. Har ni krav/önskemål på vart verktyget ska kunna köras, dvs på vilka operativsystem?

Utifrån dessa frågor kom vi fram till att LHC:s-scoutingprocess idag ser ut ungefär så här: Idag tillhandahåller LHC spelardata från framförallt ett kanadensiskt företag vid namn Sportlogiq, de erbjuder även ett sätt att visualisera den på. Med hjälp av datan arbetar sedan LHC för hand med att jämföra spelare och löner (löner, som inte finns på Sportlogiq) för att hitta nya talanger till laget. Ett problem som LHC ser med sin egen scoutingprocess är att det i nuläget är för svårt att hitta spelare som till statistiken liknar varandra. Ett annat problem är även svårigheten att veta vad som är en rimlig lön för de olika spelarna.

När sedan de mer generella diskussionsfrågorna ställdes bildade vi oss uppfattningen att: Eftersom detta är första gången LHC är med och utvecklar ett eget scoutingsystem så är visionen stor men även lite luddig. Med andra ord vet de inte riktigt vad de vill ha men vill gärna se något med mycket funktionalitet. Därför kände både vi och LHC att det var bättre om vi först började utveckla grunden och sedan under arbetets gång såg vad det kunde mynna ut till, därmed som enligt McCormick [24] beskrivning ”att arbeta typiskt agilt”.

5.2 Spelarjämförelse

Eftersom det stora problemet för LHC idag handlar mycket om hur jämförelsen mellan spelare går till lades mycket fokus på just den delen. Efter diskussion med LHC identifierades därmed att två olika typer av spelarjämförelser behövde finnas med i verktyget, ett sätt att jämföra hela spelarens viktade attribut för att snabbt och enkelt kunna hitta liknande spelare samt ett sätt att mer i detalj se hur attributen skiljer sig åt.

5.2.1 Överblicksjämförelse:

Eftersom överblicksjämförelsen skulle användas till att hitta liknande spelare ville LHC kunna välja vilka attribut som skulle tas i hänsyn till i jämförelsen. Med andra ord ville de kunna vikta de olika attributen beroende på hur mycket de tyckte just den bör räknas med. Utifrån detta arbetades då ett antal olika prototyper fram och efter diskussion med LHC valdes sedan en metod ut. Metoden är i grunden mycket simpel och pseudokoden ser ut så här:

21

(Metoden förutsätter att summan av antalet vikter alltid är mer än 0)

Där min-max-normaliseringen görs genom följande ekvation: 𝑠𝑣𝑎𝑟 =𝑖𝑛𝑖𝑡𝑖𝑎𝑙𝑡𝑉ä𝑟𝑑𝑒 − 𝑚𝑖𝑛

𝑚𝑎𝑥 − 𝑚𝑖𝑛

Där ”min” och ”max” är det minsta respektive största värdet för samma attribut bland alla spelare. Metoden går alltså ut på att hitta ett genomsnittligt värde för spelarens alla viktade attribut. Detta görs som pseudokoden beskriver genom att först räkna fram alla attributs min-max-normaliserade värden, vikta dem, summera dem och sedan dela dem på alla summerade vikter, vi kallar härmed detta framräknade värde för ”det genomsnittliga attributs värdet”, eller GAV. Skillnaden på spelarnas GAV blir då den genomsnittliga skillnaden i spelarnas alla viktade attribut.

5.2.2 Detaljjämförelse:

(Denna del av arbetet leddes av den andra gruppen och beskrivs därför i denna rapport endast med dess mest väsentliga delar)

När man väl hittat två liknande spelare vill man ofta se på mer detaljnivå vad som skiljer spelarna åt. För att göra detta utvecklades en detaljjämförelse fram, där visas istället skillnaden i attributen samt dess råa siffror får de båda spelarna.

5.3 Lagbygges-funktionen

För att ytligare underlätta scoutingprocessen i sin helhet utvecklade vi även fram den simpla funktionaliteten att sätta ihop flera spelare till ett och samma lag. Funktionen ger användaren möjligheten att sätta upp en budget, lägga in spelare med löner och positioner och sedan snabbt få en överblick av vad hela laget skulle kosta och vad som återstår av budgeten. För att sedan underlätta för användaren implementerades även möjligheten att både spara och ladda in lagen.

5.4 Design

När det kommer till designen för arbetet fanns mycket att tänka på, dels det visuella, dels hur den interna strukturen för själva arbetet borde se ut.

5.4.1 Visuellt

För att leverera ett så bra och användarvänligt program som möjligt följde vi vad Gualtieri [11] skrev, nämligen att lägga mycket fokus och energi på att inte bara utveckla verktygets användarvänlighet och användbarhet men även önskvärdhet. För att få potentiella användare att vilja använda verktyget blev då syftet att göra verktyget både lätthanterbart och estetiskt tilltalande. Detta gjordes genom att bland

1 totalAttributsNummer = 0 2 totalVikt = 0

3 Loopa igenom alla olika attribut för en spelare:

4 attributsNummer = attributet ”min-max-normaliserat”

5 totalAttributsNummer += attributsNummer * vikten för just det attributet 6 totalVikt += vikten på samma attribut

22

annat lägga till lagbilder, ha enkelt och tydligt språk samt en bra tydlig struktur på både layout och design. Nedan följer ett par exempel:

(Observera att vi valt att göra testspelare såsom, Test Testsson, då den data vi fick var sekretessbelagd)

Figur 1: En helhetsbild av applikationens framsida.

Som figur 1 visar valde vi att ha en ljus färgpalett med blåa knappar. Anledningen till detta var för att användaren alltid ska kunna veta vad som är en knapp och vad som inte är.

Figur 2: Vyn när man valt spelare.

I vyn för en vald spelare, figur 2, är en lagbild tillagd till varje spelare dels för att förhöja det estetiska, dels för att göra koppling till spelarens nuvarande lag tydligare.

23

Figur 3: Vyn för detaljjämförelsen.

Som figur 3 visar har vi i detaljjämförelsevyn inte bara förstärkt med en lagbild för spelarna men också markerat vem som har den högsta statistiken i de olika attributen med en kantmarkering runt om. Vi har även lagt till en ”jämförelse-bar” för varje attribut som visar hur stor skillnaden är. Genom att göra detta visas inte enbart vem som är bäst översiktligt utan även för vilka specifika attributet detta stämmer.

Figur 4: Vyn över löneöversikt.

Som Weissgerber et al. [9] beskrev är hur man presenterar ett resultat väldigt viktigt för hur en användare sedan uppfattar det. Därför har vi valt att göra ett sambandsdiagram med lön på Y-axeln och spelarnas GAV på X-axeln, vilket kan ses i figur 4. För att göra diagrammet så tydligt som möjligt har vi även valt att använda oss av olika färger, den blåa punkten representerar den valda spelaren, den gröna punkten representerar de mest liknande spelarna till den blåa och de orangea representerar de övriga spelarna. Efter feedback från LHC lade vi även till en inmatningsruta där man kan välja hur många liknande spelare man vill se.

24

Figur 5: Alternativ vy på löneöversiktsdiagrammet.

Möjligheten att sluta visa någon av kategorierna implementerades även för att ge en så bra översikt som möjligt. I figur 5 är ”andra spelare” gömd och för att sedan öka användarvänligheten ännu mer gjordes även prickarna i denna vy större.

Som tillägg till sambandsdiagrammet implementerade vi även en tabell med de mest liknande spelarna, vilket kan ses i figur 6. Även här kan man för lätthetens skull välja hur många liknande spelarna man vill se. För användarvänlighetensskull valde vi även att synka denna ”välj antal spelare” med samma siffra fast för spridningsdiagrammet, vi valde sedan även att implementera möjligheten att byta till en ny spelare genom att klicka på namnet i ”liknande spelare”-menyn. För att visa hur lika spelarna är visas under ”Diff” skillnaden i GAV mellan den valda spelaren och de liknande. Ovanför tabellen finns även uppskattad lön för att lättare hjälpa användaren att uppskatta den valde spelarens lön, denna väljs just nu genom att visa den mest liknande spelarens lön och under till finns även spelarens faktiska lön.

Figur 6: Vyn för liknande spelare samt uppskattad lön.

25

Figur 7: Sliders för viktning av attribut.

För att låta användaren vikta attributen vid jämförelse mellan spelarna valde vi att ha ett skjutreglage tillhörande varje attribut. Eftersom det finns väldigt många olika attribut valde vi även att dela in dessa i olika kategorier, för möjligheten att byta kategori skapades även en användarvänlig meny. Sliderna kan anta ett värde mellan 0–10 och för användarvänlighetenskull finns även min- och max-knappar samt en inmatningsruta för att ändra alla sliders inom samma kategori på samma gång. Resultatet av detta illustreras i figur 7.

26

Figur 8: ”Skapa ett lag”-funktionen.

Figur 8 visar de olika tillstånd som ”skapa ett lag”-funktionens meny kan befinna sig i. Den är implementerad så att den alltid syns oberoende av vilken del av verktyget man befinner sig i. Detta för att låta användaren alltid ha en översikt av sitt lag även när man undersöker andra spelare. Menyn implementerad så att man antigen lätt ska kunna se sitt befintliga lag eller ladda in ett lag man gjort tidigare.

27

För att enklare hitta de spelare man söker efter implementerades en dropdown-funktion som filtrerar spelare efter sökordet. Funktionen filtrerar upp till fem spelare och varje resultat visar spelarens namn, position, lag samt vilket år statistiken är ifrån. Varje resultat är klickbart och tar dig till vyn för den valda spelaren. Det är även möjligt att filtrera så att man enbart får upp anfallare (F) eller backar (D) genom att välja det i filter-dropdownen till höger om sökfunktionen. Designen för detta kan ses i figur 2.

5.4.2 Intern design

Vid uppstart av verktyget finns varken spelarstatistik eller löner inlagda, för att välja den data man vill undersöka finns möjligheten att välja filer att läsa in till verktyget. Dessa filer måste vara i CSV-format och ha strukturen att på första raden innehålla rubrikerna på all data och de nästkommande raderna innehålla en viss spelares data. Se figur 10.

Figur 10: exempel på hur en fil kan se ut.

Anledningen till denna typ av struktur var dels för att majoriteten av den data som LHC gav oss var uppbyggd på detta sätt, dels för att det gjorde inläsningen enklare. Vi valde nämligen att läsa in filerna med hjälp av ett node-paket och omvandlade dem till ett dictionary-format som sedan användes i resten av verktyget.

5.5 Den avslutande feedbacken

På det avslutande mötet gavs feedback både i form av buggar och generella förbättringar. Buggarna fixades och förbättringen att kunna se både den lönen som spelaren faktiskt har och även den uppskattade sådana lades även till.

Då LHC ofta jobbar i grupp med verktyget valde de att svara på frågorna i just denna grupp, därav fick vi endast in ett svar för alla frågor, men dessa gäller då självklart för alla användare, svaren set ut såhär:

Nr Fråga Svar

1. Jag använder gärna applikationen 5

2. Jag drar mig för att använda applikationen, den är onödigt komplicerad 1

3. Jag tycker att applikationen är lätt att använda 5

4. Jag behöver ofta hjälp av en kollega eller fråga någon teknisk person för att kunna använda applikationen

2 5. Jag tycker att funktionerna i applikationen är väl organiserade och tydliga 5 6. Jag tycker att det finns för mycket inkonsekvens och ologiska vägar i applikationen 1 7. Jag kan tänka mig att de flesta skulle lära sig att använda applikationen mycketsnabbt 5 8. Jag tror att många tycker att applikationen är mycket besvärligt att använda 1 9. Jag känner mig väldigt säker på hur jag skall använda applikationen 5 10. Jag behövde lära mig mycket innan jag kom igång med applikationen 2 Tabell 1: Frågor och svar från SUS enkäten.

Om vi då sedan räknar fram slutbetyget blir det 95, något som är bra och tillochmed anses väldigt högt.

28

6. Diskussion

I detta avsnitt diskuteras hela arbetet och de metoder som använts.

6.1 Resultat

Här följer en diskussion om arbetets resultat.

6.1.1 De inledande mötena

När det gäller den inledande diskussionen som hölls med LHC var frågorna mycket viktiga, de gav oss en insikt i både hur LHC själva såg på arbetet samt hur de ville att vi skulle se på det. Eftersom arbetet blev väldigt agilt ställdes även många frågor på vägen som inte fanns i början av arbetet. Några frågor som dock inte ställdes men som vi nu i efterhand inser att vi skulle ställt är:

1. Har ni någon åsikt om själva designen på verktyget, ska det exempelvis vara minimalistiskt eller absolut inte innehålla några speciella färger?

2. Vill ni att någon form av användarmanual eller liknande ska finnas?

3. Hur stor vikt lägger ni på att verktyget bör vara anpassat för vidareutveckling?

Eftersom dessa frågor inte har något med verktygets funktionalitet att göra (som arbetades fram agilt) hade dessa varit relevanta att ställa i början av arbetet, resultatet av att detta dock inte gjordes i början blev att vi undermedvetet exempelvis antog att en minimalistisk design med enkla färger var något som LHC inte hade något emot. Vi tog även hänsyn till den faktor att någon i framtiden även kanske skulle fortsätta arbetet på just denna kodbas. Om dessa frågor hade ställts i början hade vi antagligen varit mer säkra på det vi gjorde samt vetat mer exakt vad som förväntades av oss.

6.1.2 Funktionalitet

Eftersom funktionaliteten från början inte var helt bestämd utan istället arbetades fram i takt med utvecklandet blev denna väldigt friformig. Med andra ord implementerades den funktionalitet som LHC på vägen insåg att de ville ha. Detta gjorde att verktyget i sin helhet blev väldigt anpassat till just LHC. Om verktyget istället inte hade varit så anpassat hade annan funktionalitet kanske varit mer i fokus, exempel på dessa är:

• Flera olika sätt att jämföra och rangordna spelare på

• Mer hjälp-funktionalitet såsom en inledningsguide eller användarmanual • Mer sätt att mata in data på

• Något sätt att ändra den data som redan har lästs in till verktyget

Denna funktionalitet hade åtminstone varit lämplig att tänka på och i vissa fall även implementera. En fördel med att inte behöva göra detta var dock att mer tid kunde läggas på det som just LHC tyckte var viktigt.

29

6.1.3 Design

Som redan nämnts blev designen minimalistisk med enkla vanliga färger, detta inte bara för att låta verktygets funktionalitet ta mer plats men även för att vara så användarvänligt och så stilrent som möjligt. För att fortsätta utveckla designen i efterhand finns flera saker som skulle kunnat läggas till om så önskades, exempelvis, mörkerläge, val av språk och grafer för spelarjämförelsen. Då detta dock inte var något som LHC önskade valde vi istället för att implementera något av detta att i slutet fokusera mer på den funktionalitet som redan fanns, detta genom att städa upp koden och fixa befintliga buggar. För att göra designen ännu bättre kunde vi dock exempelvis ha haft intervjuer samt tester för att se vilken typ av design som passat bäst, detta skulle dock enligt oss varit en mindre bra användning av vår tid då vi redan varje vecka visade och tog emot feedback från LHC (vilket inkluderar feedback om designen).

6.1.4 Feedback

Den kontinuerliga feedbacken som gavs varje vecka var för oss oerhört viktig. Den gav oss inte bara möjligheten att se vad som var bra och mindre bra just den veckan utan var även bra för att få en bild över LHC:s tankar kring verktyget. Eftersom feedbacken gavs varje vecka var vi även väl förberedda att åtgärda eventuella fel då vi antagligen samma vecka hade utvecklat just det.

Den SUS enkät som användes var för oss även den väldigt givande. Inte bara för att den gav bra resultat utan för att vi då kunde se att verktyget verkligen var något som LHC blev nöjda med. Det kan dock diskuteras om poängen verkligen skulle vara 95, detta då vi endast fick in ett svar som stod för flera personer. Hade flera personer svarat individuellt hade poängen antagligen skiftat något beroende på deras tidigare erfarenheter, datakunskaper osv. Det vi dock kan ta med oss från den höga poängen är att det var just hög, detta ger oss en bra bild av att LHC verkligen gillar och kommer dra nytta av verktyget.

6.2 Metod

Nedan diskuteras de metoder som användes i arbetet. 6.2.1 Arbetsmiljö

Beslutet att arbeta i Electron blev enligt oss väldigt bra, detta i och med att vi då kunde använda våra redan befintliga kunskaper inom webbutveckling och fick därmed en bra grund att arbeta ifrån. Vi kunde därav också lägga mer fokus på att utveckla de delar som just LHC ville ha istället för att lägga onödig tid på att utforska en ny teknologi eller ett nytt ramverk. Att arbeta med webbutveckling, framförallt JavaScript, gav oss även tillgång till många olika paket att använda, detta förenklade utvecklingsprocessen markant vilket sparade oss värdefull tid och arbetskraft. Möjligheten att bygga verktyget mot andra plattformar än Windows är även det en fördel för Electron.

Beslutet att använda oss av Git för versionshantering blev även det bra, det räddade oss flera gånger då vi behövde gå tillbaka i kodbasen och se saker som tagits bort eller ändrats. Uppdelning blev även den enklare vid användningen av Git eftersom olika grenar då kunde användas.

6.2.2 Det agila arbetssättet

Att arbeta agilt har varit bra för både oss och LHC, om ett annat mer statiskt arbetssätt hade använts hade antagligen ett mer generellt program vuxit fram. Nu gav arbetssättet istället oss möjligheten att hela tiden småjustera arbetet i rätt riktning för att alltid få det optimala för just LHC. Arbetssättet gav oss även möjligheten att få snabb feedback på både design och funktionalitet under hela utvecklingsprocessen och därmed inte bara i slutet. Om vi hade haft mer tid eller arbetat i ett större team hade dock kanske andra metoder varit bättre.

30

6.3 Etik i arbetet

Detta arbete har utförts på så sätt att inga personliga uppgifter har samlats in och att ett avtal, Non Disclure Agreement(NDA), skrivits under av samtliga deltagare. Avtalet innefattade att vi utvecklare inte läcker någon av de spelardata som tillhandahållits av LHC. Detta har undvikits genom att ändra spelardatan till påhittade spelare i rapporten. Arbete har också utförts efter LHCs önskemål där deras idéer har fått ta stor plats. Egna idéer om funktioner och liknande har också föreslagits men har inte förrän efter LHCs godkännande implementerats. När det gäller hänsyn till LHC har vi fått ett godkännande att publicera all information som finns med i rapporten.

6.4 Källkritik

När det gäller de källor som använts i rapporten finns flera saker att belysa. Användningen av Wikipedia som primärkälla är ofta en typisk sak att vara på sin vakt med. Anledningen till dess dåliga stigma är framför allt på grund av att vem som helst har möjlighet att ändra sidans innehåll. Detta är dock ofta inte fallet längre, nu för tiden är Wikipedia-sidor ofta mer modererade, detta är i synnerhet fallet för större sidor med flera olika språk. Vi anser därför att de områden där Wikipedia använts som primärkälla är tillräckligt stora och generella att detta inte blir något problem.

Utöver Wikipedia har även ett flertal rapporter och studier använts som primärkällor, dels för att förklara tidigare forskning, dels för att ge en överblick över relaterade områden. Genom att se över antalet citat en rapport har fick vi snabbt en överblick hur mycket andra har litat på rapporten, med hjälp av innehållet, detta och den vetskap om hur gammal forskningen är gav vi en bedömning huruvida rapporten borde ha använts eller inte. Genom att läsa flera olika rapporter inom samma områden fick vi även en bra överblick över vilka områden som många av författarna enats om och kunde därmed även lite extra på de styckena.

Till sist användes ett fåtal andra källor så som blogginlägg och mer seriösa artiklar för att de förmedlade nyheter, nyheter som visade vad som försiggår inom relevanta områden. Dessa användes därmed inte som underlag till någon direkt fakta förutom att få en förståelse för hur området ser ut idag.

31

7. Slutsats

Nedan följer svaren på våra frågeställningar, dessa var:

1. Hur utvärderar LHC idag hockeyspelare utifrån deras tidigare prestationer och vilken data som är mest relevant för detta ändamål?

2. Hur kan ett optimalt scoutingverktyg för LHC se ut?

7.1 Scoutingprocessen idag

Genom diskussioner har vi kommit fram till följande:

När LHC utvärderar hockeyspelares tidigare prestationer använder de sig av statistik från ett utomstående företag vid namn Sportlogiq. Sportlogiq tillhandahåller även ett sätt att visualisera statistiken på, med hjälp av detta verktyg går LHC sedan igenom och jämför spelare för hand för att se vilka som bäst passar den rollen som sökes. Just den data som är mest relevant för detta ändamål beror självklart på vad det är man söker, letar man en forward, back eller en spelare som är bra på något speciellt så är ju självklart datan relaterad till just detta något man vill kolla på. På samma sätt blir då motsatsen i datan något man inte bryr sig om, självklart finns även statistik som är bra för alla typer av spelare, exempelvis ”blockerade skott” men frågan blir då istället, ”hur viktigt är just denna statistik för spelaren jag undersöker?”. Svaret på frågan blir då olika beroende på vilken typ av spelare man letar efter, är det en forward är just denna statistik bra men kanske inte lika viktig som för en back.

7.2 LHC:s scoutingverktyg

Efter flera månaders tätt arbete tillsammans med LHC har vi kommit fram till att båda parterna är nöjda. Verktyget är inte perfekt och det finns alltid saker som behövs fixas. Ju mer man använder verktyget desto mer ny funktionalitet önskar man att det hade, genom flitigt användande från både vår och LHC sida har även väldigt många buggar hittats och fixats. Verktyget har dock enligt både oss och LHC löst både de initiala problem som beskrevs i början av arbetet och även löst andra. Ett exempel på funktionalitet som LHC blev nöjda med som inte var med som ett initialt problem var ”lagbygges-funktionen”. Allt detta reflekteras i SUS enkäten som gav en oerhört hög poäng, nämligen 95.

7.3 Slutord

Eftersom arbetet gjordes som examensarbete för högskoleutbildningen i datateknik känner vi oss nöjda med det resulterande verktyget. Vi har dragit nytta av hela utbildningen men speciellt kurser inom programmering, grupparbete och framförallt webbutveckling. Vi känner att verktyget inte bara uppfyller de krav som sattes, därmed går att använda sig av, utan att det även är enkelt att använda och fortsätta utveckla i framtiden.

32

8. Referenslista

[1] Wikipedia. Ishockey. Hämtad från https://sv.wikipedia.org/wiki/Ishockey (2021/02/10).

[2] A. Y. Kondratev, E. Lanovski, A. S. Nesterov. How should we score athletes and candidates: geometric scoring rules [Internet]. arXiv [cs.GT]. 2019. Hämtad från: http://arxiv.org/abs/1907.05082

[3] D. B. Dwyer, T. J. Gabbett. Global Positioning System Data Analysis: Velocity Ranges and a New Definition of Sprinting for Field Sport Athletes, Journal of Strength and Conditioning Research: March 2012 - Volume 26 - Issue 3 - p 818-824 doi: 10.1519/JSC.0b013e3182276555

[4] T. Gulitti, NHL plans to deploy Puck and Player Tracking technology next season. NHL ALL-STAR. Weblog. Hämtad från https://www.nhl.com/news/nhl-plans-to-deploy-puck-and-player-tracking-technology-in-2019-2020/c-304218820 (2021/02/05).

[5] T. Lehmus Persson, H. Kozlica, N. Carlsson, and P. Lambrix, ‘Prediction of Tiers in the Ranking of Ice Hockey Players’, in Machine Learning and Data Mining for Sports Analytics 7th International Workshop, MLSA 2020, Co-located with ECML/PKDD 2020, Ghent, Belgium, September 14–18, 2020, Proceedings, 2020, pp. 89–100. doi: 10.1007/978-3-030-64912-8_8

[6] H. Pileggi, C. D. Stolper, J. M. Boyle and J. T. Stasko, "SnapShot: Visualization to Propel Ice Hockey Analytics," in IEEE Transactions on Visualization and Computer Graphics, vol. 18, no. 12, pp. 2819-2828, Dec. 2012, doi: 10.1109/TVCG.2012.263.

[7] H. Tomislav, J. Josip. The use of machine learning in sport outcome prediction: A review. WIREs Data Mining Knowl Discov. 2020; 10:e1380. doi: 10.1002/widm.1380

[8] T. Guo, K.Tao , Q Hu, Y Shen, 2020. Detection of Ice Hockey Players and Teams via a Two-Phase

Cascaded CNN Model Hämtad från

https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=9239271/ (2021/02/10).

[9] T. L. Weissgerber, N. M. Milic, S. J. Winham, V. D. Garovic, (2015) Beyond Bar and Line Graphs: Time for a New Data Presentation Paradigm. PLOS Biology 13(4): e1002128. doi: 10.1371/journal.pbio.1002128

[10] E. M. Smith, J, Kershaw, 2012. Data Display Choices. [Blog] Types of Data Representation, Hämtad från https://www.ck12.org/statistics/types-of-data-representation/lesson/Data-Display-Choices-MSM7/ (2021/02/09).

[11] M. Gualtieri, 2009. Best Practices In User Experience (UX) Design

Hämtad från

http://web.uchile.cl/DctosIntranet/05UsabilidadExperienciaUsuario/BuenasPracticas/BestPracticesU serExperience.pdf (2021/02/09).

[12] M. Matera, F. Rizzo, G. T. Carughi, (2006) Web Usability: Principles and Evaluation Methods. In: Mendes E., Mosley N. (eds) Web Engineering. Springer, Berlin, Heidelberg. Doi: 10.1007/3-540-28218-1_5

[13] mozilla.org. HTML basics Hämtad från https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/HTML_basics (2021/04/21).

33

[14] Mozilla. CSS: Cascading Style Sheets. Hämtad från https://developer.mozilla.org/en-US/docs/Web/CSS (2021/05/24).

[15] Mozilla. JavaScript. Hämtad från https://developer.mozilla.org/en-US/docs/Web/JavaScript (2021/05/24).

[16] Wikipedia. Type system. Hämtad från https://en.wikipedia.org/wiki/Type_system (2021/04/23).

[17] Wikipedia. Node.js. Hämtad från https://en.wikipedia.org/wiki/Node.js (2021/04/26)

[18] Wikipedia. Bootstrap (front-end framework). Hämtad från

https://en.wikipedia.org/wiki/Bootstrap_(front-end_framework) (2021/04/26)

[19] Node.js. What is npm?. Hämtad från https://nodejs.org/en/knowledge/getting-started/npm/what-is-npm/(2021/04/27).

[20] Electronjs.org. Docs. Hämtad från https://www.electronjs.org/docs (2021/05/24).

[21] Wikipedia. Programutvecklingsmetodik. Hämtad från

https://sv.wikipedia.org/wiki/Programutvecklingsmetodik (2021/05/03).

[22] Wikipedia. Cross-plattform software. Hämtad från https://en.wikipedia.org/wiki/Cross-platform_software (2021/04/26).

[23] chartjs.org. Chart.js. Hämtad från https://www.chartjs.org/(2021/04/26).

[24] M. McCormick, (2012), “Waterfall vs agile methdology”, Hämtad från: http://www.mccormickpcs.com/images/Waterfall_vs_Agile_Methodology.pdf (2021/05/04).

[25] Wikipedia. Agil systemutveckling. Hämtad från

https://sv.wikipedia.org/wiki/Agil_systemutveckling (2021/05/04).

[26] git-scm. About. Hämtad från https://git-scm.com/about (2021/05/05)

[27] Wikipedia. GitHub. Hämtad från https://en.wikipedia.org/wiki/GitHub (2021/04/29).

[28] A. Srivastava, S. Bhardwaj and S. Saraswat, "SCRUM model for agile methodology," 2017 International Conference on Computing, Communication and Automation (ICCCA), 2017, pp. 864-869, doi: 10.1109/CCAA.2017.8229928.

[29] Wikipedia. Scrum (software development). Hämtad från

https://en.wikipedia.org/wiki/Scrum_(software_development) (2021/05/04)

[30] Wikipedia. Comma-separated values. Hämtad från https://en.wikipedia.org/wiki/Comma-separated_values (2021/05/05)

[31] tiobe.com. TIOBE Index for May 2021. Hämtad från https://www.tiobe.com/tiobe-index/ (2021/05/04)

[32] Wikipedia. Python (programming language). Hämtad från