Windows Phone - Bokningsapp för taxiresor

Transkript

1 LiU-ITN-TEK-A-14/021-SE Windows Phone - Bokningsapp för taxiresor Emil Lindström Department of Science and Technology Linköping University SE Norrköping, Sweden Institutionen för teknik och naturvetenskap Linköpings universitet Norrköping

2 LiU-ITN-TEK-A-14/021-SE Windows Phone - Bokningsapp för taxiresor Examensarbete utfört i Medieteknik vid Tekniska högskolan vid Linköpings universitet Emil Lindström Handledare Karljohan Lundin Palmerius Examinator Camilla Forsell Norrköping

3 Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: Emil Lindström

4 Sammanfattning Användare kan idag boka taxi via TaxiCaller på webben, iphone och Android. De vill även finnas på Windows Phone 8 och därmed stödja de tre största smartphoneplattformarna. Den här rapporten syftar till att undersöka hur en applikation kan utvecklas med hjälp av ett användarcentrerat arbetssätt för att uppnå hög användbarhet. Prototyping, card sort, användbarhetskrav är några av de metoder som tillämpats. Rapporten beskriver metoderna genom dess teori, hur de tillämpats i projektet samt dess resultat. Det grundläggande genomförandet var att samla in användarinformation för att sedan utveckla en prototyp som testades på användare. Sedan gjordes en ny prototyp utifrån resultatet från användartestet och denna process itererade fram fyra prototyper. Användbarhetsproblem från testerna samt tid för genomförande av specificerad uppgift redogörs. Resultatet är en prototyp för Windows Phone 8 som nästintill är helt färdig för publicering. Användartest är den metod som haft mest påverkan på resultatet av applikationen. Varje test har frambringat problem med användbarheten som sedan har kunnat åtgärdas för att förbättra applikationen. Med tanke på utvärderingar och de krav som specificerades är jag nöjd med resultatet som bland annat är avskalat och grafiskt tilltalande samtidigt som den önskade funktionaliteten från TaxiCaller är implementerad.

5 Innehåll 1 Inledning Om TaxiCaller Bakgrund Syfte Avgränsningar Upplägg Teoribakgrund Användarcentrerad systemdesign Nyckelprinciper Designaktiviteter Fördelar med användarcentrerad design Användarcentrerade metoder Användbarhet Designregler Designregler för mobila enheter Designregler för Windows Phone Teknik Nätverk Asynkron programmering Lokalisering Metod Möte med intressent Requirements Lågupplöst prototyp Högupplöst prototyp Resultat 29 5 Slutsatser och diskussion 40 A - Skärmdumpar från resulterande applikation 45 1

6 Figurer 2.1 Processen för en typisk användarcentrerad systemdesign [4] Översiktlig illustration av användarcentrerad design Exempel på en pivotvy Olika typer av Progress bar Gränssnitt för nätverk på Windows Phone Översiktlig bild för utvecklingsprocessen Skärmdump från TaxiCallers Androidapplikation som visar en vy där användaren ska välja adress Tidiga skisser på papper Demo i InVisionapp Skärmdump från Användartest 2 med emulator Skärmdump från Användartest 3 med Nokia Lumia Ett dendogram för testsvaren från card sort En likhetsmatris för testsvaren från card sort Skiss för tre vyer vid bokning i Prototyp Vy för sökning på adress i Prototyp Vy för att välja adress från karta i Prototyp Vyerna visar de 3 olika bokningsstegen för Prototyp Vy för sökning efter adress i Prototyp Nytt utseende för navigationsmeny för att tydligare visa att den enbart ska användas till navigering Struktur för Prototyp Struktur för Prototyp Vyer för Prototyp Vy för Sök adress och Karta Slutgiltigt utseende på bekräftasidan A.1 Slutgiltigt utseende på bokningsvyerna A.2 Slutgiltigt utseende på Sök adress A.3 Slutgiltigt utseende för statussidan, efter man bokat en taxi A.4 Slutgiltigt utseende på kartvyn med meny A.5 Slutgiltigt utseende på avancerad sökning A.6 Slutgiltigt utseende på vyer för att välja datum, tid och antal passagerare

7 Tabeller 4.1 Jämförelse mellan prototyp och befintlig Androidapplikation Tider för hur lång tid det tog för testanvändarna att slutföra en viss uppgift Tider för hur lång tid det tog för testanvändarna att slutföra en viss uppgift

8 1 Inledning Den här rapporten beskriver ett examensarbete utfört på Institutionen för teknik och naturvetenskap vid Linköpings Universitet. Målet med projektet är att utveckla en applikation med hög användbarhet för Windows Phone 8. Kapitlet redogör en bakgrund för TaxiCaller och examensarbetet i sig, syftet med projektet och vilka begränsningar som fanns. Det kommer också återge en översikt för hur rapporten är uppdelad. 1.1 Om TaxiCaller Taxicallers beskriver sin verksamhet som: TaxiCaller bildades 2011 och har utvecklat ett trafikledningssystem som snabbt har nått internationella framgångar och används idag av taxibolag över hela världen. TaxiCallers system är revolutionerande i och med att vi använder den senaste teknologin inom både webblösningar och smarta mobiler (iphone och Android). TaxiCaller Nordic AB finns i Linköping, Sverige [15] 1.2 Bakgrund Idag kan passagerare boka resor via webben, Android- och iphone-mobiler. Taxi- Caller önskar att lägga till stöd även för Windows Phone 8, och på så vis stödja de tre största plattformarna för smartphones. Serverdelen är redan implementerad, så detta projekt avser endast själva klienten. 1.3 Syfte Projektet siktar på att undersöka hur en applikation ska implementeras och designas för att uppnå bra prestanda och användbarhet på Windows Phone 8. Detta görs genom att studera följande frågeställningar: Vilka designregler finns för Windows Phone 8? Hur väl anpassat är Windows Phone 8 för att användas på kart- och platsberoende applikationer? Hur uppnår man en god användbarhet med hjälp av användarcentrerad systemdesign? 4

9 1.4 Avgränsningar Implementation och design är endast anpassad efter operativsystemet Windows Phone 8 på en Nokia Lumia 925. Det finns många metoder för utveckling i en användarcentrerad process. I den här rapporten beskrivs de metoder som ligger till grund för resultatet. Rapporten är inriktad på användbarhet vilket medför att teorin bakom de tekniska lösningarna beskrivs kortfattat. Eftersom projektet ger en mängd utvecklingsmöjligheter använder jag kravspecifikationen för att i övrigt avgöra vilken funktionalitet som ska utvecklas inom detta examensarbete. 1.5 Upplägg Rapporten är uppdelad i fem kapitel: Inledning, Teoribakgrund, Metod, Resultat och Diskussion. Kapitel 1 innefattar bakgrund och syftet med examensarbetet. Kapitel 2 innehåller teori och den bakgrund om användbarhet, designregler, användarcentrerad systemdesign och teknik som är relevant för rapporten. Kapitel 3 beskriver genomförandet och vilka metoder som använts i den användarcentrerade utvecklingsprocessen. I kapitel 4, visas resultatet från utförandet av metoderna som sedan diskuteras i kapitel 5. Fullständig design på applikationen visas sedan i Bilaga A. 5

10 2 Teoribakgrund Detta kapitel går igenom de förberedande studier som ligger till grund för rapporten. Beskrivning av användbarhet, designregler, användarcentrerad systemdesign och teknik för Windows Phone behandlas. 2.1 Användarcentrerad systemdesign Denna sektion tar upp och beskriver den bakgrund som legat till grund för processen under projektet. Användarcentrerad systemdesign (ACSD) är ett tillvägagångssätt som fokuserar på användbarhet i hela utvecklingsprocessen för interaktiva datorbaserade system [6]. En illustration av processen visas i figur 2.1 ISO standarden ger en översiktlig beskrivning av processen för utveckling av interaktiva system med fokus på att förbättra användbarheten. Standarden är en samling krav och principer för generell systemutveckling. Figur 2.1: Processen för en typisk användarcentrerad systemdesign [4] 6

11 2.1.1 Nyckelprinciper Gulliksen et al. [6] har tagit fram tolv nyckelprinciper som karaktäriserar en lyckad användarcentrerad process och som inte är begränsad till något särskilt skede i utvecklingen. Fokus på användaren: Fokuset bör ligga på vad användaren behöver istället för tekniska problem. Utvecklaren ska ha en tydlig bild av syftet med applikationen, veta vem användaren är, deras användningssammanhang, vilken situation användaren befinner sig i, varför och hur de utför sin uppgift etc. Aktivt involvera användare: Användare som passar in i den åsyftade målgruppen bör, i ett tidigt skede, och kontinuerligt under hela processen vara involverade i utvecklingen av systemet. Evolutionär systemutveckling: Utvecklingen av systemet bör vara iterativ och inkrementell då krav förändras. Det är omöjligt att veta från början vad som kommer ske längre in i processen och man bör ha ett förhållningssätt som tillåter kontinuerliga iterationer med användare och inkrementella leveranser. Därmed kan man utvärdera en designlösning med användarna innan man går vidare med sin lösning och därmed får det svårare att senare gå tillbaka och ändra. Simpel representation av design: Använd terminologi och representationer av systemet som är enkla att förstå för användare - till exempel skisser eller någon annan form av prototyp. Målet är att alla inblandade ska ha en förståelse för vad som ska utvecklas. Prototypande: Tidigt och kontinuerligt senare i processen bör prototyper göras och användas för att visualisera och utvärdera idéer tillsammans med användare. Det är viktigt att börja med enkla skisser utan detaljer innan man börjar skriva någon kod. Börja med översiktliga skisser och gå inte vidare till detaljer för tidigt. Gulliksen rekommenderar att man gör flera prototyper samtidigt, så att man inte låser sig fast med den första prototypen. Utvärdering av användning: Analysera reaktionen hos användare när de ser tidiga skisser av systemet, för att senare i processen låta användaren testa verkliga funktioner i systemet. Observera, spela in, lyssna på förslag och idéer som kommer från användaren. Medvetna designval: Utvecklingen, speciellt för användargränssnittet och interaktionsdesignen, bör vara en konsekvens av designaktiviteter och inte en biprodukt från implementationen. Professionalitet: För att vara effektiva och använda sig av alla färdigheter i en projektgrupp bör man hålla sig till att utföra de uppgifter som tillhör ens egen specialitet. Användbarhetsexpert: Det bör finnas en erfaren expert inom användbarhet i projekt- 7

12 gruppen. Holistisk design: Allt som behövs och påverkar den framtida användningssituationen bör utvecklas parallellt. Exempelvis manualer, installationshjälp etc. Anpassningsbar process: Eftersom det inte finns någon modell för en användarcentrerad designprocess som fungerar för alla situationer, så bör de olika metoderna som används anpassas specifikt för varje enskilt projekt. Användarcentrerad attityd: Projektgruppen och alla inblandande bör vara insatta i värdet för användbarhet Designaktiviteter För att uppnå användbarhetskrav i utveckling finns det fyra viktiga användarcentrerade designaktiviteter och en planering för hur de ska genomföras [5], se figur 2.2. Processen är iterativ och ska genomföras om och om igen tills målen för användbarhet är uppnådda. Figur 2.2: Översiktlig illustration av användarcentrerad design Förstå och specificera användningssammanhanget Lär känna användarna, deras omgivning vid användandet och vad de försöker åstadkomma när de använder systemet. Tyngdpunkten är att identifiera vilken typ av 8

13 användargrupp det är och inte på enskilda användare. Möjliga attribut hos en potentiell användare är kompetens, utbildning, fysisk hälsa etc. Bestämma användarkrav och krav från eventuell uppdragsgivare Detta steg handlar om att strukturera den insamlade informationen från föregående steg. Det finns flera olika metoder för att specificera användarkrav och man får anpassa vilka metoder man använder och i vilken ordning man använder dem, utefter varje enskilt projekt. Efter framtagandet av kraven så bör de sorteras baserat på hur viktiga de och hur relevanta de är. Mätbara mål bör här dokumenteras för att kunna utvärdera framtida designlösningar. Ta fram designlösningar som uppfyller användarkraven Vid detta skede i processen, så har de första designerna skapats. Pappersskisser, modellskisser, simuleringar och andra typer av prototyper används för att visa designidéer för användarna. Utvärdera designen gentemot användarkraven Denna aktivitet hör ihop med skapandet av designlösningar. Målet är att samla in feedback för att förbättra systemet och för att se om lösningen uppfyller användarkraven, användbarhetsmålen och följer de allmänna riktlinjerna för användbarhet [10]. Beroende på vilket steg i processen man är i och vilken typ av design man gjort, så är olika metoder av varierande effektivitet Fördelar med användarcentrerad design Förutom att systemet ger en bättre användarupplevelse med en användarcentrerad designprocess så finns det en mängd andra fördelar. För att värdera fördelarna med ACSD, så bör man mäta både hur bra och tillfredsställande användaren kan använda systemet. Man bör även mäta hur mycket ett företag får tillbaka, ur en ekonomisk aspekt, för arbetet. Enligt Institude of Electrical and Electronic Engineers (IEEE) spenderas det ungefär 1 triljon dollar varje år inom IT över hela världen [3]. I en video med Dr. Susan Weinschenk konstateras det att av dessa IT-projekt överges upp till 15% och åtminstone 50% av tiden för en programmerare går åt till att göra omarbetningar som hade kunnat undvikas [20]. Weinschenk tar upp tre olika exempelområden på ekvationer som kan användas för att beräkna hur mycket pengar som kan sparas genom att fokusera på användbarhet. Dessa redogörs på sitt originalspråk i ekvationerna (2.1), (2.2) och (2.3). Errors (# of errors) (avg. repair time) (# of Employees) = Cost Savings (2.1) 9

14 Cost of Development and Maintenance (# of changes) (avg. hours/change) (cost of developer) (4, if change is late!)= Cost Savings (2.2) Productivity (time saved) (Employee Cost) (# of Employees) = Cost Savings (2.3) Vissa av de 12 vanligaste orsakerna, framtagna av IEEE, för att ett IT-projekt misslyckas kan undvikas med en ACSD-process [3]. Orsakerna redogörs för nedan på sitt originalspråk: Unrealistic or unarticulated project goals Inaccurate estimates of needed resources Badly defined system requirements Poor reporting of the project s status Unmanaged risks Poor communication among customers, developers, and users Use of immature technology Inability to handle the project s complexity Sloppy development practices Poor project management Stakeholder politics Commercial pressures Användarcentrerade metoder Det finns många användarcentrerade metoder och de kan delas in i kategorierna: planering, krav & behov, design, implementation, testning och publicering. Usabilitynet.org [17] har listat tio användarcentrerade metoder baserat på ISO som de rekommenderar vid utvecklandet av mjukvara för interaktiva system. 10

15 1. Möte med intressenter Det är viktigt att alla intressenter i utvecklingen är överens och är införstådda med vad som ska utvecklas innan designarbetet börjar. Alla bör ha en klar bild över vad som ska utvecklas och hur systemet vid färdigt tillstånd ska kunna bedömas som lyckat eller misslyckat. Ta reda på vad som är den viktigaste tekniska funktionaliteten för att uppfylla målgruppens behov och om det finns några tekniska svårigheter eller begränsningar. 2. Sammanhangsanalys Ger en grund för att senare i processen utforma användartester. Detta steg görs för att identifiera målgruppen och deras behov med applikationen och kan göras samtidigt som 1. Möte med intressenter. 3. Användningsscenarion Problem med användbarheten kan upptäckas tidigt genom att fundera på olika användningsscenarion. Det ger en bild av hur en möjlig användare skulle bete sig vid interaktion med systemet. Usabilitynet.org [17] rekommenderar att framtagna scenarion ska täcka många olika situationer och inte bara de allra vanligaste. Försök skapa situationer som orsakar problem för systemet. 4. Utvärdera befintliga system Ofta kan man hitta problem i andra system. Därför är det viktigt att i ett tidigt skede utvärdera och dokumentera existerande system vilket medför att man kan förhindra att dessa problem uppstår i sitt eget system. 5. Användbarhetskrav Bestäm konkreta mål tidigt i utvecklingsprocessen som kan bli testade senare i processen. Sätt krav för hur effektivt och tillfredsställande systemet ska vara för den målgrupp som tidigare tagits fram. 6. Pappersprototyp Ett enkelt, billigt och snabbt sätt för att testa designlösningen på användare och kan itereras flera gånger på en kort tid. Eventuella problem med användbarheten kan upptäckas innan någon kod har skrivits. 7. Designriktlinjer Genom att följa designriktlinjer ökar chanserna för att utseendet på systemet är konsekvent mellan olika vyer. Det finns bland annat riktlinjer för användargränssnitt i allmänhet, för Windows Phone och för mobila enheter. 8. Utvärdering av implementerad prototyp Under processen ska en prototyp testas iterativt flera gånger. Det gör att systemet förbättras för varje gång. Man vill undvika upptäckten av användbarhetsproblem när 11

16 systemet är färdigt. Under tiden tester utförs dokumenteras problem som upptäcks, som sedan ska åtgärdas efter testerna är färdiga. 9. Användbarhetstestning Ett mer fullständigt test än 8. Utvärdering av implementerad prototyp som används för att upptäcka användbarhetsproblem och även för att erhålla mätningar från testerna. Testerna kan visa hur effektiva och tillfredsställande testerna är. 10. Feedback Det kan vara nyttigt att samla feedback från användare efter applikationen har släppts, ifall en ny framtida applikation ska utvecklas. Prototypande En prototyp är ett utkast av ett framtida system som gör det möjligt att visa idéer och ett översiktligt designkoncept till användarna innan pengar och tid spenderas på utveckling. En prototyp kan vara allt från en lågupplöst pappers-skiss till något där man kan klicka på några få ställen till ett fullt fungerande system. Man bör arbeta med prototyper tidigt i utvecklingsprocessen eftersom det är mycket billigare att ändra ett system tidigt, än att göra ändringar i slutet av processen. Jakob Nielsen [11] konstaterar att det är billigare att göra ändringar innan någon kod har skrivits överhuvudtaget, istället för att vänta till implementationen är klar. Han säger att de största förbättringarna i användarupplevelse kommer från att samla in användardata så tidigt som möjligt. Det finns många olika åsikter om en lågupplöst prototyp ger bättre eller sämre resultat, för att hitta problem i användbarheten, än en högupplöst prototyp. I en undersökning [18] har det konstaterats att de i grunden är exakt lika bra för att samla in användardata. Men de har ändå några olika fördelar och nackdelar och de passar olika bra för olika typer av utvecklingar. Det finns flera sätt för att göra tidiga pappersprototyper. Dels kan man börja med att göra enkla statiska skisser på papper. Redan där får man en bättre inblick och förståelse för hur bra designlösningen skulle kunna fungera på en framtida användare. Men för att kunna testa prototypen på användare behöver man göra det lite mer interaktivt. Använd ett papper för varje sida i designen, och när användaren visar var den vill trycka så byter man till den sida som då ska visas. Lågupplöst prototyp En lågupplöst prototyp är ofta pappersbaserad och användaren kan inte interagera med skissen. I de flesta fall går det snabbare att göra lågupplösta skisser och de är särskilt bra på visa upp tidiga idéer och visualisationer. En annan fördel är att användare känner sig mer bekväma med att föreslå ändringar och peka ut brister. 12

17 Högupplöst prototyp Datorbaserad och med möjlighet att interagera med användare i form av musklick eller dylikt. En högupplöst prototyp görs för att likna det slutgiltiga systemet så mycket som möjligt. En fördel jämfört med en lågupplöst prototyp är att det är lättare att samla in mätbar data. Till exempel tiden det tar att utföra en specifik uppgift. Card Sort En metod som ger en översiktlig bild av vad användare förväntar sig för informationsstruktur på systemet. Varje person har ett eget synsätt för hur information ska vara strukturerad. Det är ett vanligt misstag bland utvecklare att göra ett system baserat på sitt eget synsätt. I studier om intranät så kan man se att en omstrukturering av intranätet, som återspeglar personalens arbetsflöde, ger bland den största vinsten i produktivitet för personalen [12]. För E-handel ökar försäljningen när produkter är placerade i kategorier som överensstämmer med var användaren förväntar sig att hitta dem. Det finns olika metoder för att undersöka vad användarna har för mental representation, men den primära metoden är card sorting. I grunden funkar det enligt: 1. Skriv ner namn och beskrivning för varje viktig post som ska finnas i det framtida systemet. Exempelvis Logga in eller Kontakt. 2. Blanda alla nedskrivna poster och låt användarna kategorisera dem i passande grupper. Det här kan man enkelt göra med papper och penna, men det finns även en mängd digitala verktyg. Om man gör det online ges man förmånen att kunna skicka ut undersökningen via Internet till flera personer snabbt och enkelt. Nielsen tar upp en studie av Tullis och Wood där de har undersökt hur många användare som är optimalt att göra testet på [12]. De började med att göra en card sort på 168 personer, vilket ger ett väldigt pålitligt resultat. De simulerade sedan mindre tester utifrån testet med 168 personer där de slumpvis valde ut tjugo personer. Därmed kan man kolla hur bra de små testerna korrelerar med det större referenstestet. Alltså, om korrelationen är 1 så är testresultatet för det mindre testet exakt likadant som för referenstestet. För att hitta de viktigaste problemen med användbarheten brukar det räcka att testa 5 personer. Dock är det annorlunda för card sort, där finns det bara en korrelation på 0.75 om man testar fem personer och jämför med referenstestet på 168 personer. Därför rekommenderas det att testa femton personer, och då når man en korrelation på Efter det måste man öka antalet testpersoner ganska mycket för att få bättre korrelation. Anledningen till att det inte räcker med fem testpersoner är för att denna metod genomförs för att skapa en ny designstruktur, medan ett användartest är till för att utvärdera en redan befintlig designstruktur. Card sort är 13

18 alltså en metod för skapande (generativ metod), medan användartest är en metod för utvärdering (utvärderingsmetod). De olika typerna av metod fungerar bra tillsammans. Först används en generativ metod för att sätta riktningen på designen, sedan utvärderas resultatet. Utvärderingen är snabb och billig, så man kan utföra denna flera gånger. En informationsarkitektur ska dock inte baseras enbart på de numeriska värdena från en card sort. Mycket av värdet från card sort kommer från att man observerar användaren när den sorterar korten; vilket gör att man vet varför de placerar korten som de gör. Detta ger en djupare insikt och en bättre bild av hur användarna egentligen tänker. 2.2 Användbarhet Genom ett användarcentrerat arbetssätt siktar man på ett resultat med hög användbarhet. Denna sektion beskriver vad användbarhet är och varför det är viktigt för ett system. En framgångsrik mobilapplikation bör bidra med ett gränssnitt som är tillfredsställande och lättanvänt. Användbarhet definieras av ISO som [5]: Den utsträckning i vilken en specifik användare kan använda en produkt för att uppnå specifika mål, med ändamålsenlighet, effektivitet och tillfredsställelse, i ett givet användningssammanhang Jakob Nielsen listar 5 kvalitetskomponenter för användbarhet [13]: Learnability: Hur lätt är det för användarna att genomföra en grundläggande uppgift första gången de bemöts med designen? Efficency: När användarna har lärt sig designen, hur snabbt kan de då genomföra uppgifter? Memorability: Hur snabbt kan användarna återupprätta vad de kunde efter en tids frånvaro från designen? Errors: Hur många misstag gör användarna, hur allvarliga misstag, och hur fort kan de återhämta sig efter misstagen? Satisfaction: Hur tillfredsställande är det att använda designen? Om det är oklart vad applikationen är till för, om användaren går vilse eller om applikationen är svåranvänd så kommer användaren ge upp och sluta använda applikationen. För ett företag är detta kritisk, om användaren inte kan hitta det den söker, så kan de heller inte köpa det. Genom att spendera 10% av budgeten på användbarhet kan man dubblera en webbsidas kvalitet. 14

19 Det finns en mängd olika metoder för att undersöka användbarheten hos ett system, men den mest grundläggande och nyttigaste är användartester. Ett användartest görs på en användare som passar in på målgruppen. Man ber sedan användaren att utföra en uppgift med designen, medan man observerar i vad användaren lyckas och misslyckas med. När man observerar ska man vara tyst och inte hjälpa användaren på något sätt, för att inte förstöra hela testet. Som tidigare nämnts rekommenderar Nielsen att man har en grupp på fem testpersoner vid tester, eftersom det räcker för att finna de flesta användbarhetsproblem som går i ett test. I ett ekonomiskt perspektiv är det bättre att göra flera små tester och iterativt förbättra designen än att göra ett stort och dyrt test. Ju fler tester och versioner av gränssnittet, desto bättre. Det räcker inte att endast lyssna på vad potentiella användare har att säga om ett interaktivt gränssnitt. Man måste observera vad de faktiskt gör med det. Att bara lyssna kan vara missledande. 2.3 Designregler Det finns riktlinjer för hur en design ska se ut för de flesta system. Genom att veta vilka riktlinjer som finns kan medvetna designval genomföras och en professionell design skapas. De riktlinjer som varit väsentliga för detta projekt redogörs för i denna sektion Designregler för mobila enheter Användare förväntar sig att mobila tjänster ska vara användarvänliga och samtidigt fungera bra [19]. Ivo Weevers har tagit fram sju designriktlinjer för en lyckad användarupplevelse på en mobil enhet: 1. Varje interaktion med mobilapplikationen ska återspegla företagets varumärke och det ska vara lätt för användaren känna igen sig. 2. Lägg mer resurser på den plattform som företaget tjänar mest på och där de flesta kunderna finns. 3. Bestäm vad som är det huvudsakliga syftet med applikationen och anledningen till varför personer använder den. Lägg först och främst resurser på det huvudsakliga syftet och till sist på sidofunktioner. 4. Optimera prestandan och visa för användaren att applikationen håller på att arbeta. Annars kan de tro att applikationen har fastnat och att den slösar bort deras tid. 5. Gör en avvägning om vilka UI-element som måste finnas för att bibehålla företagets varumärke, och vilka UI-element som kan ändras eller tas bort. 15

20 6. Kom överens om vilka mål applikationen ska klara prestandamässigt. Ta sedan tid på hur lång tid det tar och jämför med konkurrenter. 7. Grafik, animeringar och dylikt kommer att påverka prestandan. Därmed behöver koden bakom applikationen vara bra skriven för att förbättra laddningstiderna. Karta i mobil enhet Ett av de vanligaste användningsområdena för mobiltelefoner är att hitta platser eller för att få en vägbeskrivning. Ofta använder applikationer en karta för att visa sökresultatet istället för en enkel lista. Detta medför dock många användbarhetsproblem [2]. Ofta innehåller vyer så mycket information att användaren behöver skrolla nedåt för att se all information. Om det då har placerats en karta som täcker stor del av skärmen, kommer många användare få problem med att skrolla förbi kartan. En lösning kan vara att lägga marginal bredvid kartan där användaren kan göra svepgesten. Ett annat alternativ är att gömma kartan på något sätt, där användaren kan trycka fram kartan när den vill använda den. Musklick är mycket mer precist än när man trycker med fingret på en touchskärm. Ett vanligt fel på små skärmar är att kartmarkörer är placerade alldeles för nära varandra. Vissa försöker lösa detta genom att byta ut ikonen för markören mot en ikon med en siffra som anger antalet markörer som ligger inom samma område. Dock ska detta undvikas då det är förvirrande för de flesta användare Designregler för Windows Phone 8 Windows har specificerat en mängd olika riktlinjer för utvecklare som använder deras system [8]. Vissa av dem kommer att redogöras för nedan: Användning av knappar Likt Android OS, är Windows Phone anpassat för att köras på olika typer av telefoner. För att ge en konsekvent användarupplevelse och funktionalitet så har Windows Phone definierat en gemensam grund av hårdvara som alla tillverkare måste följa. Ett av kraven är att enheten måste ha tre fysiska knappar - Bakåt, Hem och Sök. Knapparna ger en enkel och naturlig navigationsmodell för användaren [16]. Undvik en mjukvarubaserad Bakåt -knapp eftersom systemet då upplevs mer konsistent och avskalat. Användare av Windows Phone är vana med att navigera bakåt med den fysiska knappen [1]. En egen Hem -knapp för en applikation avrådes eftersom det förstör navigationsmodellen för Windows Phone. Användaren kan fastna i en nästan oändlig loop och kommer inte ha möjlighet att gå ut ur appen via den fysiska Bakåt -knappen. 16

21 Pivot Pivot är navigationsmodell i fullskärm, där man snabbt kan förflytta sig mellan vyer, se figur 2.3. Figur 2.3: Exempel på en pivotvy Använd endast 4 till 5 pivotvyer, av prestandaskäl men även för att minska risken att användaren ska komma vilse. Använd endast för att visa liknande typer av data, eller till och med samma data men visat på olika sätt. Titeln på en pivotvy ska begränsas till maximalt 2 ord. Använd inte element som lyssnar på svepgester i en pivotvy. Exempelvis rekommenderas det inte att ha en karta inuti en pivotvy eftersom det är oklart vad som ska ske vid en svepningsgest när det finns två element som lyssnar på svepet. Enligt Neelima Salvi ska Pivot aldrig användas som olika steg i en process [14]. Progress bar Det finns två olika typer av Progress bar vilket visas i figur 2.4. En determinate progress bar som procentuellt visar hur långt det är kvar på en operation. En indeterminate progress bar som visar att en operation körs. 17

22 Figur 2.4: Olika typer av Progress bar Om en operation alltid tar längre än 2 sekunder, ska Progress bar visas direkt. Men om tiden för operation varierar och ibland tar kortare än 2 sekunder och ibland längre, ska Progress bar visas först efter 500 millisekunder för att undvika flimmer. Karta och position Om kartan ska vara interaktiv och dynamisk ska den vara så stor att användaren inte behöver zooma etc. överdrivet mycket. Det ska vara möjligt för användaren att manuellt uppdatera sin position [7]. Visa en Progress bar medan position inhämtas. Om användaren inte tillåter att positionen för enheten kan hämtas, ska ett meddelande om detta visas i applikationen. 2.4 Teknik I denna del kommer all teknisk bakgrund som är relevant för denna rapport beskrivas Nätverk Mobiltelefoner är bland de mest ansluta enheter som finns eftersom de har så många olika anslutningsmöjligheter. Alla Windows Phone-enheter stödjer nätverksanslut- 18

23 ning via mobilt nätverk och har inbyggt Wi-Fi. Enheten kan till och med ansluta via USB till programvaran Zune på en PC. I de fall som telefonen inte har tillgång till något nätverk, måste applikationerna hantera det på något sätt. Åtminstone borde användaren få ett meddelande om att applikationen inte går att använda för tillfället eftersom det inte finns någon nätverksanslutning. En mer avancerad applikation kan spara data lokalt för att skicka det senare när en nätverksanslutning har upprättats. Figur 2.5: Gränssnitt för nätverk på Windows Phone I figur 2.5 visas de olika teknikerna som används för att skicka data mellan applikationer och Internet. Applikationen kommunicerar med Internet Programmer Interface som i sin tur kommunicerar med de tre anslutningsteknikerna [9] Asynkron programmering För att undvika flaskhalsar i prestandan och förbättra responsiviteten överlag i applikationen används asynkron programmering. I vanliga val är detta en krävande och komplicerad process för att göra, felsöka och underhålla. Men Visual Studio 2012 har simplifierat asynkron programmering i Windows Runtime. Kompilatorn gör det svåra jobbet och applikationen behåller en logisk struktur. I TaxiCaller-applikationen används asynkron programmering när applikationen hämtar information från webben. Eftersom detta ofta tar en stund, beroende på uppkoppling och mängden data, så måste applikationen vänta och stannar av helt om synkron programmering används. Med asynkron programmering kan applikationen fortsätta som vanligt med saker som inte är beroende av informationen från webbresursen. Detta är viktigt ur ett användbarhetsperspektiv. Om en process blir blockerad i en synkron applikation, så stannar applikationen och användaren kan tro att applikationen har slutat fungera när den egentligen bara väntar på information. 19

24 2.4.3 Lokalisering En Windows Phone-enhet är lokaliseringsbar. Den använder Global Positioning System (GPS) som hämtar satellitsignaler för att bestämma telefonens position. Eftersom GPS-systemet endast fungerar ordentligt när det finns en fri sikt mot himmelen, så används andra tekniker för att bestämma positionen. Detta kallas assisterad GPS och då tar den hjälp av information som sänds ut i mobilradionätet. Assisterad GPS kan även bestämma positionen med hjälp av positionen på ett Wi-Fi nätverk om telefonen är ansluten till det. Med uppdateringen av Windows Phone till version 8.0 förbättrades bland annat Location API. I tidigare versioner var det ganska krångligt att hämta användarens position, men i och med uppdateringen kan positionen nu hämtas på ett enkelt och smidigt sätt. Den nya tekniken använder asynkront metodanrop vilket förbättrar prestandan av applikationen samtidigt som användarens position kan hämtas. 20

25 3 Metod Användarcentrerad systemdesign är grunden för processen i detta arbete och jag har baserat min utvecklingsprocess på rekommenderade metoder för utveckling av interaktiva system [17], se kapitel 2. Översiktligt har processen i denna rapport varit: 1. Planera och samla in information om vad som ska utvecklas och vem som ska använda det. 2. Lära känna användarna och deras behov. 3. Skapa en prototyp. 4. Utvärdera prototypen och åtgärda baserat på resultat. I processen har det itererats flera gånger mellan steg 3 och 4, vilket illustreras i figur 3.1. Här beskrivs processen och resultaten beskrivs i kapitel 4. Figur 3.1: Översiktlig bild för utvecklingsprocessen 3.1 Möte med intressent Projektet började med ett uppstartsmöte med handledaren på TaxiCaller. Det gav mig en översiktlig bild av verksamheten och vad som förväntades i resultat för exjobbet. På mötet diskuterades det fram vilka krav som var rimliga att hinna med under projektets tidsperiod. Idag kan passagerare boka taxiresor via Android, iphone och webben. Taxicaller ville även finnas på Windows Phone 8 och på så vis stödja alla de tre största smartphone-plattformarna. Applikationen skulle ha ungefär likadan funktionalitet som den nuvarande Androidapplikationen. Kraven på Windows Phone-applikationen för Taxicaller var från början: Resenär kan registrera ett konto. Resenär ska kunna skriva in reseuppgifter. Lediga bilar i närheten skall visas på en interaktiv karta. Resenär ska kunna kontrollera status på en inlagd bokning. Resenär ska kunna följa en bokning i realtid. 21

26 Resenär ska få tidsuppskattning på när taxin är framme. Resenär ska få uppgift om avstånd till taxin. Resenär ska kunna se var taxin befinner sig på en kartvy. Ett tag senare bestämdes det att registrering av konto för användare inte är viktigt för applikationen. Därmed togs det kravet bort och istället skulle användarna kunna spara adresser som favoritadress. Vi kom även fram till att målgruppen är användare mellan 20 till 40 år som är vana användare av smartphones. 3.2 Requirements Innan designfasen var avsikten att samla in information om ett tänkbart användargränssnitt, användare, omgivning etc. För att till sist formulera krav och behov för applikationen. Intervjuer För att få en första inblick i hur potentiella användare vanligtvis bokar taxi blev två personer ombedda att beskriva hur de vanligtvis går tillväga när de bokar taxi via telefon. Den ena personen är en tjej på 23 år som jobbar inom handeln. Den andra är en kille på 26 år och jobbar inom byggbranschen och bokar ofta taxi via telefon. Detta ledde till diskussioner om vad som var viktigt och vad som var mindre viktigt vid en bokning. En bokning via telefon jämfört med bokning via en mobilapplikation kan vara väldigt annorlunda och har olika styrkor och svagheter- Därför fick de även berätta hur de förväntar sig att ange upphämtningsadress etc. i en applikation. Brainstorming Efter intervjuerna brainstormades det mycket, dels på egen hand, och dels genom diskussioner med en person som passar in i målgruppsbilden. Nya infallsvinklar diskuterades och det gjordes en lista med attribut som visar vad applikationen måste innehålla för att fungera korrekt och vad som ska finnas med för att förhöja användarupplevelsen. Utvärdering av liknande applikationer Inspiration hämtades och problem undersöktes i TaxiCallers befintliga applikation, som visas i figur 3.2, och även i andra existerande bokningsapplikationer på Android och Windows Phone. 22

27 Figur 3.2: Skärmdump från TaxiCallers Androidapplikation som visar en vy där användaren ska välja adress Flera störande saker hittades i applikationerna, men det var också några saker som var bra som kunde användas senare i skissandet för den nya applikationen för TaxiCaller på Windows Phone. Card Sort För att ta reda på hur användare anser att informationsstrukturen bör vara för applikationen gjordes en card sort. Testet utfördes av 10 testpersoner där alla passade in på målgruppen. Det gav en bra bild på hur testpersonerna anser att de olika delarna hör ihop med varandra. Testet gjordes via onlineverktyget OptimalSort och innehöll 19 kort som användarna skulle gruppera ihop. Det var svårt att skriva beskrivande text för korten då de endast ska ha några fåtal ord som beskrivning. Jag hade fått en ungefärlig bild sedan innan av hur en framtida applikation kunde se ut, men eftersom jag inte visste säkert så valde jag att hellre skriva för många kort än för få. 23

28 Användningsscenarion Några användningsscenarion och potentiella användningstillfällen noterades och kan vidare ses i kapitel 4. Det lade fokus på vad en användare verkligen är i behov av och det gav en bättre förståelse för hur applikationen kommer användas i verkligheten. Dessa kunde sedan användas i hela processen för att påminna om hur applikationen kommer användas. Användbarhetskrav I slutet på insamlingen av användardata hade en förståelse för användarna byggts upp och det var nu möjligt att bestämma målen för applikationen som senare även kunde testas. Kraven som noterades var mätbara eller beskrivande. 3.3 Lågupplöst prototyp Efter undersökningen av krav och behov för användare användes den medförda kunskapen för att skapa pappersskisser. Flera skisser gjordes med papper och penna, vilket kan ses i figur 3.3. Eftersom ett av målen var att göra applikationen avskalad med så få klick som möjligt, så innehöll den första skissen endast en knapp som bokade en taxi direkt med ett fingertryck. Skissen utvecklades sedan till flera olika alternativa skisser. Eftersom det huvudsakliga syftet med applikationen är att boka en taxi, var alla skisser av typen parallell prototyp. Vilket betyder att skisserna fokuserade på de olika stegen för att boka en taxi, och inte på sidofunktioner som inloggning och inställningar etc. Vyn för inmatning av användaruppgifter vid inloggning utelämnades och vid test var användaren automatiskt inloggad som en testanvändare. 24

29 Figur 3.3: Tidiga skisser på papper Skisserna jämfördes sedan med den befintliga applikationen. Det som testades var antal klick för att boka och antal sidor/vyer som berörs under bokningen. Den skiss som krävde minst användarinteraktion och ändå ansågs ha en logisk navigationsstruktur valdes ut och utifrån den skapades en skiss i Photoshop. Photoshopskissen användes sedan tillsammans med onlineverktyget InVisionapp för att skapa en enkel interaktiv prototyp med hjälp av några få bilder, som senare kunde testas på användare. Testet kallas i fortsättningen för Användartest 1 och testades på fem personer. En skärmdump från en demo i Invisonapp visas i figur

30 Figur 3.4: Demo i InVisionapp Totalt har sex personer deltagit i användartester på prototyperna som beskrivs i rapporten. Varje test hade ett deltagande på fem personer, vilket betyder att fyra av personerna återfinns i alla tre tester. 3.4 Högupplöst prototyp Den första implementerade prototypen skapades, vilken fortfarande var av typen parallell prototyp. När implementation var klar så var det möjligt att lägga en bokning på en taxi. Prototypen testades på fem potentiella användare(varav fyra stycken återkommer från Användartest 1) och resultatet kan ses i kapitel 4. Testet kallas i fortsättningen för Användartest 2. De fick i uppgift att genomföra olika uppgifter. De skulle boka en taxi till adressen de befann sig på och vid den nuvarande tidpunkten. Sedan skulle de boka en taxi till en specifik adress och specifik tidpunkt. Tyvärr finns det i skrivande stund inget sätt för spela in ljud och bild på en Windows Phone samtidigt som en applikation körs. Därmed utfördes testerna i en emulator på en dator, vilket illustreras i figur 3.5. Detta medförde en viss osäkerhet eftersom användarna inte använde applikationen i sin naturliga miljö med svepgester, zoom etc. Det gick inte heller att skriva in bokstäverna Å, Ä och Ö vilket ledde till vissa problem. 26

31 Figur 3.5: Skärmdump från Användartest 2 med emulator Testerna utvärderades och problem som uppstod noterades för att senare åtgärdas. Nya funktioner adderades och en fullt funktionell applikation var implementerad enligt de initiala kraven. En användare hade nu möjlighet att boka taxi och sedan även se status på den med tidsuppskattning på ankomst etc. En ny diskussion med TaxiCaller ägde rum för att diskutera vad som skulle prioriteras härnäst. Det bestämdes att applikationen skulle vara mer lik Androidapplikationen navigationsmässigt av orsaken att användare skulle känna igen sig mellan de olika plattformarna. Eftersom det dittills inte hade fokuserats något nämnvärt på det grafiska utseende bestämdes det också att en ansträngning skulle göras för att applikationen skulle bli grafiskt snygg och återspegla det gula temat från Androidapplikationen. Resultatet blev två nya prototyper med likadant grafisk utseende men två olika navigationsmodeller. Den ena med likadan navigering som de tidigare skisserna och prototyperna, och en med liknande navigation som den befintliga Androidapplikationen. Båda prototyperna testades sedan av användare och resultatet kan ses i kapitel 4. Dessa användartest, vid namn Användartest 3, utfördes på en Windows Phone-enhet och filmades samtidigt, vilket visas i figur

32 Figur 3.6: Skärmdump från Användartest 3 med Nokia Lumia 925 Återigen utvärderades testerna och problem som uppstod åtgärdades och ny funktionalitet adderades. Eftersom tiden inte var tillräcklig för att fortsätta implementera för de båda olika prototyperna så valdes det att gå vidare med den nya navigationsmodellen som liknar TaxiCallers befintliga Androidapplikation. Eftersom den var mer lik de applikationer som TaxiCaller använder på andra operativsystem. 28

33 4 Resultat I detta kapitel kommer alla skisser och testresultat visas. Resultatet från examensarbetet är en Windows Phone-applikation och en studie i metoder för att uppnå bra användbarhet genom användarcentrerad systemdesign. Inledande intervjuer Jag fick en allmän förståelse för vad användaren förväntade sig vid en bokning. Det som noterades efter de inledande intervjuerna var att användare hellre vill söka på platser, restauranger, affärer etc. istället för adresser. Samtliga personer ville att en breadcrumb, för att se vilket steg man är på i bokningen, skulle finnas med. En viktig aspekt som följde med från insamlandet av användardata var att applikationen automatiskt skulle fylla i så mycket information om bokningen som är möjligt. Exempelvis genom att använda gps och fylla i nuvarande position som upphämtningsadress, och att ställa in nuvarande tid och datum etc. Brainstorming Det konstaterades att det enda som krävs för att boka taxi är: var bokaren vill bli upphämtad, och när bokaren vill bli upphämtad. Det noterades även att bokaren skulle vilja veta när taxin anländer, var den vill åka och vad resan kommer kosta. Detta var de mest relevanta attributen för taxibokning enligt de intervjuer och den brainstorming som gjordes. Card sort Resultatet av cart sort med 10 personer kan ses i figur 4.1 och figur

34 Figur 4.1: Ett dendogram för testsvaren från card sort Figur 4.2: En likhetsmatris för testsvaren från card sort Användarscenarion De användarscenarion som togs fram, som underlag för framtida referens var: Håkan är en affärsman och sitter på stan och fikar på ett möte, han blir uppringd och behöver snabbt boka en taxi. Han vet dock inte vad han är på för adress. 30

35 Freddy och 2 kompisar är hemma på förfest. De ska på en annan fest och vill därför att taxin kommer och hämtar dem på platsen de befinner sig på. Dock har de dåligt med pengar, så innan de bokar vill de veta vad det kommer att kosta dem. Anna sitter på ett tåg och behöver en taxi när hon anländer. Hon har dock ingen täckning på tåget, men hon har Internet. Hon vill att taxin plockar upp henne när tåget är framme på stationen. Användbarhetskrav Applikationens krav formulerades som: På 10 sekunder ska en van användare, som använt den av rapporten resulterande applikationen tidigare, kunna vinka in en ledig taxi som är i närheten. Det ska gå att komma åt en huvudfunktionen från huvudmenyn med mindre än 3 klick. Designriktlinjer för Windows Phone-element ska följas och vara konsekventa. Användare ska hela tiden kunna navigera till föregående sida. Användaren ska aldrig känna sig vilsen i navigationen. Minst 50% av användarna ska kunna vinka in en taxi på under 1 minut första gången de använder applikationen. Högst 10% av användarna ska störa på kritiska problem när de ska vinka in en taxi första gången de använder applikationen. Alla grafiska element ska vara lätta att förstå. Systemet ska vara lätt att lära sig. Felmeddelanden ska förklara hur felet ska åtgärdas. Funktioner som inte kan göras ogjorda ska fråga efter en bekräftelse. Layouten och färgerna ska kännas moderna och tillfredsställande. Inga tester som utvärderar de subjektiva kraven har utförts. Men de mätbara kraven kan utläsas från testresultat som redogörs senare i detta kapitel. Prototyper Resultatet av insamlingen av användardata resulterade i flera skisser, se figur 3.3. Antal sidor/vyer och fingertryck jämfördes med den befintliga Androidapplikationen som visas i figur 3.2. Resultatet från jämförelsen visas i tabell