Uppgångsappen
– En rapport om utvecklingen av en mobilapplikation.
Uppgångsappen
– A report on development of a mobile application.
Södertörns högskola | Institutionen för kommunikation, medier och IT Kandidatuppsats 15 hp | Medieteknik | Vårterminen 2012
Programmet för IT, medier och design
Av: Jessica Cederberg och Josefin Sjöström
Handledare: Mats Nilsson och Ulf Larsson
Sammanfattning
Denna rapport redovisar för utvecklingen av mobilapplikationen Uppgångsappen.
Applikationen, som har utvecklats för iPhone, skapades för att kunna ges ut av företaget Approdites AB. För utvecklingen har Apples riktlinjer följts både för design och
programmering, och fokus har legat på att utveckla en applikation som uppfyller Apples krav för att bli godkänd i App Store. Programmeringsspråket Objective-‐C har använts tillsammans med utvecklingsmiljön xCode. Designbeslut har grundats på
designprinciper och målet har framför allt varit att utveckla en applikation som ska vara lätt att använda och ha en estetiskt tilltalande grafisk design. Resultatet av denna
rapport blev en färdig mobilapplikation som var förberedd för lansering i App Store.
Nyckelord
Applikation, app, applikationsutveckling, iPhone, interaktionsdesign, grafisk design
Abstract
This report describes the development of the mobile application Uppgångsappen. The application was developed for iPhone and created by the company Approdites AB. The development has followed Apple’s guidelines for both design and programming, and the focus has been on developing an application that comply Apples requirements to be approved in the App Store. The programming language Objective-‐C has been used in combination with the development environment XCode. Design decisions have been based on different design principles and the primarily goal has been to develop an application that should be easy to use and have an aesthetically attractive graphic design. The result of this report was a completed application that was prepared for launch in the App Store.
Keywords
Mobile application, app, application development, iPhone, interaction design, graphic design
Begreppsdefinition
Nedan följer en definition på de begrepp som används i denna uppsats.
Apple
Apple grundades av Steve Jobs 1976 och är idag ett ledande företag inom dator-‐ och hemelektronik. År 2008 lanserade Apple iPhone, en smartphone med tillgång till mobilapplikationer. Apple tillhandahåller riktlinjer vid skapande av applikationer för iPhone.
App Store
App Store ä en avdelning inom iTunes varifrån man kan ladda ner Apples applikationer till sin enhet, till exempel iPhone och iPad.
Designmönster
Designmönster är vanligt förekommande i programmering och kan beskrivas som en problemidentifieringsteknik. Det handlar om att skapa en lösningsbeskrivning på ett visst problem genom att man kategoriserar typiska problem och dess lösningar.
iOS
iOS är Operativsystemet i Apples mobila enheter. Den senaste versionen heter iOS5, vilket är den som använts till projektet och som denna rapport utgått ifrån.
Mobilapplikation
Ett litet tillämpningsprogram för en mobil enhet, till exempel mobiltelefonen. I rapporten benämner vi även ordet mobilapplikation som applikation.
Multi touch
Multi touch innebär att en pekskärms yta känner av beröring på flera olika punkter samtidigt. Ett exempel är att man kan använda två fingrar till att zooma eller skrolla.
Objektorienterad programmering
Objektorienterad programmering är en programmeringsmetod där programmet
innehållet objekt som interagerar med varandra.
Objekt
Ett objekt är en simulering av en företeelse som används inom objektorienterad programmering, vilken samlar data och kod som hör ihop. Ett program innehåller flera objekt som interagerar och kommunicerar med varandra.
Smartphone
En smartphone är en blandning mellan en handdator och en mobiltelefon, och har möjlighet att använda mobilapplikationer. iPhone är den smartphone som nämns mest i rapporten.
SQL
SQL står för Structured Query Language och är ett standardiserat språk för att modifiera data i en relationsdatabas. SQL-‐frågor är de frågor som ställs till databasen för att få
fram önskad information.
Innehållsförteckning
1. Inledning ... 8
1.1. Bakgrund ... 9
1.2. Syfte/Mål ... 9
1.3. Disposition ... 9
1.4. Avgränsning ... 10
2. Teoretisk bakgrund ... 10
2.1. Design av interaktiva system ... 11
2.2. Design av mobilapplikationer ... 11
2.3. Apples riktlinjer ... 14
2.4. Designprinciper ... 17
2.5. PACT-‐analys ... 18
2.6. Prototyper ... 20
3. Planering ... 20
3.1. PACT-‐analys ... 21
3.2. Tidsplan ... 22
4. Genomförande ... 23
4.1. Initierande fas ... 23
4.2. Designfasen ... 24
4.3. Funktioner ... 28
4.4. Programmeringsfasen ... 29
4.5. Metodkritik ... 31
5. Resultat ... 31
5.1. Enkät ... 31
5.2. Analys av data ... 32
5.3. Användartester ... 33
5.4. Applikationen ... 34
6. Analys ... 36
7. Källförteckning ... 38
7.1. Elektroniska Källor ... 38
7.2. Litteratur ... 39
7.3. Video ... 39
8. Bilagor ... 40
8.1. Bilaga 1 – WBS ... 40
8.2. Bilaga 2 – Pert ... 41
8.3. Bilaga 3 – Enkät ... 42
8.4. Bilaga 4 – Lo-‐fi-‐prototyp ... 46
8.5. Bilaga 5 – Grafisk manual ... 47
8.6. Bilaga 6 – Hi-‐fi-‐prototyp ... 48
8.7. Bilaga 7 – Frågor till användartester ... 50
8.8. Bilaga 8 – Funktionsspecifikation ... 51
1. Inledning
Den 29 juni 2007 lanserades en iPhone för första gången. Denna kallades för den första generationens iPhone. Steve Jobs hade i januari 2007 avslöjat planerna på den första iPhone och han hade beskrivit den som en revolutionär och magisk produkt som bokstavligen är fem år före alla andra mobiltelefoner.
1 iPhone nådde enormaförsäljningssiffror och har sedan dominerat mobilmarknaden. Andra tillverkare har inspirerats av iPhones design, funktioner och affärsmodell, vilket har förändrat hela mobilmarknaden.
2Den 10 juli 2008 startade Apples App Store och den innehöll då 500 applikationer.
Redan i januari 2009 hade 500 miljoner applikationer laddats ner från App Store och Android Market hade öppnats för att konkurrera med App Store.
3I skrivande stund (april 2012) hade man bara i Sverige laddat ned över 205 miljoner applikationer för iPhone sedan App Stores öppnades.
4Applikationer för smartphones har blivit allt mer populärt. Därför behandlar detta examensarbete den designmässiga och tekniska process som krävs för att utveckla en applikation för iPhone. Vi som har skrivit denna rapport har utvecklat en idé för en applikation, vilken vi valde att knyta till vårt företag Approdites AB. Applikationen beräknades bli en färdig produkt som skulle gå att ladda ned ifrån App Store.
Under arbetsprocessen har vi valt att kalla applikationen för Uppgångsappen och den syftar till att hjälpa och guida användare för att hitta rätt uppgång på Stockholms tunnelbanestationer. Applikationen innehåller information om tunnelbanestationer och presenterar för en resenär vilka uppgångar som finns för respektive station, samt information om denne ska sitta långt fram eller bak i tåget för att på snabbast möjliga sätt ta sig till önskad uppgång.
1 ITPRO, 2009, Timeline: A short story of the Apple iPhone
2 Business Insider, 2011, HISTORY LESSON: How the iPhone changed Smartphones Forever
3
Read Write Web, 2012, [Infographic] History of Mobile App Stores
4 Xyologic, 2012, App Download Reports: Sweden April 2012
1.1. Bakgrund
Approdites AB är ett företag som startades i december 2011. Två av parterna i företaget är författarna till denna rapport, Jessica Cederberg och Josefin Sjöström, varav den tredje är Juliana Moreira.
Approdites främsta affärsområde är att utveckla applikationer för iPhone. Företaget utvecklar applikationer till privatpersoner och företag, men det förekommer även egna idéutvecklingar inom företaget. Approdites utvecklar webblösningar och lägger stor fokus på publiceringsverktyget Wordpress. Företaget designar logotyper,
användargränssnitt och annat grafiskt material.
Approdites har tidigare lanserat en applikation på App Store. Därför har vi sedan tidigare vissa kunskaper i hur applikationsutvecklingen går till. Vi har grundläggande kunskaper i hur genomförandet ska organiseras för att så smidigt och strukturerat som möjligt kunna ge ut även denna applikation. Denna applikation skiljer sig dock ifrån den tidigare, vilket gör att ytterligare kunskaper krävs för att kunna genomföra projektet.
1.2. Syfte/Mål
Syftet med detta examensarbete var att skapa en användbar applikation för iPhone. Den designades och kodades från grunden och vi ville skaffa oss en klar helhetsbild över processen för att skapa en applikation från idé till lansering.
Målet var att tillämpa existerande designprinciper och även anpassa
interaktionsdesignen och den grafiska designen efter Apples riktlinjer. Applikationen skulle också anpassas efter den mobilmarknad som finns i Sverige idag och utveckla en modern, lättanvänd och betydelsefull applikation.
Syftet med rapporten är att beskriva utvecklingsprocessen av applikationen som produceras.
1.3. Disposition
Rapportens första kapitel Inledning förklarar syftet med projektet, samt ger en
bakgrund till varför det har valts att göra en applikation för iPhone. Projektets
avgränsningar tas även upp i detta kapitel. Därefter följer en genomgång av Teoretisk
bakgrund i kapitel 2 som behandlar designprinciper, Apples riktlinjer och vad man ska
tänka på i designen av en mobilapplikation. I kapitel 3, Planering, redogörs för
planeringsdelen av projektet där vi tagit hjälp av olika metoder för att strukturera bland annat tidsplanen. I kapitel 4, Genomförande, beskrivs arbetsgångens olika faser, vilken inleds med den Initierande fasen för att sedan gå vidare till Designfasen och
Programmeringsfasen. Slutligen följer kapitel 5, Resultat, där projektets resultat presenteras, samt det sjätte och avslutande kapitlet Analys med reflektioner kring arbetet.
1.4. Avgränsning
Applikationen utvecklades för iPhone, vilket betyder att vi inte varken anpassade design eller programmering för andra plattformar, som till exempel Android och Windows Phone. Därmed undersöktes inte heller information och teorier gällande övriga plattformar.
Målet var till en början att skapa en applikation som innehöll alla funktioner och designelement vi önskade, men vi var väl medvetna om att vi kunde komma att behöva göra justeringar när det var dags att programmera. Detta för att programmeringen inte skulle bli allt för avancerad och ta fokus från andra delar av examensarbetet.
Vi valde att själva samla de data som behövdes för applikationen, vilket innebar att den första versionen av applikationen hade en begränsad mängd data.
Vi valde att enbart utforma statiska prototyper. Detta eftersom vi uppskattade att en interaktiv prototyp inte skulle tillföra tillräckligt mycket till resultatet och att det skulle ta mycket tid ifrån den slutgiltiga programmeringen.
Applikationen programmerades och förbereddes för att skickas till App Store, men i detta examensarbete ingick inte processen för uppladdning på App Store. Detta
eftersom att Apple har strikta riktlinjer och en lång handläggningstid, vilket vi inte ville skulle påverka denna rapport.
2. Teoretisk bakgrund
I detta kapitel följer teorier som tillämpats i arbetet med Uppgångsappen. En
redogörelse över hur man designar interaktiva system och mobilapplikationer görs,
samtidigt som olika designprinciper tas upp. En förklaring av PACT-‐analys samt lo-‐fi-‐
och hi-‐fi-‐prototyper ges.
2.1. Design av interaktiva system
Att designa interaktiva system handlar om att utveckla högkvalitativa system och produkter som är anpassade efter människan och dennes sätt att leva. Datorer och kommunikation är inbäddade i människors vardag och vi bär idag med oss teknik som är mer kraftfull än de datorer som fanns för bara några år sedan. Interaktiv design handlar om all denna teknik och man inriktar sig på att designa för hela miljöer. Att designa interaktiva system handlar även om att designa interaktionen mellan
människan och systemet. Människan ligger i centrum och den interaktiva upplevelsen måste därför fokuseras på denne. Ett interaktivt system är till för att hjälpa eller
underhålla en människa. När man designar ett interaktivt system bör man tänka på vad människan vill ha snarare än vad tekniken klarar av att göra. Man bör hitta nya sätt att få kontakt med människor och involvera människor i designprocessen.
5En interaktionsdesigner förväntas besitta egenskaper som att studera och förstå människors aktiviteter och i vilket sammanhang tekniken kan vara användbar. Denne bör också veta vilka möjligheter som finns med tekniken, utvärdera alternativa
designerlösningar och iterera igenom designprocessen tills dess att en lösning har tagits fram.
62.2. Design av mobilapplikationer
Enligt Trani finns det fem områden man ska tänka på när man designar för mobila enheter. Dessa områden är miljö, kontext, inmatningsmetoder, förmågor och metaforer.
Han nämner att det är väldigt viktigt att tänka på i vilken miljö användaren befinner sig när den interagerar med applikationen. Om man har designat ett gränssnitt som ser bra ut när man utvecklar appen betyder det inte att det kommer att fungera bra för den som ska använda den. Om användaren använder sin mobiltelefon i solljus uppstår det blänk och om man inte har designat för denna typ av miljö kan applikationen bli oanvändbar.
75 Benyon, Turner & Turner, Designing interactive systems, pp. 5-‐14 (2005)
6 Benyon, Turner & Turner, Designing interactive systems, p. 21 (2005)
7 Trani, 2012, Building Mobile Apps for Multiole Devices with Flash Professional
Figur 1. Ett exempel på hur blänk på skärmen kan påverka användarupplevelsen.
Vidare hävdar Trani att man ska tänka på vad användaren gör när denne använder applikationen. En applikation bör vara utformad för att den ska vara så pass lättanvänd att användaren kan starta applikationen och utföra det den ska inom loppet av några sekunder. Det ska även gå lika snabbt att stänga ned applikationen när användaren är färdig med sitt ändamål. Den ska också kunna hantera vad som händer om användandet avbryts av att till exempel telefonen ringer eller att användaren blir avbruten i den fysiska miljön.
Utöver detta är det viktigt att tänka på hur användaren håller sin smartphone när den använder applikationen. Beroende på om den används liggande eller stående bör man utforma knappar och andra designelement på olika sätt. Om applikationen finns tillgänglig för en surfplatta (exempelvis iPad) är det viktigt att tänka på att användaren kan hålla även denna på ett annat sätt.
Figur 2. Exempel på hur användaren kan hålla en surfplatta, respektive en smartphone.
Att designa för mobila enheter skiljer sig från att designa för webben. Ett exempel är att ett finger är betydligt mycket större än en muspekare. Därför måste man alltid tänka på att knappar bör vara tre gånger så stora som de är på webben. Detta innebär att
knappar bör vara minst 45 x 45 px stora. Placering av knappar är också viktigt att tänka på. För att designen ska bli användaranpassad krävs det att fingret inte skymmer det som händer på skärmen om man trycker på en knapp.
När det handlar om den mobila enhetens förmågor finns det många olika aspekter att ta hänsyn till. Inbyggda funktioner som till exempel Multi touch gör att man ibland kan ta bort knappar helt medan accelerometern gör att applikationen kan reagera på
skakningar eller att användaren vrider på telefonen. Andra funktioner är GPS, mikrofon, kamera och tangentbord. Alla dessa funktioner går att använda i en mobilapplikation, vilket kan förbättra användarupplevelsen.
Figur 3. Exempel på placering av knappar i en applikation. Om användaren drar i reglaget på den vänstra bilden kommer fingret att skymma det som finns nedanför, vilket inte kommer att ske i den högra bilden.
Det är, enligt Trani, mycket viktigt att tänka på att en mobil enhet har begränsningar om man jämför med en dator. Dagens smartphones beräknas ha samma kraft som en åtta år gammal dator. Skärmen är endast en tredjedel av en datorskärm och båda dessa
aspekter medför stora begränsningar. Även bandbredd och tillförlitligheten i enhetens Internetuppkoppling kan påverka användandet.
Slutligen nämner Trani att man bör jobba efter metaforer när man designar för mobila
enheter. Knappar med exempelvis plustecken, pilar eller en kalender känns igen av
användaren och gör att de förstår vad knappen betyder. Man bör tänka på vilka saker man använder i sin vardag och hämta inspiration till det man ska designa.
2.3. Apples riktlinjer
Apple tillhandahåller användarguider där de förespråkar metoder för den grafiska designen och till viss del även interaktionsdesignen. Det finns även riktlinjer för programmeringen.
2.3.1. Riktlinjer för grafisk design
Apple förespråkar att man utseendemässigt designar sina applikationer så att de liknar iOS-‐baserad utrustning. Detta eftersom att de hävdar att användarna har höga krav gällande utseendet på applikationer som de laddar ner och därför även vill att utseendet ska skilja sig åt från andra medier som till exempel webben. Användaren förväntar sig att de applikationer som laddas ner från App Store fungerar på liknande sätt.
Apple förespråkar exempelvis att delar som går att trycka på ska se klickbara ut, så att användaren förstår vad som händer och hur det fungerar. Överlag ska strukturen i applikationen vara lätt att navigera, gärna genom att man grupperar ihop olika funktionaliteter så att de blir lätta att tyda. Till hjälp finns navigationsbarerna som Apple förespråkar att man använder. Navigationsbaren visar titeln på applikationen som för stunden används och innehåller ofta en bakåtknapp.
Figur 4. En navigationbar
Längst ner i en applikation förespråkas att man har en menybar (eng. Tab bar). Den innehåller olika ikoner och ger användaren möjlighet att förflytta sig mellan olika vyer i applikationen. Även för ikonerna som befinner sig i menybaren finns det riktlinjer som det rekommenderas att man följer, exempelvis är ett förstoringsglas rekommenderat för Sök och en stjärna för Favoriter. Det går även att designa sina egna ikoner för en
applikation, men de ska inte vara enbart dekorativa utan också spela en viktig roll gällande kommunikationen med användaren.
88
Apple Developer, 2012, iOS Human Interface Guidlines, p. 20
Figur 5. En menybar
Alla mobilapplikationer som finns på App Store kräver en så kallad applikationsikon.
Det är den ikonen som man ser på App Store och som efter nerladdning syns på telefonens hemskärm. När man klickar på ikonen startas applikationen. Apple rekommenderar en stark visuell design för att skapa ett kompakt, igenkännligt och attraktivt paket. Vid uppladdningen på App Store lägger Apple in rundade hörn, en drop shadow (en skugga under applikationen) samt en blänk.
9Figur 6. Ett exempel på en ikon, en ikon med en bakgrund, samt hur den slutgiltiga ikonen ser ut då Apple applicerat effekter på den.
2.3.2. Riktlinjer för programmering
För att programmera en app för iPhone krävs det att man förstår vilka designval man kommer att behöva göra och hur dessa val kartläggs i en implementation. En applikation som programmeras för iPhone är beroende av designmönster, vilka påverkar koden man måste skriva. De viktigaste designmönstren för en applikation är Model-‐view-‐
controller, Delegation och Target-‐action.
109
Apple Developer, 2012, iOS Human Interface Guidlines, p. 166
10
Apple Developer, 2012, iOS App Programming Guide, p. 14
Model-‐View-‐Controller (MVC) är ett designmönster där objekt i en applikation klassificeras antingen som en modell (eng. model), en vy (eng. view) eller en kontroll (eng. controller). Designmönstret definierar hur objekten kommunicerar med varandra och varje typ av objekt separeras från andra typer. Modellobjekt kapslar in
applikationsspecifik data och innefattar logik och beräkningar som manipulerar och behandlar data. Vyobjekt är de objekt i applikationen som användaren kan se. Dessa objekt vet hur det ska ritas ut och besvara interaktioner från användaren. Vyobjekt visar data som kommer från applikationens modellobjekt och gör det möjligt att redigera dessa data. Kontrollobjekt fungerar som en mellanhand mellan en eller flera av applikationens vyobjekt och mellan en eller flera modellobjekt.
Figur 7. Modell-‐, vy-‐ och kontrollobjekt och dess kommunikationsmönster.
Delegation är ett designmönster där ett objekt i en applikation beter sig på ett visst sätt till fördel eller i koordination med ett annat objekt. Det delegerande objektet håller en referens till det andra objektet (delegaten) och skickar ett meddelande till det vid rätt tillfälle. Meddelandet informerar delegaten om en händelse som det delegerande objektet utför eller kommer att utföra. Delegaten kan besvara meddelandet genom att uppdatera eller förändra sig själv eller andra objekt som finns med i applikationen. Med hjälp av delegation kan man anpassa beteendet hos flera objekt i ett centralt objekt.
Target-‐action är ett designmöster som tillhandahåller information som krävs för att skicka ett meddelande till ett objekt när en viss händelse inträffar. Händelsen som inträffar kan vara vad som helst, samtidigt som objektet som skickar eller tar emot händelsen kan vara vad som helst.
Applikationer för iPhone måste hantera telefonens minne på ett bra sätt. En iPhone har
mindre minne än en dator, vilket innebär att en applikation måste kasta bort minne som
redan används och vara försiktig med att skapa nytt minne. Detta gör att
minneshantering är viktigt att tillämpa. Det är även möjligt att använda sig av ARC (Automatic Reference Counting), vilket gör minneshanteringen automatisk.
11För iPhoneapplikationer är det viktigt att man vet om applikationen kört i förgrunden eller i bakgrunden, eftersom den måste bete sig på olika sätt beroende på hur den körs.
En applikation som är igång körs i förgrunden och om man startar en annan applikation hamnar denna istället i bakgrunden. Operativsystemet har begränsningar för vad applikationen får göra när den körs i bakgrunden och det skickar en notifikation till själva appen som informerar den om den befinner sig i förgrunden eller bakgrunden.
Apple förespråkar att en iPhoneapplikation måste ta ansvar för vad den gör när den ligger i bakgrunden. Exempel på riktlinjer är att man ska spara applikationens tillstånd innan den försätts i bakgrunden, att man ska kasta bort onödigt minne, att man inte får uppdatera vyer och att man ska rensa bort känslig information. Applikationen ska göra så lite så möjligt medan den befinner sig i bakgrunden.
12
För att en applikation ska kunna laddas upp på App Store krävs det att den innehåller de resurser som Apple kräver. Vissa inställningar måste göras i en fil som heter Info.plist samtidigt som man måste ha en ikon som ska representera applikationen på
hemskärmen. Dessutom måste applikationen innehålla en bild som visas när appen startas. Allt detta programmeras in och paketeras innan man skickar appen till App Store.
132.4. Designprinciper
Krug tar upp designprinciper som är kopplade till användandet av webbsidor. Han hävdar att en effektiv interaktionsdesign hjälper till att skapa en upplevelse där användaren inte behöver tänka då den interagerar med en produkt. Användandet ska ske automatiskt så att denne istället kan koncentrera sig på innehållet och syftet med produkten.
14Krug beskriver till stor del användningsprocesser på webbsidor och han hävdar att när en användare inte finner det den söker på en webbsida tenderar denne snart att tänka
11
Apple Developer, 2012, iOS App Programming Guide, p. 49
12
Apple Developer, 2012, iOS App Programming Guide, p. 35
13
Apple Developer, 2012, iOS App Programming Guide, p. 42
14 Krug, Don’t make me think!, p. 14 (2000)
att felet ligger hos dem själva. Användaren tappar därmed intresse och entusiasm samtidigt som denne förlorar tid, vilket inte genererar en användarvänlig upplevelse.
För att undvika detta krävs webbsidor som är självförklarande där användaren inte behöver tänka för att ta sig dit den vill.
15Vidare hävdar Krug att varje webbsida bör ha en tydlig visuell hierarki mellan sina inbördes designelementet. Element med högre hierarki bör exempelvis visas tydligare, fetare eller högre upp på sidan. De kan även utmärka sig från de elementen med lägre rang på andra sätt. Genom att exempelvis gruppera olika element till varandra får användaren lättare en uppfattning över dispositionen. När en gruppering inte finns tar denna process längre tid och fördröjer intrycket av sidans organisation och uppbyggnad.
Något av det man gör mest på webben är, enligt Krug, att leta efter nästa ställe att klicka på. Därför bör det inte heller vara någon svårighet att hitta och tyda var man ska klicka för att ta sig vidare. Dessa ställen bör utmärka sig på sidan exempelvis genom färgad text. Om det visar sig då att även annan text är färgad försvinner effekten av den klickbara länken. Därför bör saker se ut som de verkar och fungera som användaren förutsätter att de ska göra.
162.5. PACT-analys
När man designar interaktiva system är det viktigt att människans behov alltid tillgodoses. Därför använder man ofta modellen PACT när man ska analysera en
designsituation. PACT står för människor(eng. People), aktivitet (eng. Activityı), kontext (eng. Contextı) och teknologi (eng. Technologies).
172.5.1. People
När man designar ett system måste man ta hänsyn till de människor som kommer att använda det. Människor har olika förutsättningar, både fysiskt och psykologiskt.
Benyon, Turner & Turner hävdar att syn, hörsel, känsel, lukt och smak är faktorer som kan ha betydelse för hur tillgängligt, användbart och underhållande ett system är för olika personer. När det gäller pekskärmar har användare förhållandevis stora fingrar om man jämför med hur pass liten en knapp går att göra.
15
Krug, Don’t make me think!, p. 19 (2000)
16
Krug, Don’t make me think!, pp. 31-‐37 (2000)
17
Benyon, Turner & Turner, Designing interactive systems, pp. 29-‐37 (2005)
När det gäller psykologiska aspekter kan människor ha olika lätt att komma ihåg saker.
Benyon, Turner & Turner anser att man ska designa för människor som har nedsatta förmågor med hjälp av tydlig skyltning och tydliga instruktioner. Även språkliga och kulturella aspekter kan påverka användningen av ett system. Olika människor tolkar ord och symboler på olika sätt. Människor har också olika erfarenheter när det kommer till att använda system. En designprincip som är viktig är att designa så att det finns en igenkänningsfaktor i systemet. På så sätt kan användaren skapa mentala modeller av hur systemet fungerar, vilket underlättar användandet.
2.5.2. Activity
Vidare hävdar Benyon, Turner & Turner finns en mängd olika aktiviteter som en designer måste tänka på då en design av ett interaktivt system tas fram. Aktiviteterna i ett system måste utformas efter de människor som kommer att använda det. En aktivitet kan äga rum varje dag eller bara någon gång per år. Den kan även äga rum under
tidspress samtidigt som den vid vilket tillfälle som helst kan bli avbruten. Därför är det viktigt att definiera vilka aktiviteter som är viktiga för användaren av det interaktiva systemet.
2.5.3. Context
Aktiviteten kan ske i olika miljöer, exempelvis en fysisk miljö som antingen är väldigt högljudd, kall, varm eller fuktig. Den sociala kontexten där aktiviteten sker är också viktig, vilket handlar om vilka människor som finns i närheten när användaren
interagerar med systemet. En kontext kan även vara organisatoriskt, vilket handlar om säkerhet och vem som har tillgång till systemet.
2.5.4. Technologies
Interaktiva system består av både hårdvara och mjukvara, samt in-‐ och utgående data.
Hur användaren matar in data i systemet kan skilja sig åt. Det kan handla om
streckkoder, pekskärmar eller att till exempel tala in data. Utgående data kan vara foton, ljud, video eller text. Det interaktiva systemet kan se annorlunda ut beroende på vilken typ av data som ska hanteras. Dessutom bör man ta hänsyn till aspekten för hur
användaren kommunicerar med systemet. Även bandbredd och hastighet har en stor
betydelse för hur användandet kommer att se ut. Det är viktigt att systemet ger respons
till användaren så att denne förstår vad det är som händer. Teknologi handlar även om
vilken form data som presenteras för användaren har. (Benyon ss. 36-‐37)
2.6. Prototyper
En prototyp är en konkret representation eller del av en implementation för ett system.
Den kan vara till för att demonstrera ett koncept i en tidig designfas, för att testa detaljer eller för en specifikation av en färdig produkt. Benyon, Turner & Turner nämner att det finns olika sätt att göra prototyper på, men att kännetecknet brukar vara att den är interaktiv. Den ska visa att något händer när användaren trycker på en knapp även fast det i realiteten kan betyda att denna knapp är ritad på en bit papper.
182.6.1. Lo-fi-prototyp
Lo-‐fi-‐prototyper kan, enligt Benyon, Turner & Turner, ofta benämnas som
pappersprototyper, eftersom de ofta ritas för hand på fysiskt papper. De fokuseras till breda designidéer som till exempel innehåll, utformande och struktur. Produktens nyckelfunktioner finns med och en lo-‐fi-‐prototyp går alltid snabbt att producera så att de snabbt kan kastas bort och göras om ifall det skulle behövas. De presenterar en tidig design och testas på användare för att man ska kunna avgöra vad som kräver
korrigering inför den slutgiltiga designen.
2.6.2. Hi-fi-prototyp
Hi-‐fi-‐prototyper liknar den färdiga produkten i känsla och utseende. En hi-‐fi-‐prototyp beskrivs av Benyon, Turner & Turner följande egenskaper:
• Den är användbar för detaljerad utvärdering av de huvudsakliga designelementen
• Den utgör ofta ett avgörande steg när man designar för en kund, vilket betyder att den fungerar som ett slutgiltigt designdokument för den färdiga
implementationen
• Den skapas ofta en bit in i projektet när idéer börjar fastställas
3. Planering
I detta kapitel redogör vi för den fas som ägde rum innan vi började genomföra projektet. Detta var planeringsfasen där vi gjorde en PACT-‐analys och en tidsplan.
18
Benyon, Turner & Turner, Designing interactive systems, pp. 254-‐256 (2005)
3.1. PACT-analys
I projektets initierande fas skapades en PACT-‐analys, enligt den modell som Benyon, Turner & Turner beskriver. I designen och planeringen av applikationen tåg vi hänsyn till denna analys.
3.1.1. People
Vi identifierade olika typer av potentiella användare för Uppgångsappen. Målgruppen är främst människor som bor i Stockholm och åker med kollektivtrafiken. De som bott i Stockholm länge och är vana med de olika stationerna har inte lika stort behov av att använda applikationen, utan det är de oerfarna tunnelbaneresenärerna som har störst behov av denna.
En annan målgrupp är turister som sällan befinner sig i Stockholm, men som ändå har ett behov av att planera sin resa och veta vilka uppgångar som finns på en viss
tunnelbanestation i förväg.
I båda målgrupperna finns det personer som anser att det är viktigt att sitta i rätt del av tåget så att de snabbt kan ta sig till önskad uppgång när de kommer fram till
tunnelbanestationen.
Människorna som använder denna applikation är vana att använda olika typer av applikationer för iPhone. De är därför väl införstådda med hur applikationer brukar fungera och vad de typiska designelementen i iPhoneapplikationer innebär. De har höga krav på att användandet ska gå lätt och smidigt. Applikationen ska gå att starta snabbt och de ska på bara några få tryckningar komma åt den information de för tillfället är ute efter.
3.1.2. Activities
För Uppgångsappen identifierade vi tre huvudaktiviteter som är relevanta för målgruppen. Vi valde att fokusera på dessa tre huvudfunktioner i applikationen:
• Att se vilka uppgångar som finns vid en tunnelbanestation, samt i vilken del av tåget man ska sitta i för att komma till rätt uppgång
• Att kunna identifiera närmaste tunnelbanestation och hitta dit
• Att kunna se tunnelbanans linjekarta
3.1.3. Context
Applikationens målgrupp använder applikationen i miljöer då de är mer eller mindre stressade. Det är mycket troligt att de befinner sig i tunnelbanan när de använder applikationen, men de kan också vara i närheten av en tunnelbanestation och vilja planera sin resa i förväg. De turister som använder applikationen kan vara förvirrade och vilse, eftersom de befinner sig i en stad som de inte är vana att lokalisera sig i.
3.1.4. Techonolgy
Eftersom applikationen till en början bara skulle komma att utvecklas för iPhone kommer samtliga användare att använda applikationen i iOS. Däremot kan de befinna sig på olika platser där mottagningen för 3G är av olika styrka och kvalitet. Detta gäller i synnerhet eftersom att de befinner sig i tunnelbanan där mottagningen ibland kan vara mycket dålig. Människorna som använder applikationen har olika operatörer, vilket kan betyda att de surfar med olika hastighet eller att de har en begränsning för hur mycket data de får använda varje månad. Därför är det viktigt att applikationen fungerar även i nedkopplat läge.
3.2. Tidsplan
Tidsplanen för projektet bestod av en WBS och ett PERT-‐diagram.
3.2.1. WBS
WBS står för Work Breakdown Structure och identifierar, enligt Hydén, projektets alla aktiviteter. Genom att bryta ner aktiviteterna i mindre delar får man en större förståelse över vad som verkligen ska göras, vilket gör det lättare att visualisera målet. Vi skapade en WBS (se bilaga 1) i vilken det finns tre huvudområden: designdelen,
programmeringsdelen och rapportdelen. Inom dessa huvudområden kategoriseras alla underaktiviteter i projektet enligt det sätt som Hydén beskriver.
193.2.2. PERT-diagram
För att planera projektets tidsåtgång skapades ett PERT-‐diagram (se Bilaga 2). PERT står för Program Evaluation and Review Technique och Hydén beskriver att de
representerar de olika aktiviteterna i förhållande till varandra, uppställda i ett grafiskt schema. I schemat ser man tydligt vilka aktiviteter som är beroende av varandra och i vilken ordning dessa ska utföras.
19
Hyden, KAMP – En projektmodell pp. 34-‐41 (2009)
4. Genomförande
I detta kapitel beskrivs hur vi genomförde projektet med Uppgångsappen. Projektet började med en initierande fas där idén fastställdes och en enkät skickades ut. Därefter beskrivs hur designfasen tog vid, vilka funktioner som fastställdes för applikationen och hur programmeringsfasen gick till.
4.1. Initierande fas
I den initierande fasen fastställdes idén. En undersökning på vad potentiella användare ansåg om idén och de tänkta funktionerna gjordes med en enkät. En tidsplan
upprättades för att strukturera projektet.
4.1.1. Fastställande av idé
I den initierande fasen beslutade vi oss för vilken typ av applikation vi skulle utveckla. Vi undersökte vilken typ av data vi skulle behöva använda för att genomföra applikationen.
Vi gjorde en kort analys av hur många tunnelbanestationer som skulle behöva finnas med i applikationen samt hur stor mängd data detta skulle innebära.
4.1.2. Enkät
Enligt Benyon, Turner & Turner handlar designen av ett interaktivt system om att tänka på vad människan vill ha. Vi valde därför att göra en enkät där vi undersökte vad
potentiella användare har för åsikter och önskemål om vår tänka applikation. Vi ville kontrollera om idén för Uppgångsappen var hållbar, samt få åsikter om hur
intäktsmodellen skulle kunna se ut.
Enkäten (se bilaga 3) publicerades online och vi valde att skicka enkätens URL till en utvald grupp personer tillsammans med en förfrågan om de kunde ställa upp på en enkätundersökning. Eftersom marknaden för applikationer är oförutsägbar och för att den förändras snabbt valde vi att hålla vår idé hemlig. Detta gjorde att vi bara kunde skicka enkäten till personer i vår familj och bekantskapskrets. Enkäten inte är tillförlitlig ur ett vetenskapligt perspektiv, men vi ansåg ändå att den var användbar för vårt arbete med Uppgångsappen.
Trots att vi valde personer ur vår bekantskapskrets försökte vi skicka enkäten både till
män och till kvinnor, personer som bor i och utanför Stockholm, samt personer i olika
åldersgrupper. Vi kunde dock inte styra vilka som svarade på enkäten. Enligt Trost
kallas denna typ av urval för bekvämlighetsurval, vilket betyder att man väljer att utför en studie på de respondenter som är mest lättillgängliga.
20Trost hävdar att sakfrågor är frågor som undersöker faktiska förhållanden och där respondenterna inte ska ange vad deras åsikter eller attityder är.
21Vi valde att inleda enkäten med sakfrågor som undersökte vilka respondenterna var och vilka vanor de har gällande tunnelbanetrafiken. Vi gav även en beskrivning av hur den tänkta
applikationen skulle fungera, följt av attitydfrågor som undersökte vad de hade för inställning till applikationen.
Trost beskriver att man ska göra en kvalitativ studie om man vill förstå människors sätt att resonera. Om man däremot vill kunna ange frekvenser och till exempel säga att ett visst antal procent av befolkningen gör på ett visst sätt ska man göra en kvantitativ studie.
22Vår enkät var en blandning mellan en kvalitativ och en kvantitativ studie.
Frågorna som ställdes var till stor del kvalitativa, trots att en enkät kan anses som en metod för att göra en kvantitativ studie.
Vi valde att använda oss av kvantitativa frågor för att få fram vilken typ av personer som svarat på enkäten, vilka vanor de har när de handlar om att åka tunnelbana, samt om de anser sig vilja använda vår applikation. Vi använde oss av kvalitativa frågor för att ta reda på vad respondenterna ansåg om betalda applikationer, samt applikationer med annonser i. Kvalitativa frågor användes även för att ta reda på vilka funktioner som skulle vara viktiga för respondenterna. Detta för att vi skulle kunna få snabba och konkreta tips på funktioner till applikationen. Eftersom vi skickade enkäten till en liten mängd personer kunde vi utan problem behandla de kvalitativa svar som gavs.
4.2. Designfasen
Designfasen i projektet krävde omfattande planering och analyser och vi kommer nedan att beskriva vilka designval vi gjorde och varför vi valde att ta fram en grafisk manual.
En redogörelse för de lo-‐fi-‐ och hi-‐fi-‐prototyper som togs fram görs. Slutligen beskrivs hur användartester gjordes för dessa prototyper.
20 Trost, Enkätboken, p. 31 (2007)
21
Trost, Enkätboken, p. 67 (2007)
22
