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
4.2. Implementation
information inte tillgänglig automatiskt. Genom att klicka på elementet Change information, som finns placerad ovanför informationen, kan användaren lägga till samt redigera sin an- vändarinformation. Vid ändring av användaruppgifter uppdateras dessa i databasen.
Vid klick på elementet Change information, öppnas en modal för användaren med rubriken Settings. Där finns fyra fält, för att ändra användarens information. Liu-id är dock inte möjligt för användaren att ändra, vilket presenteras med en ljusare text jämfört med övriga fält, för att på så sätt visa att informationen är låst. Nedanför fälten finns även en checkbox, vilken ta- lar om ifall användaren får meddelanden skickade även till sin e-post och inte bara lokalt på sidan. För att spara sina ändringar finns ett klickbart element, centrerat under informationen, med benämningen. Modalen stängs automatiskt efter detta och användaren ser därefter att informationen under rubriken My information är uppdaterad. I modalen finns även ett klick- bart element för att ändra sitt lösenord, med benämningen Click here to toggle password settings. Genom att klicka på elementet utökas modalen med ytterligare tre fält, där användaren om- beds skriva in sitt nuvarande lösenord, nytt lösenord, samt repetera det nya lösenordet. För att dölja fälten, kan användaren klicka på elementet ytterligare en gång. Vidare så finns i modalen även ett klickbart element för att spara ändringarna, Submit password changes. Om användaren väljer ett nytt lösenord som inte uppfyller sidans krav (antal tecken, siffror samt gemener/versaler), samt om fälten nytt lösenord och repeterat nytt lösenord skiljer sig åt, genereras också ett popupfönster med information kring det aktuella felet. Funktionaliteten bakom lösenordsbytet är implementerat i ett script, där information skickas i JSON-format via Ajax.
Om användaren klickar på det klickbara elementet My messages, placerat högst upp på profilsidan som nämnt ovan, så blir användaren automatiskt förflyttad längre ned på sidan till en rubrik med namnet My messages. Under denna rubrik kan användaren se de meddelan- den som skickats till sig av BikePool. Användaren ser vilket ämne meddelandet har, och en stor klickbar knapp med namnet read message har implementerats som vid klick öppnar upp en Bootstrap-modal där användaren kan läsa meddelandet och radera meddelandet. Vidare kan användaren se vilken tid meddelandet skickades/mottogs samt om meddelandet lästs eller inte.
Elementet Order History öppnar vid klick en ny sida som visar användarens tidigare or- ders via deras respektive order-id. Användaren kan sedan trycka på ett order-id för att visa mer information om just den ordern. Denna information är under vilken period cykeln var hyrd, priset för uthyrningen, området, samt vem användaren hyrde cykeln av. Den div som expanderas när användaren klickar på order-id gör även ytterligare två klickbara element synliga. Dessa är Leave a review samt File a complaint. Längst ned på sidan finns även ett klick- bart element Back to profile som tar användaren tillbaka till profilsidan.
Leave a review dirigerar användaren till en ny sida. Denna sida presenterar en meny som låter användaren välja mellan en av siffrorna 1-5 och ämnar att representera det betyg som användaren vill ge det tidigare hyrandet. På denna sida finns det även ett inmatningsfält som låter användaren skriva in precis vad den vill angående tankar och dylikt angående det tidigare hyrandet. Längst ned på sidan visas en knapp, Send, för att skicka omdömet, samt en knapp Back to history som låter användaren återvända till den tidigare sidan.
Vidare finns även, som tidigare nämnt, det klickbara elementet File a complaint som även denna dirigerar användaren till en ny sida. Denna sida presenterar först ett inmatningsfält med rubriken Subject där användaren skriver in ämnet på sitt klagomål. Detta inmatningsfält visar även en placeholder innan dess att användaren har skrivit in någonting som ämnar att förklara för användaren hur formateringen av ämnet ska ske. Det finns även ett inmatnings- fält där användaren får skriva i klartext vad för klagomålen den har angående den aktuella ordern. Detta inmatningsfält har en rubrik Message. Längst ned på sidan hittas även ytterli- gare två klickbara element, Back to history samt Send message som dirigerar användaren till
4.2. Implementation
placerad i profilsidans navigationsmeny (Figur 4.12). Användaren kan även skapa en annons genom att klicka på elementet markerat med ett additionstecken, placerad under rubriken My Rentals (Figur 4.13).
Figur 4.13: Additionssymbol för att skapa en annons samt två exempelannonser.
När användaren klickar på något av dessa element öppnas en modal där användaren fyller i uppgifterna som ska ingå i annonsen. Dessa innefattar område, upphämtningsplats och cykelns tidigare nämnda attribut. Vidare anges även mellan vilka datum användaren önskar hyra ut sin cykel samt att användaren blir ombedd att ladda upp en bild på sin cykel, vilket har blivit implementerat som ett krav för att annonsen ska gå att lägga upp. Precis ovanför det inmatningsfält där användaren blir ombedd att fylla i priset/dag för sin cykel finns en klickbar länk. Denna länk förklarar för användaren att om vederbörande känner sig osäker på hur eller vilket pris man ska sätta på sin cykel så kan man via länken gå till en Pricing Guide som förklarar detta. När samtliga uppgifter är ifyllda och användaren har tryckt på Create Ad sker en omdirigerad till profilsidan, där användaren nu kan se sin nya annons under rubriken My Rentals.
Under rubriken My Rentals, som är placerad högst upp på My Profile-sidan, visas samtliga aktiva annonser som användaren själv har lagt upp. Dessa är större klickbara figurer som blir aningen förstorade när användaren svävar med muspekaren över dem, så kallad zoomeffekt, för att markera det aktuella elementet. Figuren visar cykelns pris per dag uppe i det vänstra hörnet gestaltad som en label på figurens bakgrundsbild, som visar den bild som användaren laddade upp i samband med annons-skapandet. Vidare visas området för cykeln samt datu- met den kan bli hyrd till, i det nedre segmentet (Figur 4.14). När man klickar på en av dessa figurer öppnas en modal som visar annonsens information. Här kan användaren ändra all information, fram tills dess att cykeln blir hyrd. Under denna rubrik finns även figuren som symboliserar ett additions-tecken, nämnt ovan (Figur 4.13). Denna figur är ett klickbart ele- ment som vid klick öppnar upp samma modal som öppnas när användaren klickar på Create Ad och syftar således till att låta användaren skapa en annons.
4.2. Implementation
Figur 4.14: Annons för en cykel.
4.2.6
Köpprocess
Betalningssidan nås när användaren valt en cykel på ett specifikt datum. På sidan finns to- talpris (pris per dag * antal hyrda dagar), plats och valda datum presenterade, samt en bild på cykeln och en karta för upphämtningsplatsen. Högst upp finns en progress bar som visar för användaren hur långt i köpprocessen denne har kommit (Figur 4.15). De steg som finns är Review, Payment samt Done och dessa finns presenterade genom hela köpprocessen, genom att markera med vit bakgrund samt siffra, vilket av de tre stegen användaren befinner sig på för tillfället.
Figur 4.15: Progress bar för köpprocessen.
Under informationen finns en betalningsknapp som är implementerad med Stripe API för kortbetalning, där användaren ombeds skriva in sina kortuppgifter. Dessa fält blir rödmarke- rade om formatet på kortnumret eller CVC-numret är felaktigt samt om datumet för kortet är valt i förfluten tid. Det finns även en checkbox, Remember me, vilken är valfri för användaren att kryssa i. Denna används för att verifiera köparens identitet för framtida köp på BikePool genom att telefonnummer anges. Användarens mejl är förifylld, då inloggning krävs för be- talning. Efter betalning skickas ett autogenererat mejl med order-id, pris samt vilka datum cykeln har hyrts. Användaren omdirigeras även till en bekräftelsesida med samma informa- tion som ovan, samt namn, e-postadress och telefonnummer till uthyraren av cykeln. Överst på sidan finns en tydlig rubrik att köpet har gått igenom.
Stripe är ett färdigbyggt betalningsalternativ som implementerats direkt i koden på server-sidan. För att beräkna rätt pris skickas en parameter med antal hyrda dagar samt cy- kelns id från föregående sida, så dagspriset kan hämtas för aktuell cykel i databasen. Genom cykelns id, hämtas även cykelns position som används till Google Maps API för att visa rätt position på kartan. Google Maps API är även den implementerad direkt i koden, men på front-end-sidan (Figur 4.16).
4.2. Implementation
Figur 4.16: Exempel på användning av Googles API för att visualisera lokaliseringen av en cykel i Valla.
4.2.7
Databasstruktur
I det framtagna EER-diagrammet framgår det att en databastabell över användare, benämnd User, som listar användare (både uthyrare och hyrare), har skapats, se bilaga A (Figur A.3). Denna har attributen ID, som är tabellens primary key. Tabellen omfattar också liu-id, telefon- nummer, e-postadress, namn, hashat-lösenord, betalningsinformation samt ett attribut med dataty- pen boolean som sparar information om användaren vill ta emot informations-mejl.
Det är möjligt att, via webbsidans funktioner, hyra en cykel med specificerade attribut, vilket ledde till att ytterligare en databastabell kallad Bike Wish skapades. Denna databastabell inkluderar alla attribut som Bike gör och använder sig av ID som primary key samt vilken användare som gjort önskningen, som är en foreign key och hänvisar till ID i klassen User.
Vidare ska en användare kunna få meddelanden skickade till sig, varpå databastabellen MessageToUser implementerades. Denna består av attributen ID, som är tabellens primary key, message, subject, timestamp samt ett boolean-attribut, isRead, som anger om meddelandet har blivit läst av användaren eller inte. Denna tabell har även en foreign key kopplad till ID i modellen User som berättar vilken användare som meddelandet berör.
Användaren ska även kunna skicka meddelanden till administratören. Därför skapa- des databastabellen ContactMessage. ContactMessage är uppbyggd på samma sätt som Mes- sageToUser men har inte attributet isRead, däremot har tabellen istället användarens name och email.
Sedermera skapades en databastabell för cyklar, vid namnet Bike med attributen Bike-ID som fungerar som tabellens primary key, antalet växlar, plats, pris, två boolean-attribut som anger om cykeln har en lampa respektive om cykeln har en korg. Vidare innehåller tabellen attribut som start- och slutdatum, upphämtningsplats, minimala antalet dagar för reservation av cykeln, om cykeln har en bild samt i sådana fall bildens namn. Vidare finns även en foreign key som beskriver ägaren av cykeln genom att tabellen är kopplad till ID i klassen User.
För att veta när cykeln är tillgänglig och lagra information kring detta så utformades en tabell med datum då cykeln är tillgänglig, vid namnet AvailableBikeDate. Denna består av attributen ID, som är primary key, en boolean som berättar om datumet är tillgängligt för uthyrning eller inte, samt det aktuella datumet. Databastabellen har även en foreign key som ger vilket Bike ID i class Bike den reserverade cykeln besitter.
Då användare ska kunna skicka ett eventuellt klagomål angående en aktuell reservation till webbtjänsten, fanns ett behov av att skapa en databastabell som hanterar detta. Denna tabell, Complaint, berörs av attributen ID, som är tabellens primary key, ämne, meddelande, tidsstämpel, samt en boolean om användaren är en hyrare. Vidare finns även en boolean som anger om ärendet blivit löst eller inte, samt två foreign keys. Den ena är kopplad till ID i klassen User och anger vilken användare som har skickat klagomålet. Den andra är kopplad till Res ID i Reservations som ger information vilken reservation klagomålet berör.
Slutligen skapades en tabell över gjorda reservationer med attributen Res ID som är data- bastabellens primary key, start- och sluttid, pris, en boolean om reservationen är betald eller inte samt två attribut angående reservationens eventuella recensioner och omdömen. Vidare är två foreign keys implementerade. En berättar vilken cykel reservationen berör genom att
4.3. Utvärdering
databastabellen är kopplad till Bike ID i klassen Bike, samt en är kopplad till ID i klassen User som anger vem som är den aktuella cykelns ägare.
4.2.8
Auto-skalning
Ett av de ursprungliga tekniska kraven som sattes upp för webbsidan var att den skulle ut- vecklas på ett sådant sätt att den kan användas oberoende av användarens skärmstorlek. Det- ta har implementerats på samtliga sidor med hjälp av Bootstraps rutnätssystem (eng. Bootstrap grid system). Rutnätssystemet använder sig av en serie av kolumner, rader och containers för att justera och skala innehållet på hemsidan. Kolumnerna kan skräddarsys med flera olika prefix för att innehållet ska skala till rätt skärmstorlek. Webbsidan använder sig av prefixen sm (small), md (medium) och lg (large). Denna auto-skalning innebär i praktiken att webbsidan kan nås och användas på ett funktionellt sätt via mobiler, surfplattor såväl som datorer.
4.3
Utvärdering
Nedan presenteras resultatet av användartesterna som utfördes i syfte att utvärdera webbsi- dan. Fokus låg på att testa användbarheten i form av enkelhet och navigerbarhet, likt fråge- ställningen som presenterades under rubriken syfte.
4.3.1
Användartest 1
Första användartestet gjordes i slutet av sprint två. Testdeltagarna bestod utav fem studenter på Linköpings Universitet, som matchade webbapplikationens sökta målgrupp. Tre testle- dare bevakade samtliga genomförda moment. Det som observerades var tiden det tog att genomföra en specifik uppgift, antal klick samt antal felklick. Resultaten presenteras i ett an- tal diagram nedan, tillsammans med kommentarer och förbättringsförslag från deltagarna som uppkom under testningen.
Figur 4.17: Resultat från testfallet Skapa en profil.
Första uppgiften som testdeltagarna fick genomföra var att Skapa en profil (Figur 4.17). Den genomsnittliga tiden för att utföra momentet var 133.4 sekunder, det genomsnittliga antalet klick var 9.4 samt genomsnittliga antalet felklick uppmättes till 2. Fyra av fem deltagare fick skriva in lösenordet upprepade gånger för att klara de uppsatta säkerhetskraven, vilket re- sulterade i längre tid för att utföra momentet. Några testdeltagares respons efter testfallet var
4.3. Utvärdering
kring hur lösenordet skulle vara utformat saknades, alltså information om nödvändig längd, antal siffror och stora bokstäver. Genom att dubbelklicka på registreringsknappen sändes två mejl med olika bekräftelsekoder, något som inte uppskattades av testpersonerna då det ska- pade förvirring om vilken kod som skulle användas.
Figur 4.18: Resultat från testfallet Logga in och redigera profil.
Nästa uppgift var att Logga in och redigera profil (Figur 4.18). Fyra av fem deltagare kla- rade momentet helt utan felklick. Vissa testdeltagare upplevde det otydligt var ändringar- na av profilinformationen skulle göras. Efter redigering av ens profilsida saknades även en bekräftelse att ändringen blivit genomförd. Detta var något som upplevdes förvirrande av testdeltagarna då de inte uppfattat om ändringen gått igenom eller inte.
Figur 4.19: Resultat från testfallet Skapa en annons.
Testfallet som sedan genomfördes av testdeltagarna var att Skapa en annons (Figur 4.19). En av fem deltagare klarade uppgiften utan felklick. Medelvärdet för det totala antalet klick uppmättes till 8.4, samt den genomsnittliga tiden uppmättes till 45.6 sekunder. Testdeltagar- na upplevde det otydligt var man skulle klicka för att skapa annonsen. Vid prissättning av cykeln önskades förvalda alternativ. Efter skapandet av annonsen skedde automatisk omdi- rigering till start-sidan, något som upplevdes negativt. Ytterligare information om vad som händer efter att användaren skapat en annons önskades. Historiken av hyrda och uthyrda cyklar upplevdes som rörig, samt att all historik kunde ses (inte bara den inloggade an-
4.3. Utvärdering
vändarens). Det önskades även en direktlänk till hjälpsidan då testdeltagaren upplevde en osäkerhet och behövde hjälp.
Figur 4.20: Resultat från testfallet Hitta vem som grundat BikePool.
Testfall nummer fyra gick ut på att Hitta vem som grundat BikePool (Figur 4.20). Samtliga testdeltagare hittade till informationssidan utan några felklick, med en genomsnittlig tid på 14.8 sekunder. Dock upplevdes sidan som svårläst då vissa delar bestod av en bild med ljus bakgrund med vit text ovanpå.
Figur 4.21: Resultat från testfallen Hyra en cykel.
Sista uppgiften var att Hyra en cykel (Figur 4.21). Testet genomfördes två gånger av samtli- ga testdeltagare för att kunna jämföra huruvida deltagarnas tid samt antal klick och felklick minskades eller inte jämfört med första gången. Fyra av fem testdeltagare minskade sin tid andra gången de genomförde momentet, medan tre av fem minskade antalet klick. Vidare så minskade två av fem testdeltagare antalet felklick, samt samma antal hade oförändrat antal. En av fem ökade antalet felklick andra gången.
Deltagarna upplevde det otydligt att annonsen var klickbar och att klick krävdes för att komma vidare till bokning och betalning. Sorteringselementen upplevdes som röriga med mycket information. Vissa deltagare upptäckte att cyklar gick att välja i förfluten tid, något
4.3. Utvärdering
valda cykeln upplevdes som otydlig. Det upplevdes även negativt att priset ändrats från dagspris till totalpris först vid betalningssidan.
Nedan visas ett utdrag från enkätundersökningen som genomfördes av samtliga deltaga- re efter avslutad testning. Graferna visar de frågor som fick högst (Figur 4.22) respektive lägst (Figur 4.23) medelvärde, där 1 betyder Instämmer inte alls och 5 betyder Instämmer helt.
Figur 4.22: Resultat från enkätundersökningen. Fråga med högst medelvärde.
Figur 4.23: Resultat från enkätundersökningen. Fråga med lägst medelvärde.
4.3.2
Användartest 2
Andra användartestet genomfördes i slutet av sprint tre, vilket också var den sista utveck- lingsfasen. Likt det första användartestet bestod deltagarna av fem studenter studerandes på Linköpings Universitet, som matchade den identifierade målgruppen. Även detta test beva- kades av tre testledare och samma moment genomfördes, samt samma enkätundersökning efter avslutad testning. Resultaten från testfallen presenteras nedan i ett antal diagram, med