Uppgångsappen. En rapport om utvecklingen av en. mobilapplikation. Uppgångsappen. A report on development of a mobile

Transkript

1 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 Uppgångsappen En rapport om utvecklingen av en mobilapplikation. Uppgångsappen A report on development of a mobile application. Av: Jessica Cederberg och Josefin Sjöström Handledare: Mats Nilsson och Ulf Larsson

2 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 2 (51)

3 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 3 (51)

4 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. 4 (51)

5 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. 5 (51)

6 Innehållsförteckning 1. Inledning Bakgrund Syfte/Mål Disposition Avgränsning Teoretisk bakgrund Design av interaktiva system Design av mobilapplikationer Apples riktlinjer Designprinciper PACT- analys Prototyper Planering PACT- analys Tidsplan Genomförande Initierande fas Designfasen Funktioner Programmeringsfasen Metodkritik Resultat Enkät Analys av data (51)

7 5.3. Användartester Applikationen Analys Källförteckning Elektroniska Källor Litteratur Video Bilagor Bilaga 1 WBS Bilaga 2 Pert Bilaga 3 Enkät Bilaga 4 Lo- fi- prototyp Bilaga 5 Grafisk manual Bilaga 6 Hi- fi- prototyp Bilaga 7 Frågor till användartester Bilaga 8 Funktionsspecifikation (51)

8 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 enorma fö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. 2 Den 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. 3 I skrivande stund (april 2012) hade man bara i Sverige laddat ned över 205 miljoner applikationer för iphone sedan App Stores öppnades. 4 Applikationer 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 (51)

9 1.1. Bakgrund Approdites AB är ett företag som startades i december 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 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 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 9 (51)

10 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 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, 10 (51)

11 samtidigt som olika designprinciper tas upp. En förklaring av PACT- analys samt lo- fi- och hi- fi- prototyper ges 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. 5 En 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 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. 7 5 Benyon, Turner & Turner, Designing interactive systems, pp (2005) 6 Benyon, Turner & Turner, Designing interactive systems, p. 21 (2005) 7 Trani, 2012, Building Mobile Apps for Multiole Devices with Flash Professional 11 (51)

12 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. 12 (51)

13 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 13 (51)

14 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 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 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. 8 8 Apple Developer, 2012, ios Human Interface Guidlines, p (51)

15 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. 9 Figur 6. Ett exempel på en ikon, en ikon med en bakgrund, samt hur den slutgiltiga ikonen ser ut då Apple applicerat effekter på den 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 Apple Developer, 2012, ios Human Interface Guidlines, p Apple Developer, 2012, ios App Programming Guide, p (51)

16 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 16 (51)

17 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. 11 Fö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 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. 14 Krug 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 Apple Developer, 2012, ios App Programming Guide, p Apple Developer, 2012, ios App Programming Guide, p Krug, Don t make me think!, p. 14 (2000) 17 (51)

18 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. 15 Vidare 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 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) 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 (2000) 17 Benyon, Turner & Turner, Designing interactive systems, pp (2005) 18 (51)

19 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 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 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 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 ) 19 (51)

20 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 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 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 (2005) 20 (51)

21 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 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 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 21 (51)

22 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 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 Tidsplan Tidsplanen för projektet bestod av en WBS och ett PERT- diagram 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 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 (2009) 22 (51)

23 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 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 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 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 23 (51)

24 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. 20 Trost 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. 21 Vi 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. 22 Vå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 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 Trost, Enkätboken, p. 23 (2007) 24 (51)

25 Designval Vid utveckling av denna mobilapplikation har vi tagit hänsyn till de designprinciper som Benyon, Turner & Turner nämner. 23 Detta för att kunna använda ett så standardiserat sätt som möjligt, vilket underlättar för användaren. Med hjälp av effektiv interaktionsdesign ville vi att användaren inte ska behöva tänka vid användande av vår produkt, utan att detta skulle ske automatiskt så att denne istället kan koncentrera sig på innehållet och syftet med applikationen. Vi baserade detta tankesätt på Krugs principer som handlar om att användaren inte ska behöva tänka när den interagerar med ett system. 24 Enligt Benyon, Turner & Turner bör en interaktionsdesigner bland annat veta vilka möjligheter som finns med tekniken. Då en av oss ansvarade för designen, medan den andra ansvarade för programmeringen tyckte vi att det var viktigt att vi förstod varandras processer. Vi valde därför att ha öppna dialoger i ett tidigt skeende för att designen skulle kunna anpassas efter de tekniska förutsättningarna. I programmeringen för iphone använder man ofta standardiserade designelement och det är viktigt att designen förstår hur dessa används och implementeras för att en hållbar interaktionsdesign ska kunna skapas. Enligt Krug ska man då man designar en webbsida anpassa designen efter principen att användare inte ska behöva tänka. Webbsidor ska vara självförklarande så att användaren finner vad den söker. Trots att design för webbsidor och mobilapplikationer skiljer sig markant från varandra anser vi att Krugs principer är användbara även för mobil design. Om användare slipper tänka blir själva användandet snabbt, smidigt och tillfredsställande. Detta behövs i en mobilapplikation, vilket gjorde att vi strävade efter en interaktionsdesign som var lättförståelig och där användaren kan utföra den uppgift den vill på så få klick som möjligt. Krug beskriver hur element grupperas och skiljs ut på webbsidor, vilket även är implementerbart i en applikation. Apples designelement innehåller grupperade menyrader, listor och navigationsbarer. Designer i iphoneapplikationer kännetecknas av en tydlig struktur där varje element har sin plats och sin funktion. Dessa principer tillgodosågs då vi designade Uppgångsappen. 23 Benyon, Turner & Turner, Designing interactive systems (2005) 24 Krug, Don t make me think! (2000) 25 (51)

26 Enligt Trani skiljer det sig att designa för en mobil enhet i jämförelse med att designa för webben. Vi var medvetna om att det är väldigt lätt att man tänker på webben när man ska designa en applikation, vilket vi i största möjliga mån försökte undvika. För att få rätt känsla studerade vi andra iphoneapplikationer och inspirerades av ikoner, färger, placering av designelement och presentation av innehåll. Trani nämner fördelar med att använda metaforer då man designar en mobilapplikation. Vi försökte implementera detta tankesätt genom att skapa ikoner som fungerade som metaforer. Applikationens huvudikon innehåller en bild på en figur som står i en rulltrappa, vilket vi anser ger kopplingar till att man åker upp ur tunnelbanan. De ikoner som förekommer inbördes i applikationen är ett tåg för Stationer, en vägskylt för Nära mig och en linje med punkter på för Linjer. Tanken med detta var att användarna ska känna igen dessa symboler som även kan förekomma i tunnelbanan. Även i listan för linjer försökte vi använda knappar som påminner om skyltar som kan förekomma på tåg- eller tunnelbanestationer. Figur 8. De symboler vi tagit fram för Stationer, Nära mig och Linjer. Figur 9. Ikonen för applikationen, föreställande en figur som åker upp för en rulltrappa. Denna figur är utan rundade hörn, blänk och drop shadow, vilket Apple lägger till inför lansering till App Store. 26 (51)

27 Lo-fi-prototyp Designprocessen inleddes med lo- fi- prototyper (se bilaga 4) i syfte att utvärdera den tidiga interaktionsdesignen i applikationen. Dessa prototyper skissades, enligt Benyon, Turner & Turners rekommendationer, på fysiska papper tills vi hade strukturen färdigställd. 25 De första pappersskisserna visade alla delar av den tilltänkta applikationen, med handgjorda ikoner och vissa grafiska element, tänkta att likna den slutgiltiga produkten i så stor mån som möjligt. De användes för att få återkoppling på interaktionsdesignen från potentiella användare. Detta gjorde att dessa prototyper snabbt kunde uppdateras och förbättras. De utvalda respondenterna var alla iphoneanvändare, vilket syftade till att de skulle vara vana vid Apples gränssnitt och funktioner Grafisk manual Vi skapade en grafisk manual med designelement, färger och mönster som skulle finnas representerade inuti applikationen (se bilaga 5). Detta för att applikationen skulle uppfattas som mer seriös, komplett och kompetent av användarna. Den grafiska profilen skulle även hjälpa oss vid marknadsföring av applikationen, vilket främst skulle ske via sociala medier. Till skapandet av den grafiska manualen använde vi Cap & Designs manual för detta Hi-fi-prototyp Enligt Benyon, Turner & Turner ska en hi- fi- prototyp vara så lik den färdiga produkten som möjligt. Vi har i detta examensarbete valt att fokusera hi- fi- prototypen enbart till designen, vilket innebär att även denna prototyp gjordes på papper. Den gjordes däremot med fler detaljer och med de designelement som skulle användas i den färdiga applikationen (se bilaga 6). Till skapandet av hi- fi prototypen använde vi oss av PSD IOS5 GUI 27, vilket är en Photoshopfil med många av en iphoneapplikations vanligaste delar. Dessa användes för att montera ihop en applikation som i grunden utgick ifrån Apples riktlinjer för design. 25 Benyon, Turner & Turner, Designing interactive systems, p. 254 (2005) 26 Cap & Design, 2012, Så fixar du en grafisk manual 27 ios 5 GUI PSD (iphone 4S) 27 (51)

28 Vi justerade färger och storlekar tills vi fick fram det resultat som vi eftersträvade. Diverse illustrationer inuti applikationen skapades med hjälp av Adobe Illustrator Användartester Det utfördes två olika typer av användartester i arbetet med Uppgångsappen: lo- fi- tester och hi- fi- tester. Syftet med användartesterna var att se hur en riktig användare interagerar med mobilapplikationen. Användartesterna visade vad som hade upplevts svårt, respektive lätt av användarna, samt vad som fungerat bättre eller sämre. Det togs även tillvara på övrig feedback som exempelvis önskade funktioner och funderingar kring applikationen. Detta material användes vid en slutgiltig skiss för att grundlägga interaktionsdesignen och för att kunna gå vidare in i nästa fas. Den första typen av användartester som utfördes var tester på lo- fi- prototypen. Testerna utfördes på iphoneanvändare och syftet med detta var att de som är vana vid iphoneelementen kan ge feedback utifrån tillämpningen av dessa i mobilapplikationen. Testet gick till så att respondenterna fick tre olika uppgifter som de skulle genomföra i prototypen, vilka hade som syfte att testa de tre olika huvudområdena (se Bilaga 7). De fick utföra uppgifterna på de sätt de trodde var rätt och samtidigt berätta vad de gjorde och hur de tänkte. Eventuella följdfrågor ställdes vid behov. Hi- Fi- testet utfördes på samma grund som lo- Fi- testet, vilket gjorde att det baserades på samma frågor. Eftersom den grafiska designen i detta användartest var mer detaljerat och definierat kunde respondenterna ge feedback på utseende och dess funktionalitet. Respondenterna hade även möjlighet att dela fria åsikter gällande applikationen, vilket gav oss tips på förbättringar och andra funktioner som de skulle uppskatta. Dessa önskemål har vi bearbetat och gjort en bedömning på. Vissa av dessa har av olika anledningar sållats bort ur materialet, medan andra tagits tillvara på och utformats i applikationen Funktioner En specifikation (se bilaga 8) av de funktioner som ansågs vara nödvändiga för applikationen togs fram. Vi beslutade oss för att dela upp applikationen i tre tabbar : Stationer, Nära mig och Linjer: 28 (51)

29 I Stationer skulle det finnas en så kallad tableview (iphonespecifik lista) som innehåller alla stationer som finns i Stockholms tunnelbana. Varje post i listan skulle vara klickbar och ta användaren vidare till en vy som visar detaljerad information om uppgångarna för varje tunnelbanestation. I Nära mig skulle det vara möjligt att hitta till den tunnelbanestation som ligger närmast användarens nuvarande position. I Linjer skulle en linjekarta över Stockholms tunnelbanenät presenteras Programmeringsfasen Nedan ges en beskrivning på hur programmeringsfasen i projektet gick till. Det beskrivs vilka tekniker som användes och hur programmeringen gick till. Slutligen ges en förklaring på varför en databas implementerades i applikationen Teknik Programmering gjordes i Apples utvecklingsmiljö Xcode tillsammans med programmeringsspråket Objective- C. Xcode innehåller verktyg för att analysera och testa sin kod, en simulator för att testa applikationen och SDK:er för Mac OS X och ios. Även design skapas i xcode med hjälp av Interface Builder Programmeringen Under programmeringen såg vi till att förhålla oss till de riktlinjer som Apple förespråkar. Vi använde oss av designmönstret Modal- View- Controller, Delegation och Target- action. Om man gör något fel riskerar man att applikationen får avslag när man försöker ladda upp den i App Store och för att undvika detta såg vi till att följa tutorials, läsa i böcker och titta på kod från Apples dokumentation. Om man hittar på egna lösningar för saker som egentligen är standardiserade löper man en stor risk att få avslag i App Store. Vi försökte även planera programmeringen och använda de inbyggda element som finns att tillgå i Interface Builder. Vi började med att bygga applikationens funktioner och struktur och avslutade arbetet med att implementera designen. 29 (51)

30 Databas Under programmeringen av applikationen försökte vi ta hänsyn till att den ska gå att använda i nedkopplat läge, precis som Trani beskriver. 28 Av denna anledning valde vi att skapa en databas inuti applikationen. På så sätt finns data alltid tillgängligt, till skillnad om man skulle koppla applikationen till en databas som nås via nätet. Conway & Hillegass beskriver hur man använder sig av SQLite i en applikation för iphone. SQLite är ett bibliotek som ingår i iphone OS. Författarna rekommenderar att man använder detta bibliotek när man ska hantera en större mängd data. På så sätt kan man konstruera SQL- frågor för att hämta enbart det data man för tillfället har ett behov av att visa. I applikationer för iphone lagrar man ofta data med hjälp av arkivering, men med SQLite blir applikationen snabbare och hanterar telefonens minne på ett bättre sätt. 29 Vi ansåg att det skulle vara mest passande för oss att skapa en databas och använda oss av SQLite, vilket gjorde att vi hade ett behov av att modellera en databas. Innan databasen modellerades samlade vi data för några av Stockholms tunnelbanestationer. Vi kunde på detta sätt komma fram till av vilken typ av data som skulle behöva presenteras i vår applikation, samt fundera över hur den skulle presenteras. När väl designen var fastställt påbörjades modellering av databasen. Vi valde att skapa en så kallad ER- modell, vilket är ett sätt att representera och beskriva data. Enligt Padron- McCartey & Risch är en ER- modell ett bra steg för att slutligen kunna göra tabeller i en databas, eftersom det i slutänden leder till en bättre design. 30 För att kontrollera att vår modell stämde överens med verkligheten skapade vi en testdatabas utifrån modellen, vilken vi sedan använde till att konstruera de SQL- frågor som vi behövde köra mot databasen. När vi hade säkerställt att databasen fungerade som den skulle började vi fylla den med data. 28 Trani, 2012, Building Mobile Apps for Multiole Devices with Flash Professional 29 Conway & Hillegass, iphone programming: the Big Nerd Ranch guide, pp. 363 (2010) 30 Padron- McCarthy & Tore, Databasteknik, p. 28 (2005) 30 (51)