Teknik och samh¨alle
Datavetenskap och medieteknik
Examensarbete
15 h¨ogskolepo¨ang, grundniv˚a
JMR - Kontextmedveten musikrekommenderare f¨or Spotify
JMR - context-aware music recommender for SpotifyVictor Marante
Simon M˚
ansson
Examen: kandidatexamen 180 hp Huvudomr˚ade: datavetenskap Program: systemutvecklare
Datum f¨or slutseminarium: 29/5-2018
Handledare: Steve Dahlskog Examinator: Lars Holmberg
Sammanfattning
Str¨ommande musiktj¨anster erbjuder ett stort utbud av musik. F¨orutom att anv¨andare kan skapa egna listor fr˚an detta utbud, erbjuder tj¨ansterna ofta personliga rekommendationer.
¨
Aven om rekommendationerna passar anv¨andaren v¨al, passar de inte alltid f¨or situationen de befinner sig i. I denna studie presenteras en artefakt i form av en kontextmedveten musikapplikation som anv¨ander Spotify f¨or rekommendation och uppspelning av musik. En kontextmedveten musikapplikation ¨ar en applikation som tar anv¨andarens kontext i beaktning vid musikrekommendation. I denna studie refererar kontext till den situation som en potentiell anv¨andare befinner sig i, exempelvis ”ute och springer i parken klockan tre”.
Vi presenterar en enk¨atunders¨okning om vilka kontextuella faktorer anv¨andare tycker ¨
ar viktiga, och fr˚agor kring lyssnarbeteende. Artefakten testas i en anv¨andarstudie och resultaten analyseras och diskuteras i relation till tidigare forskning. Vi ser att anv¨andare har en positiv inst¨allning till att kontextuella faktorer p˚averkar vilken musik de lyssnar p˚a, och att det finns en positiv inst¨allning till kontextmedvetna musikapplikationer. Vidare ser vi att aktivitet ¨ar den mest relevanta kontextuella faktorn f¨or anv¨andare.
Abstract
Music streaming services offer a large quantity of music. Apart from users being able to create their own playlists, these services also offer personal music recommendations. Even though these recommendations meet the users preferences, they don’t always fit the users current situation. In this study, we present an artifact in the shape of a context-aware music recommender application, that uses Spotify services to recommend and handle playback of music. A context-aware music application is an application that takes a users current context in consideration when recommending music. In this study, context-aware refers to the situation a given user might find themselves in, e.g. ”jogging in the park at 3pm”.
We present a questionnaire about which contextual factors users think are important, and questions about listening preferences. The artifact is tested in a user study, and the results are analysed and discussed in relation to previous studies. We found that users have a positive attitude towards contextual factors influencing which music they listen to, and that there is a positive attitude towards contextual music recommenders. Furthermore we found that activity is the most relevant contextuall factor to users.
Inneh˚
all
1 Inledning 1 1.1 Problemdiskussion . . . 1 1.2 Syfte och m˚al . . . 1 1.3 Fr˚agest¨allning . . . 2 1.4 Kontext . . . 2 1.5 Kontextmedvetenhet . . . 2 1.6 Musikrekommnenderare . . . 3 1.7 Tidigare forskning . . . 3 1.8 Spotify . . . 4 1.9 Avgr¨ansningar . . . 5 1.9.1 Kontextuella faktorer . . . 5 1.9.2 Str¨ommande tj¨anster . . . 5 1.9.3 Plattform . . . 5 1.9.4 M˚algrupp . . . 5 2 Metod 5 2.1 Systematisk litteraturstudie . . . 52.2 Design Science Research . . . 6
2.3 Genomf¨orande . . . 7 2.4 Datainsamling . . . 7 2.4.1 Enk¨at . . . 7 2.4.2 Intervju . . . 7 2.4.3 Anv¨andarstudie . . . 8 2.5 Pilotstudie . . . 8 2.6 Metoddiskussion . . . 8 2.6.1 Alternativa forskningsmetoder . . . 9 2.6.2 Enk¨atdiskussion . . . 9 2.6.3 Intervjudiskussion . . . 10 2.6.4 Datainsamlingsmetoder . . . 10
2.7 Etiska ¨overv¨aganden . . . 10
3 Design av artefakt 11 3.1 Overgripande design . . . .¨ 11 3.2 Iteration ett . . . 11 3.3 Iteration tv˚a . . . 12 4 Implementation av artefakt 12 4.1 Mobilapplikation . . . 12 4.1.1 Iteration ett . . . 13 4.1.2 Iteration tv˚a . . . 14 4.2 Backend . . . 16
5 Resultat 17 5.1 Enk¨at . . . 17 5.2 Iteration ett . . . 19 5.2.1 Anv¨andarstudie . . . 19 5.2.2 Anv¨andardata . . . 19 5.2.3 Intervju . . . 20 5.3 Iteration tv˚a . . . 21 6 Analys 24 6.1 Enk¨at . . . 24 6.2 Iteration ett . . . 26 6.3 Iteration tv˚a . . . 27 7 Diskussion 28 7.1 Tid . . . 28 7.2 Plats . . . 29 7.3 Aktivitet . . . 29 7.4 Upplevelse . . . 30 7.5 Str¨ommande tj¨anster . . . 31 7.6 Artefakt . . . 32 7.7 Alternativ l¨osning . . . 32 7.8 Sammanfattning . . . 33
8 Slutsatser och vidare forskning 33 8.1 Framtida forskning . . . 34 9 Referenser 35 10 Bilagor 38 10.1 Bilaga A . . . 38 10.2 Bilaga B . . . 40 10.3 Bilaga C . . . 41
1
Inledning
Dagens str¨ommande tj¨anster har m¨ojlighet att leverera musik i en rad olika genrer och vi kan ta med oss v˚ara favoritl˚atar vart vi ¨an g˚ar. Borta ¨ar problemen med vilken cd som skulle med i cd-spelaren eller vilka l˚atar som skulle lagras i mp3-spelaren. Spotify hade ¨over 35 miljoner l˚atar i sin tj¨anst i slutet av 2017 [1]. Ett markant st¨orre utbud att v¨alja fr˚an i j¨amf¨orelse med f¨orr n¨ar tjugo stycken l˚atar fick plats p˚a mp3-spelaren. F¨orsta versionen av str¨ommande tj¨anster introducerades f¨or ungef¨ar 25 ˚ar sedan [2] och trots att vi nu har med oss mer musik ¨an vi hinner lyssna p˚a, finns d¨ar fortfarande problem att v¨alja l˚atar.
1.1 Problemdiskussion
Det kan t¨ankas att n¨ar vi sitter och tar det lugnt i soffan vill vi inte h¨ora samma musik som vi lyssnar p˚a under ett intensivt tr¨aningspass. En l¨osning p˚a detta dilemma ¨ar att skapa egna spellistor. Nackdelen med dessa listor ¨ar att de tar l˚ang tid att skapa eller inte riktigt passar till situationen fullt ut. Vi kan inte heller anpassa v˚ara listor hela tiden, eftersom det skulle ta alldeles f¨or mycket tid. Det finns listor skapade av exempelvis Spotify f¨or olika m¨ojliga situationer vi kan t¨ankas befinna oss i, men vilken musik som passar till en viss situation ¨ar subjektivt och skiljer sig s˚aledes fr˚an lyssnare till lyssnare. Spotify g¨or ¨
aven personliga listor och ¨aven om de ligger n¨armre v˚ar musiksmak ¨ar det inte s¨akert att de passar till det vi g¨or f¨or stunden. Spotify vet mycket om vilken musik vi gillar men inte i vilken kontext vi vill h¨ora den. Samtidigt b¨ar vi med oss v˚ara smartphones som ¨ar kapabla att l¨asa av kontexten vi befinner oss i. En anv¨andarstudie visar p˚a att anv¨andare tycker olika l˚atar passar b¨attre till olika kontexter, det ¨ar tidskr¨avande att skapa egna listor och obeh¨andigt att byta l˚at mitt i en syssla [3]. H¨ar ser vi precis som en tidigare studie [4] en m¨ojlighet att unders¨oka hur kontextmedvetenhet och str¨ommande tj¨anster kan anv¨andas f¨or att automatisera processen att rekommendera musik till personer. Vidare ser vi en m¨ojlighet att unders¨oka hur musiklyssnare ser p˚a att bli rekommenderad musik utifr˚an kontextuella faktorer.
1.2 Syfte och m˚al
Syftet med v˚ar studie ¨ar att unders¨oka hur anv¨andare upplever att bli rekommende-rad musik utifr˚an kontextuella faktorer och bidra till den samlade forskningen inom ¨
amnet Kontextmedvetna musikrekommenderare (Context-Aware music recommen-ders) (KMMR). V˚art m˚al ¨ar att bygga en proof of concept mobilapplikation som tar anv¨andarens kontext i beaktning n¨ar musik ska rekommenderas, och utv¨ardera hur anv¨andare upplever att bli rekommenderade utifr˚an kontextuella faktorer.
1.3 Fr˚agest¨allning
V˚ara forskningsfr˚agor ¨ar f¨oljande:
1. Vill musiklyssnare att de kontextuella faktorerna tid, plats och aktivitet skall inverka p˚a musikval?
1.1. Vilken eller vilka av dessa faktorer ¨ar viktigast i en applikation som v¨aljer musik efter kontext?
2. Hur upplever folk att bli rekommenderad musik utifr˚an tid, plats och aktivitet?
1.4 Kontext
Kontext ¨ar information som karakt¨ariserar en situation f¨or en person, plats eller f¨orem˚al som anses vara relevant f¨or interaktionen mellan anv¨andare och applikation [5]. Tid, plats, aktivitet och anv¨andarens identitet anses vara de viktigaste kontextuella faktorerna [5]. F¨or mobila applikationer kan ¨aven kontext utvecklas till att beskriva tillst˚andet i omgivningen som p˚averkar applikationens beteende eller startar en h¨andelse i applikationen som ¨ar intressant f¨or anv¨andaren [6].
1.5 Kontextmedvetenhet
Vi har st¨ott p˚a ett antal definitioner f¨or vad ett context-aware (kontextmedveten) system ¨
ar. En beskrivning delar in det in fyra kategorier a) Proximate selection ¨ar en teknik f¨or anv¨andagr¨anssnitt d¨ar n¨arliggande f¨orem˚al betonas och g¨ors enklare att v¨alja. b) automa-tic contextual reconfiguration komponenter l¨aggs till, tas bort eller kopplingarna ¨andras
mellan dem beroende p˚a nuvarande kontext. c) contextual information and commands
samma kommando ger olika resultat beroende p˚a anv¨andarens kontext, t. ex. skriv-ut kommandot v¨aljer den n¨armaste skrivaren. d) context-triggered actions IF-THEN regler som beskriver hur systemet ska anpassa sig [7]. En annan definition s¨ager att ett system ¨
ar context-aware om det anv¨ander kontextuell data f¨or att a) presentera information f¨or anv¨andaren b) automatiskt utf¨ora en tj¨anst f¨or anv¨andaren c) spara ner informationen om anv¨andarens situation f¨or senare anv¨andning [5]. F¨or mobilapplikationer kan kontext anv¨andas p˚a tv˚a s¨att: automatiskt anpassa sitt beteende efter det kontext som uppt¨ackts d.v.s. active context awareness, presentera den kontext som uppt¨ackts f¨or anv¨andaren eller spara undan kontexten f¨or senare anv¨andning d.v.s. passive context awareness [6].
Flera system som forskats fram har haft problem att realiseras i praktiken. Ofta har de fallerat d¨arf¨or att de problem de f¨ors¨oker l¨osa slutat existerar [8]. Exempelvis The Active Badge Location System kopplade samtal till medarbetare baserat p˚a deras plats i byggnaden som s¨andes ut via s¨andare medarbetarna bar [9]. Att koppla om samtal slutade vara ett problem n¨ar mobiltelfonerna kom. De system som haft framg˚ang i praktiken har a) agerat reaktivt. b) haft m¨ojlighet att avslutas n¨ar som helst. c) till˚atit anv¨andaren kontrollera m¨angden data som systemet kan tillg˚a [6]. Systemen har ¨aven haft ett begr¨ansat och definierat omf˚ang. M¨ojliga kontext har begr¨ansats och uppgifter systemet ska utf¨ora har haft tydliga start och slut kriterier [6].
1.6 Musikrekommnenderare
Musikrekommenderare ¨ar verktyg som ¨amnar att rekommendera l˚atar som passar anv¨andaren. Det ¨ar dock inte l¨att eftersom flera faktorer p˚averkar, exempelvis personlighet, ˚alder, so-cioekonomisk bakgrund och hur bekant lyssnaren ¨ar med musiken de h¨or [10]. Det finns flera s¨att att tackla de h¨ar problemen, i resten av kapitlet ges en v¨aldigt kort summering av tv˚a alternativ.
Collaborative filtering (CF) ¨ar en teknik d¨ar feedback fr˚an anv¨andarens interaktion med systemet anv¨ands f¨or att ge och f¨orb¨attra rekommendationer. Feedback kan best˚a av anv¨andares betygs¨attning av l˚atar eller tiden de lyssnar p˚a en l˚at [10]. CF beh¨over allts˚a inte genomf¨ora kostsamma analyser av l˚atars inneh˚all f¨or sina rekommendationer [11]. Tre problem med CF ¨ar a) Cold start-problemet. N¨ar en ny anv¨andare eller l˚at l¨aggs till finns ingen tidigare information om dem och kan d¨arfor inte kopplas till andra anv¨andare eller l˚atar. b) Long tail-problemet. Polpul¨ara l˚atar tenderar att rekommenderas oftare vilket g¨or att ok¨anda l˚atar f˚ar sv˚art att synas. c) Data-sparsity-problemet. Finns det ett stort antal l˚atar och anv¨andare, tenderar t¨ackningen av betyg vara l˚ag. Detta kan leda till ostadiga rekommendationer f¨or anv¨andare som har betygsatt ett f˚atal l˚atar. F¨or att l¨osa dessa problem kan CF kombineras med n¨asta teknik.
Content-based filtering (CB) analyserar inneh˚all med h¨ansyn till tempo, frekvensomf˚ang eller metadata som: artist, titel eller bolag f¨or att ta fram en feature(s¨ardrag) vektor[11]. Dessa vektorer kan sedan anv¨andas i algoritmer som exempelvis Nearest Neighbour f¨or att finna l˚atar som liknar de anv¨andaren gillar. CB kan f˚a ett “long tail”-liknande problem d¨ar l˚atar som liknar varandra ¨ar det enda som rekommenderas. Det kan ¨aven bli problem med genrer d˚a lyssnaren kan anse att en l˚at h¨or till en helt annan genre ¨an vad systemet g¨or.
Ovanst˚aende tekniker kan kombineras i olika grad f¨or att t¨acka varandras svagheter [11]. Rekommendationerna ¨ar alltid utifr˚an en historisk kontext och det ¨ar sv˚art att veta vad anv¨andaren g¨or just nu. Det ¨ar h¨ar kontextmedvetna musikrekommendare kommer in i bilden.
1.7 Tidigare forskning
En ung gren inom omr˚adet musikrekommendationssytem ¨ar KMMR. F¨orutom CF och
CB anv¨andes sensorer f¨or att ta reda p˚a anv¨andarens nuvarande situation och ta med i beaktning n¨ar musik ska rekommenderas. Sensorerna kan vara i mobiltelefonen eller exempelvis ett armband. Arkitekturen best˚ar oftast av en klient-servermodell med en mobilapplikation f¨or kontextdetektering och uppspelning av musik och en server f¨or att ta fram musikrekommendationer [3, 12, 13]. D¨ar finns ¨aven exempel best˚aende av endast mobilapplikationer [14].
Data som samlats in om anv¨andarens kontext ¨ar: plats [3, 12, 13, 4, 15, 16], tid [13, 14, 4, 15], ljusstyrka [3, 13, 4], aktivitet [3, 12, 13, 14, 4], bakgrundsljud [3, 14, 4] och vibration [15]. ¨Aven data fr˚an sociala medier har anv¨ants f¨or att rekommendera musik. Facebook-, Twitter- och Instagramfl¨oden avl¨ases f¨or att hitta l˚atar som ¨ar popul¨ara och omtalade f¨or tillf¨allet [16]. Maskininl¨arningsmetoder kan appliceras p˚a data f¨or att detek-tera anv¨andarens kontext. Modeller har tr¨anats med supervised learning [3, 12, 13, 15] eller unsupervised learning [14] och anv¨ants i applikationen. Vissa applikationer bygger ¨
Kontexten som detekterats har kategoriserats in i f¨ordefinierade aktiviteter exempelvis g˚a, springa, k¨ora, ligga still, sitta etc. [3, 13]. Moodmapping har anv¨ants som parameter f¨or indata i KMMRs [17, 4]. En studie har anv¨ant sig av en f¨ordefinierad lista av olika hum¨or som kopplas till l˚atar [4]. I en annan studie fick anv¨andare v¨alja aktivitet och hum¨or innan de b¨orjade anv¨anda applikationen [17]. L˚atar som spelades upp under denna session kategoriserades baserat p˚a valen som anv¨andaren gjorde. Efter tre veckor hade applikationen tillr¨ackligt med data f¨or att rekommendera musik automatiskt, baserat p˚a aktivitet och hum¨or [17].
Genomg˚aende f¨or tidigare studier ¨ar att ett fast f¨orutbest¨amt antal l˚atar har anv¨ants i testerna [3, 12, 13, 14], f˚a har anv¨ant sig av anv¨andarens egna musikbibliotek [4] och l˚atarna har lagrats lokalt p˚a mobiltelefonen [12, 15]. I en studie har l˚atar gradvis lagts till applikationen f¨or att simulera ett v¨axande bibliotek av l˚atar och nya kontexter [15]. KMMRs har visat sig ge b¨attre rekommendationer ¨an slumpen [3, 14] och visat p˚a en f¨orm˚aga att anpassa sig till anv¨andarens musikperenser [14, 13]. En anv¨andarstudie visar p˚a att anv¨andare tycker olika l˚atar passar b¨attre till olika kontexter, det ¨ar tidskr¨avande att skapa egna listor och obeh¨andigt att byta l˚at mitt i en syssla [3]. Utv¨arderingar av anv¨andarupplevelsen har skett i sm˚a grupper kring 10 personer [3, 14] eller st¨orre grupper omkring 60 personer [12, 4]. Anv¨andare st¨aller sig positivt till den h¨ar typen av applika-tioner [14, 12].
1.8 Spotify
Spotify ¨ar en str¨ommande underh˚allningstj¨anst som levererar musik, podcasts och videos i gratis och betalform1. Ut¨over att anv¨andare kan skapa egna spellistor och l¨agga till l˚atar som de ¨onskar, rekommenderar Spotify musik ˚at sina anv¨andare. Discover Weekly och Daily Mix ¨ar tv˚a exempel p˚a rekommendationer som Spotify genererar ˚at sina anv¨andare baserat p˚a bland annat vad anv¨andare tidigare har lyssnat p˚a [18].
Spotify tillhandah˚aller funktionalitet som till˚ater utvecklare att sj¨alva skapa rekom-mendationer och utf¨ora diverse operationer som finns tillg¨angligt i deras ¨oppna Web API2. Exempelvis ¨ar det m¨ojligt att h¨amta de 50 senast spelade l˚atarna f¨or en anv¨andare, eller en anv¨andares mest spelade artister och l˚atar. Vidare erbjuder Spotify m¨ojligheten att rekommendera musik utifr˚an fem stycken v¨arden som kan vara antingen l˚atnamn, artist-namn eller genrar.
Spotify anv¨ander flera algoritmer f¨or att generera rekommendationer. CF appliceras p˚a alla spellistor f¨or att ta reda p˚a anv¨andares prefrenser och ranka l˚atar. CB anv¨ands f¨or att analysera l˚atar d¨ar liknande artister och genrer bildar kluster. Resultaten av CB anv¨ands f¨or att skapa skapa s˚a kallade taste profiles f¨or anv¨andare. Natural language processing anv¨ands f¨or att sammanst¨alla metadata om artister. Deep learning algoritmer anv¨ands f¨or att f¨orutsp˚a framtida lyssningsprefrenser hos anv¨andare [19].
1https://www.spotify.com/ 2
1.9 Avgr¨ansningar
1.9.1 Kontextuella faktorer
Vi har valt att avgr¨ansa oss till tid, plats, aktivitet och identitet vad g¨aller kontextuel-la faktorer. Definitionen av aktivitet skiljer sig beroende p˚a vem man fr˚agar. Vi valde f¨oljande definition d˚a vi anser att den ¨ar rimlig f¨or studiens omf˚ang: in vehicle, on bi-cyle, on foot, walking, running, still, unknown, d¨ar unknown inneb¨ar att aktiviteten inte kan detekteras av Googles API. Denna aktivitet anv¨ands som standard v¨arde, innan en aktivitet uppt¨ackts. Denna defintion ¨ar en delm¨angd av de olika aktiviteter som Google definierar i sitt aktivitets-API, Google Activity Recognition [20]. Vi valde en f¨ardig l¨osning f¨or att vi vill fokusera p˚a kombinationen av kontextmedvetenhet och str¨ommande tj¨anster ¨
over att implementera algoritmer. F¨or begr¨ansa applikationens komplexitet valde vi att inte anv¨anda ytterligare bibliotek.
1.9.2 Str¨ommande tj¨anster
Idag finns det flera str¨ommande tj¨anster f¨or musik, exempelvis Apple Music och Spotify. 2017 hade Spotify 50 miljoner betalande anv¨andare, dubbelt s˚a mycket som Apple music [21]. Spotify har ett API som vi kan utnyttja till v˚ar applikation [22] och vi har ¨aven tidiga-re erfatidiga-renheter av att anv¨anda det vilket kommer till nytta, eftersom tid f¨or utvecklingen av applikationen ¨ar begr¨ansad. D¨arf¨or v¨aljer vi att avgr¨ansa oss till Spotify.
1.9.3 Plattform
De vanligaste operativsystemen f¨or smartphones idag ¨ar Android och iOS. ˚Ar 2017 var antalet anv¨andare i Sverige 39% f¨or Android och 46% f¨or iOS [23]. P˚a grund av tidi-gare kunskaper inom utveckling av androidapplikationer, valde vi ¨and˚a att utveckla v˚ar prototyp i android.
1.9.4 M˚algrupp
M˚algruppen f¨or v˚ar studie ¨ar aktiva musiklyssnare med en androidtelefon och ett Spotify premium konto.
2
Metod
2.1 Systematisk litteraturstudie
Vi har genomf¨ort en systematisk litteraturstudie f¨or att samla in relevanta artiklar och skapa en uppfattning om det r˚adande forskningl¨aget. F¨or att finna artiklar har ACM Di-gital Library (ACM) [24], IEEE Xplore DiDi-gital Library (IEEE) [25] och Google Scholar (Scholar) [26] anv¨ants. Vi s¨okte huvudsakligen i databaserna ACM och IEEE. Scholar anv¨andes f¨or att g¨ora snowballing eller hitta artiklar som inte var direkt relaterade till datavetenskap. Vi s¨okte i databaserna med hj¨alp av s¨okstr¨angar som konstruerades uti-fr˚an forskningsfr˚agorna (Se bilaga A f¨or s¨okstr¨angar). Utifr˚an resultaten fr˚an s¨okningarna applicerades kriterier som publikations˚ar och titel, f¨or att s˚alla bort artiklar som inte var
l¨ampliga (Se bilaga A f¨or komplett lista). F¨or att granska artiklar som klarade urvalspro-cessen tog vi inspiration av S. Keshav trestegsmodell [27]. I f¨orsta steget l¨astes rubriker, diskussion, slutsats och k¨allh¨anvisning. I andra steget l¨aste vi mer noggrant f¨or att skapa en b¨attre helhetsbild av artikeln. I tredje steget granskades artikeln grundligt med fokus p˚a detaljerna i studien. Artiklar som gick igenom alla steg togs med i studien.
2.2 Design Science Research
Vi anv¨ander Design-science research (DSR) vilket ¨ar ett konceptuellt ramverk med sju riktlinjer f¨or hur forskning inom IT b¨or bedrivas [28]. DSR ¨ar en variant av Design and Creation och handlar kortfattat om att skapa en relevant artefakt f¨or ett dom¨anproblem, noggrant utv¨ardera den med vedertagna metoder och presentera resultaten. Utvecklingen av artefakter kr¨aver utnyttjandet av tillg¨angliga resurser och vilka bidrag som genereras utifr˚an den forskning som gjorts, ska redovisas tydligt.
Till DSRs riktlinjer (se fig. 1) f¨orh˚aller vi oss p˚a f¨oljande vis 1) skapa en kontextmedve-ten musikapplikation, 2) utf¨ora en systematisk litteraturstudie och en enk¨atunders¨okning, 3) anv¨andartester och intervjuer, 4) bidra till den samlade forskningen inom ¨amnet KMMR, 5) anv¨anda vedertagna design- och arkitektursm¨onster f¨or mjukvarutveckling, 6) utveckla till Android och f¨or Spotifys API, 7) sammanst¨alla v˚art resultat i den h¨ar uppsatsen.
Syftet med att f¨olja DSR ¨ar att ha en ett ramverk att f¨orh˚alla sig till och undvika ad hoc l¨osningar.
Tabell 1: Hevners sju riktlinjer f¨or Design Science Research [28].
Design-Science Research Guidelines
Guildeline Description
Guideline 1: Design as an Arti-fact
Design-science research must produce a viable artifact in the form of a construct, a model, a method, or an instan-tiation.
Guideline 2: Problem Relevance The objective of design-science research is to develop technology-based solutions to important and relevant bu-siness problems.
Guideline 3: Design Evaluation The utility, quality, and efficacy of a design artifact must be rigorously demonstrated via well-executed evaluation methods.
Guideline 4: Research Contri-butions
Effective design-science research must provide clear and verifiable contributions in the areas of the design artifact, design foundations, and/or design methodologies.
Guideline 5: Research Rigor Design-science research relies upon the application of rigo-rous methods in both the construction and evaluation of the design artifact.
Guideline 6: Design as a Search Process
The search for an effective artifact requires utilizing avai-lable means to reach desired ends while satisfying laws in the problem environment.
Guideline 7: Communication of Research
Design-science research must be presented effectively both to technology-oriented as well as management-oriented au-diences.
2.3 Genomf¨orande
Arbetet utf¨ordes i tv˚a stycken iterationer. Innan vi p˚ab¨orjade utvecklingen av artefakten, unders¨okte vi vilka mobilsensorer och ramverk som fanns att tillg˚a samt hur dessa kunde kombineras f¨or att detektera de prim¨ara kontextuella faktorerna identitet, tid, plats och aktivitet. Parallellt med att vi b¨orjade implementera systemet v¨acktes fr˚agan om vilka faktorer potentiella anv¨andare anser ¨ar viktiga och vill bli rekommenderad musik utifr˚an. F¨or att besvara fr˚agan skapades enk¨aten beskriven i kap. 2.4.1.
Utvecklingen av systemet utgick fr˚an en iterativ process, d¨ar vi gjorde integrationstes-ter av mobilapplikation och server, ett antal g˚anger under utvecklingen. Efter varje test diskuterade vi eventuella bristf¨alligheter eller f¨or¨andringar som vi tyckte beh¨ovde g¨oras. N¨ar applikationen n˚adde ett acceptabelt stadie b¨orjade vi leta efter personer som ville delta i v˚ar studie. Vi riktade fr¨amst in oss p˚a andra studenter, som hade tillg˚ang till en android telefon och ett Spotify premiumkonto.
Inf¨or iteration ett tog vi fram tv˚a versioner. Den beskriven i kap 4.1 och en som ger slumpm¨assiga rekommendationer. Detta gav oss en baslinje att m¨ata v˚ar applikation mot. Applikationen testades av 9 personer under tre dagar och varannan person fick applika-tionen med slumpade rekommendationer. Testarna fick prova applikaapplika-tionen i tre dagar f¨or att sedan bli intervjuade om upplevelsen. N¨ar vi intervjuat varje person samlade vi alla transkriberingar, och analyserade dem. Resultaten tolkades och finns presenterade i kap. 5.2.3. Feedback ifr˚an intervjuerna anv¨andes ocks˚a f¨or att f¨orb¨attra prototypen inf¨or iteration tv˚a.
Iteration tv˚a inleddes med att bygga om applikationen utifr˚an den feedback vi f˚att. Vidare best¨amde vi ocks˚a att den slumpade versionen inte bidrog i den m˚an vi t¨ankte oss fr˚an b¨orjan, och best¨amde oss d¨arf¨or att enbart testa med den kontextmedvetna versionen. Efter att applikationen byggts om, genomf¨ordes anv¨andartester p˚a nytt. N¨ar anv¨andarna testat applikationen i tv˚a veckor, fick de svara p˚a en enk¨at om kontextuella faktorers inverkan p˚a rekommendationer av musik, och hur de upplevde applikationen.
2.4 Datainsamling
2.4.1 Enk¨at
Enk¨aten best˚ar av en ¨oppen och tio icke-¨oppna fr˚agor om lyssnarbeteende och ˚asikter om kontextmedvetna musikapplikationer (Se bilaga B). Enk¨aten skickades ut som en web-benk¨at med sn¨obollsurval [29] via sociala medier och urvalsramen sattes till obunden slumpm¨assig. F¨or att finna oklarheter i enk¨aten genomf¨ordes en pilot-studie innan den skickades ut.
Syftet med enk¨aten ¨ar att a) finna generella ˚asikter om kontextmedvetna applikationer, b) ta reda p˚a hur folk st¨aller sig till att bli rekommenderad musik utifr˚an kontexter som utr¨onas av mobiltelefonen, c) ta reda p˚a vilka kontexter som anses viktigast f¨or musikre-kommendation. Det kommer ocks˚a hj¨alpa oss besvara forskningsfr˚aga 1 och 1.1.
2.4.2 Intervju
Intervjuer genomf¨ordes semi-strukturerat och skedde efter att varje testperson f˚att prova applikationen (Se bilaga C f¨or fr˚agor). Vi hade nio f¨orutbest¨amda fr˚agor som vi utgick
ifr˚an i v˚ara intervjuer. Vi f¨orh¨oll oss till dessa fr˚agor som en grund f¨or intervjun.
Syftet med intervjuerna ¨ar att f˚a en djupare f¨orst˚aelse f¨or a) hur folk upplever kon-textmedvetna musikapplikationer, b) vad folk tycker om att kontextuella faktorer anv¨ands f¨or att rekommendera musik c) vad kontextmedvetna applikationer saknar. Det kommer ocks˚a hj¨alpa oss besvara forskningsfr˚aga 2.
2.4.3 Anv¨andarstudie
F¨or att testa applikationen genomf¨orde vi tv˚a anv¨andarstudier. I den f¨orsta iterationen skapades tv˚a versioner av applikationen: en kontextmedveten och en som slumpar l˚atar tagna fr˚an topplistor p˚a Spotify. Varannan deltagare f˚ar applikationen som slumpar l˚atar. Vi gjorde en applikation med slumpade rekommendationer f¨or att ha en baslinje att m¨ata oss mot. Vi bad anv¨andare att testa applikationen minst en g˚ang om dagen. Ut¨over detta ¨
ar de fria att testa hur de vill. Anv¨andartester sker under tre dagar. Vi valde tre dagar f¨or testning eftersom vi ans˚ag att det var den minsta tiden som beh¨ovs f¨or att anv¨andare ska uppleva effekten av kontextmedvetenhet. Efter det intervjuade vi anv¨andare och bad dem ange betyg och antal g˚anger de anv¨ant applikationen i en anonym enk¨at. Deltagarna bestod av studenter fr˚an ˚arskurs 1-3 fr˚an de olika programmeringsprogrammen p˚a Malm¨o Universitet.
Utifr˚an feedback fr˚an iteration ett, gjordes f¨or¨andringar och buggfixar i applikationen inf¨or iteration tv˚a. I iteration tv˚a testades enbart den kontextmedvetna applikationen, d˚a den slumpade versionen inte bidrog till att besvara v˚ara forskningsfr˚agor. Testerna ge-nomf¨ors p˚a liknande s¨att i iteration tv˚a, med skillnaden att applikationen testades i tv˚a veckor. Vi ins˚ag att tre dagar var otillr¨ackligt med tid utifr˚an feedback fr˚an testare, som upplevde att de inte hann testa applikationen ordentlig och vi var oroliga att insamlad data skulle vara underm˚alig p˚a grund av detta. Applikationen delas ut till testpersoner och sedan utv¨arderas den genom en enk¨at. Syftet med anv¨andartesterna ¨ar att utv¨ardera applikationen och samla data att analysera och st¨alla mot resultat fr˚an tidigare forsk-ning. Urvalet av testare i iteration tv˚a bestod till del av testare fr˚an iteration ett och slumpm¨assigt valda personer som hade Spotify och en Android-telefon.
2.5 Pilotstudie
En pilotstudie genomf¨ordes f¨or att s¨akerst¨alla att enk¨aten och applikationen var i tillr¨ackligt bra skick. Enk¨aten skickades till n¨ara v¨anner och familj, som fick svara p˚a fr˚agorna och ge feedback om deras upplevelse. Samma process gjordes med applikationen. Applikatio-nen testades i fem dagar f¨or att hitta eventuella buggar. Efter pilotstudien utv¨arderades enk¨aten, och skrevs om utifr˚an den feedback vi fick.
2.6 Metoddiskussion
Vi fann inga kommersiella mobilapplikationer som f¨oll inom ramen f¨or v˚art forskningsgap. F¨or att besvara v˚ara forskningsfr˚agor beh¨ovde vi skapa en egen artefakt att utv¨ardera. P˚a grund av detta var Design and Creation en l¨amplig metod [30]. Vi fann tv˚a olika varianter av Design and Creation: DSR och Design Science Research Methodology (DSRM). DSRM bygger p˚a samma grundid´e som beskrivs i DSR, men skiljer sig med sitt fokus p˚a Procedure som DSRM anser ¨ar en vital del i en metodik [31]. Vi valde att utg˚a ifr˚an DSR ¨over DSRM
eftersom forsknings¨amnet ¨ar relativt ungt och att det inte finns vedertagna procedurer f¨or att skapa den h¨ar typen av applikationer.
DSR ¨ar ett vedertaget ramverk f¨or att bedriva datavetenskaplig forskning, men d¨ar finns ¨aven nackdelar att diskutera. En fara med DSR ¨ar att l¨agga f¨or mycket fokus p˚a skapandet av artefakten och f¨or lite fokus p˚a sj¨alva studien och problemet som unders¨oks. [28]. Detta kan leda till en v¨aldesignad artefakt, som ¨ar oanv¨andbar i verklig milj¨o [28]. Det kan ¨aven vara sv˚art att generalisera resultaten vilket kan leda till att forskningsbi-draget blir bristf¨alligt [30]. Med detta i ˚atanke var vi noggranna med att g˚a igenom DSRs riktlinjer, och s¨akerst¨alla att vi inte missar att uppfylla n˚agon av dem. F¨or att m¨ojligg¨ora generalisering har vi f¨ors¨okt g¨ora applikation s˚a enkel som m¨ojligt. Vi har anv¨ant sensorer som ˚aterfinns i de flesta smartphones och grundl¨aggande API-funktioner f¨or att h¨amta l˚atar.
Vissa av de riktlinjer som n¨amns i DSR [28] ¨ar mindre relevanta f¨or v˚ar forskning. I DSR uppmuntras det att anpassa riktlinjerna s˚a de passar det nuvarande forsknings-projektet [28]. D¨arav kommer vi att anpassa vissa riktlinjer s˚a dem ¨ar mer passande v˚ar studie. Enligt beskrivningen i riktlinje tv˚a, ¨ar ett av m˚alen med DSR att utveckla teknik-baserade l¨osningar till viktiga och relevanta aff¨arsproblem [28]. V˚ar forskningsfr˚aga ber¨or inte ett st¨orre aff¨arsproblem, d¨arf¨or blir denna riktlinje bortprioriterad. Enligt beskriv-ningen i riktlinje sju, ¨ar ett av m˚alen med DSR att presentera forskningen till teknisk och administrativ publik [28]. V˚ar studie ¨ar ett examensarbete och vi riktar oss fr¨amst mot studenter och examinatorer.
2.6.1 Alternativa forskningsmetoder
Ett par m¨ojliga alternativ till DSR ¨ar exempelvis fallstudie och experiment. Fallstudier unders¨oker moderna fenomen i riktiga milj¨oer [32]. V˚ar tanke var att j¨amf¨ora tv˚a appli-kationer. V˚art problem var att det inte fanns mobilapplikationer som m¨otte v˚art identifi-erade forskningsgap. I v˚ar situation hade vi beh¨ovt utveckla tv˚a applikationer och sedan genomf¨ora fallstudien, vilket inte ¨ar rimligt inom tidsramen.
Ett annat angrepps¨att att besvara fr˚agorna om hur olika kontextuella faktor kan p˚averka musikrekommendationer ¨ar experiment. Experiment ¨ar l¨ampligt eftersom det un-ders¨oker orsak och verkan, i v˚art fall specifika kontexter och rekommendationerna de kan ge [30]. Vi vill unders¨oka hur kontextmedvetenhet och str¨ommande tj¨anster kan kombine-ras. Det ¨ar ett flertal variabler som ska samarbeta och p˚a grund av detta blir experiment ett s¨amre metodval. Kontext ¨ar ett hopkok av olika faktorer och det ¨ar d¨arf¨or sv˚art att utesluta variabler. Vi har ingen kontroll ¨over hur Spotify fungerar internt och kan inte utesluta variabler d¨ar heller. Ett annat tillv¨agag˚angss¨att ¨ar att genomf¨ora ett kvasiexpe-riment [30]. Detta passar oss illa eftersom vi vill unders¨oka hur applikationen anv¨ands n¨ar inga direktiv ges till anv¨andaren hur de ska g¨ora.
2.6.2 Enk¨atdiskussion
F¨or att besvara p˚a forskningsfr˚aga 1 och 1.1 beh¨over vi ta reda p˚a vad den generella mo-bilanv¨andaren tycker om att kontextuella faktorer inverkar p˚a musikval, och vilka faktorer som ¨ar viktigast. D¨arf¨or valde vi att samla in data via enk¨ater. Det ¨ar ett bra s¨att att samla in kvantitativ data eftersom det g˚ar att n˚a ut till en stor grupp [30]. Vi valde att distribuera enk¨aten som en webbenk¨at eftersom den kan spridas till en stor grupp och de
som svarat kan i sin tur sprida enk¨aten vidare. Vi inser att webbenk¨ater som publiceras i sociala medier ¨ar sv˚ara att kontrollera. Det kan bli problematiskt att utr¨ona hur pass bred urvalsgrupp man egentligen fick [29]. Syftet med v˚ar enk¨at var att hitta ett generellt lyssnarbeteende hos m¨anniskor och den generella ˚asikten om kontextuella faktorers inver-kan p˚a musikval. I detta fallet ¨ar faktorer som k¨on, etnicitet och ˚alder ointressant f¨or v˚ar studie.
2.6.3 Intervjudiskussion
F¨or att f˚a en ˚asikt om applikationen, gjordes intervjuer i samband med testningen. Denna data gav oss en djupare f¨orst˚aelse om vad anv¨andare tyckte om konceptet. V˚art m˚al var explorativt, och d¨arf¨or kan det vara sv˚art att utg˚a ifr˚an ett strikt tillv¨agag˚angss¨att. Vi valde semi-strukturerade intervjuer eftersom det gav oss m¨ojlighet att st¨alla f¨oljdfr˚agor ut¨over v˚ara f¨orutbest¨amda fr˚agor [33, 30]. Det gav oss ocks˚a en m¨ojlighet att ha en mer ¨
oppen dialog med intervjuobjekten [33]. Exempelvis gav vi anv¨andaren m¨ojlighet att tala fritt om fr˚agor, och avbr¨ot inte ifall de kom ifr˚an fr˚agan.
2.6.4 Datainsamlingsmetoder
Andra insamlingsmetoder f¨or data som rekommenderas vid Design and Creation-forskning ¨
ar observation och dokument [30]. Observation handlar om att studera vad folk g¨or, ist¨allet f¨or att lita p˚a vad de s¨ager att de g¨or [30]. V˚ar tanke var att l˚ata folk testa applikationen, och observera deras k¨anslor via ansiktsuttryck. Att en person uttrycker sig ¨oppet finns d¨ar ingen garanti f¨or [30]. Om personen inte ¨ar ¨oppen, komplicerar det processen att utr¨ona k¨anslor eftersom vi endast har ansiktsuttryck att g˚a p˚a. Ett annat problem ¨ar i de fall testgruppen skall utf¨ora fysiska aktiviteter s˚a kan det vara b˚ade obekv¨amt och opraktiskt att observera personen i fr˚aga. Dokument inneb¨ar att manualer, webforum, protokoll och f¨oretagsdokument analyseras. V˚ar studie ¨ar explorativ och inte kopplad till n˚agon organisation, d¨arfor kan vi inte samla in data fr˚an dokument.
2.7 Etiska ¨overv¨aganden
Det har alltid funnits etiska krav p˚a forskning i form av vad som ¨ar r¨att eller fel [34]. Etik inom forskning ¨ar ett vitt begrepp som omfattar m˚anga olika aspekter, varav en av dessa ¨
ar att skydda integriteten och informationen om de personer som innefattas i studien [34]. Vi str¨avar efter att vara etiskt korrekta och noggranna med att informera medverkande personer i studien om all information som applikationen anv¨ander, eftersom vi beh¨over tillg˚ang till anv¨andardata som kan vara k¨anslig exempelvis plats och tid. F¨or oss ¨ar det ¨
aven viktigt att t¨anka p˚a anv¨andarens konfidentialitet. P˚a grund av detta valde vi att h˚alla alla intervjuobjektens namn anonyma.
3
Design av artefakt
Utveckling av artefakten skedde i tv˚a iterationer. I detta kapitel beskrivs f¨orst den ¨overgripande designen, f¨oljt av valen gjorda i iteration ett och tv˚a under respektive rubrik.
3.1 Overgripande design¨
Spotify tillhandah˚aller tj¨anster som till˚ater utvecklare att h¨amta data om anv¨andare, och kontrollera uppspelning av musik. Dessa tj¨anster ing˚ar inte i samma API. F¨or att h¨amta data om anv¨andare och beg¨ara rekommendationer fr˚an Spotify beh¨over vi anv¨anda oss av Spotifys Web API. F¨or att sk¨ota uppspelning av musik p˚a mobiltelefonen beh¨over vi anv¨anda oss av Spotifys Android SDK. Eftersom de ¨ar separata tj¨anster v¨aljer vi att dela upp v˚ar applikation i tv˚a delar, mobilapplikation och backend.
Mobilapplikationen kommunicerar med b˚ade backend och Spotify. En access token
(tillg˚angspollet) h¨amtas fr˚an Spotify n¨ar applikationen och anv¨andaren autentiseras av Spotifys login-tj¨anst. Access token kr¨avs f¨or att utf¨ora operationer p˚a anv¨andarens kon-to vilket sker via artefaktens backend. Fr˚an den beg¨ars rekommendationer som i sin tur h¨amtar data fr˚an Spotify och behandlar den innan svar skickas tillbaka till klienten. Bac-kenden tar ¨aven emot och lagrar anv¨andarloggar f¨or utv¨ardering av applikationen.
Den prim¨ara anledningen till den h¨ar uppdelning ¨ar att det f¨orenklar utvecklingen av applikationen. Med en egen backendl¨osning ¨ar det l¨attare att hantera data som vi h¨amtar fr˚an Spotifys Web API. N¨ar vi beg¨ar rekommendationer kommer det en stor m¨angd metadata som vi inte har n˚agon anv¨andning f¨or. I v˚ar backend kan vi strukturera om data innan den skickas till mobiltelefon, f¨or att endast f˚a den v¨asentliga informationen. Vidare blir det mindre belastning f¨or mobilapplikationen om vi v¨aljer att dela upp applikationen i tv˚a delar.
P˚a grund av uppdelningen, ¨ar klient-server arkitekturen ett naturligt val. DSR f¨orlitar sig p˚a anv¨andadet av rigor¨osa metoder f¨or konstruktion och utv¨ardering av artefakten [28]. I dessa metoder ing˚ar arkitektur-m¨onster som klient-server. Klient-server passar v¨al n¨ar det finns distribuerade klienter som ska anv¨anda webbtj¨anster (smartphones, v˚ar backend, Spotify) [35]. ¨Aven tidigare forskning har anv¨ant klient-server arkitekturen [3, 12, 4, 13] med goda resultat.
Applikationens m˚al ¨ar att rekommendera musik utifr˚an de kontextuella faktorerna tid, plats och aktivitet (stilla, eller i r¨orelse), om det finns l˚atar kopplade till dessa, alternativt ge en slumpad rekommendation. Till en detekterad kontext kopplas en l˚at och sparas som en vektor i en databas. Flera kontext och l˚atar kan paras ihop. Vi v¨aljer denna representation eftersom det ¨ar den minsta m¨ojliga enligt Dey et. al. [5] och ¨ar genomf¨orbar inom ramen f¨or uppsatsen. Koppla kontext och l˚at f¨orekommer ¨aven p˚a liknande s¨att i tidigare forskning [13].
3.2 Iteration ett
I iteration ett valde vi att g¨ora applikationen aktivt kontextmedveten d¨ar anv¨andaren endast kan v¨alja paus, play eller n¨asta l˚at eftersom vi ¨ar intresserade av hur en helauto-matiskt l¨osning upplevs av anv¨andare. P˚a grund av detta v¨aljer vi att g¨ora UI-designen v¨aldigt simpel, i syfte att f¨orenkla f¨or anv¨andaren.
3.3 Iteration tv˚a
I iteration tv˚a, utifr˚an feedback fr˚an anv¨andarstudien efter iteration ett, ¨andrade vi de-signen att ge mer kontroll ¨over vilka kontextuella faktorer som inverkar p˚a musikrekom-mendationen. Anv¨andare kan sj¨alva v¨alja vilken kombination av tid, plats och aktivitet de vill bli rekommenderade utifr˚an. Vidare tillkom funktionalitet som till˚ater anv¨andare att best¨amma en specifik genre.
4
Implementation av artefakt
Artefakten implementeras med f¨oljande verktyg och komponenter. Applikationen utvecklas f¨or Android3 och skrivs i Java4 vilket ¨ar det dominerande spr˚aket f¨or Android. F¨or att
lagra data i applikationen anv¨ands SQLite5 eftersom Android ger bra st¨od f¨or SQLite. Google Activity Recognition6 (GAR) anv¨ands f¨or att detektera anv¨andares aktivitet. Vi anv¨ander det eftersom det enkelt integreras i applikationen och vid ett fast intervall samlar tillg¨anglig sensordata i mobilen och detekterar en av f¨oljande kontexter in vehicle, on bicyle, on foot, walking, running, still, unknown. Backend skrivs i Golang7. Golang ¨ar ett enkelt spr˚ak som l¨ampar sig f¨or concurrency (samtidighet) och webbtj¨anster, vilket ¨ar tv˚a faktorer som v˚ar applikation arbetar med. Vi har ¨aven tidigare erfarenheter av spr˚aket vilket g¨or det l¨ampligt f¨or oss att v¨alja. Heroku8 anv¨ands f¨or att husera v˚ar backend. Valet av Heroku gjordes utifr˚an att det ¨ar en enkel hostingplattform att arbeta med, och de erbjuder en gratisversion som vi kan utnyttja.
Fr˚an Spotify9 anv¨ands flera API:er. Spotify Web API(ett REST API) anv¨ands f¨or att generera l˚atlistor baserat p˚a fem l˚atar s˚a kallade seeds. Det anv¨ands ¨aven f¨or att h¨amta anv¨andares senaste spelade l˚atar att f¨or att ta fram seeds om inga l˚atar finns sparade i applikationen. till applikationen anv¨ands Android SDK vilket f¨orenklat m¨ojligg¨or f¨or utvecklare att spela musik fr˚an Spotify p˚a en mobiltelefon. Detta SDK kr¨aver att utvecklaren sj¨alv hanterar alla situationer d¨ar appar kan kolidera exempelvis n¨ar det ringer b¨or musiken sluta spela. Anv¨andandet av detta SDK medf¨orde flera buggar och problem f¨or v˚ara testare och till iteration tv˚a gick vi ¨over till att anv¨anda Spotify App Remote. Detta SDK nyttjar den befintliga Spotify appen f¨or att spela musik och interagerar v¨al med ¨ovriga appar p˚a mobilen.
4.1 Mobilapplikation
Mobilapplikationen implementerar en lagerarkitektur. Den har komponenter f¨or att detek-tera anv¨andarens kontext, h¨amta rekommendationer, spela musik, lagra gillade l˚atar och interagera med anv¨andaren. Applikationen utvecklades i tv˚a iterationer. Under iteration ett skapade vi en prototyp som anv¨andas under f¨orsta testomg˚angen. Utifr˚an feedback
3https://www.android.com/ 4 https://www.java.com/en/ 5https://www.sqlite.org/index.html 6 https://developers.google.com/android/reference/com/google/android/gms/location/ActivityRecognition 7 https://golang.org/ 8https://devcenter.heroku.com/ 9 https://beta.developer.spotify.com/
fr˚an testerna, byggdes applikationen om, och buggar fixades. N¨ar applikationen n˚adde en acceptabel niv˚a, p˚ab¨orjades testomg˚ang tv˚a.
4.1.1 Iteration ett
Figur 1: Applikationsarkitektur.
Hur kontextuella faktorer representeras Tid, plats och aktivitet v¨aljs f¨or att representera kontext eftersom det ¨ar den minsta m¨ojliga enligt Dey et. al. [5]. F¨or att minska antalet m¨ojliga kom-binationer av faktorer, begr¨ansas de varje faktor till en fast m¨angd. Tid delas in i fem delar: p˚a dyg-net, morgon, f¨ormiddag, eftermiddag, kv¨all och natt. Plats representeras av GPS koordinater. Aktivitet kan vara n˚agon av f¨oljande: in vehicle, on bicyle, on foot, walking, running, still, unknown.
Anv¨andargr¨anssnitt
Figur 2: Anv¨andargr¨ansnitt huvudvy.
Anv¨andargr¨anssnittet best˚ar av en uppstartsvy och en huvudvy. F¨orsta g˚angen applikationen startas vi-sas uppstartsvyn och beg¨ar tillst˚and att anv¨anda
GPS-funktionen och anv¨andarens Spotify konto.
Resterande g˚anger applikationen anv¨ands presen-teras bara huvudvyn. I den presenpresen-teras vilken l˚at och artist som spelas. Det finns tv˚a knappar, en f¨or att pausa och ˚ateruppta uppspelning och en f¨or att byta till n¨asta l˚at i k¨on. N¨ar applikationen startar p˚ab¨orjas uppspelning av l˚atar. Vi valde att begr¨ansa anv¨andarens kontroll ¨over applikationen eftersom vi vill att kontextmedvetenheten ska driva applikatio-nen.
Algoritm f¨or att v¨alja l˚atar
F¨or att v¨alja l˚atar identifieras f¨orst de kontextuel-la faktorernas nuvarande v¨arden. F¨or tid anv¨ands heltimmen f¨or att avg¨ora vilken del av dygnet anv¨andaren ¨ar i. Anv¨andarens aktivitet uppdateras regelbundet av GAR med typ och hur s¨aker detek-tionen var p˚a en skala fr˚an 0 till 100. Det senaste v¨ardet ¨over 85 anv¨ands, vilket Google rekommen-derar. F¨or plats ber¨aknas en kvadrat om 111m om anv¨andaren ¨ar i r¨orelse och 11m om hen ¨ar stilla.
F¨or en person i r¨orelse anser vi att 111m ¨ar tillr¨ackligt f¨or att representera olika geogra-fiska omr˚aden. ¨Okar vi till 1km eller mer anser vi att det blir f¨or stort. D¨arefter g¨ors en s¨okning i databasen. Om fler ¨an fem l˚atar finnes skickas de till backend f¨or att st˚a till
grund f¨or rekommendationen. ¨Ar det f¨arre en fem skickas inga l˚atar till backend och en rekommendation skapas ist¨allet fr˚an anv¨andarens recently played (se 4.2 f¨or hur backend ¨
ar uppbyggd). Vi valde fem l˚atar som gr¨ans eftersom vi vill anv¨anda alla m¨ojliga seeds n¨ar en rekommendation h¨amtas fr˚an Spotify. Vi valde att anv¨anda recently played eftersom det ¨ar rimligt att anta att l˚atar anv¨andaren nyligen har lyssnat p˚a ¨ar n˚agot de gillar. Hur l˚atar sparas
Vi anser att en person kan antas gillat en l˚at om den spelats fr˚an b¨orjan till slut. N¨ar en l˚at spelats till slut sparas den i applikationens databas med data om tid p˚a dygnet, GPS-koordinater och anv¨andarens aktivitet.
Applikation med slumpade rekommendationer
Till iteration ett skapades en applikation med slumpade rekommendationer f¨or att anv¨andas som baslinje att m¨ata effektiviteten av v˚ar kontextmedvetna applikation mot. Den ser ut och beter sig f¨or anv¨andaren precis som v˚ar kontextmedvetna applikation. Skillnaden ¨ar att kontext inte anv¨ands f¨or att rekommendera l˚atar. Ist¨allet har 10 topplistor fr˚an Spoti-fy sammanst¨allts. N¨ar rekommendationer ska h¨amtas till applikationen v¨aljs de fr˚an den slumpvis fr˚an den sammanst¨allda listan.
4.1.2 Iteration tv˚a
I iteration tv˚a gjordes det f¨or¨andringar i applikationen baserat p˚a feedback fr˚an anv¨andartester, b˚ade i UI-design och funktionalitet. Vi bytte SDK till Spotify App Remote10eftersom det anv¨ander Spotify-applikationen i mobilen och ¨ar d¨armed stabilare och interagerar b¨attre med andra funktioner i mobiltelefonen exempelvis pausa Spotify n¨ar det ringer. Detta SDK har ett annat API och det ¨ar inte m¨ojligt att bli uppdaterad n¨ar en l˚at ¨ar f¨ardigspelad. Eller programatiskt t¨omma den nuvarande k¨on. D¨arf¨or valde vi att h¨amta fem l˚atar, spa-ra dessa med information om anv¨andarens kontext och sedan k¨oa alla samtidigt. Vi gav anv¨andare m¨ojligheten att v¨alja en genre av tv˚a anledningar. Dels f¨or att b¨orja rekom-mendera r¨attmusik i en ny kontext och p˚a s˚a vis hantera cold start -problemet. Dels f¨or att inf¨ora ny musik till en k¨and kontext.
Anv¨andargr¨anssnitt
F¨orsta g˚angen applikationen startas beh¨over anv¨andaren godk¨anda att den kopplas ihop med anv¨andarens Spotifykonto. D¨arefter landar anv¨andaren i hemvyn d¨ar hen kan se sin tid, plats, aktivitet och vald genre. V¨aljer anv¨andaren att bli rekommenderad musik f˚ar de en ny vy med tv˚a val, bli rekommenderad utifr˚an vald genre eller utifr˚an l˚atar som lyssnats p˚a tidigare i liknande kontext som anv¨andarens nuvarande. Rekommendationer kan hanteras i historyfliken d¨ar spellistor eller individuella l˚atar i listor kan spelas upp eller tas bort. Det finns en vy med valbara genrer fr˚an Spotify. Slutligen finns det en vy med inst¨allningar d¨ar anv¨andaren kan v¨alja vilka kontextuella faktorer som ska ing˚a n¨ar det letas efter tidigare lyssnade l˚atar att rekommendera utifr˚an.
10
Figur 3: Anv¨andargr¨ansnitt iteration tv˚a
Hur kontextuella faktorer representeras
Likt f¨orsta iterationen representeras kontext av tid, plats och aktivitet. Tid representeras av dygnets 24 timmar. Plats representeras fortfarande av GPS koordinater. Aktivitet kan vara n˚agon av f¨oljande in vehicle, on bicyle, on foot, walking, running eller still.
Algoritm f¨or att v¨alja l˚atar
F¨or att v¨alja l˚atar identifieras f¨orst de kontextuella faktorernas nuvarande v¨arden. F¨or tid ber¨aknas ett omf˚ang fr˚an den nuvarande heltimmen +-1 timme. Anv¨andarens aktivitet uppdateras regelbundet av GAR med typ och hur s¨aker detektionen var p˚a en skala fr˚an 0 till 100. Det senaste v¨ardet ¨over 85 anv¨ands, vilket Google rekommenderar. F¨or plats ber¨aknas en kvadrat om 111m. F¨or en person i r¨orelse anser vi att 111m ¨ar tillr¨ackligt f¨or att representera olika geografiska omr˚aden. ¨Okar vi till 1km eller mer anser vi att det blir f¨or stort. D¨arefter g¨ors en s¨okning i databasen. Om fler ¨an fem l˚atar finnes beg¨ars en rekommendation precis som i iteration ett annars f˚ar anv¨andaren bara v¨alja att bli rekom-menderad utifr˚an genre. De kontextuella faktorer anv¨andaren inte vill bli rekommenderade ifr˚an bortses n¨ar en s¨okning g¨ors. Exempelvis har anv¨andaren valt bort faktorerna akti-vitet och plats. Klockan ¨ar 15 p˚a dagen, och s˚alunda kan alla sparade l˚atar mellan 14-16 anv¨andas till rekommendationen.
Hur l˚atar sparas
Varje g˚ang en rekommendation h¨amtas sparas l˚atarna som en spellista. Till denna spellista sparas ¨aven information om anv¨andarens nuvarande kontext.
4.2 Backend
Iteration ett
V˚ar backend ¨ar en tj¨anst f¨or att rekommendera musik och spara anv¨andardata. Servern tar emot requests fr˚an mobilapplikationen f¨or att h¨amta rekommendationer fr˚an Spotify (se figur 4). Detta sker genom att anv¨andaren skickar med en access token som identifierar vem anv¨andaren ¨ar, och till˚ater oss att anv¨anda Spotifys API.
Beroende p˚a om mobilapplikationen skickar med l˚atar att anv¨anda i rekommendatio-nen eller ej, kan en beg¨aran fr˚an servern till Spotify ske p˚a tv˚a olika s¨att. 1) de 50 senaste spelade l˚atarna fr˚an anv¨andarens historik h¨amtas och anv¨ands som data f¨or rekommenda-tionen. 2) l˚atar som anv¨andaren har gillat skickas med, analyseras och resultatet anv¨ands f¨or att generera rekommendationen.
Spotify till˚ater endast fem parametrar som seed n¨ar en beg¨aran f¨or rekommendationer g¨ors. Parametrar som kan ing˚a i seeden kan vara l˚atnamn, artistnamn eller genre. N¨ar en beg¨aran fr˚an anv¨andare skickas till servern, ¨ar d¨ar alltid fem eller fler parametrar. I servern reduceras antalet l˚atar och artister till fem, genom att ta ut de mest f¨orekommande l˚atarna eller artisterna i requesten. Detta sker genom att ta reda p˚a vilka l˚atar och artister som ¨ar mest f¨orekommande i requesten. Efter denna process skickas en request till Spotify att h¨amta rekommendationer. Om access token ¨ar giltig, och requesten ¨ar korrekt, skickar Spotify ett svar med l˚atar och metadata. Metadatan filtreras bort, och servern skickar endast l˚atarnas uri:er, artister och titel till mobilapplikationen f¨or uppspelning.
Iteration tv˚a
I iteration tv˚a m¨ojliggjordes det rekommendationer baserat p˚a enbart genre. Vidare togs den slumpade versionen bort fr˚an applikation under iteration tv˚a, vilket reflekterades i backenden d˚a routen f¨or slumpade rekommendationer togs bort.
5
Resultat
F¨oljande avsnitt presenterar resultaten som samlats in fr˚an enk¨ater och anv¨andarstudier. Applikationen testades i tv˚a iterationer, och informationen fr˚an dem kommer att delas upp i tv˚a avsnitt. Data fr˚an enk¨aten ¨ar generell, och tillh¨or inte n˚agon av iterationerna. P˚a grund av detta kommer denna data att vara genomg˚aende f¨or hela studien.
5.1 Enk¨at
Enk¨aten besvarades av 55 personer under en sjudagars-period. Svarsalternativen g˚ar fr˚an 1 till 4, d¨ar 1 inneb¨ar att de inte inst¨ammer alls, och 4 att de inst¨ammer helt. Nedan presenteras sammanst¨allningen ifr˚an enk¨aten.
Tabell 2: Jag f¨oredrar att lyssna p˚a viss musik under en viss tid p˚a dygnet.
Alternativ Antal
1 16
2 11
3 19
4 9
Tabell 3: Vilka tider p˚a dygnet lyssnar du p˚a musik? Alternativ Antal Morgon 23% F¨ormiddag 20% Eftermiddag 25% Kv¨all 25% Natt 7%
Tabellerna ovan visar svaren p˚a fr˚agor om lyssnarbeteende i relation till tid p˚a dygnet. I fr˚agan om folk lyssnar p˚a viss musik under en viss tid p˚a dygnet ¨ar det 28 av 55 som svarat en 3:a eller 4:a. 16 utav 55 lyssnar inte p˚a viss musik under en specifik tid p˚a dygnet. Vilka tider p˚a dygnet som folk f¨oredrar att lyssna p˚a musik ¨ar j¨amnt f¨ordelat ¨over grupperna, med undantaget f¨or natt, vars grupp endast best˚ar utav 7%.
Tabell 4: Var jag befinner mig har be-tydelse f¨or vilken musik jag lyssnar p˚a.
Alternativ Antal
1 7
2 10
3 22
4 16
Tabell 5: Jag lyssnar ˚aterkommande p˚a samma musik p˚a samma plats.
Alternativ Antal
1 13
2 14
3 21
Tabellerna ovan visar svaren p˚a fr˚agor kring lyssnarbeteende i relation till var folk befinner sig. 38 utav 55 respondenter tycker att var de befinner sig har betydelse f¨or vilken musik de lyssnar p˚a. 8 personer tycker inte att plats har n˚agon betydelse.
F¨or fr˚agan om folk ˚aterkommande lyssnar p˚a samma musik p˚a samma plats, ¨ar re-sultatet annorlunda. 27 utav 55 svarade 1:a eller 2:a. 21 svarade 3:a, vilket var det mest f¨orekommande svaret.
Tabell 6: Jag f¨oredrar att lyssna p˚a musik n¨ar jag utf¨or en aktivitet.
Alternativ Antal
1 0
2 6
3 17
4 32
Tabell 7: Jag lyssnar ˚aterkommande p˚a samma musik n¨ar jag utf¨or en akti-vitet. Alternativ Antal 1 4 2 16 3 24 4 11
Tabellerna ovan visar svaren p˚a fr˚agor kring lyssnarbeteende i relation till aktiviteter. 32 utav 55 svarade en 4:a p˚a fr˚agan om jag f¨oredrar att lyssna p˚a musik n¨ar jag utf¨or en aktivitet. Ingen svarade en 1:a.
I fr˚agan om folk ˚aterkommande lyssnar p˚a samma musik n¨ar de utf¨or en specifik aktivitet, svarade 24 personer en 3:a.
Tabell 8: Jag vill bli rekommenderad musik. Alternativ Antal 1 4 2 7 3 24 4 20
Tabell 9: Jag vill bli rekommenderad musik utifr˚an f¨oljande kontexter.
Alternativ Antal
Tid 18%
Plats 18%
Aktivitet 39%
Inget av dem 24%
Tabellerna ovan visar svaren p˚a fr˚agor om respondenterna vill bli rekommenderad musik, och i vilka kontexter. 24 utav 55 personer svarade en 3:a, och 20 svarade en 4:a.
39% av respondenterna vill bli rekommenderade musik utifr˚an aktivitet. 18% kan t¨anka sig bli rekommenderade utifr˚an tid och plats. 24% vill inte bli rekommenderade utifr˚an tid, plats eller aktivitet.
Tabell 10: Jag har en god uppfattning om vad en kontextmedveten musikap-plikation ¨ar. Alternativ Antal 1 18 2 15 3 12 4 10
Tabell 11: Jag kan t¨anka mig anv¨anda en kontextmedveten musikapplikation. Alternativ Antal 1 9 2 10 3 24 4 12
Tabellerna ovan visar svaren p˚a fr˚agor kring respondenternas uppfattning om kontext-medvetna musikapplikationer. 18 utav 55 svarade en 1:a p˚a fr˚agan om de har en god uppfattning om vad en kontextmedveten musikapplikation ¨ar. 36 utav 55 svarade en 3:a eller 4:a i fr˚agan om de kunde t¨anka sig anv¨anda en kontextmedveten musikapplikation.
I samband med fig. 11 fick anv¨andaren motivera sitt svar, vilket 28 av respondenterna gjorde. Tv˚a typiska svar ¨ar: ”Vet inte vad det ¨ar” och ”L˚ater intressant och jag provar g¨arna n˚agot nytt!”.
5.2 Iteration ett
5.2.1 Anv¨andarstudie
Nio personer deltog i v˚ar anv¨andarstudie. Av dem var det ˚atta stycken som deltog i intervju och sex stycken som svarade p˚a enk¨aten. Sammanst¨allning av intervju presenteras i n¨asta kapitel. Svar p˚a enk¨aten presenteras i tabellen nedan.
Tabell 12: Enk¨atsvar f¨or kontextmed-vetna rekommendationer.
Kontextmedvetna
Antal svar 3
G˚anger Anv¨and Betyg
3 2
5 1
8 6
Summa 16 9
Medelv¨arde 5,3 3
Tabell 13: Enk¨atsvar f¨or slumpade re-kommendationer.
Slumpade
Antal svar 3
G˚anger Anv¨and Betyg
9 4 8 4 5 3 Summa 22 11 Medelv¨arde 7,3 3,6 5.2.2 Anv¨andardata
Nedan tabeller visar summering av data fr˚an anv¨andarloggar som samlats in under test-ningen. Antalet spelade l˚atar ¨ar l˚atar som p˚ab¨orjat uppspelning, oberoende hur l¨ange som anv¨andaren lyssnade p˚a l˚aten. I den slumpade versionen lyssnade testare i snitt 52 minuter per session, och 16 l˚atar spelades per session. I den kontextmedvetna versionen lyssnade testare i snitt 48 minuter per session, och 8 l˚atar spelades per session. P˚a grund av problematik med applikationen, ¨ar relationen skippade l˚atar och spelade l˚atar inkorrekt.
Tabell 14: Anv¨andardata fr˚an den slumpade versionen.
Slumpade versionen
# spelade l˚atar 212
# skippade l˚atar 265
# sessioner > 2min 13
Total sessionsl¨angd 677min
Tabell 15: Anv¨andardata fr˚an den kontextmedvetna versionen.
Kontextmedvetna versionen
# spelade l˚atar 72
# skippade l˚atar 149
# sessioner > 2min 9
5.2.3 Intervju ˚
Atta personer deltog i enskilda intervjuer efter att ha testat applikationen i tre dagar. Tre personer fick slumpade rekommendationer (SR). Fem fick rekommendationer baserat p˚a kontext (KR).
P˚a fr˚agan ”Hur upplevde du applikationen?” framkom det att en del testare hade pro-blem med applikationen. Den kraschade mellan varje l˚atbyte f¨or en person. Den startade h¨alften av g˚angerna f¨or en annan person. Hen var tvungen att starta om applikationen vissa g˚anger f¨or att den skulle fungera. Tre personer hade problem med att applikationen b¨orjade spela musik av sig sj¨alv i bakgrunden. Om anv¨andargr¨anssnittet kommentera-de samtliga anv¨andare att det var enkelt men p˚averkade inte upplevelsen. Sammanlagt upplevdes applikationen positivt av tre utav fem med KR och tv˚a utav tre med SR.
N¨asta fr˚aga var ”I vilka situationer anv¨ande du applikationen?” och vi fick veta att den fr¨amst anv¨andes n¨ar personer var i r¨orelse. Aktiviteter som n¨amndes var g˚a, cykla, ˚aka buss och sitta still. Platser var hemma, skola och gymmet. Typiskt anv¨andningsscenario var att ta sig till och fr˚an skolan eller sitta stilla i hemmet.
P˚a fr˚agan ”Hur upplevde du rekommendationerna fr˚an applikationen?” fick vi reda p˚a att de upplevdes positivt av tre utav fem med KR. F¨or SR upplevde en person det nega-tivt och tv˚a upplevde rekommendationerna blandade. ˚Aterkommande oavsett om testare anv¨ant SR, eller KR upplevde de att rekommendationerna passade b¨attre n¨ar de var i r¨orelse mot om de satt stilla. Till anv¨andare som anv¨ant applikationen mer ¨an en g˚ang fr˚agade vi ”Upplevde du n˚agon skillnad mellan situationerna?”. Tre personer med KR och en med SR upplevde att de fick lugnare musik n¨ar de var stilla. En med KR och en med SR upplevde att applikationen anpassade sig efter om de var i r¨orelse, tv˚a med KR och en med SR upplevde att den inte anpassade sig. Testperson 1 svarade ”F¨or de mesta. Jag upplevde det som att t.ex. imorse innan jag gick gav mig ut och cyklade, s˚a fick jag lite lugnare l˚atar s˚ad¨ar, det var sk¨ont mjuk start p˚a dagen. N¨ar jag stod och diska n˚an g˚ang s˚a var det s˚ah¨ar det var d˚a lite mer party-pop musik liksom”.
p˚a fr˚agan ”Saknade du n˚agot i applikationen?” svarade alla f¨orutom en med SR att de saknade funktioner. Tre ¨onskade m¨ojlighet att v¨alja kategori eller genre n¨ar man startar applikationen. Tv˚a personer ¨onskade alternativ f¨or att gilla eller spara l˚atar i en lista att g˚a tillbaka till och lyssna p˚a senare. En person tyckte att d¨ar skulle finnas historik ¨over vilka l˚atar som spelats upp, och m¨ojligheten att ta bort de l˚atar som inte passar in f¨or framtida rekommendationer. Testperson 1 sa i sin intervju att: ”Metrics som visar vad rekommendationen baseras p˚a vore en bra funktion.”. Testperson 2 tyckte att det var f¨or lite kontextmedvetenhet och n¨amnde att: ”Jag skulle v¨al s¨aga att det var lite f¨or lite kontextmedvetenhet [...], jag k¨anner att om man nu sitter ner bara s˚a m¨arker den ju det men den vet ju inte vad jag g¨or och jag vill lyssna p˚a annan musik n¨ar jag skriver och programmerar eller bara tar det lugnt.”
I fr˚agan ”Hur st¨aller du dig till att data samlas om dig?” fick vi reda p˚a att samtliga personer till¨at datainsamling om det tydligt framgick var data sparas och hur den anv¨ands. Testperson 3 sa f¨oljande: ”S˚a l¨ange den datan f¨orvaras s¨akert s˚a ¨ar det inga problem.”. Senare i intervjun n¨amner testperson 3 att: ”om den skulle beg¨ara min kamera d˚a skulle det vara direkt n¨a den h¨ar appen skulle jag aldrig anv¨anda och ta bort, men om det skulle st˚att i appen d˚a den anv¨ander din plats f¨or att g¨ora rekommendationer f¨or musik skulle jag anv¨ant den.”
Vi fr˚agade ”Skulle du vilja forts¨atta anv¨anda applikationen eller en liknande applikatio-ner?”. Sju personer kunde t¨anka sig anv¨ande v˚ar applikation eller en liknande i framtiden. Samtliga som kunde t¨anka sig anv¨anda applikationen tyckte det var sk¨ont att slippa v¨alja l˚atar, och bli rekommenderad ny musik. N¨ar vi intervjuade testperson 1 n¨amnde hen att: ”om m¨ojligheten att v¨alja genre eller kategori fanns hade jag kunnat t¨anka mig anv¨anda applikationen i framtiden”. Testperson 2, som inte kunde t¨anka sig anv¨anda applikation i framtiden, sa f¨oljande: ”Jag vill g¨arna ha kontrollen ¨over vilken musik jag lyssnar p˚a.”. En testare sa f¨oljande: ”Det ¨ar r¨att s˚a roligt att ha folk som f¨oresl˚ar musik ˚at en. Det ¨ar v¨al l¨att att man trasar s¨onder sina egna spellistor, man spelar dem om och om igen, s˚a att ha n˚agon som f¨oresl˚ar musik ˚at en ¨ar v¨aldigt kul koncept.”
Sammanfattningsvis st¨allde sig ˚atta personer positivt till applikationen och sju av dem kunde t¨anka sig anv¨anda den i framtiden. Sju personer tyckte att det var bekv¨amt att bli rekommenderad musik och det var ett bra s¨att att hitta ny musik. En person utav de tv˚a som inte kunde t¨anka sig anv¨anda applikationen, ville ha full kontroll ¨over vilken musik som spelades. Den andra personen kunde t¨anka sig anv¨anda applikationen om d¨ar fanns m¨ojlighet att v¨alja genre eller kategori av l˚atar som rekommenderades.
5.3 Iteration tv˚a
Nedan presenteras resultatet fr˚an anv¨andarstudien som utf¨ordes under iteration tv˚a. I ite-ration tv˚a fick anv¨andare testa applikationen under tv˚a veckors tid. Efter˚at fick anv¨andarna svara p˚a enk¨aten som finns beskriven i Bilaga B. Skalan i tabellerna utg˚ar ifr˚an att en 1 ¨
ar minst viktig, och 5 ¨ar mest viktig.
Tabell 16: Rangordning av hur relevanta olika kontextuella faktorer ¨ar f¨or anv¨andare.
Tid Betyg Svar 1 1 2 1 3 1 4 1 5 1 Plats Betyg Svar 1 1 2 2 3 0 4 2 5 0 Aktivitet Betyg Svar 1 0 2 0 3 0 4 4 5 1
Anv¨andarna fick rangordna hur relevant varje kontextuell faktor ¨ar f¨or dem, p˚a en skala fr˚an 1 till 5. Svarsalternativen f¨or tid ¨ar j¨amnt f¨ordelade och det g˚ar ej att peka ut ett typv¨arde. F¨or plats kan vi se en j¨amnare f¨ordelning mellan relevant och icke relevant. Vi kan se att aktivitet ¨ar relevant f¨or samtliga anv¨andare med 4:a som typv¨arde.
Figur 5: Vilken grad anv¨andare tycker att kombinationer av kontextuella faktorer h¨or ihop.
Vi l¨at anv¨andarna rangordna till vilken grad de kombinationer som syns i tabellen h¨or ihop. Utifr˚an svaren ser det ut som kombinationerna: plats och aktivitet, och tid och aktivitet h¨or ihop.
Figur 6: Kombinationer av kontextuella faktorer anv¨andare pr¨ovade.
I diagrammet ovan ser vi vilka olika kombinationer av faktorer som anv¨andarna har testat och vad de tyckte om just den kombinationen. Vi kan se att aktivitet ¨ar en v¨aldigt popul¨ar faktor i samtliga fall, f¨orutom ett d¨ar aktivitet och plats fick en 1:a. Vidare var det tre personer som testade plats och gav det en 3:a.
Figur 7: Om kontextuella faktorer ska p˚averka anv¨andarens musikrekommendation
Enligt diagrammet ovan ser vi att 60% av testarna svarade ja p˚a fr˚agan om de vill att kontextuella faktorer ska p˚averka p˚a deras musikrekommendationer.
Tabell 17: Hur upplevde du att bli rekommenderad musik utifr˚an de kontextuella faktorerna tid, plats och aktivitet?
Betyg Svar 1 0 2 0 3 2 4 2 5 1
I tabellen ovan ser vi resultatet p˚a fr˚agan om hur testarna upplevde att bli rekommenderad musik utifr˚an faktorerna tid, plats och aktivitet. Utifr˚an svaren kan vi se att personerna st¨aller sig positivt till att bli rekommenderad utifr˚an dessa faktorer.
6
Analys
I detta kapitel analyserar vi studiens resultat. Resultatet fr˚an respektive iteration presen-teras separat med liknande struktur som tidigare kapitel.
6.1 Enk¨at
I enk¨aten besvarades hur viktigt faktorerna tid, plats och aktivitet ¨ar vid valet av musik f¨or anv¨andaren. I kommande avsnitt g¨ors en ¨overgripande analys av varje faktor och deras samband. Svarsalternativen g˚ar fr˚an 1 till 4, d¨ar 1 inneb¨ar att de inte inst¨ammer alls, och 4 att de inst¨ammer helt.
Tabell 18: Tid
Jag f¨oredrar att lyssna p˚a viss musik vid en specifik tid p˚a dygnet.
Dygnsindelning 1 2 3 4 Morgon 10 8 15 5 F¨ormiddag 10 9 8 6 Eftermiddag 11 10 13 7 Kv¨all 14 10 13 5 Natt 2 4 4 2
Utifr˚an respondenternas svar kan vi inte se att de finns n˚agon tidsperiod som musik lyssnas p˚a mer ¨an andra oavsett om respondenterna f¨oredrar att lyssna p˚a en specifik tid p˚a dygnet.
Tabell 19: Plats
Jag lyssnar ˚aterkommande p˚a samma musik p˚a samma plats. Var jag befinner mig har betydelse
f¨or vilken musik jag lyssnar p˚a. 1 2 3 4
1 5 1 1 0
2 5 5 0 0
3 2 5 14 1
4 1 3 6 6
Fr˚an tabellen ovan kan vi se att det finns en korrelation mellan platsen som en person befinner sig p˚a, och om de ˚aterkommande lyssnar p˚a samma musik p˚a den platsen. Detta kan tyda p˚a att spara anv¨andares plats och l˚atar som lyssnats p˚a den platsen kan vara f¨ordelaktigt f¨or en KMMR.
Tabell 20: Aktivitet
Jag lyssnar ˚aterkommande p˚a samma musik n¨ar jag utf¨or en aktivitet. Jag f¨oredrar att lyssna p˚a musik n¨ar
jag utf¨or en aktivitet. 1 2 3 4
1 0 0 0 0
2 1 4 1 0
3 2 7 8 0
4 1 5 15 11
Fr˚an tabellen ovan kan vi se att det finns en korrelation mellan aktivitet och om perso-nen ˚aterkommande lyssnar p˚a samma musik p˚a aktivitet. Detta kan tyda p˚a att spara anv¨andares aktivitet och l˚atar som lyssnats p˚a under den aktiviteten kan vara f¨ordelaktigt f¨or en KMMR.
Tabell 21: Plats & Aktivitet
Jag f¨oredrar att lyssna p˚a musik n¨ar jag utf¨or en aktivitet. Var jag befinner mig har betydelse
f¨or vilken musik jag lyssnar p˚a.
1 2 3 4
1 0 2 3 2
2 0 0 6 4
3 0 4 3 15
4 0 0 5 11
St¨aller vi svaren p˚a fr˚agorna om plats och aktivitets betydelse mot varandra kan vi se att majoriteten av respondenterna som anser att aktivitet ¨ar viktigt tycker ¨aven att plats ¨
ar viktigt. Med tanke p˚a att fr˚agorna ¨ar st¨allda oberoende av varandra, b¨or resultatet analyseras med det i ˚atanke.
Tabell 22: Kombinationer av val och hur pass de vill bli rekommenderade
Vill bli rekommenderad
Val 1 2 3 4 Total
Inget av dem 4 4 6 6 20
Tid 0 0 0 0 0
Plats 0 0 0 1 1
Aktivitet 0 1 11 2 14
Tid & Plats 0 0 0 2 2
Tid & Aktivitet 0 1 2 3 6
Plats & Aktivitet 0 1 3 1 5
Tid, Plats & Aktivitet 0 0 2 5 7
Tabellen ovan visar om respondenterna vill bli rekommenderad musik, och utifr˚an vilka faktorer. I resultaten kan vi se att aktivitet som ensam faktor var den mest popul¨ara. Utav de 35 som vill ha n˚agon form av kontextuell faktor, ¨ar det bara 3 som inte inkluderat aktivitet i deras svar. Vidare kan vi se att 20 stycken inte vill bli rekommenderad musik utifr˚an n˚agon kontextuell faktor. Bland dem ¨ar det j¨amn f¨ordelning mellan de som vill
och inte vill bli rekommenderad musik. Detta kan tyda p˚a att bara f¨or att man vill bli rekommenderad musik, beh¨over det n¨odv¨andigtvis inte involvera kontextuella faktorer.
6.2 Iteration ett
Anv¨andarstudien utf¨ordes p˚a nio personer. Vi anser att det ¨ar ett tillr¨ackligt antal f¨or en proof of concept applikation, d¨aremot inser vi att det kan vara sv˚art att generalisera utifr˚an nio personers svar. Om vi hade utg˚att ifr˚an att utveckla en komplett applikation, hade vi valt ett st¨orre antal testare.
Utifr˚an resultaten av intervjuerna presenterade i f¨oreg˚aende kapitel framkommer ett antal teman: ˚asikt om konceptet, kontroll ¨over applikation och personlig data. Det fram-gick att anv¨andarna gillar konceptet kontextmedveten musikapplikation och kan t¨anka sig anv¨anda en i framtiden. F¨orslag p˚a musik ¨ar uppskattat, eftersom det inte alltid ¨ar l¨att att v¨alja. De n¨amner ¨aven att de vill ha kontroll ¨over genre, spara l˚atar de gillar och ta bort l˚atar som ogillas. Vi f¨orst˚ar att dessa funktioner efterfr˚agas eftersom de ¨ar vanliga i andra musikapplikationer.
Majoriteten av testare samtycker med att anv¨andardata lagras. Detta kan bero p˚a flera anledningar. F¨or det f¨orsta ¨ar det vanligt att dela med sig av anv¨andardata f¨or dagens applikationer. F¨or det andra skickar anv¨andaren redan mycket data till Spotify, vilket g¨or dem mer ben¨agna att dela med sig till oss.
P˚a enk¨aten till anv¨andarstudien svarade lika m˚anga anv¨andare av den kontextmed-vetna applikationen (KR) som den slumpade (SR), tre personer i respektive grupp. SR anv¨andes 6 g˚anger mer och hade 0.6 b¨attre i medelv¨arde. Fr˚an resultaten kan vi s˚aledes se att den kontextmedvetna applikationen inte presterade b¨attre ¨an slumpen. Resultatet skiljer sig fr˚an de intervjuer som genomf¨ordes d¨ar 3 utav 5 med KMA och 2 utav 3 med SR hade en positiv upplevelse av applikationen. Skillnaden kan bero p˚a att a) enk¨aten ¨ar anonym och d¨arf¨or ¨ar det l¨attare att vara ¨arlig. b) I intervjuerna kan anv¨andarna pratat om id´een som helhet, och i enk¨aten fokuserat p˚a v˚ar applikation specifikt.
Att vi inte gav n˚agra restriktioner p˚a hur applikationen skulle anv¨andas kan ocks˚a ha bidragit till helt olika upplevelser. Utifr˚an intervjuerna verkar det inte ha haft n˚agon be-tydelse men kan ha haft bebe-tydelse f¨or betygs¨attningen. Vidare fr˚agade vi inte anv¨andarna hur pass kritiska lyssnare de ¨ar. Detta kan dock ha haft betydelse f¨or hur v¨al de anser att en l˚at passar en viss kontext. Fr˚an en tidigare studie ser vi att kritiska lyssnare rankat rekommendationen l¨agre ¨an vardagliga lyssnare [36].
V˚ara anv¨andare testade bara applikationen i tre dagar, tidigare studier har testat i 3-5 veckor. Nyhetens behag kan har p˚averkat resultatet f¨or SR eftersom det blir en st¨orre bredd p˚a l˚atarna som rekommenderas. 3 dagar kan vara f¨or kort tid f¨or KR att lagra l˚atar att utg˚a ifr˚an och d¨armed tycker anv¨andarna att det inte ¨ar n˚agon skillnad. Vi tror att detta ¨ar en av anledningarna till att den kontextmedvetna versionen fick l¨agre betyg ¨an den slumpade versionen. Om anv¨andare testat 3 veckor kanske resultatet blivit mer likt tidigare forskning.
Applikationen ¨ar en proof of concept applikation, och ¨ar inte helt felfri. Att anv¨andare beh¨ovde starta om applikationen upprepade g˚anger ¨ar en faktor som kan p˚averka appli-kationens betyg negativt. Den har inte heller ett polerat anv¨andargr¨anssnitt vilket ocks˚a kan ha p˚averkat upplevelsen negativt.
