Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 18hp | TDDD83 Kandidatprojekt datateknik
2018 | LIU-/LITH-EX-G--18/023--SE
BikePool - Utveckling av en
enkel och navigerbar
webbap-plikation
BikePool - Development of a simple and navigable web application
Sofie Bengtsson
Filip Cornell
Hampus Engström
Elin Håkansson
Emma Nilsson Tengstrand
David Schützer
Philip Stratelis
Kasper Vinberg
Handledare : Dennis Persson Examinator : Aseel Berglund
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år 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 lösningar av teknisk och admi-nistrativ 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 sam-manhang 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 http://www.ep.liu.se/.
Copyright
The publishers will keep this document online on the Internet – or its possible replacement – for a period of 25 years starting from the date of publication barring exceptional circumstan-ces. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/hers own use and to use it unchang-ed for non-commercial research and unchang-educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the con-sent 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 Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c Sofie Bengtsson Filip Cornell Hampus Engström Elin Håkansson
Emma Nilsson Tengstrand David Schützer
Philip Stratelis Kasper Vinberg
ABSTRACT
The report covers a study made by a project group at Linköping University. The report discusses and analyzes the project that is developing and implementing BikePool, a web application that serves as an online marketplace ser-vice for people to rent or lease bikes. The discussion emanates from the aspects of achieving a high simplicity and navigationability in terms of usability because that is desirable attributes from the target group. A survey, distribu-ted among a number of students, at the Linköping University lies as a foundation of the project. What is more, it showed the fundamental necessity of what the core business BikePool tries to attain. Additionally, the outcome of the survey was utilized to form an original prototype that was to be used in the development process. The project group embraced an iterative working method by executing continuous user tests, collecting the emitted information in order to answer the affirmed question formulation. Furthermore, the report discusses and motivates selected te-chnical solutions to substantiate the project goal and purpose. With user tests and a thoroughgoing discussion the conclusion could be drawn that by implementing a web application considering the color and placement of elements and removing noncrucial elements as well as focusing on single-age design, the web application achieves the aspects high navigationability and simplicity in terms of usability.
SAMMANFATTNING
Rapporten undersöker utvecklingen och implementeringen av webbtjänsten BikePool, en tjänst för att hyra och hy-ra ut cyklar mellan studenter. Syftet bakom detta arbete var att undersöka hur en webbshop bör utvecklas samt implementeras för att uppnå god användbarhet i form av enkelhet och navigerbarhet, eftersom det är önskvärda egenskaper från den valda målgruppen. Utifrån en förstudie inhämtades information som användes som grund för planeringen av webbapplikationen. Denna information användes för att skapa en prototyp som senare användes under utvecklingen. Gruppen utformade arbetet efter en iterativ arbetsprocess och genom kontinuerliga användar-tester inhämtades information för att besvara frågeställningen. I följande rapport presenteras hur gruppens fråge-ställning har använts för att uppnå rapportens syfte. Utöver detta diskuteras tekniska lösningar samt hur dessa motiveras för att underbygga rapportens syfte. Med användartester samt diskussion som grund drogs slutsatsen att gruppen har genom att implementera hemsidan med placering och färg på element enligt framtagen teori, ta bort onödiga element samt att ha ett tydligt fokus på single-page design skapat en e-shop med god användbarhet i form av enkelhet och navigerbarhet.
Innehåll
Abstract iii Sammanfattning v Innehåll v Figurer viii Tabeller x 1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställning . . . 1 1.4 Avgränsningar . . . 1 2 Teori 3 2.1 Konsument-till-konsument-plattform . . . 3 2.2 Användbarhet . . . 3 2.2.1 Enkelhet . . . 4 2.2.1.1 Arkitektur . . . 4 2.2.1.2 Färgval . . . 52.2.1.3 Textens utseende och presentation . . . 5
2.2.1.4 Köpprocess . . . 5
2.2.2 Navigerbarhet . . . 6
2.2.2.1 Placering och utformning av element på webbsidan . . . 6
2.2.2.2 Navigationsmeny . . . 7
2.2.2.3 Rullgardinsmeny . . . 7
2.2.2.4 Undvika dead-end vid navigering . . . 7
2.2.2.5 Single-Page design . . . 7 2.2.2.6 Logotyp för webbtjänst . . . 7 2.3 Metodteori . . . 8 2.3.1 Förstudie . . . 8 2.3.1.1 Enkätmetodik . . . 8 2.3.1.2 Utvärdering av enkät . . . 8 2.3.1.3 Brainwriting . . . 8 2.3.1.4 Marknadsföringsplan . . . 9 2.3.1.5 Prototyp . . . 9 2.3.2 Scrum-metodologin . . . 9 2.3.3 Par-programmering . . . 10 2.3.4 Utvärdering . . . 10
2.3.4.3 Användartester . . . 11 3 Metod 12 3.1 Förstudie . . . 12 3.1.1 Enkätundersökning . . . 12 3.1.2 Prototyp . . . 12 3.2 Implementation . . . 12 3.2.1 Front-end . . . 13 3.2.2 Back-end . . . 13 3.3 Utvärdering . . . 13 3.3.1 Användartester . . . 13 3.3.2 Acceptanstester . . . 14 4 Resultat 16 4.1 Förstudie . . . 16 4.1.1 Enkätundersökning . . . 16 4.1.2 Prototyp . . . 17 4.2 Implementation . . . 18 4.2.1 Start-sida . . . 18 4.2.2 Navigationsmeny . . . 20 4.2.3 Kontaktformulär . . . 20
4.2.4 Inloggning och registrering . . . 21
4.2.5 Profilsida . . . 22 4.2.6 Köpprocess . . . 25 4.2.7 Databasstruktur . . . 26 4.2.8 Auto-skalning . . . 27 4.3 Utvärdering . . . 27 4.3.1 Användartest 1 . . . 27 4.3.2 Användartest 2 . . . 30 4.3.3 Acceptanstester . . . 34
4.3.4 Åtgärder för samtliga tester . . . 34
5 Diskussion 36 5.1 Resultat . . . 36 5.1.1 Förstudie . . . 36 5.1.1.1 Enkätundersökning . . . 36 5.1.1.2 Prototyp . . . 37 5.1.2 Implementation . . . 37 5.1.2.1 Start-sidan . . . 38 5.1.2.2 About-sidan . . . 38 5.1.2.3 Navigationsmeny . . . 39 5.1.2.4 Kontaktformulär . . . 40
5.1.2.5 Inloggning och registrering . . . 40
5.1.2.6 Profilsida . . . 40 5.1.2.7 Köpprocess . . . 41 5.1.2.8 Databasstruktur . . . 42 5.1.3 Utvärdering . . . 42 5.1.3.1 Användartest 1 . . . 42 5.1.3.2 Användartest 2 . . . 43 5.1.3.3 Sammanställning av användartester . . . 44 5.1.3.4 Acceptanstester . . . 46 5.2 Metod . . . 46 5.2.1 Förstudie . . . 46
5.2.1.1 Enkätundersökning . . . 46 5.2.1.2 Prototyp . . . 47 5.2.2 Implementation . . . 48 5.2.3 Utvärdering . . . 48 5.2.3.1 Användartester . . . 48 5.2.3.2 Acceptanstester . . . 49 5.2.4 Källkritik . . . 50
5.3 Samhälleliga och etiska aspekter . . . 50
5.3.1 Miljö- och kostnadsaspekter . . . 50
5.3.2 Säkerhet . . . 51
5.3.3 Etiska aspekter . . . 51
6 Slutsats 53
Litteratur 54
7 Bilagor 57
A Bilder: Flödescheman och databas 58
B Ordlista 61
Figurer
2.1 Antal deltagare och identifierade problem vid sannolikhet 0.3. . . 10
4.1 Enkätsvar resultat Hur ofta använder du din cykel? . . . 16
4.2 Enkätsvar resultat Hur mycket skulle du vilja ha betalt per dag för att HYRA UT din cykel 17 4.3 Ursprunglig prototyp för start-sidan. . . 17
4.4 Ursprunglig prototyp för sök-sidan. . . 18
4.5 Ursprunglig prototyp för inloggning- och registrerings-sidan. . . 18
4.6 Applikationens start-sida . . . 19
4.7 Search-sidan med annonser . . . 20
4.8 Jinja if-sats för att se om användaren är inloggad eller ej. . . 20
4.9 Kod-snipp på post till databas för Contact-modalen . . . 21
4.10 Login-sidan . . . 21
4.11 Kod-snipp av hur flask-tillägget flask-mail används. . . 22
4.12 Profil-sidans navigeringselement . . . 22
4.13 Additionssymbol för att skapa en annons samt två exempelannonser. . . 24
4.14 Annons för en cykel. . . 25
4.15 Progress bar för köpprocessen. . . 25
4.16 Exempel på användning av Googles API för att visualisera lokaliseringen av en cykel i Valla. . . 26
4.17 Resultat från testfallet Skapa en profil. . . 27
4.18 Resultat från testfallet Logga in och redigera profil. . . 28
4.19 Resultat från testfallet Skapa en annons. . . 28
4.20 Resultat från testfallet Hitta vem som grundat BikePool. . . 29
4.21 Resultat från testfallen Hyra en cykel. . . 29
4.22 Resultat från enkätundersökningen. Fråga med högst medelvärde. . . 30
4.23 Resultat från enkätundersökningen. Fråga med lägst medelvärde. . . 30
4.24 Resultat från testfallet Skapa en profil. . . 31
4.25 Resultat från testfallet Redigera profil. . . 31
4.26 Resultat från testfallet Skapa en annons. . . 32
4.27 Resultat från testfallet Hitta vem som grundat BikePool. . . 32
4.28 Resultat från testfallen Hyra en cykel. . . 33
4.29 Resultat från enkätundersökningen. Fråga med högst medelvärde. . . 33
4.30 Resultat från enkätundersökningen. Fråga med lägst medelvärde. . . 34
4.31 Resultat från enkätundersökningen. Fråga med lägst medelvärde. . . 34
5.1 Kod-snipp av JS-funktion för att dirigering mellan Divar på samma sida. . . 41
5.2 Total tid för de olika testmomenten. Jämförelse mellan Användartest 1 och 2. . . . 44
5.3 Totalt antal klick för testmomenten. Jämförelse mellan Användartest 1 och 2. . . . 45
5.4 Totalt antal felklick för testmomenten. Jämförelse mellan Användartest 1 och 2. . . 45
5.5 Fördelning av svar från enkätundersökning. Jämförelse mellan Användartest 1 och 2. . . 46
A.1 Flödesschema över förstudiens metodik . . . 58 A.2 Flödesschema över implementationen och utvärderingens metodik . . . 59 A.3 EER-diagram för implementerad databas . . . 60
Tabeller
2.1 Exempel på variabler inom kategoriserande dimensioner . . . 9 4.1 Vidtagna åtgärder för samtliga tester. . . 35
Kapitel 1
Inledning
Kapitlet beskriver motivering till varför studien gjorts, dess syfte, frågeställning samt de av-gränsningar som gjorts.
1.1
Motivering
Många studenter på Linköpings universitet befinner sig någon gång under sin studietid i en situation när de behöver en extra cykel. Det kan exempelvis vara när ens cykel fått punkte-ring och måste repareras, eller när studenten får besök över en helg och vill att besökarna ska kunna ta sig runt i Linköping på cykel. Detta behov bekräftades även av en enkätunder-sökning utförd på studenter på Linköpings universitet, där hela 93.2% svarade att de kunde tänka sig att hyra en cykel när ens egen är trasig alternativt när denne har bekanta på besök. Idag går det att lösa detta problem genom att antingen köpa en helt ny cykel eller besöka Cykelmästaren, en cykelbutik i centrala Linköping där man kan hyra en cykel. Nackdelen med Cykelmästaren är att studenten då måste besöka den fysiska lokalen i Vasastaden, samt att en deposition krävs för att hyra en cykel.
Nedanstående rapport undersöker webbtjänsten BikePool, framtagen av åtta studenter på Linköpings Universitet. BikePool erbjuder ett alternativ som tillämpar delningsekonomi där studenter på Linköpings Universitet på ett enkelt sätt kan komma i kontakt med varandra för att hyra och hyra ut cyklar sinsemellan. Istället för att låta cyklarna stå outnyttjade, kommer BikePools tjänst skapa en möjlighet att hyra ut dem mot ekonomisk kompensation vilket hanterar studenters cykelägande på ett mer resurseffektivt sätt. Exempel på framgångsrika företag som använder sig ut av konceptet om delningsekonomi är Airbnb och Uber.1
För att BikePool ska etableras och användas av den valda målgruppen, ställer det ett an-tal krav på webbtjänsten. För att både hyrare och uthyrare ska bli nöjda när de använder webbtjänsten bör den vara utformad så att den har god användbarhet. [29] En god använd-barhet innebär bland annat att applikationen ska vara enkel och navigerbar. [23] Detta för att inte skapa frustration och förvirring hos användaren.[18] Om tjänsten inte är användbar kan det leda till att användaren inte hittar det den är ute efter och eventuellt slutar använda tjänsten.[29] Detta leder i sin tur till att webbtjänsten inte kan uppfylla sitt syfte.
1.2
Syfte
Syftet med projektet är att undersöka hur en webbtjänst som agerar plattform för hyrning och uthyrning av cyklar ska skapas för att resultatet ska ha god användbarhet i form av navigerbarhet och enkelhet.
1.3
Frågeställning
Hur kan en webbapplikation för uthyrning av cyklar utformas för att uppnå god användbar-het med avseende på enkelanvändbar-het och navigerbaranvändbar-het?
1.4
Avgränsningar
Frågeställningen avgränsar arbetet med att enbart undersöka webbtjänstens användbarhet med avseende på enkelhet och navigerbarhet. Det betyder att projektet och därmed rapporten
1.4. Avgränsningar
inte tar ställning till och inte undersöker faktorer som inte rör dessa aspekter eller andra former av användbarhet.
Vidare avgränsas webbtjänsten till att endast vara en portal för uthyrning/hyrande av cyklar och således inte försäljning/hyrande/uthyrande av andra föremål/tjänster. Även det-ta påverkar både implemendet-tationen samt den faktiska enkelheten och navigerbarheten hos användaren. Detta eftersom att implementationen, baserad på denna avgränsning, implicerar att det finns färre objekt för användaren att se och således hitta.
Slutligen så är projektet avgränsat till att inte hantera den juridiska aspekten av verk-samheten. Innan det att en transaktion görs krävs det av båda användarparterna att dessa accepterar ett avtal. I detta avtal avsäger sig webbtjänsten allt juridiskt ansvar, från och med efter att tjänsten blivit genomförd. Detta kan handla om situationer som äger rum efter det att användarna har nyttjat tjänsten, som kräver juridisk uppmärksamhet, till exempel om cykeln går sönder, försvinner eller blir stulen. Detta påverkar indirekt navigerbarheten hos användaren då det kan komma att uppstå en situation där användaren letar efter assistans i ett juridiskt ärende, men på grund ut av avgränsningen så kan detta ej lokaliseras. Vidare så påverkar det enkelheten direkt eftersom avgränsningen implicerar att användaren inte behö-ver fylla i en stor mängd information, skriva under kontrakt samt gå igenom andra processer relaterade till att göra tjänsten juridiskt korrekt för samtliga parter.
Kapitel 2
Teori
Kapitlet beskriver relevant teori som berör ämnen relaterade till frågeställningen samt teori relaterat till metoden som behövs för att genomföra projektet.
2.1
Konsument-till-konsument-plattform
Konsument-till-konsument (eng. Customer to customer, C2C) verksamheter skiljer sig från företag-till-företag (Business-To-Business, B2B) verksamheter i avseendet att konsumenterna agerar direkt med varandra i en konsument-till-konsument verksamhet.1På Konsument-till-konsument-plattformar behöver vanligtvis säljare betala en avgift för att lägga upp annonser, men ingen extra avgift finns för köpare. Köpare behöver endast betala priset för produkten. C2C förutspås växa i framtiden på grund av dess kostnadseffektivitet då de inte behöver använda sig av återförsäljare, vilket sänker priset [8].
Den stora nackdelen med C2C är svårigheten att garantera betalning och kvalitet. Detta är ett problem som är svårt att åtgärda eftersom det vanligtvis inte är företaget som utvecklar webbapplikationen som ansvarar för dessa områden.2
2.2
Användbarhet
En e-handelswebbplats framgång är delvis relaterad till hur lätt det är att använda den. [15] Det är därför högst relevant att vid utveckling av en e-handelswebbplats att ha användbar-heten i åtanke. Användbarhet är i allmän mening ett mått på att den avsedda användaren av en produkt kan uppnå de mål som berör effektivitet och tillfredsställelse som kan kopplas till produktens specifika användningsområde. I samband med utvecklingen av själva webbap-plikationen bör ett användarcentrerat tillvägagångssätt för design användas [5].
För att vidare kunna mäta huruvida god användbarhet uppnås eller inte, delas använd-barheten upp i tio mindre faktorer, vilket visas i en studie gjord av Lee och Kozar. Med ut-gångspunkt i tidigare studier och med hjälp av experter på området, har författarna Lee och Kozar utvecklat mätvärden, riktlinjer och teorier kopplade till användbarhet. Bland dessa finns faktorerna enkelhet och navigerbarhet. [23] Dessa två faktorer är högt relevanta för frå-geställningen och beskrivs mer ingående i kommande kapitel. Kortfattat kan de tio faktorna förklaras på följande sätt.
• Konsistens - Webbplatsen upprepar samma struktur, komponenter, och övergripande look över sidor.
• Navigerbarhet - Webbplatsen innehåller flera sökfunktioner (till exempel sökmotor, me-nyrader, bak- och framåtknappar, etc.) för att användaren ska kunna erhålla målinfor-mationen.
• Support - När en användare besöker webbplatsen känner användare att de kan få till-gänglig support när de behöver det.
• Lärbarhet - Innehållet som tillhandahålls av webbplatsen är lättförståeligt. • Enkelhet - Webbplatsens struktur är kortfattad.
1C2C e-commerce
2.2. Användbarhet
• Interaktivitet - Webbplatsen ger en lämplig mängd av interaktiva funktioner (t ex grafik, popup-fönster, animering, musik, röster).
• Telenärvaro - Användare känner empati gentemot webbplatsen.
• Trovärdighet - Användare känner sig trygga i deras transaktioner med webbplatsen. • Innehållsrelevans - Webbplatsen innehåller fördjupad och aktuell information.
Omfatt-ningen av informationen som tillhandahålls av webbplatsen är lämplig. • Läsbarhet - Webbplatsens formulering är tydlig och lätt att förstå.
Rapporten kommer att avgränsas till att behandla faktorerna, enkelhet och navigerbarhet på grund av att studier visar att en webbtjänsts framgång är starkt kopplad till dessa faktorer samt att användare har en tendens att gå vidare till andra e-butiker eller tjänster om det är så att aktuell webbtjänst är svår att navigera och onödigt komplicerad. [11]
2.2.1
Enkelhet
Lee och Kozar visar i sin studie att en webbapplikation upplevs enkel då strukturen är kort-fattad, och de flesta komponenterna på sidan kan nås på ett fåtal sekunder. Den studie för-fattarna har utfört pekar även på att det finns en stark korrelation mellan enkelhet och na-vigerbarhet. De menar att en ökad enkelhet även ger upphov till en god nana-vigerbarhet. Just enkelheten handlar främst om att ta bort alla onödiga element som rör design och innehåll. Exempel på onödiga element kan vara bilder i sidhuvud och sidfot, ramar runt bilder och skuggor. En enkel webbapplikation bidrar till följande fördelar, alla kopplade till användbar-het. [23]
• Enklare att navigera eftersom en enkel webbsida har färre sidor och sektioner. Den är också mindre rörig i och med att navigationselementen enklare kan hittas.
• Snabbare laddningstid eftersom en enkel webbsida har mindre innehåll, vilket ger en lägre laddningstid.
• Innehållet blir enklare att läsa och förstå eftersom en enkel webbsida utan dekorativa element istället gör att innehållet sätts i fokus.
För att uppnå enkelhet och därmed de ovanstående fördelarna, bör den som designar webbapplikationen utgå från nedan beskrivna riktlinjer vid skapandet.
2.2.1.1 Arkitektur
En webbapplikations arkitektur beskriver hur applikationen är uppbyggd och konstruerad med avseende på dess utseende. Eccher påpekar vikten av att man som designer av en web-bapplikation utgår från ett flertal aspekter vid uppbyggnaden av en enkel arkitektur. Den första aspekten Eccher tar upp är att dämpa designerns kreativa input när det kommer till design av rubriker och länkar. Vikten ska ligga på intuitiv design och beskrivning och på så sätt minska antalet bildliga uttryck och symboler. Teorin bygger på att användaren vid första anblick ska kunna associera sektionen eller sidan till det förväntade. [9]
Vidare beskriver Eccher att nästa viktiga aspekt är användningen av en djup arkitektur, även kallad fallande arkitektur. Detta betyder att större delen av informationen som skulle kunnat presenteras på förstasidan elimineras. Istället grupperas all information med liknan-de innebörd ihop och presenteras i andra liknan-delar av webbsidan. Detta gör att användare slipper söka igenom lika mycket information för att uppnå sitt mål, vilket i sin tur gör att webbap-plikationen blir mer enkel. [9]
2.2. Användbarhet
2.2.1.2 Färgval
Tekniken i att designa en tillgänglig och enkel webbapplikation behöver inte nödvändigtvis implicera att applikationen måste vara färglös och tråkig. Dock måste man som designer ta hänsyn till att många användare har nedsatt syn eller andra synfel. Detta gör i sin tur att det blir ännu viktigare att det visuella presenteras på ett korrekt sätt så att hela målgruppen kan nås. Barney påstår att rätt färgkodning skapar ledtrådar för användaren att enklare och mer intuitivt hitta den sökta informationen. [2]
Oftast är det framgångsrikt att som designer använda sig av en kärnfärg. Detta menar Garrett skapar en identitet för varumärket och gör webbapplikationen tydlig och lätt att över-skåda. Med utgångspunkt i kärnfärgen kan en bredare palett skapas men det är då viktigt att färgerna kompletterar varandra väl. [10]
2.2.1.3 Textens utseende och presentation
Wu och Yuan skriver i sin rapport om vilka riktlinjer man som designer borde utgå ifrån när text ska presenteras på ett så enkelt och effektivt sätt som möjligt på en webbsida. De menar att det finns tre viktiga aspekter att utgå ifrån. En av dessa handlar om att välja om texten ska presenteras i en tabell eller i ett brödtextformat. Listan nedan beskriver för vilken typ av innehåll som de olika formaten bör användas. [41]
• Menyer och sidofält bör vara i tabellform.
• Nyheter och beskrivande innehåll bör presenteras i brödtext. • Objekt med liknande struktur bör vara i tabellform.
En annan aspekt som Wu och Yuan tar upp är att det kan vara användbart att gruppe-ra textinnehåll med hjälp av olika bakgrundsfärger. På så sätt gränsas stycket av från den resterande texten. Detta bidrar till en enkelhet och därmed till en ökad läshastighet för an-vändarna. [41] Vidare påstår Barney i hennes rapport om desgin av webbsidor för universiell användbarhet att för ökad läsbarhet och enkelhet, bör texten vara skriven med ett teckensnitt av typen sans-serif. Detta för att leda användaren till att läsa horisontellt och på så vis inte låta användaren att läsa på fel rad.[2]
Leavitt och Schneiderman menar att texten som presenteras bör vara skrivet i ett känt typsnitt med en storlek på minst 12 pixlar. Texten bör vara svart och vara placerad på en bakgrund med hög kontrast mot det svarta. Detta eftersom det bidrar till en effektivare kom-munikation med användaren. [36]
Användning av mönstrade bakgrundsbilder bör tillämpas försiktigt då de kan försvåra läsbarheten av text. Barney menar att om en bakgrundsbild krävs bör denna vara så subtil och svag att texten ovan är i stor kontrast till bilden. [2]
2.2.1.4 Köpprocess
För att skapa en väl fungerande köpprocess krävs det att denna är enkel och att den optimeras så att fler kunder köper produkten eller tjänsten. Det första steget för en enkel köpprocess har sin utgångspunkt i att optimera hur själva processen, från första till sista steg, bör utformas. Page påpekar då att följande riktlinjer bör tillämpas [32]:
• Ett fält som indikerar var köparen befinner sig i köpprocessen bör alltid synas tydligt på sidan.
2.2. Användbarhet
En tredje aspekt som Page menar skapar en enkel köpprocess för användaren är att utfor-ma och optimera sidorna för granskning av ordern och orderbekräftelse. För att användaren ska kunna granska att ordern stämmer innan transaktionen går igenom ska en sida för detta visas. Denna sida bör innehålla följande information [32]:
• Produkt/tjänst och dess kvantitet. • Totala kostnaden.
• Leveransadress.
När transaktionen är genomförd bör en sida för orderbekräftelse dyka upp. Denna bör inne-hålla följande information [32]:
• Ett tack till kunden att den handlat på sidan.
• Ett referensnummer så att kunden kan spåra sin produkt.
2.2.2
Navigerbarhet
Enligt en undersökning utförd av U.S. Department of Health and Human Services definieras navigerbarhet som metodiken för att hitta information på en webbplats. Vidare kom de fram till i undersökningen att en sidas navigerbarhet, sett till dess funktioner och utformning av navigationselement, det vill säga olika typer av knappar, listor, formulär och mer, bör vara designade på ett sätt som ger användaren effektiv tillgång till information. [36]
Innehåll som är svårt att förstå, inkonsekventa format, problem att navigera, desorien-tering och ineffektiva sökfunktioner är användbarhetsproblem relaterade till navigerbarhet som ofta identifieras med kommersiella webbplatser. Detta leder på sikt till färre användare eller att e-handelsföretaget inte lyckas ta sig in på en e-handelsmarknaden. [23] Det är därför högst relevant att bygga webbsidor med hög navigerbarhet.
Nedan följer en rad aspekter som bör tas i hänsyn i utformandet av en webbsida för att uppnå en kvalitativ navigerbarhet.
2.2.2.1 Placering och utformning av element på webbsidan
Stukturen på navigationselement bör vara konsistent över hela webbsidan. Primärflikar, sök-fält, listor och dylikt ska behålla sin position oavsett vilken del av webbsidan användaren befinner sig på. Detta för att lätt kunna navigera sig vidare samt för att erhålla en förståelse över hur navigationen på webbsidan går till, det vill säga att användare förstår sig på navi-gationsstrukturen. Detta tillför även att användaren kan ägna mer besökstid åt webbsidan då den känner sig bekväm i att använda den, eftersom kunskapen om sidans navigationsstuktur växer för varje besökt sida av webbsidan. [36, 33] Sedermera så har placering av navigations-element visat sig vara bäst lämpad i det topp-vänstra segmentet av webbsidan för att uppnå hög navigerbarhet.[19].
Enligt U.S. Department of Health and Human Services ska navigationselementen vara ut-formade på ett sådant sätt att användare på ett enkelt sätt ska kunna förstå skillnader med mening och funktion/måldestination på respektive element. Vidare ska elementen grupperas efter relevans mellan varandra, för att simplifiera och reducera söktiden hos användaren till respektive element. [36, 22] Vidare även genom att implementera funktionen att kunna sväva över elementet med muspekaren för att få en text-baserad överblick av elementets funktion. [33] Att få en sådan överblick ger användaren förståelse och en korrekt förväntning av vad som sker när användaren klickar på det aktuella navigationselementet. Detta är essentiellt eftersom att ifall en användare inte vet var ett knapptryck leder den, är det hög risk att fru-stration hos användaren skapas och att denne känner sig missnöjd med webbtjänsten. Detta kan innebära att användaren direkt överger webbtjänsten och söker sig till andra alternativa källor för att uppfylla sitt behov. [26]
2.2. Användbarhet
2.2.2.2 Navigationsmeny
En navigationsmeny adderas på en webbsida för att hjälpa användaren att navigera sig mel-lan olika sidor. I en undersökning gjord av Mcgillis och Toms visade det sig att över 60 % av användarna tyckte att en navigationsmeny var till hjälp och betydelsefull för sidan.[27] Det är viktigt att navigationsmenyn bland annat innehåller länkar till sidorna Kontakta oss och Om oss [37]. Det bör också vara tydligt att dessa länkar är klickbara. [27] Navigationsmeny, bör vara placerad längst upp på sidan och denna meny med länkar bör alltid dyka upp på samma ställe oavsett vilken sida användaren befinner sig på. [20]
2.2.2.3 Rullgardinsmeny
Istället för att låta användaren gå genom ett flertal undersidor och nivåer i webbsidan genom att trycka på en sekvens av navigationselement, bör navigationselement istället designas med en hierarki-form representerat i en typ av rullgardinsmeny. Genom att sväva över ett huvu-delement så dyker dess undersidor upp och sedan deras undersidor i sin tur. Detta gör det möjligt för användare att navigera långt in i webbsidans innehåll med endast ett knapptryck och eliminerar eventuell förvirring hos användaren om var denna är. Det innebär också en tydligare inblick i sidans innehåll, och innebär möjlighet att återgå till föregående sida med endast ett knapptryck bakåt. Detta istället för att behöva klicka ett flertal gånger i rad. [17] 2.2.2.4 Undvika dead-end vid navigering
Navigation på sidan, genom att klicka på navigationselement, bör aldrig resultera i att en användare ej kan navigera sig vidare. En användare bör alltid ha möjligheten till att minst navigera sig till start-sidan med endast ett knapptryck, detta gäller även för andra vitala sidor på webbsidan. Detta navigationselement bör vara utformad som en knapp och bör vara lokaliserad på ett pålitligt ställe som lätt hittas, t.ex uppe i vänstra hörnet. [33]
2.2.2.5 Single-Page design
Många av det ovannämnda faktorerna för att uppnå en god navigerbarhet kan lätt imple-menteras om teorin och metodiken om Single-Page design anammas. Teorin bygger på att, istället för att ha flera olika sidor kring samma huvudämne, endast har en sida som använda-ren istället scrollar på. Detta för att undvika att användare tappar bort sig på webbsidan och upplever missnöje samt frustration, genom att behöva gå igenom ett flertal sidor för att hitta den sökta informationen. [28]
Vidare bör det vid single-page design även implementeras ett navigationselement som följer med användare genom scrollning på sidan och som låter användare gå tillbaka till top-pen av den aktuella sidan med endast ett knapptryck. Fortsättningsvis så medför en single-page design att eventuella laddningstider för att gå emellan sidor elimineras storskaligt, ef-tersom allt innehåll laddas samtidigt, endast en gång, på sidan. [28] Dock kan fallet vara så att om sidan innehåller en väldigt stor mängd data kan detta implicera att just den enskilda laddningstiden är väldigt lång, vilket resulterar i frustration hos användare. [18].En single-page design kan emellertid medföra att användare kommer till en återvändsgränd, det vill säga att användare inte kan navigera sig vidare. [18]
2.2.2.6 Logotyp för webbtjänst
Webbtjänsten bör presentera sin logga på sidan, på varje sida tillhörande webbtjänsten. Den-na logotyp bör vara klickbar och ta användare till startsidan. Detta är fundamentalt för att er-hålla en hög navigerbarhet. Logotypen ger användare möjligheten till att alltid hitta tillbaka
2.3. Metodteori
för användaren att återvända till start-sidan, i jämförelse med om logotypen var placerad i mitten av den aktuella sidan. [38, 3]
2.3
Metodteori
Följande kapitel lägger fram teori som ligger till grund för de val av metoder som gjorts under processen att ta fram webbapplikationen. De teorier som presenteras täcker det förstu-diearbete som gjorts med enkät, brainwriting och prototyp samt arbetet i implemetation och utvärdering med testning.
2.3.1
Förstudie
Under förstudien arbetades det med att ta fram och besluta kring idéer med hjälp av hand-ledning, använda sig av brainwriting samt att utforma, skicka ut och analysera enkätunder-sökning. Även att utforma en initial prototyp, se flödesschema i bilaga A (Figur A.1).
2.3.1.1 Enkätmetodik
Utformning av en enkät består av att göra frågeformuleringar med tillhörande formuleringar av svar, för att sedan arrangera frågorna i relevant ordning. Därefter ska en lämplig distribu-tionskanal identifieras och enkäten kan skickas ut. [12]
Enkätfrågor kan delas in i olika grupper; det finns attribut och egenskaper, som till ex-empel ålder eller ägodelar, beteenden och vanor, mätt i exex-empelvis tid eller frekvens samt kategorin åsikter och värderingar. [12] En medvetenhet kring de olika kategorierna för fråge-formulering kan leda till en tydligare bild kring hur de olika frågorna ska mätas, samt att se till att frågor i alla kategorier formuleras för att få en så tydlig och tillförlitlig bild över situationen som möjligt. Vid formulering av frågor till enkäten är det ytterligare viktigt att frågan ska vara så tydlig att den ska tolkas på samma sätt av samtliga svaranden, samtidigt som frågan ska vara enkel och så kort som möjligt utan att förståelsen ska påverkas. [34]
Vidare ska svar formuleras till frågorna på ett sådant sätt att insamlat data är enkelt och tydligt att bearbeta. Ställning ska tas kring om svaren ska vara öppna, slutna, utgöras av verbala svar eller siffror. De slutna svaren anses vara normen för formulering av svar och har fördelen att datan blir relativt enkel att analysera jämfört med datan som samlas in från öppna svarsalternativ. Vid formulering av svarsalternativ för slutna svar, bör svaren vara hel-täckande, med ett rimligt antal alternativ. För många alternativ får läsaren att tappa intresset. Det finns även möjlighet att formulera svaret på så sätt att svaret är delvis slutet, och om svar ges på ett specifikt alternativ, måste svaret motiveras eller specificeras med ett öppet svar. [34]
När frågor och svar för enkäten är formulerade och sammanställda, bör den distribueras på ett sådant sätt att den är lättillgänglig för målgruppen. Vid utskickning finns det ett antal faktorer som bör uppfyllas för en framgångsrik distribuering. Att hitta rätt målgrupp, att ha starka sociala färdigheter vid utskickning av enkäten samt att göra utskicken personligt. [34] 2.3.1.2 Utvärdering av enkät
Genom att svaren formuleras med slutna svar, kan data sammanställas och analyseras på ett översiktligt och korrekt sätt. Svaren på de slutna frågorna sammanställs och visualiseras så att det går att stärka eller dementera framtagna hypoteser. [34]
2.3.1.3 Brainwriting
Brainwriting är en alternativ metod till brainstorming, där individer i gruppen har som upp-gift att ta fram tre idéer under fem minuter, och upprepa detta sex gånger. Idéerna skrivs ned på ett papper som sedan skickas vidare mellan medlemmarna. På så sätt undviks risken att
2.3. Metodteori
en person måste dokumentera alla idéer som nämns och därmed inte kan bidra till diskussio-nen fullt ut. Brainwriting uppmuntrar till att medlemmarna ska använda och bygga vidare på de tidigare skrivna idéerna och på så sätt skapa en kreativ skapandeprocess. Processen syftar till, till skillnad från brainstorming, att skapa en process där allas idéer lyfts, inte bara de som hörs mest.[16]
2.3.1.4 Marknadsföringsplan
Till skillnad från en affärsplan, som erbjuder en överblick över hela organisationens uppdrag, mål, strategi och resursfördelning, har en marknadsföringsplan en mer begränsad räckvidd. Den tjänar till att dokumentera hur organisationens strategiska mål kommer att uppnås ge-nom specifika marknadsföringsstrategier och taktik, med kunden som utgångspunkt.[21]
I en marknadsföringsplan analyseras marknaden, befintliga konkurrenter och de interna kompetenser som ett företag besitter för att öka chanserna av ett lyckat resultat av projektet. [21] I detta projekts marknadsföringsplan används ramverk som STP-analys (Segmentering, Targeting, Positioning), SWOT-analys (Strengths, Weaknesses, Opportunities samt Threats) och en PESTEL-analys (Political, Environmental, Social, Technological, Economical, Law). 2.3.1.5 Prototyp
Att göra en prototyp är en mycket viktig del i designprocessen, då den ger projektgrupper möjligheten att diskutera, utforska och värdera olika designer på ett enkelt sätt. En proto-typ kan även ställas inför externa testgrupper som då kan inflika åsikter kring designer och navigationsmöjligheter. [31] När en prototyp skapas går det att utgå från så kallade filtering dimensions, vilket är kategoriserade dimensioner menade att beskriva de viktigaste aspek-terna. Genom att utgå från dimensionerna utseende, data, funktionalitet, interaktivitet och spatial struktur, ges en tydlig struktur över hur en komplett prototyp ska göras, som kan ses i tabell 2.1.[25]
Tabell 2.1: Exempel på variabler inom kategoriserande dimensioner Kategoriserande dimension Exempel på variabler inom dimensionen
Utseende storlek, färg, form
Data datastorlek, datatyp, hierarki, organisation Funktionalitet systemfunktion, användarfunktionalitet Interaktivitet input- och outputbeteende
Spatial struktur relation mellan objekt och element
2.3.2
Scrum-metodologin
För många projekt är just Scrum-metodologin väldigt lämplig att använda sig av; i synnerhet i projekt med ett lägre antal medlemmar, eftersom metodologin är skapad och anpassad för flexibilitet. Bland annat finns kontrollmekanismer för att kontrollera att allt går rätt till i pro-jektet, exempelvis daily scrum möten. Dessa skapar en större flexibilitet i propro-jektet, och som ett resultat av detta skapas möjligheter att snabbt ta nya vändningar i projektet vid behov. Även slutprodukten blir mer flexibel eftersom den kan förändras under projektets gång, ifall projektmedlemmarna till exempel skulle inse att en viss funktionalitet eller annan del av pro-dukten är ohållbar. [35] En projektgrupp av mindre storlek gör också att en snabb och smidig kunskapsöverföring sker inom gruppen; detta som ett resultat av kontinuerliga daily scrum möten. [35]
2.3. Metodteori
2.3.3
Par-programmering
Par-programmering är en agil mjukvaruutvecklingsteknik som innebär att två programme-rare arbetar tillsammans vid en dator eller arbetsstation. En av programmerarna agerar föprogramme-rare medans den andre agerar navigatör. [39] Parprogrammering är snabbare och effektivare än so-loprogrammering när uppgiften inte är vidare komplex. Parprogrammering ger också högre kvalité på lösningarna då problemen är komplexa. Dock kan parprogrammering innebära lägre arbetsmoral och engagemang. [13].
2.3.4
Utvärdering
För att kontinuerligt utvärdera och kontrollera projektet utförs tester. I enlighet med Scrum-metodologin, bidrar tester till att kunna bestämma vilka förändringar som ska göras under projektets gång. Se flödesschema över utvärderingsprocessen i bilaga A, (Figur A.2). [35] 2.3.4.1 Antal deltagare vid testning
För att på ett tillförlitligt sätt identifiera problem gällande användbarhet krävs enligt flera studier minst fem deltagare. Dessa studier menar att ungefär 80 procent av alla fel kommer att upptäckas genom de fem första deltagarna.[1, 24, 30, 40] (Figur 2.1)
Albert och Tullis skriver dock att en brist med att bara använda fem deltagare är att det kan vara stor skillnad mellan individerna som testar. Det kan vara tillräckligt för att inte kunna identifiera problemen. [1]
Figur 2.1: Antal deltagare och identifierade problem vid sannolikhet 0.3.
2.3.4.2 Acceptanstester
Acceptanstester görs i projekt där leveransen sker direkt till en kund, och har syftet att kun-den ska acceptera slutprodukten som framställts av projektgruppen. Kriterierna för accep-tanstestet tas utifrån kravspecifikationen som tidigare getts.3
Ett acceptanstest utförs på färdig funktionalitet under projektets gång. Då görs dessa tes-ter i ett par steg; först görs en testplan. En testplan är en rad testfall gjorda för att testa alla olika situationer som en användare kan vara i då denna använder produkten. Därefter utgör denna testplan grunden för testningen, och denna testning måste göras av användare som inte har någon som helst insikt i bakomliggande funktioner på hemsidan, som till exempel beställaren.4
3Acceptanstester http://www.sast.se/q-moten/2010/stockholm/q15/SAST_Q15_Rylander_Acceptanstest_ar_mer_an_du_tror.pdf 4Testning http://www.cse.chalmers.se/edu/year/2016/course/TDA550/Resources/Testning.pdf
2.3. Metodteori
2.3.4.3 Användartester
Användartester används för att låta projektgrupper skapa sig en uppfattning om användares tankar och behov för produkten. Dessa blir, i kombination med Scrum-metodologin, kontinu-erliga prövningar av produkten som påverkar design och funktionalitet, beroende på utfallet av testerna. Dessa kan då bidra till en större kundnöjdhet och produktens nytta. De har visat sig vara en oerhört effektiv metod för att kartlägga problem med användbarhet. På grund av detta är det en väldigt bra metod för att utvärdera en webbsidas användbarhet. [14]
När användartester genomförs som har sitt fokus på att utvärdera navigerbarhet och en-kelhet är det bäst att låta personer som valts ut utifrån en målgruppsprofil att använda de nyligen utvecklade funktionerna. [14] Användarna frågas sedan ut via frågeformulär eller intervjuer, utformade så att frågorna är enkla och tydliga för att lyckas få ut så mycket infor-mation som möjligt för vidareutveckling. [34] Frågorna kan exempelvis vara rankningsfrågor, där den intervjuade på en skala 1-5 får uttrycka sin uppfattning kring olika delar av använd-barheten. [7]
Nedan beskrivs fem grundläggande prestandamått som är användbara vid användartes-ter. [1]
• Task success. Det vanligaste prestandamåttet som beskriver om användaren lyckas kla-ra av uppgiften eller inte. Det går att mäta två typer av fkla-ramgång, binär fkla-ramgång eller nivå av framgång, där binär framgång är det enklaste alternativet att mäta.
• Time on task. Ett mått på hur lång tid det tar för användaren att slutföra en uppgift. Detta mått är extra viktigt att mäta om uppgiften repeteras ofta. Sedermera, vid ana-lys av mätningen är det viktigt att som testare ha i åtanke att användare kan ha olika mycket vana med system som liknar det som ska testas.
• Efficiency. Ett mått på hur mycket användaren behöver anstränga sig för att klara av uppgiften. Exempelvis mäts antalet klick eller steg i processen. Återigen är det viktigt att tydligt definiera uppgiftens start- och stoppunkt.
• Errors. Är ett mått på antalet fel som användaren gör under uppgiftens gång. För att korrekt mäta detta antal krävs det att uppgiften är tydligt definierad.
• Learnability. Mäter hur snabbt användarens prestanda förbättras vid upprepade tester. Lärbarheten mäts oftast genom att vid upprepade tester mäta tiden det tar för använ-daren att slutföra uppgiften.
Kapitel 3
Metod
Tillvägagångssättet för metoden innebar att göra en förstudie med olika aktiviteter, sedan implementation och därefter en utvärdering av arbetet.
3.1
Förstudie
Målet med förstudien var att göra en preliminär studie för att kartlägga hela projektet. Meto-den för förstudien delades in i arbete med enkätundersökning, brainwriting och framtagning av prototyp samt att litteratur togs fram för att kunna stödja metodarbetet.
3.1.1
Enkätundersökning
För att kunna identifiera, bekräfta och få en tydligare uppfattning om situationen för cykel-behov bland Linköpings studenter, gjordes en enkätundersökning, se Appendix A1: Mark-nadsundersökning. Processen inleddes med att formulera enkla och tydliga frågor för att säkerställa att de som svarar på enkäten har motivation att svara på frågorna samt förståel-se för dem. [34] Eftersom att BikePool är en konsument-till-konsument-plattform som riktar sig till både de som hyr ut och de som hyr cyklar, var det viktigt att formulera frågorna så att tydlighet och distinktion gavs kring de båda målgrupperna. Frågorna som formulerades kategoriserades för att skapa tydlighet samt att säkerställa att all eftersökt information sam-lades in.[12] Enkäten efterfrågade information om studenten äger en cykel eller inte samt hur beteenden och vanor angående användningsfrekvensen av sin cykel såg ut. Under kategorin åsikter och värderingar efterfrågades prissättning av eventuell cykeluthyrning. Dessa frågor utformades på ett sätt som säkerställde att ett behov av tjänsten fanns och att marknaden skulle kunna existera. Ytterligare efterfrågades åsikter kring utformningen av webbapplika-tionen.
Enkätens svar formulerades med slutna svar för att på ett säkert och tydligt sätt samla in användbar och komplett data.[34] Enkäten distribuerades därefter via studentgrupper för studenter på Linköpings universitet på Facebook för att nå målgruppen, studenter på Linkö-pings Universitet.
3.1.2
Prototyp
En prototyp för slutprodukten togs fram. Bilder togs fram med hjälp av Keynote i syfte att följa de riktlinjer som sattes upp i och med frågeställningen samt resultaten av enkätunder-sökningen. Dess funktionalitet togs fram genom metoden brainwriting, en påvisat bra metod för att få fram idéer från hela gruppen. [16] I prototypen utvecklades dimensionerna funk-tionalitet, utseende, interaktivitet och spatial struktur, för att göra prototypen komplett [25]. När denna prototyp framställts i form av en lista på önskad funktionalitet, designades en prototypen sedan genom presentationsprogrammet KeyNote, som hade sitt fokus på utseen-de och struktur. Här skapautseen-des visuella bilutseen-der över olika möjliga prototyper, och därmed för hela användarupplevelsen på webbplatsen.
3.2
Implementation
Projektet utfördes i sammanlagt fyra faser av olika längd, även kallade Scrum-iterationer eller sprintar [35]. I de olika sprintarna gjordes olika saker; i den första planerades arbetet, och en teoretisk bas för att effektivt kunna skapa slutprodukten i nästkommande iterationer lades fram. Inför varje iteration planerades först arbetet, och tidigare arbete användes för att
3.3. Utvärdering
utvärdera hur gruppen skulle förbättras inför nästa sprint. Därmed delades uppgifter ut som kunde utföras av olika grupper parallellt vid planeringen, för att kunna effektivisera arbetet. Implementationen av webbtjänsten skedde i huvudsak i form av kodutveckling. Med det-ta menas att webbsidan utvecklades i den mån som gruppen i försdet-ta iterationen kommit överens om, med prototypen som utgångspunkt. Utvecklingen skedde framförallt i två delar, front-end och back-end.
3.2.1
Front-end
Utvecklingen inom front-end innebar att utveckla det som användaren möter; designen, själ-va utseendet på sidan. Denna utveckling skedde främst utefter den visuella prototypen som framställdes i den första iterationen. Själva utvecklandet utfördes framförallt i CSS, HTML och JavaScript, och ramverket Bootstrap underlättade manipulation av innehållet på webbsi-dan. Användandet av det sistnämnda och alla de olika inbyggda funktionerna som ingick är ofta färdigutvecklade, vilket underlättade arbetet.
JavaScript och tilläggsbiblioteket JQuery användes för att hantera front-end funktioner. Dessa JavaScript-funktioner bidrog både med kommunikation mellan server och användare, men också rendering av innehåll. Användandet av JQuery hanterade risken att webbsidan kan reagera olika på olika webbläsare. En minskad risk för att sidan inte är kompatibel med olika webbläsare bidrog till en ökad användbarhet för samtliga webbläsare.1
3.2.2
Back-end
Back-end-utvecklingen bestod av implementation och utveckling av databaslogik och ser-verfunktionalitet på hemsidan. Det innebar att de funktioner som tagits fram genom user stories implementerades. Back-end-utvecklingen skedde i en flask-baserad miljö, ett Python-ramverk som inkluderade bibliotek som Jinja2 och Werkzeug.2
3.3
Utvärdering
Projektets utveckling och framsteg utvärderades löpande. Efter varje sprint testades såväl funktionalitet som användbarhet med individer som stämde in på BikePools målgrupp. I slutet av arbetet genomfördes ett acceptanstest, som avgjorde huruvida de funktioner som tidigare planerats implementeras faktiskt blivit implementerade, och ifall de uppfyllde de krav som bestämts initialt i projektet.
3.3.1
Användartester
Användartester genomfördes i slutet av sprint 2 respektive sprint 3 med fem testpersoner varje gång, noggrant utvalda enligt identifierad målgrupp. Testdeltagarna studerade alla på Linköpings Universitet i varierande årskurser och hela testgruppen bestod av lika många män som kvinnor. Alla test nedan utfördes av en person åt gången i ett rum som var tyst utan andra distraktionsmoment. Testen utfördes av tre testledare där en agerade tidtagare och räknade antal klick, en beskrev för testdeltagaren vad uppgiften var och ledde testaren genom testet medan den sista observerade skärmen. Testpersonen började med att utföra ett antal uppgifter och varje uppgift utfördes en gång av testaren. Punkt tre nedan utfördes dock två gånger för att kunna jämföra tiden mellan första och andra gången uppgiften genomfördes.
• Skapa en profil.
3.3. Utvärdering
• Hyr en cykel mellan datum xx/xx och xx/xx med följande attribut: x, x, x, samt betala för den. (Datumen bestämdes precis inför testet och det säkerställdes att cyklar fanns tillgängliga under de valda datumen).
• Ta reda på vilka som har grundat BikePool. • Lägg upp en annons för din egen cykel.
För respektive deluppgift togs följande data, vilken en av testledarna var ansvarig för att dokumentera:
• Tiden det tog från att testaren gick in på sidan tills det att uppgiften var genomförd. • Antalet klick som gjordes från det att testaren gick in på sidan tills det att uppgiften var
genomförd.
• Antalet fel testaren gjorde från det att testaren gick in på sidan tills det att uppgiften var genomförd.
• Tidsskillnaden mellan första och andra gången uppgiften gjordes.
Ytterligare ställdes ett antal frågor till testdeltagaren. Dessa frågor var utformade utefter de fem grundläggande prestandamåtten [1]. Frågorna besvarades på en skala från 1-5, där 1 innebar att testaren inte instämde med påståendet och 5 innebar att testaren instämde helt.
Frågor om enkelhet:
• Det var enkelt att skapa en profil. • Det var enkelt att ändra min profil.
• Det var enkelt att hyra en cykel (det vill säga sortera bland cyklar och gå vidare till betalning).
• Det var enkelt att som uthyrare lägga upp en annons. • Det var enkelt att förstå sidans syfte.
Frågor kring navigerbarhet:
• Jag tycker att elementen i navigeringsmenyn är tydliga.
• Jag förstod direkt var jag skulle klicka för att hitta lediga cyklar.
• Det var tydligt att jag kunde läsa mer på hjälp-sidan när jag inte förstod hur jag skulle gå tillväga.
3.3.2
Acceptanstester
Acceptanstester gjordes kontinuerligt under varje sprint, samt ett slutgiltigt acceptanstest i slutet av projektet utifrån en framtagen definition of done. Detta valdes för att lättare och snab-bare kunna se över vad som behövde göras bättre. Koden som någon skrivit testades därefter av en annan. Buggar som hittades under dessa tester fördes in som kort i Trello. Allteftersom koden förbättrades genom att buggarna som hittats under dessa tester eliminerades.
Definition of done-dokumentet som togs fram under projektet resulterade i följande krav för sidorna: Home, About, My Profile, Register, Leave a Review, File a Complaint, Order History, Payment, Payment Done:
• Kunna uppdatera sidan. • Sidan ska ha en footer.
3.3. Utvärdering
• Kunna navigera med fram- och bakåtpilen.
• Navigeringsmenyn ska finnas på alla sidor och rubriken ska vara markerad. • Alla knappar ska se likadana ut och ha zoom-effekt.
• Alla sidans funktioner ska fungera.
• Javascript och CSS-kod är utflyttade från html-filerna. • Det ska inte finnas dubbla importer i någon fil.
• Skalning ska fungera för små, medium och stora skärmar. • Inga felmeddelanden i terminalen eller konsolloggen.
Ytterligare formulerades en definition of done för de modaler som användes på hemsidan: • Vit rubrik med blå bakgrund.
• All text (förutom rubrik) ska vara grå.
• Modalen ska försvinna då man trycker på close, kryss eller utanför modalen. • Det ska gå att navigera med fram- och bakåtpilarna.
Kapitel 4
Resultat
I nedanstående kapitel presenteras resultatet av förstudie, implementation och utvärdering. Till grund för resultatet ligger den teori som presenterats i kapitel två.
4.1
Förstudie
Avsnittet nedan behandlar resultatet av den förstudie som låg till grund för projektet. Detta inkluderar resultatet av enkätundersökningen som skapats och distribuerats samt den ur-sprungliga prototypen.
4.1.1
Enkätundersökning
Enkätundersökningen resulterade i en stor mängd data från de 147 svarande och låg som grund för både den prototyp som senare togs fram samt en mängd av de ingående funktio-nerna som implementerades i webbtjänsten.
Samtliga svarande uppgav att de ägde en cykel, varav 14.3 % svarade att de kunde tänka sig att hyra ut sin cykel till vem som helst. 41.5 % procent svarade däremot att de endast var villiga att hyra ut sin cykel till en annan student. När frågan ställdes om man själv skulle kunna tänka sig att hyra en cykel var svaret ett ja med en procentsats på 93.2 % av svaren. 75.5 % angav att de använder sin cykel varje veckodag. Endast 1 person uppgav att de aldrig använder sin cykel (Figur 4.1). På frågan om hen skulle kunna tänka sig att faktiskt hyra en cykel när ens egen är trasig alternativt när denne har bekanta på besök svarade den stora majoriteten, 93.2 %, ja och resten nej.
Figur 4.1: Enkätsvar resultat Hur ofta använder du din cykel?
Gällande prissättning svarade 43.4 % att summan att få betalt för att hyra ut sin cykel rimligen ligger mellan 40-60 kr per dag och 36.6 % angav att en rimlig betalning för att hyra ut sin cykel skulle ligga på mer än 60 kr per dag, se bilaga C (Figur 4.2). När motfrågan senare ställdes, alltså hur mycket en person var villig att betala per dag för att hyra en cykel sva-rade 30.6 % att summan skulle vara mindre än 70 kr per dag och 51 % svasva-rade att summan bör vara mindre än 50 kr per dag. Därefter ställdes frågan om hur en önskvärd betalnings-funktion skulle se ut varav majoriteten, 52,4 %, angav att det skulle känns mest bekvämt om betalningen skedde automatiskt via en hemsida.
4.1. Förstudie
Figur 4.2: Enkätsvar resultat Hur mycket skulle du vilja ha betalt per dag för att HYRA UT din cykel
I resultatet på frågan om vad som anses vara den viktigaste delen i hyrandet av en cykel framgick det att den viktigaste aspekten, med 43.5 % av rösterna, var att det skulle gå snabbt, följt av priset på 36.1 % samt att det skulle kännas tryggt att hyra på 20.4 %. Fortsättningsvis framgick ytterligare information, bland annat om vilken som är den viktigaste informationen i uthyrandet av en cykel, där den svarande fick välja flera alternativ. De tre viktigaste sakerna utsågs vara att det fanns en bild på cykeln, var cykeln kunde hämtas samt tillgängligheten på cykeln i fråga. Inte långt efter på fjärdeplats var informationen om vilket skick cykeln befann sig i, följt av information om storlek, korg, lampa.
4.1.2
Prototyp
Nedan presenteras tre bilder som motsvarar den ursprungliga prototypen som skapats för BikePool. Prototyperna låg till grund för utformandet av tjänsten. Den ursprungliga idén om hur start-sidan skulle designas, gjordes ur ett funktionellt samt visuellt perspektiv (Figur 4.3).
Figur 4.3: Ursprunglig prototyp för start-sidan.
Enligt den ursprungliga prototypen kan användaren ändra önskade attribut på sin cykel i vänsterkolumnen och scrolla på sidan för att se cyklar som är annonserade (Figur 4.4).
4.2. Implementation
Figur 4.4: Ursprunglig prototyp för sök-sidan.
Den ursprungliga prototypen för att logga in eller registrera sig designades enligt (Figur 4.5). Användaren ska enkelt kunna navigera till login-sidan efter det att användaren har re-gistrerat sig, allt för att reducera förvirring och frustration.
Vidare, i samtliga sidor i den ursprungliga prototypen, visas en navigationsmeny bestå-ende av fyra element; Home, About, Help, Leaser. Även BikePools logga-prototyp är synlig i det vänstra hörnet.
Figur 4.5: Ursprunglig prototyp för inloggning- och registrerings-sidan.
4.2
Implementation
Nedan presenteras resultatet av hur webbsidans olika delar implementerades. Design och funktionalitet förklaras med hjälp av skärmklipp på webbsidan samt utdrag ur kod med förklarande text. Allt innehåll på sidan, som användare upplever, har designats på engelska för att nå en större grupp användare.
4.2.1
Start-sida
BikePools start-sida (Figur 4.6) är den del av webbsidan som användaren först tar del av. Centrerad högst upp på sidan är en text som förklarar att det är här användaren kan söka efter en cykel. Under denna text finns två inmatningsfält som är implementerad med javascript-funktionen date-picker som låter användaren fylla i datum först för när den vill påbörja sitt hyrande och sedan till vilket datum den vill hyra till.
Under dessa inmatningsfält finns ett klickbart element som öppnar upp en lista med al-ternativa områden som användaren kan tänka sig vilja hyra sin cykel i. När användaren har fyllt i ovanstående information möts den av ett klickbart element med texten Search.
4.2. Implementation
Vidare, om användaren scrollar ned på sidan, möts denne av en bild samt en kort sam-manfattning av en rad funktioner som kan utföras på BikePool, såsom Rent a bike, Lease a bike, Your BikePool account. Samtliga av dessa informationsrutor kommer med ett tillhörande klick-bart element som tar användaren till respektive funktion. Längst ned på sidan finns en footer placerad med BikePools namn och årtalet tjänsten designades.
Figur 4.6: Applikationens start-sida
När användaren klickar på Search dirigeras denne till en ny sida (Figur 4.7), som visar resultatet av sökningen. Här kan användaren se samtliga annonser som ligger ute på webb-tjänsten som matchar sökkriterierna, med tillhörande information om område, pris samt äga-re av annonsen. Varje annons ger användaäga-ren möjligheten att klicka på två element. Det ena är ett klickbart element med namnet More Info, som vid klick öppnar en Bootstrap-modal som visar samtlig information kring annonsen. Det andra elementet, Book this bike!, tar använda-ren, förutsatt att denne har fyllt i korrekta datum, vidare i köpprocessen, som finns beskriven längre ned. Sedermera kan användaren klicka på ett klickbart element högst upp på sidan med namnet Advanced Search. Detta klickbara element är kopplat till Bootstrap-funktionen collapse. Denna funktion expanderar, vid klick, en HTML-div som gör ett flertal inmatnings-fält och checkboxar synliga.
Dessa inmatningsfält är till för att vara en mer avancerad sökning för att smalna av sökre-sultatet ytterligare. Här kan användaren filtrera resökre-sultatet beroende på cykelns olika attribut; lampa, korg, antalet växlar samt högsta tillåtna pris/dag för att hyra. Vidare kan användaren välja att sortera resultatet, stigande eller fallande efter parametrarna pris och antal växlar. När användaren har fyllt i ovanstående checkboxar och inmatningsfält kan denne klicka på en ny search-knapp som gör sig synlig i samband med klickandet på Advanced Search. Om användaren önskar att stänga den sistnämnda utvidgningen, klickar användaren återigen på elementet Advanced Search.
4.2. Implementation
Figur 4.7: Search-sidan med annonser
4.2.2
Navigationsmeny
Navigationsmenyn är placerad högst upp på webbapplikationens sida och är utformad så att den alltid ligger fixerad, oavsett om användaren scrollar ned på sidan eller växlar mellan olika sidor. När en användare är på en sida markeras den befintliga rubriken i navigationsmenyn, så att användaren alltid vet vilken sida denne befinner sig på för tillfället. När användaren rör pekaren över de olika elementen i menyn så ändrar även dessa rubriker färg. I menyn finns det även ett klickbart element som representerar BikePools logotyp, vilket är webbtjänstens namn och ingen bild, detta element tar användaren tillbaka till start-sidan oavsett var använ-daren befinner sig för tillfället. Denna är placerad i övre vänstra hörnet.
Till höger om logotypen är Home placerad, vilket även denna tar användaren till start-sidan. Denna är alltid markerad när man befinner sig på startstart-sidan. Bredvid Home är About placerad, där information och hjälp om hemsidan kan hittas.
Längst till höger i navigationsmenyn finns Register/Login, vilket ändras till Logout när an-vändaren är inloggad. Denna funktionalitet är möjlig genom att använda if-satser i jinja för att undersöka om användaren är anonymous eller ej (Figur 4.8). I inloggat läge finns även My Profile, vilken är placerad strax till vänster. Bredvid denna finns Contact, vilken är synlig både för inloggade och ej inloggade användare.
Figur 4.8: Jinja if-sats för att se om användaren är inloggad eller ej.
Navigationsmenyn skapades med Bootstrap Navigation Bar, där funktioner som Fixed och Right-Aligned användes för att fixera placeringen överst på sidan, samt dela upp vissa element till den högra delen av sidan. Active, Toggle och Collapsible har använts för att visa användaren vilken sida denne befinner sig på samt för att anpassa hemsidan för mindre skärmstorlekar, där navigationsmenyn blir för stor för att visas. I dessa situationer visas endast BikePools logotyp samt en drop-down meny med resterande element.
4.2.3
Kontaktformulär
Kontaktformuläret designades som en Bootstrap-modal, vilket gjorde det enkelt att nå från alla sidor, utan att behöva omdirigeras till en separat sida. Kontaktknappen är placerad i
4.2. Implementation
navigationsmenyn i högra hörnet för att snabbt, enkelt och överskådligt kunna nås. Kon-taktformuläret består av en ämnesrad, där de förvalda alternativen Bike questions, Renting questions, och Advertisement options finns att välja. Sedan följer tre fritextfält där använda-ren kan fylla i namn, meddelande och e-postadress. Informationen från användaanvända-ren hämtas med hjälp av HTML Form, och sparas sedan i en lista i databasen. Detta görs med hjälp av jQuery-funktionen post (Figur 4.9). Meddelandena kan enkelt ses, tas bort och redigeras på Admin-sidan som finns beskriven nedan.
Figur 4.9: Kod-snipp på post till databas för Contact-modalen
4.2.4
Inloggning och registrering
Inloggnings-sidan nås genom att klicka på Login till höger i navigationsmenyn. Login-formuläret är presenterat i en Bootstrap-modal och ber användaren skriva in sitt liu-id samt lösenord (Figur 4.10).
Figur 4.10: Login-sidan
Via login-modalen kan användaren även klicka på ett element om lösenordet glömts bort. Detta element använder en toggle-function som vid klick visar ett utökat fönster där använda-ren kan skriva in sitt liu-id, för att sedan få en kod skickad till sin liu-mejl. Efter att användaanvända-ren har skrivit in denna kod får denne ett nytt mejl med sitt nya lösenord.
För att ändra lösenordet kan användaren välja att navigera till sin profilsida, vilken är be-skriven ytterligare i nästa avsnitt. Login-modalen presenterar också alternativet att registrera sig på BikePool om man inte redan är en användare av tjänsten, via en registreringssida som nås via ett klickbart element.
För att registrera sig krävs att användaren fyller i liu-id samt ett lösenord två gånger efter varandra för att undvika felskrivning. Lösenordet ska bestå av minst åtta tecken varav minst en versal, en gemen och en siffra, vilket står beskrivet under inmatningsfältet. Alla fälten är obligatoriska och krävs vara ifyllda för en lyckad registrering. Om användaren skulle lämna en ruta tom eller fylla i fel format kommer ett popupfönster upp med information angående det aktuella felet och hur det detta fel kan åtgärdas. Detta gäller även om användaren skulle
4.2. Implementation
en sida där denne blir ombedd att skriva in en bekräftelsekod samtidigt som den tidigare modalen försvinner som ett resultat av funktionen hide. Bekräftelsekoden är automatiskt ran-domiserad samt genererad och blir skickad vid lyckad registrering till användarens liu-mejl. Till detta har flask-tillägget flask-email implementerats samt så har funktionen randNr använts för att generera en automatiserad kod (Figur 4.11). Efter användaren matat in denna konfir-meringskod har ett användarkonto skapats och användaren blir direkt inloggad på BikePool. Front-end funktionalitet som hanterar när en användare har matat in fel lösenord vid regi-strering eller inloggning har också implementerats. Denna funktionalitet innebär att lösenor-det i inmatningsfältet försvinner automatiskt från fältet för att underlätta för användaren.
Figur 4.11: Kod-snipp av hur flask-tillägget flask-mail används.
4.2.5
Profilsida
Profilsidan nås då användaren är inloggad och syns i navigationsmenyn högst upp till hö-ger, mellan Contact us och Logout. Överst på sidan finns ett välkomnande meddelande till användaren, samt en en klickbar länk som visar mer information om användaren behöver hjälp i fallet då den inte vet hur denne ska gå tillväga. Under denna information finns fem klickbara element med benämningarna My information, Order history, Create Ad, Lease History, samt My messages (Figur 4.12). Med dessa element kan användaren nå hela profilsidans inne-håll. Elementen är dessutom implementerade så att de alltid ska synas för användaren, även då denne har scrollat ned på sidan. Detta har implementerats med hjälp av style-kommandot sticky, vilket gör att elementen fästs högst upp på sidan i underkant mot den övergripande navigationsmenyn, vid scrollande på sidan. Detta gör att informationen på sidan försvinner in under både navigationsmenyn och navigeringselementen vid scrollning. Vid klickande på något av elementen, flyttas användaren nedåt på sidan för att direkt komma till den valda sektionen. Denna information kan även nås genom att scrolla som vanligt på sidan, då allt är implementerat enligt Single-Page-design.
Designen på elementen är utformade för att passa in på sidan, både färgmässigt samt ge-nom storlek och form. Förutom information som beskriver för användaren vart denne dirige-ras vidare vid klick, finns även symboler för att förstärka och förtydliga elementens innebörd.
Figur 4.12: Profil-sidans navigeringselement
Då användaren klickar på elementet My information, scrollas denne automatiskt näst längst ner på sidan. Där finns en rubrik med samma namn som elementet, samt ett antal informa-tionsfält presenterade. Dessa är User, vilket beskriver användarens liu-id, Email, Name samt Phone number. De två senare fälten har informationen No number/name entered om användaren själv inte valt att lägga till detta, vilket har implementerats med hjälp av attributet Placehol-der i HTML-input-taggen. Då endast liu-id anges vid registrering av nytt konto, finns denna
