DET MOBILE REJSEKORT KURSUS: DESIGN TIL DIGITALE KOMMUNIKATIONSPLATFORME UNDERVISER: BRIAN EVERETT UDARBEJDET AF: PLOR, MALN OG MTPL

Transkript

1 DET MOBILE REJSEKORT KURSUS: DESIGN TIL DIGITALE KOMMUNIKATIONSPLATFORME UNDERVISER: BRIAN EVERETT UDARBEJDET AF: PLOR, MALN OG MTPL 1

2 DET MOBILE REJSEKORT // Vejledning VEJLEDNING TIL DET MOBILE REJSEKORT Da app en på nuværende tidspunkt kun er en interaktiv prototype er dens funktionalitet opbygget omkring et specifikt brugerscenarie. Vi vil derfor her beskrive, hvordan du kan bruge prototypen på den mest optimale måde. Vi anbefaler, at du ser prototypen i FireFox eller på en iphone/android smartphone. Bemærk, at app en er optimeret til en skærmstørrelse på 320x480 pixel. BRUGERSCENARIE Du er Klaus Hansen (bruger-id: og mobilkode: 1234) og er gået ind på prototypen Det Mobile Rejsekort. 1. Du står ved metrostationen DR Byen, København. Klokken er 9:05 og du ønsker at tage hjem med offentlig transport, som er beliggende på Elmegade, Nørrebro, København. Du har følgende rejseplan: 1. DR Byen-Nørreport st. (metro) 2. Nørreport st.- Elmegade (5A bus) Når du har indsat DVD en og er klar til at udforske vores prototype, vil du møde følgende to mapper: I løbet af din rejse vil du blive mødt af en kontrollør i metroen, som gerne vil tjekke om du er checket ind. Prototypen Opgaven 2. Efter at du er kommet hjem ønsker du at tjekke dine tidligere rejseaktiviteter. Klik dig ind i mappen Prototypen og klik derefter på index.html for starte prototypen. Hvis du er interesseret i at åbne prototypen direkte fra ITU-serveren, så skal du blot taste følgende adresse: 3. Derefter ønsker du at tilmelde dig automatisk optankning (beløb: 200 kr.). Men efter kort tid ombestemmer du dig, og vil igen afmelde dig automatisk optankning. 4. Afslutningsvis ønsker du at beregne prisen for en tur med toget fra Nørreport st. til Kolding st. (standard), lørdag d. 18. maj kl

3 DET MOBILE REJSEKORT // Indholdsfortegnelse 1. INDLEDNING MTPL 4 2. MÅLGRUPPE MTPL 5 3. METODISK TILGANG PLOR EN BRUGERCENTRERET DESIGNPROCES PLOR IDE GENERERING MTPL STORYBOARD MTPL EKSPERTVURDERING MTPL SKETCHING MTPL MOCK-UP FØRSTE PROTOTYPE MTPL 9 8. KODNING PLOR MOBILE PLATFORME PLOR JQUERY MOBILE PLOR GENEREL OPBYGNING PLOR GENEREL OPBYGNING AF EN SIDE PLOR SPECIFIKKE OPTIMERINGER TIL IPHONE PLOR POP-UP PLOR INDTASTNINGSFELTER PLOR CHECK-IND/CHECK-UD LYD MTPL PROTOTYPE MALN BRUGERTEST PLOR FØRSTE BRUGERTEST MTPL ANDEN BRUGERTEST MTPL KONKLUSION PLOR REFERENCER INFORMATIONSARKITEKTUR MALN BILAG DESIGNPRINCIPPER MALN VISUEL IDENTITET MALN BOMÆRKE MALN NAVNETRÆK MALN FARVE MALN TYPOGRAFI MALN IKONER MALN 18 3

4 DET MOBILE REJSEKORT // Indledning 1. INDLEDNING Hver dag bruger millioner af danskere offentlig transport. Men det fysiske klippekort er ved at blive skrottet og udfaset (udløbsdato 1. juli 2013). Alternativet hedder Rejsekortet, som nu bliver brugt af to millioner kunder i Danmark (Rejsekort.dk, 2013). Der er dog nogle problemer med Rejsekortet. Man får ingen kvittering for rejsen, man kan ikke se om man er checket rigtigt ind og glemmer man at checke ud får man en dummebøde på 50 kroner. Alt sammen ting der var løst med det gammeldags klippekort. Vores produkt er en app-løsning til Rejsekortet, der kan løse problemerne og give kunden bedre overblik over saldo, rejseaktivitet og personlige oplysninger. Teknologien til en back end løsning findes allerede i dag med NFC og GPS selv på iphone, der ikke har tilsluttet sig NFC-teknologien, vil det være muligt at sende en datapakke med oplysningerne fra Rejsekortet til ens mobil (kilde: Ken Friis Larsen, lektor i datalogi ved Københavns Universitet). - Det, der mangler for at lave en app for Rejsekortet i dag, er politisk velvilje. Rejsekortsstanderne laver i dag en almindelig netværksforbindelse til Rejsekortes backup-system. Det kan ligeså godt køre på en mobiltelefon, forklarer Ken Friis Larsen. Rejsekorts Applikationen vil komme til at fungere som et supplement til Rejsekortet som vi kender det i dag. Løber mobilen tør for strøm vil man kunne rejse videre på sit normale Rejsekort, ligesom man vil kunne checke ud på mobilen, hvis man glemmer at checke ud, når man har afsluttet sin rejse med det normale Rejsekort. Der er i dag allerede flere applikationer, der kan minde en om at checke ud, når man har afsluttet ens rejse. En egentlig mobil erstatning for Rejsekortet findes ikke. Med udbuddet af nuværende mobile lappeløsninger for Rejsekortet og allerede eksisterende løsninger for klippekort og billetter til DSB er det oplagt, at der mangler en mobil løsning for Rejsekortet. Det leder os hen til følgende problemformulering: Hvordan skaber man en mobilløsning som videreudvikling af Rejsekortet, der forenkler rejsen for brugeren, samt løser nogle af Rejsekortets nuværende problemer? 4

5 DET MOBILE REJSEKORT // Målgruppe og Metode 2. MÅLGRUPPE 3. METODISK TILGANG Vi har valgt at lade vores mobilløsning henvende sig til en primær målgruppe i alderen år. Det sker ud fra et valg om, hvem der er de primære smartphone-brugere og mest fortrolige med apps og den teknologi, der følger med. Generelt har halvdelen af danskerne nu en smartphone. Og det forventes, at det antal stiger til 80 procent i år. (Dwarf.dk, 2013) Rejsekortet har ikke så godt fat i den yngre målgruppe. En nylig brugerundersøgelse fra Epinion af Rejsekortets brugere, viser at der findes flest brugere i aldersgruppen år (41 procent), mens det overraskende viser sig, at den mindste gruppe, kun 23 procent, af brugerne er mellem 18 til 34 år (Epinion, 2012). Af borger.dk s personas passer gruppen De unge borgere også bedst til vores produkt. Johannes er 20 år, online 24/7, har en smartphone og bruger en masse apps. Han vil gerne betjene sig selv, men de digitale løsninger skal være forståelige. En sekundær målgruppe er De velvillige. Men selvom Claus på 44 år, har en smartphone og bruger apps, så er han lidt mere usikker end Johannes. Claus vil gerne have en vished for, at han gør det rigtigt. (Borger.dk, 2013) Derfor konkluderer vi, at vi ud fra både et forretningsmæssigt og brugermæssigt synspunkt har en målgruppe som hedder 18 til 34 år. I følgende afsnit vil vi redegøre for den metodiske tilgang og proces i vores konceptudvikling af det mobile rejsekort. Vi vil beskrive, hvordan vi med udgangspunkt i en brugercentreret designproces er kommet fra idé, første mock-up og endt op med den færdige prototype. 3.1 EN BRUGERCENTRERET DESIGNPROCES I forbindelse med udviklingen af nye brugergrænseflader, som fx softwareprogrammer er det en tradition at tage udgangspunkt i en udviklingsmodel. Modellen kan hjælpe til at give overblik og struktur over processen (Sharp et al. 2007). I lang tid har den såkaldte vandfaldsmodel været den mest anvendte model (Sharp et al. 2007). Vandfaldsmodellen som gennemgår seks forskellige faser i designprocessen er lineær og kronologisk. Det vil sige, at man ikke går tilbage til de tidligere faser i processen. Kun fremad. Da brugerinddragelsen først sker i afslutningen af designprocessen, karakteriseres modellen som ikke særlig anvendelig inden for processer, hvor man ønsker løbende feedback på design og funktionalitet fra brugeren. Ved udvikling af en ny app, der skal blive et aktivt redskab for brugeren, vurderer vi, at en brugercentreret designproces frem for en lineær, som fx vandfaldsmodellen, er vigtigst. Jf. Gregersen & Wisler-Poulsen, 2009 bør brugerinddragelse (usability-tests) altid være en integreret del af alle stadier i designprocessen. Fordi at uanset hvor godt man 5

6 DET MOBILE REJSEKORT // Metode som designer kender til produktet og slutbrugere, og uanset hvor meget erfaring man har med produktet eller design af brugergrænseflader, må man acceptere, at man reelt ikke har kendskab til konsekvenserne af ens mange designvalg. Dette kan man først få, når en bruger interagerer med grænsefladen i en virkelig brugssituation. Jf. Gregersen & Wisler-Poulsen, 2009 er der her tale om den såkaldte designudfordring. Designprocesser bør derfor være en gentaget (iterativ) proces, hvor de designvalg, der løbende foretages, skal afprøves og vurderes af de brugere, der i sidste ende skal anvende produktet. På denne måde skal designvalg altid evalueres for at tilgodese designudfordringen, og evalueringen bør altid føre til justering af det eksisterende design. Med afsæt i ovenstående har vi valgt at arbejde ud fra en såkaldt Interaction Design Lifecycle Model (Sharp et al. 2007). Denne cirkulære livscyklusmodel viser, hvordan brugen af interaktive prototyper og brugerevaluering får et tidligt fokus på brugernes behov og dermed mulighed for at evaluere, identificere nye behov og redesigne undervejs i processen. Da modellen kun illustrerer en iterativ proces, kan den i princippet fortsætte i det uendelige (Sharp et al. 2007). Set i lyset af vores tidsmæssige begrænsninger, valgte vi derfor at afgrænse designprocessen til to brugerevalueringer. Samtidig vurderede vi, at det ikke var nødvendigt at udføre en spørgeskemaundersøgelse, da vi havde materiale om Rejsekortets brugere fra Epinions undersøgelser. (Re)Design INTERACTION DESIGN LIFECYCLE MODEL (SHARP ET AL. 2007) 3.2 IDÉ GENERERING Identify needs establish requirements Build an interactive version Evaluate Final product Efter at vi havde fået gruppeformationen på plads, begyndte vi at tænke over hvilket koncept vi skulle designe. Om det skulle være et re-design af en eksisterende hjemmeside, eller noget nyt. Vi nåede egentlig ikke at idéudvikle ret længe, før at Philipp bragte et forslag på banen. Ud fra en hverdagssituation og fra noget som han manglede i sin hverdag, kom han med forslaget om en app til Rejsekortet. Vi kom derfor ikke at være ret lang tid i divergensprocessen, før vi 6

7 DET MOBILE REJSEKORT // Metode bevægede os videre til designproces og konvergens (Buxton, 2009: s. 91). Vi kunne alle sætte os ind i problemstillingen med det fysiske Rejsekort og valgte derfor at lave et nyt produkt, som vil være med til at løse de problemstillinger. STORYBOARD 3.3 STORYBOARD For at illustrere vores koncept begyndte vi derefter at producere et storyboard. Her har vi ladet os inspirere af professor ved datalog Stanford HCI Group, Scott Klemmers Youtube tutorial om storyboard, paper prototypes og mock-ups (Youtube.com, 2013). I vores storyboard fortæller vi en lille hverdagshistorie, hvor vores mobile løsning for Rejsekortet kunne forbedre brugeroplevelsen. Vi ser en mand, som skal til at tage bussen, men som har glemt sit Rejsekort derhjemme. Men så kommer han i tanke om, at han har Rejsekortet som mobil-app også. Han checker ind og kommer med bussen. Da han stiger af bussen bliver han dog i tvivl om, om han har husket at checke ud. Der kommer en alert fra Rejsekorts app en, der efter noget tid minder ham om, at han skal huske at checke ud. Manden er glad, fordi han har kunnet komme hjem med bussen og samtidig ikke har skulle betalt en bøde for at glemme at ud. 3.4 EKSPERTVURDERING Inden vi lagde os fast på emnet til denne opgave, var det vigtigt for os, at vi fik belæg for, at vi lavede et produkt som rent faktisk ville virke i dag, eller i den nærmeste fremtid. Derfor researchede vi og læste flere artikler om problemstillingen med, at der ikke er en app til Rejsekortet. Samtidig interviewede vi forskellige fagfolk. Vi fik i den forbindelse et interview i stand med en lektor i datalogi fra Københavns Universitet, Ken Friis Larsen. Han har også tidligere optrådt i DR2- programmet So Ein Ding i forbindelse med samme problemstilling. Her er hans konklusioner efter vores interview med ham: - Det handler om at have den politiske vilje for at lave en mobilløsning til Rejsekortet. Teknologien findes allerede. 7

8 DET MOBILE REJSEKORT // Metode - Med NFC-teknologi kan vi allerede i dag aflæse den RFID-chip, som sidder i alle fysiske rejsekort. Det betyder, at man med lidt teknisk snilde kan lave ens mobil om til en mobil rejsekortsscanner. Et problem med NFC er dog, at iphone ikke understøtter standarden. Men den datapakke, som sidder i Rejsekortet i dag kan scannes og sendes til enhver mobil. Så kommer man ud over problemet med NFC. - Via GPS og datatraffik kan man lokalisere ens smartphone, når man laver et check-ind eller ud. Der kan dog være lidt usikkerheder med lokationen, men oftest rammer den ret præcis. 3.5 SKETCHING Med belægget for opgaven på plads kastede vi os over sketching. Sketching er vigtigt for at tænke og lære design rigtigt. Samtidig er sketching godt for fantasien og forståelsen. (Buxton, 2009: s. 118 & 135) Vi tegnede en mobil med skærm og begyndte at tegne de funktioner ind i modellen, som vi gerne ville have med. Det var et utroligt godt redskab til at få vores tanker ned på papir. Samtidig var det med til at løse diskussioner i gruppen, fordi vi pludselig kunne se at det tegnede ofte var et kompromis af vores individuelle tanker. Da vi havde den overordnede navigation på plads begyndte vi at designe undersiderne. - Det er ikke muligt at lave en løsning, hvor man bare checker ind en gang og så ud, når man er færdig. Man skal stadig checke ind, når man skifter transportmiddel. Det hænger sammen med, at transportselskaberne har forskellige systemer. Derfor har vi lavet en løsning, der stadig fungerer som det nuværende Rejsekort på det punkt. UDKAST FRA SKETCHING PROCESSEN Problemer med en mobilløsning: - Man kan snyde med falske GPS-koordinater. Der kan dog indarbejdes en blokering mod disse i app en. - Det kræver politisk velvilje og penge til at udvikle teknologien til backend løsningen. Nu har vi så udviklet frontend løsningen. 8

9 DET MOBILE REJSEKORT // Metode 3.6 MOCKUP FØRSTE PROTOTYPE FYSISKE MOCKUPS Vi førte vores skitser over på papir og pap i en såkaldt papirs prototype. Dem bestod af en iphonelignende papmodel, hvor vi på papir tegnede de forskellige menusider og undersider. Det var første mockup af vores prototype. Vi havde skellettet på plads udfra vores første sketch, men blev hurtigt enige om, hvad de fem menuer skulle indeholde, og hvordan det skulle designes. Vi havde naturligvis en del idéer der blev sorteret fra under udarbejdelsen af mock-uppen. Ved at have designet foran os på papir kom vi hurtigt fra idé til udførelse. Efter at have lavet en komplet mock-up på papir overførte vi den til DIGITALE MOCKUPS en elektronisk version gennem programmet Appcooker. Med Appcocker fik vi en første interaktiv prototype som fungerede godt til en brugertest. Samtidig var det en stor hjælp, for at vores testpersoner kunne teste konceptet på en mobil og ikke skulle bladre igennem en masse papir mock-ups. (se afsnit 4.1). 9

10 DET MOBILE REJSEKORT // Brugertest 4. BRUGERTEST En brugertest er en kvalitativ metode, hvis styrke blandt andet består i at kunne afprøve, om brugeren kan løse de opgaver og mål, som det undersøgte produkt er konstrueret til (Gregersen & Wisler-Poulsen 2009). I den konkrete evaluering af app en gennemføres en brugertest med udgangspunkt i udvalgte fokusområder. Metoden anses særdeles relevant for usability-evalueringen. Testen giver indblik i den faktiske brug af app en, og hvad brugeren tænker og oplever, når app en bliver brugt. I brugertesten observeres således den faktiske brug, brugeroplevelse og eventuelle problemer. Sagt på en anden måde menes brugertesten at kunne give indsigt i hvordan app en måler sig i forhold til de tre usability-dimensioner: funktionalitet, effektivitet og tilfredshed (Gregersen & Wisler-Poulsen 2009). I vores designproces blev der gennemført to forskellige brugertests med fire testdeltagere hver. Alle testdeltager blev rekrutteret tilfældigt, men var alle inden for den primære målgruppe for nærmere karakteristika se afsnit 4.1 og 4.2. Brugertestene er gennemført efter tænke højt -metoden (Gregersen & Wisler-Poulsen 2009), fordi det blev vurderet, at brugernes begrundelser og refleksioner på siden er interessant. Det er en viden, som ikke ville være mulig at få indsigt i ved kun at foretage en observation af testdeltagernes brug. Til hver brugertest var en testleder og en observatører til stede. Det skete fordi, at flere personer med fordel kan opleve flere nuancer af testforløbet end en enkelt gør. Samtidig kunne intervieweren koncentrere sig om at spørge og lytte, mens observatøren tog noter og aflæste kropssprog og lagde mærke til hvordan brugeren brugte produktet. En nærmere beskrivelse af udførelsen af brugertesten (testlederens manuskript) kan findes i bilag FØRSTE BRUGERTEST Halvejs inde i processen havde vi fået mock-up af konceptet på plads, og ville derfor undersøge om vores idéer og tanker også blev opfattet på samme måde hos brugerne. Derfor tog vi en dag ud af kalenderen og gav os til at brugerteste. Vi havde lavet den første mock-up på papir og pap, men til brugertesten havde vi omsat den til en elektronisk prototype gennem programmet Appcooker, så prototypen fungerede på en smartphone. Det gjorde det lettere at teste produktet, at vores brugere kunne teste direkte på den tiltænkte platform. Formål med brugerstesten: At se om ikoner og menutitler var forståelige og brugervenlige. Om brugeren let kunne sætte sig ind i funktionerne og fandt den overskuelig. Om produktet var en god idé og om de ville bruge det, hvis de fik muligheden. 10

11 DET MOBILE REJSEKORT // Brugertest Selve testen: Testen foregik ved Det Natur -og Sundhedsvidenskabelige Fakultetbibliotek, hvor vi testede på fire studerende, der alle faldt inden for den primære målgruppe på år. Fælles for de fire testpersoner var, at de alle brugte offentlig transport. Ingen af dem havde et rejsekort, to havde uddannelseskort og de to sidste brugte klippekort. Testpersonerne var: Emil, 24 år, single, læser Forvaltning på RUC. Christian, 26 år, kæreste og barn på halvandet år, læser Forvaltning RUC. Anne-Sofie, 24 år, single, læser Journalistik RUC. Søren, 29 år, kæreste, medicin-studerende. 1. opgave brug af check-ind og ud: Her gik det ikke så godt. Tre af testpersonerne gik ind under menupunktet Rejser først. De var forvirrede. Christian skulle have forklaret teknikken bag GPS først. Kun Søren løste testen med det samme. 2. opgave Rejse med flere transportmidler: Her blev testpersonerne sat til at bruge vores app til at rejse fra Nørreport St. til DR Byen. Tre af vores testpersoner klarer opgaven uden problemer og med mindst antal klik. Christian, der ikke har en smartphone eller Rejsekort, brugte dog skift-funktionen og blev lidt forvirret under vejs. Han manglede en pop-up når han trykker på skift. 3. opgave find ud af hvad en tur til Kolding koster: Alle fire testpersoner klarer opgaven til perfektion. Første deltest forståelse af menuer: Vi satte vores testpersoner til at gætte, hvad de enkelte menuer indeholdte af funktioner. Her viste det sig, at tre ud af fire brugere havde problemer med at gætte, hvad menuen Rejser indeholdt. Alle brugere gættede rigtigt ved de andre menuer. Problemet med menuen Rejser var, at de troede, at de kunne planlægge deres rejse i menuen. Vores formål med menuen var, at man skulle se en oversigt over ens tidligere rejseaktiviteter. 4. opgave afmeld automatisk optankning: Der er lidt tvivl hos to af testpersonerne, om de skal gøre det under saldo eller profil. Alle klarede dog fint opgaven. Kommentarer til produktet: - App en er dejlig overskuelig. Det er godt, at man får en kvittering. Det løser nogle af de problemer, der er med det nuværende Rejsekort, Søren 29 år. - Menuerne er fine og enkle, Anne-Sofie 24 år. - Jeg kunne godt bruge en kortfunktion, så man kunne planlægge 11

12 DET MOBILE REJSEKORT // Brugertest rejsen og se hvor man var samtidig, Christian 26 år. BILLEDE FRA NØRREPORT Konklusioner efter første brugertest: Der var nogle problemer med menu-punktet Rejser. Det forvirrede. Derfor lavede vi det om til Mine rejser. Generelt var applikationen let at bruge for vores brugere. Der var nogle tekniske udfordringer ved at det kun var en mock-up, som de testede. Deres holdninger til forbedringer bestod mest i tilføjelser som link til Rejseplanen og en kortintegration. Vi konkluderede derfor, at vores produkt var ret godt, da forbedringer var yderligere funktioner og ikke store problemer med vores nuværende design. 4.2 ANDEN BRUGERTEST En uge senere i processen var prototypen af Rejsekorts-app en ko- Testpersonerne var: det færdigt. Vi havde brugt erfraringerne fra første brugertest til Kvinde, 26 år, et barn, bor i København, sygeplejerske, bruger ofte of- at tilpasse og udvikle vores prototype. Prototypen blev testet på en fentlig transport. Bruger klippekort, har ikke kendskab til Rejsekortet. iphone og blev hentet over en server på IT Universitetet. Vi ville teste produktet ved et trafikknudepunkt, hvor det var tiltænkt, Mand, 27 år, ingen børn, bor i København, studerende, bruger of- at det skulle bruges i virkeligheden. Derfor tog vi til Nørreport Sta- fentlig transport, bruger klippekort, har ikke Rejsekort, men har tion. Danmark mest benyttede trafikknudepunkt (Orestad.dk, 2013). kendskab til konceptet. Vi gik efter den primære målgruppe på år i vores udvælgelse, og gik efter folk der stod stille, eller tog en pause. Tourister og folk under Kvinde, 21 år, ingen børn, bor i København, studerende, bruger 18 år blev valgt fra. sjældent offentlig transport (cykler mest), bruger klippekort, har ikke et Rejsekort, men har kendskab til det. 12

13 DET MOBILE REJSEKORT // Brugertest Mand, 34 år, ingen børn, bor i København, bruger sjældent offentlig transport (har sidst taget en tur til Svendborg), bruger klippekort, har ikke kendskab til rejsekort-konceptet, har ingen smartphone. Første deltest Forståelse af menuerne: Ingen havde problemer med at afkode vores nye menuer og ikoner. Alle gættede rigtigt. - Jeg er positivt overrasket. Det er lige til og meget logisk. Jeg er ikke i tvivl om noget undervejs, kvinde 21 år. Forbedringer: - Betalingsinfo kunne godt stå lidt højere oppe, så man ikke skal scrolle ned, Lars 27 år. Der mangler lidt info om hvordan man bruger Rejsekortet, hvis man ikke kender til det nuværende system. 1. opgave Forestil dig, at du skal bruge app en til at komme hjem: Alle klarede opgaven uden problemer. 2. opgave Hvad koster en rejse til Kolding: Igen havde ingen af testpersonerne problemer og fandt hurtigt prisen. Også de to personer uden smartphones, kvinden på 21 år og manden på 37 år, indtaster let stationerne i menuen Beregn pris. 3. opgave afmelding af automatisk optankning Alle testpersonerne gik hurtigt ind i profil, fandt menupunktet og klarede opgaven med det mindst antal klik muligt. Konklusioner efter anden brugertest: Vi fik løst de problemer som der var ved den første prototype. Ved anden brugertest var der ingen af de fire personer, der havde problemer med opgaverne undervejs. Det viser, at vi har lavet et produkt med et overskuelige menuer og ikoner. Det vi har taget med os fra anden brugertest er små forbedringer, som placeringen af funktioner og at der måske mangler en smule info til førstegangsbrugere, der skal bruge check-ind og ud funktionen for første gang. Kommentarer: - Jeg synes generelt, at Rejsekortet er et håbløst projekt, men jeres app virker nem og mange vil få gavn af den. Det er en positiv forenkling, Lars 27 år. 13

14 DET MOBILE REJSEKORT // Informationsarkitektur 5. INFORMATIONSARKITEKTUR I dette afsnit præsenterer og redegører vi for opbygningen af vores færdige prototype. Derudover redegører vi for hvilke tanker vi har gjort os omkring navigation, strukturering og brugervenligheden i udarbejdelsen af app en. Informationsarkitektur dækker over, hvordan man strukturerer sit indhold på en given platform. Det essentielle for informationsarkitekturen er, at den understøtter brugernes behov. Brugerne skal let kunne finde forskellige informationer, samt navigere rundt uden større problemer og forvirring. En velstruktureret informationsarkitektur er usynlig for brugerne og man bemærker den kun, hvis den ikke fungerer (Morville & Rosenfeld, 2007: s.41). For at skabe den gode struktur, var det vigtigt at visualisere den. Det første skridt var at organisere og strukturere, hvad og hvor meget indhold app en skulle bestå af. Vi tog udgangspunkt i Rejsekortets hjemmeside, og fandt frem til det vigtigste indhold, der skulle med i app en. Vi begyndte dernæst at sortere i indholdet for at skære ind til benet, og kun udvælge det som brugeren har brug for, samt tilføre mangler (Lynch & Horton, 2008). Det var herefter vigtigt at gruppere og adskille indholdet, og finde frem til det indhold der passede logisk sammen. Herefter opdelte vi indholdet i kategorier og gav dem navne. Da disse overvejelse var på plads, kunne vi begynde at planlægge navigationen i app en. Det endte med fem menupunkter, med tilhørende undersider der alle kan ses i nedenstående flowchart. Det essentielle var, at brugeren hurtigt og nemt kunne nå i mål. Altså at brugeren med få tryk med lethed skulle opnå det ønskede scenarie. Vi forsøgte derfor at begrænse antallet af undersider. FLOWCHART Ind/Ud Kontrol Skift/Ud Kvittering Mine Rejser Loading screen Login Saldo Beregn pris Oversigt Betaling Tilmelding Pris Kvittering Kvittering Betalingsinfo Korttype Betalingsinfo Kortnummer Mobil By Postnummer Adresse Udløbsdato Sikkerhedskode 14

15 DET MOBILE REJSEKORT // Designprincipper 6. DESIGNPRINCIPPER Rejsekortet er forholdsvis nyt, og ikke alle danskere har kendskab til det. Det erfarede vi gennem vores brugertest. Det var derfor vigtigt, at vi havde genkendelighed og ensartethed i højsædet i udarbejdelsen af den visuelle identitet og designet til app en. Vi ville ikke gøre folk forvirrede. Samtidig var det vigtigt for os at vise, at det fysiske og mobile Rejsekort ikke var to uafhængige ting med to forskellige afsendere. Vi har derfor arbejdet hårdt på, at den eksisterende visuelle identitet i form af hjemmesiden og det fysiske rejsekort, skinnede igennem i vores design af det mobile Rejsekort. Hvis vi skal kigge nærmere på designet, har vi fulgt nogle designprincipper, for at skabe en rød tråd og en overskuelighed igennem designet. Især følgende designprincipper er gennemgående i designet og den visuelle identitet: - Ensartethed - Genkendelighed - Enkelhed - Brugbarhed Vi har haft fokus på ensartethed igennem hele designet. Det er de samme farver, former og størrelser der ofte går igen. Det kommer dermed til at fremstå mere struktureret og overskueligt (Wisler- Poulsen, 2012: s.35) Samtidig har genkendeligheden også været i fokus. Brugeren skal ikke blive forvirret i anvendelsen af app en. Det skal være let for brugeren at bruge app en. Det er essentielt, at brugeren opnår den samme følelse ved brugen af app en som ved brugen af det fysiske rejsekort. Oplevelsen skal være så identisk som muligt. Vi stiler efter at opretholde brand-security (Wisler-Poulsen, 2012 : s.61). Derfor har vi prøvet at holde designet så enkelt som muligt. Vi har benyttet os af KISS-principper (keep it simple, stupid) Alle unødvendige elementer og de såkaldte darlings har vi forsøgt at skære væk. Da det er en rejse-app, skal brugeren også kunne benytte sig af den hurtigt uden for mange unødvendige elementer, der nedsætter funktionaliteten og brugbarheden. Som usability-ekspert Jakob Nielsen udtaler: Websitet bør ikke indeholde information, som er irrelevant eller sjældent brugt. Enhver ekstra enhed af information i dialogen med systemet konkurrerer med de relevante enheder af information og formindsker deres relative synlighed (Wisler-Poulsen, 2012: s.29) Dette udsagn har vi taget til os, og vi har benyttet disse tanker i udformningen af app en. Alle informationer som man finder i app en er skåret ind til benet. Det er sket gennem vores brugertest, hvor vi erfarede hvilke menupunkter der var essentielle, samt hvad menupunkterne skulle hedde for at højne brugervenligheden. 15

16 DET MOBILE REJSEKORT // Visuel identitet 7. VISUEL IDENTITET 7.1 BOMÆRKE BOMÆRKE For at den visuelle identitet skal være opfyldt og komplet, skal der indgå fire elementer: Bomærke, Navnetræk, Farve og Typografi (Wisler-Poulsen, 2005: s.20). Som skrevet tidligere har vi fokuseret på at drage en klar parallel mellem Rejsekortets hjemmeside og app en. Vi har derfor designet næsten samme bomærke, der i høj grad minder om det eksisterende. Dette bomærke er designet i Adobe Illustrator, og sat sammen af ni cirkler, hvor de alle er transparente undtagen den yderste, som har den helt oprindelige blå farvekode, som Rejsekortet anvender på hjemmesiden rejsekortet.dk. 7.2 NAVNETRÆK Rejsekortet har betalt for at få udviklet og designet en font specielt til navnetrækket. Det er ikke muligt at bruge den præcis samme. Fonten som vi har brugt til navnetrækket er Arial. Det er en sans serif font, som er god til web og som de fleste brugere har. Samtidig minder den meget om Rejsekortets font. Navnetrækket står i versaler, da det fremstår stærkt og dermed også er let læseligt. Det er vigtigt i de små formater, der er på smartphones. Vi har valgt en bold garniture, da det er mere iøjnefaldende. Arial er også god til overskrifter, da fonten fremstår tydeligt. Det ville have været et problem, hvis vi havde benyttet den til brødtekst, da sans serif fonte tit bliver klumpet og utydeligt, hvis man skal læse meget. Det sker fordi den ikke har fødder. NAVNETRÆK REJSEKORT 16

17 DET MOBILE REJSEKORT // Visuel identitet 7.3 FARVE FARVER Der er tre farver, der er benyttet igennem hele designet. Det er den blå farve som er repræsenteret på logoet, navnetrækket, aktivitetsknapper og de forskellige ikoner. Den blå farve er valgt for at bibeholde farveidentiteten, samt fremhæve og styrke logoet og ikonerne. Derudover er der to variationer af grå. En meget mørkegrå, som bliver brugt på skriften igennem hele app en, og en meget lysegrå, som indrammer forskellig tekst. Den lysegrå fremhæver de forskellige lukkede bokse, for at skabe en kontrast til den hvide CMYK: 89,54,0,0 RGB: 2,112,183 #: 006fb7 CMYK: 11,8,9,0 RGB: 223,223,223 #: dfdfdf CMYK: 79,63,54,45 RGB: 47,62,70 #: 2f3e46 baggrund. Ved at der er en forholdsvis stor kontrast mellem den blå og de grå farver opretholder man et visuelt hierarki. 7.4 TYPOGRAFI Rejsekortet.dk bruger tre fonte. Helvetica, Arial og en serif font som er specielt designet til identiteten. For at holde det enkelt, har vi valgt nedenstående css-kode, hvor Helvetica er den førstkomne typografi. Vores app består i høj grad af illustrationer, fremfor tekst. Vi vurderede derfor at én font var passende. Det var essentielt at denne font fremstod tydelig og letlæselig, da vi arbejder i et lille format. Helvetica er en sans serif font, som fungerer godt, når det typisk er overskrifter og underskrifter der bliver anvendt. Hierakiet i typografien bliver derfor skabt ved hjælp af forskellig punktstørrelse i overskrifter, underoverskrifter og brødtekst. TYPOGRAFI AaBb123 abcdefghijklmnopqrstuvwxyzæøå ABCDEFGHIJKLMNOPQRSTUVWXYZÆØÅ @,.!?=+% Helvetica Bold CSS KODE {font-family: Helvetica,Arial,sans-serif} 17

18 DET MOBILE REJSEKORT // Visuel identitet 7.5 IKONER Vi blev opmærksomme på vigtigheden af ikoner og symbolikken i vores brugerundersøgelse. Den viste, at ikke alle opfattede og fortolkede symbolikken af ikonerne ens. Der var samtidig nogle af testpersonerne der havde svært ved at identificere teksten til ikonerne i menuen, og misforstod betydningen af selve ikonet og menupunktet. Med udgangspunkt i resultaterne fra brugerundersøgelserne har vi designet fem ikoner og fem menutekster. Menuen er dermed en kombination af ikoner med tilhørende tekst. Det sker for at øge brugervenligheden. Vi har anvendt bomærket som check ind/ud/ skift ikon, for at sikre ensartethed og enkelhed i brugeropfattelsen. De fremstår på forsiden, da vi vurderede at de ville blive de mest benyttede ikoner i app en. MENU IKONERNE CHECK IND IKON Ind 18

19 DET MOBILE REJSEKORT // Kodning 8. KODNING I det følgende afsnit vil vi se nærmere på den tekniske udførelse af app en, som vi har kodet med hjælp af HTML5, CSS og jquery Mobile. Her vil vi endvidere beskrive de udfordringer/ problemstillinger vi har mødt undervejs i kodningsprocessen. 8.1 MOBILE PLATFORME Der er grundlæggende set fire måder at skabe mobile platforme på: MOBILE WEBSITES designes som normale websites og optimeres til mobile platforme ved hjælp af media quieries og responsive design. Mobile websites bliver vist i den mobile enheds browser og kræver netadgang. WEB APPS designes i frameworks som fx jquery Mobile og Sencha Touch, der kombinerer HTML5, CSS3 og JavaScript. Web apps bliver vist i den mobile enheds browser og kræver netadgang. NATIVE APPS designes fra bunden i specifikke udviklingsmiljøer (SDKs) og kodes i de dertil hørende sprog, fx Objective-C for ios og Java for Android. Native apps er typisk preloadet på den mobile enhed og kræver derfor ingen netadgang. HYBRID APPS designes som web apps og indpakkes derefter i en native container vha. fx Phone Gap. Dvs. den kombinerer fordelene ved web apps og native apps (se figur 1 til højre). Adgang til mobilens hardware (API) FIGUR 1. NATIVE APPS: - Platform specifik udvikling - Hurtig - app en er preloadet - God udnyttelse af mobilens hardware (APIs) fx geolocation - AppStore distribution. - Raffineret og lækker brugeroplevelse HYBRID APPS: Platform tilgængelighed - Cross-platform udvikling vha. HTML5, CSS3 og JavaScript - Loades via mobilen (hurtigere pga. preloading) - Adgang til mobilens hardware (APIs) - AppStore distribution WEB APPS: - Cross-platform udvikling vha. HTML5, CSS3 og JavaScript - Loades via webserveren (løbende opdatering) - Ikke knyttet til én platform - derfor ingen faste rammer. Da opgaven var at udvikle en prototype ud fra de formelle krav om, at der skulle benyttes de kodningssprog som er dækket på kurset, dvs. HTML5, CSS og jquery, kunne en native app meget hurtigt udelukkes. Valget stod derfor mellem et mobil website eller en web app. Ud fra perspektivet om, at konceptet kræver en app-løsning, hvor geolocation er en central funktionalitet. Og at man kan lave en web app om til en hybrid app, så at den kan få adgang til mobilens APIs, valgte vi at udvikle prototypen som en web app med jquery Mobile som framework. På denne måde kunne vi udvikle en prototype, der i design og funktionalitet kommer til at ligne og opføre sig mest muligt som en native app. 19

20 DET MOBILE REJSEKORT // Kodning 8.2 JQUERY MOBILE JQuery Mobile er et HTML5/CSS3/JavaScript UI-framework, der bygger på JavaScript biblioteket, jquery (Jquerymobile. com, 2013). Fordelen ved jquery Mobile er, at man kan generere touch -optimerede mobile web apps uden at skrive en eneste linje JavaScript. App en skrives i HTML, hvor elementerne klassificeres efter et bestemt data-role-system (se afsnit 8.4), hvor de automatisk får en tilsigtet funktionalitet. jquery Mobile er kompatibel med mange forskellige mobile enheder, hvilket gør at prototypen bliver tilgængeligt på mange forskellige platforme (Jquerymobile.com, 2013). Det er en stor fordel for konceptets formål. 8.3 GENEREL OPBYGNING Prototypen består overordnet af en index-fil, 28 undersider i mappen pages (alle sider er html-filer), en mappe med billeder (images) samt forskellige JavaScript og CSS-filer. Samtlige sider er udviklet vha. jquery Mobile hvilket betyder, at hver enkelt side har følgende JavaScript- og CSS-filer placeret i <head>: <link rel= stylesheet href= custom.css /> Det vil sige, at det samlede design/formatering udgøres af to css-filer. Ingen formatering er anvendt i selve html-dokumenterne. I prototypen anvendes to tilpassede default-themes fra jquery Mobile, data-theme= c og data-theme= b. Det skal bemærkes, at datatheme= b kun bruges til de blå knapper samt listevisningen under Mine rejser. På grund af, at det er ret vanskeligt at tilpasse jquery Mobiles CSS med vores eget CSS (en af de store ulemper ved jquery Mobile) er der nogle gange blevet foretaget en direkte tilpasning af jquery Mobiles data-theme. Som eksempel de blå knapper, hvor den blå farvekode er blevet tilpasset direkte i jquery.mobile min.css ved søg- og erstat metoden og ikke i custom.css <link rel= stylesheet href= jquery.mobile min.css /> <script src= jquery min.js ></script> <script src= jquery.mobile min.js ></script> Dertil kommer en egen generet CSS-fil, som primært tilpasser defaultdesignet fra jquery Mobile til vores eget rejsekort-design: 20