Rickard Tornblad
Erik Carlsson
15 mars 2010
Master’s Thesis in Computing Science, 2*30 credits
Supervisor at CS-UmU: Håkan Gulliksson
Examiner: Per Lindström
Umeå University
Department of Computing Science
SE-901 87 UMEÅ
1 Introduktion 9
1.1 ICAs marknadsföring . . . 10
1.2 iPhone . . . 10
1.2.1 iPhonens tekniska detaljer . . . 11
1.3 Projektets bakgrund . . . 11 2 Problembeskrivning 15 2.1 Uppgift . . . 15 2.2 Syfte . . . 15 2.3 Uppdragsgivare . . . 16 3 Vetenskaplig fördjupning 17 3.1 Användartestning anpassat till iPhone (Erik Carlsson) . . . 17
3.1.1 Användartestning . . . 17
3.1.2 Metoder för användartestning . . . 18
3.1.3 Touchinteraktionen . . . 19
3.1.4 Svårigheter med små tryckkänsliga skärmar . . . 20
3.1.5 iPhonens lösningar . . . 21
3.1.6 Användartestning anpassat till iPhone . . . 22
3.2 Integrera User Centered Design i Scrum (Rickard Tornblad) . . 25
3.2.1 Scrum . . . 25
3.2.2 User Centered Design . . . 27
3.2.3 Integrera UCD i Scrum . . . 28
4 Metodbeskrivning 31 4.1 Utvecklingsprocessen . . . 31
4.2 Förberedelser . . . 32
4.2.1 Teoretiska förberedelser . . . 32
1.1 Bilden visar telefonen iPhone som släpptes av Apple Inc, år 2007 [3]. . . 10 1.2 Denna bild illustrerar den andelen datatrafik som olika
smartp-hones står för. Som man enkelt kan se är iPhone ledande i mäng-den datatrafik [2]. . . 12
3.1 Dessa två bilder illustrerar hur en användare genom en finger-rörelse eller gest kan scrolla i iPhonen. Detta är en vanlig rörel-se som många andra smartphones också använder sig av. Den vänstra bilden visar scroll-rörelse i vertikal riktning, medan den högra bilden visar på samma rörelse men i horisontell riktning. 20 3.2 Den vänstra bilden visar iPhonens gest för att förstora en vy. Den
högra bilden illustrerar gesten som används för att förminska vyn. 20 3.3 Bilden visar hur Apple har löst det fysiska hinder problemet. . 22 3.4 Illustration av hur Apple har löst mappnings problemet. . . 22 3.5 Detta manifest skapades av “the Agile Alliance“ år 2001 [4]. . . 26 3.6 Denna bild beskriver hur ett arbetsflöde med Scrum ser ut. Till
höger kan man se hur man delar in hela projektet i olika sprints. Varje sprint är mellan två och fyra veckor. Backlog är alltså de uppgifter som finns kvar att göra. . . 26 3.7 Denna figur illustrerar hur man kan arbeta med UCD och hur
processen kan se ut. (Om man vill se texten tydligare är bilden skalbar om du öppnar en pdf-läsare i datorn). Denna bild är en anpassning från Gulliksson et al.[11] . . . 28
4.1 Bilden illustrerar en itterativ utvecklingsprocess, just denna bild är inspirerad av en sprint som används i Scrum, läs närmare i sektion 3.2. . . 32
6.1 I högerkant långt ner ses Ikonen för applikationen. . . 48
6.2 Figuren illustrerar huvudmenyn i applikationen En Riktig Jul. För att navigera drar man i detta fall etiketten Recept åt höger eller vänster. Önskar man navigera in i receptdelen trycker man endast på denna och delen öppnas. . . 49
6.3 Till vänster hur receptkategorierna visas upp. Bilden till höger visar recepten i en vald kategori, i detta fallet kategorin bakat. 50
6.4 Den vänstra bilden visar ett enskilt recept. Bilden till höger visar ett enskilt recept med header och footer vy nere. . . 51
6.5 Den vänstra bilden visar de undansparade recepten som en an-vändare har valt som favoriter. Den högra bilden visar recept vyn via enskilda recept. . . 52
6.6 Bilden illustrerar när användaren kommer in i Sökdelen, sök-fältet är markerat och ett tangentbord visas för att underlätta sökningen för användaren. Sökningen sker genom fritext och om inget resultat hittas av sökningen kommer inget recept att visas. 53
6.7 Bilden till vänster visar på hur en användare kan tänkas söka på receptnamnet Janssons, hittas receptet visas detta upp på sam-ma sätt som tidigare, nämligen genom en bild samt tillhörande text. Den högra bilden visar det andra sättet som sökfunktionen kan användas till, nämligen att söka på recept som innehåller en ingrediens. I detta fallet kommer alla recept som har ingredien-sen grädde att visas i gridden. Klickar användaren på något av träffresultaten kommer receptet att visas på samma sätt som i Receptdelen. . . 54
6.8 Bilden visar hur Julmusik-delen av applikationen ser ut. De tre etiketter som man kan se längst ned i bilden är metaforer för de tre låtar som användaren kan lyssna på. Klickar en användare på någon av dessa etiketter kommer den valda låten att spelas upp. . . 55
6.10 Denna bild visar på när en film spelar, som man kan se spelas filmen upp i liggande läge detta för att inte behöva dra ned på filmformatet. . . 56
6.11 Bilden till vänster visar vyn som möter användaren när denne kommer öppnar julkortsdelen. Den högra bilden visar hur an-vändaren får möjligheten att skriva in sitt namn. . . 57
6.12 Bilden till vänster visar ett julkort utan huvud och sidfot. Den högra bilden visar när huvud och sidfot är synliga. . . 58
A.1 Här kan man se hur hur tidsschemat ser ut för detta projekt. (För att få bättre upplösning i bilden kan den zoomas i en vanlig pdf läsare.) . . . 69
C.1 Till vänster illustreras ett koncept där menyn hänger i en grankvist. Det var därifrån tänkt att man skall gå vidare in i applikationen. Till höger ses en julkula som skulle upplevas som en tredimen-sionell kula med snurrfunktion. Där olika delar av denna kula skulle symbolisera olika delar av applikationen. . . 73
C.2 Till vänster ses ett koncept med ett julbord. Notera även pilarna i hörnet som skulle fungera som navigation i applikationen. Dessa pilar gav sedan inspiration till receptdelen av applikationen. Till höger ses ett koncept med en anslagstavla. . . 74
C.3 Till vänster ses ett koncept där man skall kunna snurra på julku-lan. (Denna julkula ses uppifrån) Till höger ses ett roulettehjul som ett koncept på att navigera i huvudmenyn. . . 74
C.4 Till vänster ses ett koncept där en grid med iconer ska represen-tera olika kategorier av mat exempelvis bakat och kött. Bilden till höger illustrerar ett koncept som innefattar en en känsla av att använda en kokbok. . . 75
C.5 Till vänster ses ett koncept där man skall kunna snurra på jul-kulan. (Denna julkula ses uppifrån) Till höger ses ett förslag på hur man kan göra ett alternativt menysystem med hyllplan. . . 75
D.1 Till vänster ses ett koncept hur en julkula kan snurras för att navigera i applikationen. Till höger ses ett koncept med en an-slagstavla, där varje lapp representerar en del av applikationen. 77 D.2 Till vänster ses ett koncept hur en pepparkaka kan snurras för
att navigera i applikationen. Till höger ses ett koncept där en julkula hänger och när man snurrar på denna navigerar man sig runt i applikationen. . . 78 D.3 Till vänster ses hur pepparkaksfigurer hänger i en grankvist,
des-sa representerar olika delar i applikationen. Till höger ses ett kon-cept med en kokbok med olika minneslappar dessa minneslappar symboliserar olika kategorier av julmat. . . 78 D.4 Till vänster i figuren ses ett koncept där en grid med bilder
presenteras. Varje bild representerar ett recept. Till höger ses ett koncept två hyllplan där övre nivån är vilket humör man är på och den nedre nivån är hur mycket tid man har för att laga maten. . . 79 D.5 Till vänster ses ett sätt att visa upp receptvyn, koncept är
in-spirerat av ett anteckningsblock. Till höger ses även där ett sätt hur man kan visa upp receptet. Där stjärnan reprecenterar att lägga till receptet till sina favoriter och playknappens funktion är att spela upp en film på tillagningen av receptet. . . 79 D.6 Till vänster ses hur ett koncept med julskiva där de olika låtarna
kan ses i en lista under bilden. Till höger ses ett koncept på hur Splash screen användas. . . 80 D.7 Till vänster ses förslag på hur julkort skulle kunna konstrueras
och visas i applikationen, till höger ses ett förslag på hur ett spel skulle kunna vara en del av applikationen. . . 80 D.8 Här visa hur recepten kan visas när man vrider iPhonen 90◦. . 81 D.9 Denna bild illustrerar juletiketter som i sin tur representerar
Introduktion
Denna rapport är en beskrivning av arbetet att utveckla en iPhoneapplikation på uppdrag av ICA. Rapporten är den teoretiska delen av ett examensarbete för programmet Interaktion och Design på Umeå universitet.
Året 2007 släppte Apple sin första mobiltelefon. De valde att inrikta sig på telefoner som faller under kategorin Smartphone och namnet på telefonen var iPhone. Med sin stora pekskärm och sitt innovativa gränssnitt fick iPho-ne snabbt fotfäste på marknaden. Med intelligenta lösningar och kontinuerliga mjukvaru- samt hårdvaru- uppdateringar har Apple lyckats ta marknadsande-lar av stora etablerade mobilföretag. I skrivande stund besitter iPhone 17% av Smartphonemarknaden [24]. Apple använder sig av en utvecklingsmodell som innebär att alla kan bli utvecklingspartners med Apple och genom detta med-lemskap tillåts de utveckla applikationer. Dessa applikationer kan alla iPhone användare välja att ladda hem till sina egna telefoner.
Uppdragsgivare för examensarbetet är matvarukedjan ICA AB. ICA kon-cernen är en av nordens ledande matvarukedjor och har över 2000 butiker placerade i Sverige, Norge och Baltikum. Butikerna är till stor del handelsägda och huvudkontoret är placerat i Stockholm. ICA idéen tog form 1917 då AB Hakon Swenson grundades [5]. ICA lägger ned mycket tid och pengar på sin marknadsföring och de strävar hela tiden efter att utveckla den än mer. För att kunna bredda sin marknadsföring och hitta nya sätt att nå sina kunder har ICA börjat titta på den mobila marknaden. Den mobila marknaden är väldigt intressant eftersom den genomgår stora förändringar. För att ICA skall kunna få en uppfattning om hur denna marknad fungerar togs beslutet att en kampan-japplikation skulle skapas. Då julkampanjen låg rätt i tiden för examensarbetet blev uppdraget att utveckla en applikation för att bredda ICA’s julkampanj.
1.1
ICAs marknadsföring
Väl genomförd marknadsföring har en stor del i att ICA AB blivit så pass fram-gångsrikt som det är i dag. ICAs marknadsföring är mest känd för reklamfilmer i tv, sedan 2001 har en typ av reklamsåpa visats flitigt [10] med nya delar varje vecka. ICA har varit representerade på webben sedan 1996 och webben har för ICA blivit en viktig marknadsföringskanal där kunder kan planera sina inköp, inspireras av olika recept och delta i diverse tävlingar. ICAs webbsida är dess-utom mobilanpassad vilket medför att sidan finns tillgänglig även för mobila användare. ICA har fyra värdeord som genomsyrar hela deras verksamhet, även i sin marknadsföring. De fyra värdeorden är inspirerande, personligt, tryggt och enkelt. Eftersom smartphonemarknaden just nu växer kraftigt ser ICA en stor fördel i att finnas med och kunna marknadsföra sig även på mobila-plattformar.
1.2
iPhone
iPhone är en mobil/multimedia telefon, interaktionen sker taktilt via skärmen och telefonen har endast tre fysiska knappar (se bild 1.1).
Figur 1.1: Bilden visar telefonen iPhone som släpptes av Apple Inc, år 2007 [3].
1. Telefon En telefon med taktil skärm viken gör det möjligt att ringa bara genom en lätt tryckning i kontaktboken, favorit listan, telefon loggen eller på ett telefonnummer.
2. iPod Vilken gör det möjligt att spela upp media som musik, film och tv-serier. Du kan ladda hem musik trådlöst genom iTunes och navigera i ditt mediabibliotek genom enkla finger rörelser.
3. Ständigt uppkopplad till internet iPhonen använder sig av snabbt 3G men ger även möjligheten att koppla sig till trådlöst nätverk, detta för att ge användaren en rikare upplevelse vid internet surfande av alla de slag. GPS och olika kartmotorer fungerar också utmärkt. iPhone har en funktionell och lättanvänd webläsaren, den har t.ex inbyggd Google sök funktion. Detta kan vara en av anledningarna till den relativt höga datatrafiken som iPhone användare genererar (se figur 1.2).
1.2.1
iPhonens tekniska detaljer
– Skärmen är 3,5-inch widescreen utrustad med Multi-Touch interaktion, upplösningen är 480 x 320 pixlar med 163 ppi.
– Hårddisken varierar i storlek från modell till modell, men de iPhones som finns i butik just nu ligger på en storlek av 16GB och 32GB.
– Storleken på telefonen är Höjden: 115.5 mm, Bredden: 62.1 mm, Djup: 12.3 mm och vikten 135 gram.
– Sensorer som finns inbyggda i iPhonen är accelerometer, avstånd samt ljussensor.
– Positionering via GPS, digitalt kompass, och Wi-Fi.
– Miljökrav är enligt Apple: drifttemperatur 0 till 35 C samt maxhöjd över havet som telefonen fungerar är 3000m.
1.3
Projektets bakgrund
Internet är en stor del i vardagen för allt fler människor, numera besöker man inte bara internet via en dator utan många använder sig också av sin mo-biltelefon. Mobilt-anpassade hemsidor blir mer vanligt förekommande och de utvecklas allt eftersom telefonerna blir kraftfullare och mer lika en fickdator.
iPhone-användare står i dagsläget för 50% av all datatrafik från mobil-telefoner och besitter 17% av smartPhone-marknaden [24]. Industrin ser därför en allt större vikt i att befinna sig på iPhonemarknaden.
Figur 1.2: Denna bild illustrerar den andelen datatrafik som olika smartphones står för. Som man enkelt kan se är iPhone ledande i mängden datatrafik [2].
Eftersom ICA redan mobil-anpassat sin hemsida är steget till att skapa en iPhoneapplikation inte stort. Utvecklingen av mobila applikationer och mobi-lanpassade hemsidor är ännu relativt ung. För att få en bättre bild av vad man skall tänka på när man utvecklar en iPhoneapplikation kan man adoptera en del saker som mobilanpassade hemsidor redan har lyckats med. Anpass-ning till mobilens mindre skärm, försöka visa den mest relevanta informationen så att sidan/applikationen upplevs ha bra prestanda, samt att tänka på att interaktionssättet är helt annorlunda gentemot hur man interagerar med en persondator. Rapporten är uppdelad i åtta kapitel, innehållet i dessa kapitel förklaras kortfattade nedan.
– Kapitel 1 - Introduktion
Introduktion av projektet och uppgiften, samt övergripande information om iPhonen’s funktioner samt tekniska detaljer.
– Kapitel 2 - Problembeskrivning
Beskrivning av uppgiften som har utförts, syftet med uppgiften, målet med projektet samt beskrivning av uppdragsgivaren.
– Kapitel 3 - Vetenskaplig fördjupning
En fördjupning av i hur användartestning kan anpassas till iPhone samt en fördjupning i hur User Centered Design kan integreras i en Agile process som Scrum.
– Kapitel 4 - Metodbeskrivning
– Kapitel 5 - Genomförandebeskrivning
Beskrivning av projektets genomförande. Olika diagram och scheman för att illustrera tidsplanen. Förklaring av gränssnitts framtagande genom mockups, interaktiva prototyper och skisser. Visar också på hur användar-testning har genomförts samt en diskussion om ICA’s målgrupp kontra iPhoneanvändare.
– Kapitel 6 - Resultat
Här beskrivs det resultat som har framkommit ur projektet, genom olika processer samt genomförande.
– Kapitel 7 - Slutsats
Beskrivning av de slutsatser som man kan dra utifrån rapporten samt den färdiga applikationen.
– Kapitel 8 - Tack
Problembeskrivning
Det huvudsakliga problemet var till en början att det mål som var uppsatt var otydligt. Det som stod klart tidigt var dock att systemet skulle utvecklas för iPhone.
Projekt genomfördes med en begränsad tidsram och för ICA en okänd platt-form. Dessa två parametrar bidrog till att utvecklingen av applikationen skedde skilt från uppdragsgivarens övriga verksamhet. Därför var det lämpligt att pro-jektet utfördes som ett examensarbete.
2.1
Uppgift
Huvuduppgiften för detta examensarbete var att utöka ICAs julkampanj till att inkludera även iPhone, vilket innebar att ta fram en applikation från idé till färdig och lanserad produkt. I detta ingick att alla delar av applikationen skulle ha ett övergripande tema, dessutom skulle det vara tydligt att den ingick i ICAs julkampanj.
Fokus under arbetet var att tillsammans med ICA arbeta fram en grafisk profil som överensstämmde med den övriga julkampanjen samt att skapa ett interaktionssätt som är intuitivt men samtidigt unikt.
En annan del av målet var även att skapa en djupare förståelse för vilken typ av process som lämpar sig i skapandet av system för mobila enheter på uppdrag av en extern kund. Ännu är denna typ av uppdrag relativt nya för både beställare och uppdragstagare därför delades detta mål med alla inbladade i projektet.
2.2
Syfte
Syftet med examensarbetet var att skapa en bättre inblick i hur ett projekt genomförs samt att tillägna sig kunskap inom utveckling för mobila enheter.
I detta ingår att skapa sig en klarare uppfattning om vilka arbetssätt och tillvägagångssätt som är lämpliga i projekt för dessa typer av system.
Det fanns även ett uttalat kommersiellt syfte med produkten vilket var att skapa en applikation som appellerar till ICAs kunder med iPhone för att stärka ICAs varumärke och öka försäljningen under julen 2009.
2.3
Uppdragsgivare
Vetenskaplig fördjupning
I denna del kommer fördjupande studier inom användartestning samt arbets-processer att presenteras.
3.1
Användartestning anpassat till iPhone (Erik
Carlsson)
Fler och fler mobiltelefoner använder sig av pekskärmar som primärt interak-tionssätt. Detta är ett relativt nytt sätt för användaren att navigera med sin telefon. Användartestning är ett väldigt viktigt inslag för de som utvecklar ap-plikationer till pekskärms telefoner på grund av att det är ett så pass nytt sätt att interagera. Detta kapitel beskriver användartestning och dess olika metoder samt vad man skall tänka på när man utvecklar eller designar en applikation för en pekskärmstelefon, i detta specifika fall iPhone.
3.1.1
Användartestning
Användartestning är ett sätt att utvärdera en applikation, ett system eller en produkt från slutanvändarens perspektiv. Detta uppnås genom att involvera de tänkta slutanvändarna i projektets olika faser. Man genomför användartest-ning bland annat för att kunna effektivisera, förenkla samt göra systemet mer intuitivt. Resultatet av användartestning används för att skapa sig en bättre bild av vad användaren förväntar sig av systemet, hur denne interagerar med det, men även vad användaren kan tänka sig acceptera med systemet. En vanlig definition av denna så kallade användarvänlighet är
"Enkelheten av användningen och acceptansen av systemet för en specifik användargrupp som utför en given uppgift i en specifik omgivning."[7].
Användartestning har förekommit inom utvärdering av system sedan början av 1980 -talet, men först omkring 1990 sattes det som en standard [18]. För att man bättre skall kunna avgöra vilka resultat som är viktiga när man genomför
en användartestning kan man dela in den i fem olika delar enligt Nielsen et al. [17]:
– hur enkelt systemet är att lära sig
– hur effektivt systemet är
– hur enkelt det är att memorera eller komma ihåg hur navigationen och interaktionen fungerar
– antalet fel som en testperson genererar
– hur nöjd testpersonen är med systemet eller applikationen
Visar det utvärderade systemet bra resultat på dessa fem delar kan man dra slutsatsen att systemet kommer att fungera och vara tillfredsställande vid an-vändning.
Användartestning skall ske kontinuerligt genom hela projektet, ju tidigare man genomför första användartestningen desto bättre, då finns det en större chans att utvecklaren hinner rätta till eventuella fel enligt Holzinge [13]. Vid genomförande av en användartestning finns det många olika metoder som man kan välja mellan, beroende på i vilken fas av projektet man befinner sig i kan man välja att använda sig av just den metoden som passar bäst in för den fasen. De metoder som flitigast används är tänka högt, fältobservation och frågefor-mulär (se sektion 3.1.2). Eftersom de olika metoderna kan användas under olika faser av projektet fungerar det väldigt bra att kombinera olika metoder, detta hjälper dessutom till att förbättra resultatet av användartestningen eftersom en viss metod kanske undersöker en helt annan del av systemet än den del som tidigare genomförda undersökningen gjorde.
3.1.2
Metoder för användartestning
Tänka högt är en metod som man kan använda sig av i designfasen av ett projekt, den tar relativt lång tid att genomföra och kräver minst tre deltagare för att resultatet skalla vara tillfredsställande. Metoden fungerar så att testper-sonen får utföra olika scenarion med olika uppgifter och samtidigt som dessa uppgifter löses uppmuntras testpersonen att prata rakt ut vad denne tänker på under genomförandet. Fördelen med denna metod är att resultatet inte bara är ren data som beskriver hur lösningarna på scenarierna har uppnåtts, utan man kan även bilda sig en uppfattning om vad testpersonen tycker och tänker om applikationen.
vad som är av mindre intresse, han måste även på ett bra sätt kunna tolka den information som testpersonerna genererar.
Fältobservationer är en metod som fungerar bra vid stationära förhållan-den till exempel när ett system eller program till en dator skall undersökas. Vid utvärdering av mobila system eller applikationer måste man ta hänsyn till att användningsmiljön ej är statisk utan snarare är väldigt varierande. Därför kan det vara en god idé att dela in fältobservation metoden i två delar, den första delen är när metoden används för att utvärdera statiska system (se ovan). Den andra delen av fältobservationer är när applikationen är byggd för apparater som är mobila, i detta fall mobiltelefoner. För att man skall kunna validera de resultat som uppkommer från användartestningen måste man kunna vara säker på hur applikationen används i olika omgivningar. Denna validering kan bara ske genom fältstudier av användningen i verkligheten. För att kunna ge-nomföra en fältstudie på en mobil applikation som resulterar i tillfredsställande resultat kan man följa med användaren och avbryta denne för att ställa frå-gor när användaren interagerar med applikationen, detta kan dock upplevas stötande av användaren då utvärderaren invaderar dennes privatliv. En annan lösning kan vara att applikationen påminner användaren att skicka utvärde-rings information men jämna mellanrum. Det går även att i viss mån simulera användnings miljöer som man vill undersöka. Vet man att applikationen kom-mer att användas när personerna promenerar kan man simulera detta genom att låta testpersonerna gå på ett löpband samtidigt som de interagerar med applikationen enligt Gulliksson [12].
Frågeformulär är en metod som man kan använda sig av under vilken fas i projektet som helst. Denna metod tar lite tid att genomföra och är mycket enkel. För att få ett pålitligt resultat rekommenderas att man testar minst tjugo personer, denna metod blir mer exakt ju fler personer som testas. Me-toden fungerar på så sätt att testledaren delar ut frågeformulär med frågor som är intressanta för utvecklingen av applikationen eller systemet, resultatet av frågeformuläret sammanställs sedan för att kunna avgöra hur majoriteten av testpersonerna resonerar. Bra med denna metod är att den är snabb men resulterar ändå i att designern får tillgång till hur testpersonerna tänker om applikationen enligt Holzinger [13].
3.1.3
Touchinteraktionen
Figur 3.1: Dessa två bilder illustrerar hur en användare genom en fingerrörelse eller gest kan scrolla i iPhonen. Detta är en vanlig rörelse som många andra smartphones också använder sig av. Den vänstra bilden visar scroll-rörelse i ver-tikal riktning, medan den högra bilden visar på samma rörelse men i horisontell riktning.
Den vänstra delen av figur 3.2 visar den rörelse eller gest som en användare kan använda sig av för att förstora en vy på iPhonen. Rörelsen involverar två stycken fingrar som användaren för bort från varandra, denna gest behöver inte ha någon specifik riktning det enda som är viktigt är att fingrarna rör sig bort från varandra.
Den högra delen av figur 3.2 illustrerar hur en användare kan förminska en vy, detta genom att utföra den motsatta rörelsen mot förstoring. Rörelsen inkluderar två fingrar som användaren för mot varandra, samma regel gäller på denna gest nämligen att riktningen inte har någon betydelse så länge fingrarna rör sig mot varandra.
Figur 3.2: Den vänstra bilden visar iPhonens gest för att förstora en vy. Den högra bilden illustrerar gesten som används för att förminska vyn.
3.1.4
Svårigheter med små tryckkänsliga skärmar
ofta figurerar när man utvärderar ett tryckkänsligt gränssnitt [16][20][26]. Fysiska hinder är ett av problemen eftersom en användares finger ofta kan upplevas större än de ikoner som man klickar på, detta medför att använda-ren kan ha svårt att veta exakt vart denne trycker. Dessutom skymmer man ofta resten av skärmen med sin hand medan man klickar med sitt finger enligt Moscovich et al. [16], detta blir ett problem då möjligheten att man missar nå-got på skärmen finns. Andra fysiska hinder som kan förekomma i mobiltelefoner är att en applikation är utvecklad för de som är högerhänta, det vill säga att man har placerat ikoner eller dylikt på ett sådant sätt att en vänsterhänt per-son skymmer hela skärmen vid tryckning. En applikation skall vara utformad på så sätt att det inte spelar någon som helst roll vilken hand man använder sig av.
Mappning av objekt och händelser när en handling utförs. Detta problem uppkommer ofta när en applikation inte tar hänsyn till användare som för första gången använder applikationen, t.ex. om det inte finns några som helst alternativ utan all interaktion sker genom gester. Detta är ett svårt problem som man måste avväga som designer. Man vill ha en effektiv applikation men samtidigt får det inte vara en för svår mappning så att ingen kan använda den. Det finns två olika sorters mappning enligt Norman et al. [20] , Naturlig mappning vilket betyder att en användare genast kan förstå vad en handling kommer att leda till och inlärningsmappning där användaren måste lära sig vad en handling får för konsekvenser.
Valet av Gester i en applikation är en stor del av designvalen som måste göras vid utveckling av en tryckkänslig applikation, man vill uppnå effektivitet med hjälp av gester men användaren måste samtidigt förstå dem och kunna utföra gesten. Problemet med gester är att en naturlig rörelse för en användare kanske inte alls är naturlig för en annan, dessutom kan det vara väldigt svårt att mappa en gest till dess konsekvens enligt Wu et al. [26].
3.1.5
iPhonens lösningar
iPhonen är en av de telefoner som har kommit längst i termer av användarvän-lighet. Den har egna lösningar på de tre stora svårigheterna med tryckkänsliga skärmar.
Figur 3.3: Bilden visar hur Apple har löst det fysiska hinder problemet.
Bilden 3.4 beskriver det standard huvud som förekommer i de flesta iPho-neapplikationer. Man kan se hur den knapp som ligger till vänster är utformad som en tillbakapil samt har en text på sig som förklarar vart man navigerar om användaren klickar på den. Detta är ett bra exempel på en mappning som är enkel att förstå för en användare.
Figur 3.4: Illustration av hur Apple har löst mappnings problemet.
De gester som förekommer i iPhonen är de som beskrives ovan i figurerna 3.1 3.2. Dessa gester kan vara svåra för en användare som använder sig av telefonen första gången. Gesterna upplevs naturliga för den som känner till dem men här lever gestproblemet kvar.
3.1.6
Användartestning anpassat till iPhone
För den som utvecklar en iPhone applikation och planerar att genomföra vändartestning kan man dra slutsatsen att i stort sett samma regler för an-vändartestning gäller även för en utvärdering av en iPhone applikation. Den stora skillnaden är att mobila-applikationer används i många olika omgivningar och i dessa omgivningar kan olika sociala aspekter spela in. Enligt Gulliksson et al.[12] är det viktigt att den som utvecklar en mobil applikation ställa sig frågorna:
ICA att synas på den allt mer växande smartphone marknaden. Behovet ur användarperspektiv kom att bli en hjälpreda under julen.
Vem kommer använda sig av applikationen? För att kunna skapa sig en bild av till vilken målgrupp applikationen riktar sig är det viktigt att ha klart för sig vilken typ av personer som kommer att använda applikationen. ICA koncernen har en uttalad målgrupp som är kvinnor i åldern 30-55 år. När det gäller iPhoneanvändare ligger användargruppen något lägre i ålder samt en större del av användarna är män.
Vad skall applikationen användas till? Vilka funktioner skall vara med och vilket användningsområde skall applikationen täcka. För en utvecklare kan den-na fråga vara enkel att förstå och genomföra om en kravaden-nalys har genomförts före implementationen. Problemet uppkommer om beställaren eller utvecklaren vill lägga till funktionalitet eller helt enkelt väljer bort befintlig funktionalitet vilket kan påverka hela applikationens funktionalitet det vill säga vad applika-tionen skall användas till. Under examensarbetet har detta scenario uppkommit ett flertal gånger då funktionalitet och ibland hela delar lades till. Lösningen på detta är att försöka bygga applikationen så generisk som möjligt för att underlätta ändringar under projektets gång.
Vart och när kommer applikationen att användas? Eftersom användning-en av användning-en mobilapplikation kan ske i princip i vilkanvändning-en miljö som helst bör användning-en användartestning och utvärdering genomföras för att kunna förutse och testa applikationen i olika miljöer. Vanliga miljöer som en mobilapplikation används i är stationära eller dynamiska, de olika miljöerna kan vara mer eller mindre gynnsamma i förhållande till ljus, ljudnivå eller olika sociala sammanhang som på ett bibliotek eller sittande på bussen. De sociala sammanhangen är bland de svåraste miljöerna att hantera, en enkel genväg som många utvecklare tar är att helt enkelt ge användarna möjlighet att själv ställa in vilken miljö som de befinner sig i, ett bra exempel på detta är den vanligt förekommande funk-tionen flygplansläge. I examensarbetet har frågan vart och när diskuterats och anpassningar för omgivningen har tagits i beaktning. För att undersöka hur bra applikationen klarar sig i olika miljöer är fältstudie för mobila applikationer att föredra, där man kan undersöka hur användarna faktiskt presterar i de verkliga förhållandena.
Hur skall utvecklingen och användartestningen genomföras? Som tidiga-re nämnts följer utveckling av mobila-applikationer i stort de riktlinjer som finns för statiska applikationer. Den stora fördelen med iPhone applikationer är att alla versioner av telefonen har samma storlek på skärmen och klarar av att använda sig av samma program. Detta medför att man slipper bry sig om skillnader i prestanda eller skärmstorlek. Man skall även sträva efter att åter-använda sig av åter-användarens kunskaper från tidigare system eller applikationer. Under projektets gång har egna metoder för utvecklingen använts (se 3.2) och användartestningen har genomförts med hjälp av välkända metoder.
applikation eller till vilken plattform man utvecklar. Den metod för användar-testning som passar bäst i ett tidigt stadium, just för att den inte är tidskrävan-de men resulterar i mycket information, är Frågeformulär metotidskrävan-den [22]. Med frågeformulär kan man tidigt bestämma vad användaren anser är viktigt med applikationen samt få bra underlag för sina egna funderingar kring design och funktioner.
För att kunna få en bra och rättvis bild av applikationen kommer man att behöva använda sig av flera olika användbarhetsmetoder och dessutom finns möjligheten att kombinera dem. Till en början under de första iterationerna av ett projekt kommer frågeformulär metoden att besvara de flesta oklarheter, men så fort utvecklingen av interaktiva prototyper tar sin början är det en stor fördel att undersöka hur användarna interagerar med applikationen. Under denna del av utvecklingen fungerar tänkahögtmetoden som ett kvitto på vad som fungerar bra och vad som fungerar mindre bra i en applikation. Ofta behöver man inte genomföra många tänkahögt tester innan brister i applikationen kan upptäckas.
Metod kan man använda sig av ändå till slutet av utvecklingen, men vad som kan vara bra att tänka på är att inte använda sig av samma person för varje nytt test av nya versioner utan istället försöka testa personer som aldrig interagerat med tidigare versioner. Om man gör på detta sätt kan man få en mer korrekt statistik över vilka fel en användare ofta gör i ett scenario. Detta för att man skall få en så naturlig simulering av verkligt användande som möjligt. Naturligtvis är det en fördel att testa samma personer på olika versioner också för att se hur bra applikationen uppfyller minnes aspekten det vill säga om en användare kommer i håg hur navigationen fungerade även om de inte använt applikationen under en tid.
När applikationen är färdig och har klarat sig igenom de tidigare användar-testningarna är det en bra idé att genomföra en fältstudie för att se hur ap-plikationen används i den tänkta miljön. När detta gäller en mobilapplikation blir denna metod annorlunda om man jämför mot statiska applikationer. När man genomför en fältstudie för en mobilapplikation måste man tänka på att undersöka applikationen i den eller de miljöer som applikationen kommer att användas i. För att kunna få en så rättvis bild som möjligt är det en fördel att följa en person som använder sig av applikationen i en dag och låta den-na person sedan utvärdera applikationen. Har man inte möjlighet att följa en person en dag kan man alltid försöka att simulera de miljöer där användningen sker i laboratorium, genom att till exempel skapa en bullrig miljö med dåligt ljusförhållande för att simulera användningen av applikationen på en buss. An-vändaren kan ibland även ha svårt att bara koncentrera sig på en applikation, därför kan det vara bra att integrera fältstudie med något sorts frågeformulär där användarna får ge sina tankar om hur de tycker applikationen fungerar och har fungerat. Från detta resultat kan man ofta få nya idéer och förslag på förbättringar till senare versioner av applikationen.
miljöer utan också de tre svårigheterna med tryckkänsliga skärmar som nämns ovan. En iPhoneanvändare har vanan från Apples applikationer hur mappning, fysiska hinder samt gester fungerar på telefonen, därför är det bra att inte designa en applikation som helt går ifrån dessa standardlösningar.
3.2
Integrera User Centered Design i Scrum
(Ric-kard Tornblad)
Denna del undersöker hur man kan integrera User Centered Design (UCD) i en Agileprocess som Scrum. UCD används huvudsakligen av designers som en process för att skapa användarvänliga produkter [17].
Scrum är en process som används mycket i mjukvaruindustrin som en pro-cess för utvecklare att producera bra och stabil mjukvara i en dynamisk miljö [1].
Det är tydligt att mer och mer mjukvara som produceras i industrin idag har ett större fokus på att vara användarvänliga. Därför är det intressant att undersöka hur man kan integrera en av det mest använda designprosesserna UCD, som använts av mjukvarudesigners under en lång tid [11], med Scrum som är en av de mest använda utvecklingsprocesserna av mjukvaruutvecklare enligt Bohem et al.[6].
Anledning till att dessa två processer är viktiga att förstå är att många moderna it-projekt har olika roller som skall fyllas och två av dessa är designer och tekniker/programmerare [15]. Att kunna få dessa olika roller att fungera bra ihop är inte trivialt då de ofta kommer från helt olika bakgrund. Desig-nern har inte sällan sitt ursprung i tryckt media eller grafisk design, program-merare/tekniker har ofta sin bakgrund inom datavetenskap och mer tekniskt orienterade utbildningar.
Under detta examensarbete har dessa två processer integrerats för att möta ICAs krav på väl designade produkter samt en stabil implementation med hög kvalité.
3.2.1
Scrum
The agile manifesto
– Individuals and interactions over processes and tools
– Working software over comprehensive documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
Figur 3.5: Detta manifest skapades av “the Agile Alliance“ år 2001 [4].
Termen Scrum kommer från sporten rugby och är ett sätt att starta om spelet, inom mjukvaruindusrin är Scrum en lättviktig och interaktiv utveck-lingsprocess. Scrum fokuserar på hur medlemmar i ett Scrum-team skall agera för att producera en bra produkt.
Hirotaka et al. [25] som introducerade termen Scrum 1886 tycker att “när ett lag försöker förflytta sig som en enhet, och passa bollen fram och tillbaka“ är en bättre lämpade process än de traditionella sättet att utveckla mjukvara. När man arbetar med Scrum använder man sig av något som kallas för sprints, dessa är mellan 2-4 veckor långa iterationer beroende på projektets stolek och tidsplan. För varje “sprint“ samlas “Scrum-team“ och bryter ner må-let av sprinten i olika uppgifter. Dessa uppgifter sparas i en så kallad “backlogg“ som illustreras i figur 3.6. Bilden beskriver även det dagliga Scrummötet, möte är en mycket viktig del av processen som värdesätter högt att man har kor-ta och intensiva möten dagligen. Dessa mötet skall vara i ca 15 minuter och genomförs stående, detta med syfte att hålla övriga gruppen uppdaterad med hur all ligger till.
2-4 veckor 24 timmar
Produktens
Backlog BacklogSprint
Dagligt Scrum Möte
Färdig Produkt
Figur 3.6: Denna bild beskriver hur ett arbetsflöde med Scrum ser ut. Till höger kan man se hur man delar in hela projektet i olika sprints. Varje sprint är mellan två och fyra veckor. Backlog är alltså de uppgifter som finns kvar att göra.
en kugge i den avslutande produkten. I manifestet står det även tydligt att man skall implementera fungerande mjukvara heller är dokumentera.
3.2.2
User Centered Design
User Centered Design (UCD) är en itterativ utvecklingsprocess som används primärt av designers, detta anses vara ett bra tillvägagångssätt för att skapa produkter med tydligt fokus på bra användbarhet som är anpassad till använ-daren enligt Gulliksen et al. [11].
Begreppet UCD eller User Centered System Design (UCSD) som det också kallas var först uttalat av Norman et al. Enligt denna process skall man först skapa sig en tydlig förståelse för användaren, vad som skall göras och hur sy-stemet skall fungera innan man startar med implementation enligt Norman et al. [19].
UCD kan implementeras på olika sätt, alla projekt är unika och det finns inget recept på hur man exakt skall gå till väga. Man kan se UCD som en guide för hur man skall gå tillväga för att öka chanserna till att designa och utveckla en produkt med hög användbarhet för den tänkte användaren. UCD är en process som har användaren i fokus, detta hörs på namnet och det är viktigt att man hela tiden har med sig användaren i tanke när man fattar viktiga designbeslut. För att kunna hålla användaren i fokus och veta vem användaren är inleds processen med en analys. Denna analys går ut på att förstå vad man skall designa, få en bild av vem användaren är och i vilken kontext som användaren förvänta använda produkten [11].
Den iterativa delen av UCD är mycket viktig och man låter designen växa fram. Iterationerna sker så att man börjar med skisser, utreder och testar dessa och gör ett förfinat koncept. När detta koncept är klart testas det och utvärderas och de ändringar som behövs göras utförs och på så sätt växer en produkt fram. När man arbetar på detta sätt är det viktigt att börja med många olika koncept och hålla parallella spår i utvecklingen enligt Mcinerney et al. [15].
För att kunna få ett så bra resultat som möjligt av de utvärderingar som görs i processen finns är det viktigt att dessa sker i rätt kontext för användaren. Detta görs i syfte att få en bättre förståelse för hur användaren tänker använda produkten och även kan det känns bättre för användaren att vara i bekant miljö.
mer detaljrik och så även återkopplingen.
Vision och plan • Kartlägg mål och önskade effekter • Initialt koncept • Planera för ACSD Analysera användarbehov och mål • användare, användningssammanhang, uppgifter och mål • behov, features scenarier och designmål Design För användbarhet genom prototyping • konceptuell design • interaktionsdesign • detaljerad design Utvärdera i verklig användning • testa tidigt och kontinuerligt • mät användbarhet, nytta och effekt Konstruera och inför • kontinuerligt fokus på användningen • användbarhetstestning och monitoring Återkoppla
planera för nästa iteration • förslag på förändringar i prototypen • förbättringsåtgärder i verksamheten
• projektplanering utifrån resultatet
Figur 3.7: Denna figur illustrerar hur man kan arbeta med UCD och hur pro-cessen kan se ut. (Om man vill se texten tydligare är bilden skalbar om du öppnar en pdf-läsare i datorn). Denna bild är en anpassning från Gulliksson et al.[11]
3.2.3
Integrera UCD i Scrum
För att förstå tydligt vad problematiken ligger i när man skall integrera UCD i Scrum är det viktigt att inse dessa olika processers bakgrund. Scrum har sitt ursprung i ett datavetenskapligt tänkande om hur man effektivt skall göra en produkt som rent funktionellt är stabil och utan buggar. Det primära målet kan anses vara att skapa mjukvara med hög funktioanalitet i en dynamisk miljö [1] UCD har ett annat fokus som Macinley et al. formulerar på följande vis:
Användarcentrerad design är en process med fokus på använd-barhet genom hela utvecklingsprocessen och vidare genom hela sy-stemets livscykel [15].
motstridiga i någon mening men om man tittar djupare på hur man skall arbeta med de olika processerna ser man en stor skillnad.
Scrum förespråkar att varje iteration “sprint“ skall producera fungerande kod som är en del av slutprojektet. Om man är osäker på hur hela produkten skall se ut börjar man med de delar som man är säker på och iterera fram resul-tatet. Detta står delvis i konflikt med hur UCD sätt att arbeta. Enligt UCD är det viktigt att man förstår helheten innan implementationen av slutprodukten startar. Detta innebär att implementation av den faktiska produkten ej startar i den första iterationen. Från början är det analys av användaren sen fortsätter processen enligt figur 3.7. Implementationen av produkten skall alltså göras först när man förstått helheten. Detta för att det är mycket mindre kostsamt att ändra en skiss än att programmera om ett helt system.
För att kunna lösa dessa problem kan man tänka sig att en gedigen analys av målgruppen görs från början innan imlementationen tar vid. Efter det får man fokusera på att ta fram koncept tills man slagit fast hur produkten skall fungera och vad denna skall innehålla i grova drag. När man gjort detta kan man med fördel börja implementera de delar som är klara i väntan på att resten av designen skall bli fördig.
Under projektet med ICA har vi erfarit att det är mycket viktigt att arbeta mot korta mål och deadline. Under vissa skeden har det varit tendenser åt att man gör om designen och koncept många gånger utan att ta sig framåt i projektet, det har då varit till stor hjälp att ha tydliga mål och deadlines. Om man inte har dessa deadlines är risken stor att man inte når önskat resultat och slutprodukten blir försenad. Det är därför viktig att sätta upp några tydliga och mätbara mål innan projektstart som man kan förhålla sig till när man är mitt uppe i arbetet. Risken med att utveckla del för del och inte se hur lång tid hela projektet kommer att ta är att man underskattar andra delar och jobbar hårt med problemen som finns för dagen.
För att komma åt problemet med att integrera en fungerade designprocess i Scrum är det viktigt att noga överväga designanalysen av alla prototyper i Scrum, om dessa påverkar den implementation som pågår och hur man skall förhålla sig till detta.
I Scrum ligger tonvikten på att producera mjukvara som är stabil, och sam-tidigt kunna ta in nya önskemål från beställare under implementationsfasen. När man säger att scrum är anpassat för att utveckla stabil mjukvara i en dy-namisk miljö tänker man främst på funktionalitet. När beställarens önskemål analyseras är det stor fokusering på huruvida dessa önskemål är tekniskt ge-nomförbara eller inte. Det som ofta åsidosätts är hur detta önskemål påverkar helheten av produkten. Risken med en sådan utveckling är att helhetsintrycket av applikationen inte blir det man eftersträvar.
En annan intressant aspekt av vad som skulle kunna göras redan på ett designstadie i processen är att designa applikationen på ett skalbart sätt. Med detta menas att man kan gör en typ av design som tillåter ett växande inom vis-sa ramar. Mer konkret kan detta fungera genom att tidigt designa grundelement som genomsyrar hela applikationen, ett exempel på detta är receptkategorier-na i receptdelen av applikationen “En Riktig Jul“. Sättet som valdes var att använda en typ av grid med bilder med förklarade text under bilden, se figur 6.3. När denna design fastslogs bestämdes även att alla delar i applikationen med liknade val skulle se ut på liknade sätt. Detta kan man se bland annat i sökfunktionen, filmdelen och julkorten. Detta gjordes för att användaren enkelt skulle känna igen interaktionen och för att skapa en bra helhet.
Metodbeskrivning
För att uppnå ett bra resultat och en bra arbetsmiljö är det viktigt att ha ett tätt samarbete med alla inblandade, detta för att gemensamt komma överens inom vilka ramar arbetet ska utföras.
Ett delsyfte med projektet har varit att undersöka vilka metoder/arbetssätt som är lämpliga när man utvecklar produkter för mobilaenheter. Denna inrikt-ning togs för att underlätta och bättre förstå liknade projekt i framtiden.
Arbetet med att plocka fram och utvärdera olika koncept har hela tiden varit en stor del av arbetet, detta för att undvika extraarbete och säkerställa en hög kvalité på produkten. Till en början var dessa koncept vitt skilda åt men allt eftersom utvecklades koncepten tills en färdig prototyp uppkom.
Detta kapitel behandlar vilken utvecklingsprocess som använts under pro-jektet, vilka förberedelser som gjorts samt vilka verktyg som användes under projektet.
4.1
Utvecklingsprocessen
Under projektet används ett iterativt arbetssätt (se figur 4.1), mer specifikt User Centered Design (UCD) integrerat i ett Agile-liknade arbetssätt. Detta gjordes för att minska riskerna att beställarens krav och mål inte skulle upp-fyllas (se sektion 3.2).
I processen lades även ett tydligt fokus på användartester i syfte att sä-kerställa en hög kvalitet med ett tydligt fokus på användbarhet. Lämpliga an-vändartester kommer även att utredas närmare i sektion 3.1.
Figur 4.1: Bilden illustrerar en itterativ utvecklingsprocess, just denna bild är inspirerad av en sprint som används i Scrum, läs närmare i sektion 3.2.
Arbetet genomfördes på ett sprint-liknande sätt som figur 4.1 illustrerar. Varje sprint inleddes med en analys av uppgiften genom fakta och observationer av användare. Utifrån denna kunskap inleddes designfasen i vilken koncept förslag togs fram och utvärderades. De bästa koncepten togs sedan vidare till implementationfasen där implementation kunde vara allt från digitalisering av skisser till fungerande program. Dessa implementationer testades på användare på olika sätt, som behandlas i sektion 3.1.
4.2
Förberedelser
Projektet inleddes med en hel del förberedelser på både teoretiskt och tekniskt plan. Redan från början var det klart att en iPhoneapplikation skulle utvecklas. Detta gjorde att förberedelserna med att lära sig den miljö som man använder i utvecklingen av iPhoneapplikationer inleddes tidigt.
4.2.1
Teoretiska förberedelser
Den teoretiska förberedelsen för projektet var avsedd för att få fördjupad kun-skap inom vilka begränsningar och möjligheter som utvecklingsplattformen har. Den teoretiska förberedelsen innehöll bland annat föreläsningar från Stanford Univerity om iPhone utveckling [23], samt studier av allmän litteratur och in-ternet.
4.2.2
Praktiska förberedelser
4.3
Verktyg
De verktyg som har används under detta projekt är:
– X-code - är den utvecklingsmiljö som använts för att utveckla till iPhone. Interface-builder - en del av X-code, det kan användas för att skapa det grafiska användargränssnittet.
iPhone simulator - också detta verktyg är en del av X-code, det används för att testköra applikationen.
Analysverktyg - används för rensa bort minnesläckage från koden.
– Adobe produkter
Photoshop - bildhanterings program som har använts till att digita-lisera koncept samt skapa grafiska objekt till applikationen.
Fireworks - liknande uppgifter som photoshop och har varit till stor hjälp vid bild konvertering samt beskärning av bilder.
Illustrator - vectorbaserat bildhanteringsprogram där alla ikoner och knappar till applikationen har skapats.
Genomförandebeskrivning
Projektet startade med att det fanns ett intresse från ICA att undersöka hur man skulle kunna använda iPhone som en ny mediekanal i syfte att bredda ICAs marknadsföring. ICA ansåg det vara lämpligt att genomföra detta som ett examensarbete vilket för dem innebar små kostnader och minimering av risker.
När projektet inleddes var det viktigt att få till en arbetsform som passade dels för beställaren (ICA) samt för vårt examensarbete. Det blev tidigt över-enskommet att de skulle ske avstämningsmöten ca en gång i veckan, detta för att säkra att beställaren hela tiden var involverad i projektet.
Metoder som har används för att hitta nya idéer är framför allt brainstor-ming. Under konceptfasen ägnades en session dagligen åt att komma på nya lösningar på redan befintliga problem och brainstorma fram nya idéer. Detta visade sig vara mycket bra framför allt för att hela tiden tänka i nya banor. Många av avstämningsmötena som skedde i samarbete med kontaktpersoner på ICA har även mynnat ut i workshops1. Dessa har handlat om att analysera
de olika koncepten och idéerna som uppkommit från tidigare möten. Under implementationsfasen har pair programming 2 används som utvecklingsmetod.
Denna metod är mycket användbart när olika implementationslösningar skall diskuteras och komplicerade lösningar skall implementeras. Enligt Cockburn et al. [9] är det fördelaktigt att använda sig av pair programming framför att sitta själva vid varsin arbetsstation.
Dock har det visat sig att pair programmin har varit ineffektivt när im-plementationen är enkel och standardmässig. Därför har utvecklingen varierat mellan pair programming och att sitta vid enskilda datorer.
Kapitlet behandlar hur projektet har genomförts i termer av de olika faser som har genomgåtts.
1Workshops har i detta projekt inneburit att några personer med olika ansvarsområden i
projektet suttit i samma rum och haft kreativa samtal om hur olika problem skall lösas.
2Pair programming innebär att man sitter två personer kring en dator och implementerar.
5.1
Tidsplan
En Gant-tidsplan finns redovisad i bilaga A.
Detta tidsschema ger en ganska grov bild av hur arbetet har sett ut och ger också en uppfattning om hur lång tid olika saker tagit samt i vilken ordning de utförts.
5.2
Kravspecifikation
Kravspesifikationen för projektet har iterativt tagits fram i samarbete med ICA. Från början var specifikationen för detta projekt löst formulerat, på grund av att det fanns oklarheter i vad som var möjligt att göra på den valda plattfor-men. Något som bidrog till vissa oklarheter inom projektet var att den julkam-panj som applikationen skulle ingår i inte hade tagit form i början av projektet. Dock fanns det en klar vision redan från början, denna kan beskrivas som att: Applikationen skall stå ut från applikationerna gjorda av ICAs konkurren-ter, samt att en viss lekfullhet skall finnas i applikationen. ICA ansåg detta vara lämpligt i och med att applikatioen endast skulle finnas tillgänglig under en begränsad tid och att den skulle ingå i den planerade julkampanjen.
Allt eftersom applikationen tog form handlade arbetet om att fastställa vilka delar som skulle förkomma i applikationen. Alla delar av applikationen fastslogs så sent som 19/10/09, först då kunde specifikationen av applikationen anses som fastställd. Detta kunde hanteras genom att implementationen av de delar som redan var fastslagna kunde inledas. En av punkterna i manifestet som agile processer utgår ifrån är att kunna anpassa sig till nya krav som sent kommer från beställaren in i projektet 3.2.1.
De krav som kommit från Umeå Universitet har framförallt handlat om do-kumentation och en vetenskaplig förankring i de arbete som utförts. Projektet skall i någon mån spegla vad utbildningen Interaktion och Design står för. Det har även funnits ett krav på att en kontaktperson på ICA skall finnas tillgäng-lig. Krav på en ordentlig projektplan innan projektstart där en sammanfattning om projektets omfattning och inriktning presenteras se bilaga B. Arbetet skall utföras på ett ingenjörsmässigt sätt där tydliga resultat presenteras i rapporten samt i den muntliga presentationen.
5.3
Konceptfas
från ICAs recept-databas, men även att den skulle innehålla flera skilda delar. När detta beslut tagits inriktades konceptförslagen på ett menysystem där man skulle kunna inkludera flera olika delar. Eftersom syftet med applikationen var att marknadsföra ICA och bredda deras julkampanj fanns kravet att applika-tionen skulle skilja sig från andra applikationer på Appstore. Detta skulle ske genom att inte använda standardutseende och standardinteraktion som redan befintliga applikationer har.
Konceptfasen består av brainstorming, lo-fi prototyper, mockup och inter-aktiva prototyper. Dessa delar har genomförts i iterationer och ur dessa har applikationen vuxit fram organiskt.
5.3.1
Brainstorming
Det finns många olika sätt att genomföra en brainstorming på. Det vanligaste sättet är att man sitter ned i en grupp av människor och diskuterar olika idéer och tankar. Dessa förslag skrivs eller skissas ned samtidigt som diskussionen pågår.
Man brukar prata om tre enkla regler när man utför en brainstorming [21]
– Fokusera på kvantitet för att försöka lösa problemet, detta bygger på att ju större antal förslag som kommer fram desto större chans är det att någon av dessa förslag passar bäst som lösning.
– Undvik att kritisera varandra, detta eftersom ovanliga eller ogenom-förbara idéer kan resultera i nya tankebanor samt att det alltid finns en chans att utveckla eller addera idéer.
– Kombinera och förbättra idéer för att på så sätt kunna komma fram med nya förslag samt förbättra redan befintliga.
Under projektet har dessa regler efterföljts vilket också resulterade i att en stor mäng med idéer och förslag uppkom. Brainstorming har varit en van-ligt förekommande företeelse främst under konceptfasen då rena brainstorming möten förekom nästan dagligen.
5.3.2
Lo-Fi prototyper
man kommer att tänka på. Dessa skisser kan man sen utvärdera för att kunna minska ned antalet och belysa de idéer som man kan gå vidare med.
Under projektet har mängder av Lo-Fi prototyper uppvisats för beställaren och detta har varit mycket uppskattat och har lett till nya koncept. För att bättre få en uppfattning om storlek och form på konceptet har en mall använts. Denna mall består av bilden på en telefon med samma skärmstorleken som iPhonen, man skissar hel enkelt på samma yta som skärmen har i verkligheten. Nedan följer en kort beskrivning av ett urval från den Lo-Fi prototyper som skapades efter brainstorming sesioner.
Meny
En stor del av arbetet från början gick ut på att skapa en meny som kändes intuitiv och naturlig för en iPhoneanvändare. Det stod klart tidigt att huvud-menyn skulle vara själva centrum i applikationen samt det första som mötte användaren. På grund av detta och en uttrycklig önskan om att applikationen skulle kännas annorlunda och unik gjorde att stor vikt lades på denna del. Nedan nämns några av förslagen mer i detalj, bilder på dessa kan ses i bilaga C.
– Pepparkakor som hänger i en grankvist var ett tidigt koncept som job-bades länge med. Den första skissen av detta koncept ses i figur C.1 till vänster. Vid ett tryck på en av pepparkakorna öppnas den delen av ap-plikationen.
– En hängande julkula är även den inspirerad av pynt som hänger i granen se figur C.1 till höger. Konceptet fungerar så att kulans olika delar illu-strerar olika delar av applikationen (som en klassisk badboll). Med fingret kan man snurra på julkulan för att navigera till rätt del i applikationen.
– Ett julbord med mat på var ett koncept som tidigt togs bort men kom att bli mer intressant senare i utvecklingen. Detta koncept kan ses i figur C.2 till vänster.
– Anslagstavla var ett koncept som senare vidareutvecklades se figur C.2 till höger. Detta koncept blev omtyckt då anslagstavla i hemmet ofta kan vara en central plats där familjen samlas.
– Julkula uppifrån var ett annat koncept på hur menyn skulle styras se figur C.3 till vänster. När man snurrar på kulan ändras den delen som ser ut som ett blad mellan meny alternativen som finns tillgängliga.
Recept
Receptdelen av applikationen var den del som först blev fastslagen att den skulle vara med. Det konstaterades tidigt att denna del av applikationen skulle bli den mest omfattande. För att förstå hur denna del skulle utformas gjordes många olika förslag, några av dessa kan ses i bilaga C. Trots att denna del tidigt fastslogs som en del i applikationen beslutades inte innehållet av denna del förens senare i projektet. Nedan följer en mer detaljerad beskrivning av några av de tidigaste koncepten kring receptdelen.
En Kokbok är ett bekant inslag för den som ofta lagar mat, alltså hur den ser ut och hur man kan hitta olika recept i ett index längst bak och så vidare. Det är en utmaning att få en användare som skall laga mat att se iPhonen som en ersättare till en kokbok. Dock har fler och fler börjat använda Internet och de stora receptsidorna där istället för kokboken. En iPhone har svårt att konkurrera med en dator med tanke på fysiska begränsningar så som skärmstorlek. Tanken med designen var att skapa ett komplement till datorn och inspirera användarna i användningen.
– Att göra en grid med bilder som skulle representera olika kategorier av applikationen var en tidig idé som skulle visa sig vara med hela vägen fram till slutet se figur C.4 till vänster. Detta sätt att presentera objekt är standard för huvudmenyn på iPhonens operativsystem, vilket underlättar för användaren att känna igen sig med interaktionen.
– Kokbok var ett förslag som även var med och förfinades länge i processen se figur C.4 till höger. Tanken med konceptet var att användaren skulle känna igen sig med kokbokstanken fast nu skulle kokboken vara på en iPhone.
– Att visa upp själva receptet har under hela skapandet av denna applika-tionen varit en av de designelement som tagit längst tid att komma fram till. Receptkonceptet som skapades visar på hur man kan leka med bilden för att få en mera tilltalande design. På just detta koncept kan man se hur bilden placerats utanför ramen se figur C.5.
– Hyllplan var ett koncept som har klar koppling till ICA butiken, konceptet var tänkt att fungera så att man kan sortera recepten på t.ex klassiskt julrecept som är vegetariskt se figur C.5 till höger.
Julkort
ICA har sedan länge ett samarbete med Childhood foundation [8], det an-sågs lämpligt att på något vis få in denna organisation i applikationen. Jul-kortsdelen ansågs passande för detta ändamål.
Splash screen
Splashscreenen visas när applikationen öppnas, detta sker automatiskt när ap-plikationen startas och under själva laddningen visas en bild upp. Konceptet för denna del var tidigt att imitera ett lackförseglat papper som öppnas när applikationen har laddat klart se figur C.6 till höger.
5.3.3
Mockups
Nästa steg efter skapande av Lo-Fi prototyper är att utveckla dessa i mer detalj. Genom att digitalisera skisserna med en dator får man en bättre känsla av hur konceptet kommer att te sig på en mobilskärm. Det resultat som uppkommer från digitaliseringen brukar man referera till som en Mockup 3. Under projektet skapades som tidigare nämnts en stor mäng med konceptförslag genom Lo-Fi skisser, de koncept som i samarbete med ICA valdes ut att jobba vidare med digitaliserades för att sedan utvärderas återigen. För att skapa Mockups utifrån de Lo-Fi skisser som tagits fram användes program från Adobepaketet. Ofta digitaliserades två versioner av koncepten för att inte fastna i något spår vid val av färger.
Nedan följer en redogörelse för några av de valda koncepten, dessa är utvalda på basis att de varit betydelsefulla för slutresultatet.
Meny
De olika koncepten som valdes att arbeta vidare med, alltså gå från skissbordet till att göras digitala var något som tog lång tid och en grov gallring av kon-cept utfördes. Just för menydelen fanns det många olika krav som skulle tänkas på när den designades. Viktigt var att designa menyn på ett vis som innebar att den var oberoende av hur många delar av applikationen som skulle finnas, på grund av att denna information än så länge var okänd. Detta innebar att applikationen kunde bestå av mellan 4 - 7 delar beroende på tid och vilja från beställare. Ett annat väsentligt krav på denna meny var att bygga något som såg annorlunda och unikt ut, då menyn alltid är i centrum av applikationen. Kravet fanns också att applikationen endast skulle fungera som en kampanjap-plikation under en begränsad tid. Detta gjorde att viss lekfullhet gavs utrymme i applikationen, det stora fokusen för ICA var att se hur man kan använda iP-hone i deras verksamhet och testa vad som fungerar och vad som inte fungerar. Nedan beskrivs några av de menykoncept som digitaliserades.
3En Mockup kallar man en mer detaljerad illustration av en idé eller ett koncept, gärna
– Olika julattribut i menyn är återkommande på olika sätt, detta koncept visar hur en julkula ses uppifrån och genom att snurra på denna navigerar man mellan delarna i applikationen se figur D.1 till vänster. Detta sätt att navigera var tänkt att gå igenom hela applikationen och det som skall föreställa centrum på julkulan kan även ses en hem-knapp med den tänkta funktionen att gå till huvudmenyn.
– Anslagstavlan är ofta en central del i köket och de flesta är familjära med den. Därför var ett koncept att använda sig av denna som ett sätt att navigera i applikationen se figur D.1 till höger.
– Pepparkaka är även det något som förknippas med julen, tanken här var alltså att när man snurrar på pepparkakan navigerar man mellan de olika delarna i applikationen se figur D.2 till vänster.
– Detta koncept var att ha en julkula som för användaren har en tredimen-sionell effekt, den skall se ut som en riktig julkula som hänger i granen och när man snurrar på denna motsvarar varje del av kulan en del av ap-plikationen se figur D.2 till höger. Detta koncept var mycket uppskattat från alla inblandade, dock ansågs risken vara för stor med ett sådan kon-cept på det tekniska planet därför vidareutvecklades inte detta konkon-cept längre.
– Konceptet att hänga pepparkaksfigurer i granen där alla delar represen-teras av en hängande pepparkaka var även de populärt. Detta koncept har en mycket tydlig koppling till julen se figur D.5 till vänster.
Recept
Receptdelen av denna julapplikation var på ett tidigt stadie fastställt som en del av applikationen. Det var dock inte klart hur stor denna del skulle bli och hur pass central receptdelen skulle bli av applikationen. Några av de koncept som visas i denna del har förutsatt att den skulle vara i centrum, det vill säga att de andra delarna skulle vara delar som byggde på receptdelen. T.ex inköpslista och favoritrecept.
– Kokbokskonceptet som kan ses i figur D.3 till höger bygger på hur man kan använda det traditionella sättet med en kokbok med olika kapitel, dessa kapitel motsvarar en kategori av recept i applikationen. Interaktio-nen för detta koncept fungerar så att man drar en av flikarna till andra ändan av skärmen och på så sätt öppnas denna kategori av recept.
– Konceptet med att visa ett recept som i en anteckningsbok var ett utav väldigt många se figur D.5 till höger. Tanken här var att man skulle kunna bläddra mellan olika recept genom att dra/trycka på fliken i hörnet.
– Ett koncept för att visa upp alla recept i en receptkategori visas i figur D.4 till vänster. Tanken är att på ett snabbt och enkelt sätt kunna skapa sig en uppfattning om vilka recept som finns och även visa en liten bild på hur maten ser ut detta för att ge inspiration till användaren.
– Hyllplanskonceptet som kan ses i figur D.4 till höger, den visar hur man kan använda olika vägar in till att visa recept. Här är tanken t.ex att det skall genereras olika recept beroende på vilket humör man är på och hur mycket tid man har att laga mat på.
Julskiva
ICA har under några år använt sig av artister som spelar in en julskiva i samar-bete med Childhood foundation4som en del av julkampanjen. Detta var något
som ansågs vara lämplig som en del i applikationen, alltså att låta iPhonean-vändare lyssna på smakprov av ICAs julskiva. Under arbetets gång kom det fram att endast tre låtar skulle finnas tillgängliga i applikationen. Dessa låtar var kortare versioner på ca 45 sekunder.
Det koncept som kan ses i figur D.6 till vänster visar julskiva-delen på ett tidigt stadie. Tabellen med låtnamn är klickbar och när någon låt spelas så visas en ikon att just den låten spelas.
Splash screen
Splash screen är den första bilden som visas under laddningstiden när applika-tionen startas. Detta är öppningen av programmet och ett utmärkt tillfälle att på ett bra sätt välkomna användaren till applikationen. Ett koncept för var att ha liknade ett paketpapper som var förseglat med ett lacksigill se i figur D.6 till höger. När applikationen har laddat färdigt knäcks lacksigill och huvudmenyn visas.
Julkort
Konceptet med att ha julkort som en del av applikationen kan ses i figur D.7 till vänset. Tanken är att man skriver in sitt namn i julkortet och därefter kan man skicka detta julkort till den man önskar via MMS eller epost. Detta koncept har även tagit med Childhood foundation för att visa hur man kan integrera detta i applikationen.
Att ha med ett spel i applikationen var även det ett koncept som satte prägel på applikationen. Tanken här är nämligen att man skall ordna de olika bitarna av pusslet i rätt ordning, när spelet startas kommer alla delar huller om buller och det gäller att ordna dessa i den korrekta ordningen där bilden som ses i figur D.7 till höger visas.
4Childhood grundades 1999 av H.M. Drottning Silvia.Syftet är att arbeta för barns rätt
5.3.4
Interaktiva prototyper
Interaktiva prototyper är en vidareutveckling av Mockups. De är mer utveck-lade versioner med vilka man kan interagera för att få en bättre känsla av konceptet. Ofta skapar man interaktiva prototyper i något enkelt och snabbt programspråk för att spara tid, men i detta fall utvecklades dessa i den riktiga miljön. Varför prototyperna utvecklades i X-Code har sin förklaring i ett ut-bildningssyfte. Dessa prototyper fyllde också funktionen att undersöka vad som kunde implementeras och vilka koncept som inte skulle vara möjliga att genom-föra. Eftersom en stor mängd med Mockups producerades sållades många av dem bort efter utvärdering, de som fortfarande var intressanta utvecklades till interaktiva prototyper. Detta gjordes för att få en tidig användartestning och lättare kunna bedöma riskerna med just den lösningen.
För att få en bra bild av hur det skulle fungera med att snurra på en julkula som interaktionsverktyg var det viktigt att göra en interaktiv prototyp av detta, se i figur D.2 till höger. Tidigt fattades beslutet om att gå vidare med att ha en tredimensionell julkula som roterade i applikationen skulle bli allt för tidskrävande. Därför implementerades den tvådimensionella varianten som kan ses i figur D.1 till vänster. Denna typ av interaktion blev ett av många alternativ till menyn.
Ett annat menykoncept som implementerades var att ha juletiketter som alla symboliserade en del av applikationen. Dessa juletiketter roterar i en tänkt cirkel där endast en etikett visas fullt och en etikett på vardera sida ses halvt av användaren, se figur D.9. Koncept är oberoende av hur många delar av applikationen som implementeras vilket kan ses som en fördel. När man trycker på en av etiketterna kommer detta leda till att den delen av applikationen visas. Att kunna presentera många recept i kombination med att användaren en-kelt skall få en snabb bild av de olika recepten var en stor utmaning. Ett förslag var att när användaren vrider telefonen 90◦ skulle det visas bilder på recepten, med denna lösning gick det även att scrolla fram och tillbaka mellan de olika recepten se figur D.8.
