Applikation til Rejseplanen

Transkript

1 Applikation til Rejseplanen Hold 1-E2010 Lærer Sigurd Trolle Grönemann Rejseholdet, gruppe 7 Jeppe Boutrup Nielsen Kenni Kindler Odelheim Susanne Tvedergaard Kristensen Cameline Bolbroe Anslag:

2 Vejledning til brugerscenarie Da applikationens prototype skal demonstrere interaktivitet, er dens funktionalitet opbygget omkring et specifikt bruger-scenarie, da den ikke er fuldt ud funktionel. Følgende funktionaliter er derfor mulige: Forsiden At indtaste tekst i Fra og Til felterne At klikke på det øverste favoritikon At klikke i tid og/eller datofeltet At vælge ankomst eller afgang (herefter er felterne udfyldt i overenstemmelse med vores brugerscenarie) At klikke Find Rejse og gå til ruteoversiten Oversigt Klikke på disketten og vælge adresser som skal tilføjes til favoritter Vælge den nederste rute Rejsen Klikke på beskrivelse af gåturen mellem Finlandsgade og Amarbro Metro Station Gårute Klikke på div. foto og navigere i Street View via linket Live Kort er tilgængeligt på alle sider i bundmenuen Rejse i bundmenuen er også aktiv og linker til første side Brugerscenarie 1. Du taster adresserne Finlandsgade 34 og Tagensvej 118 ind i felterne 2. Du vælger evt. Finlandsgade fra Favoritter 3. Du vælger tid for afgang ved at klikke på dato feltet og vælger Afgang Nu 4. Du har nu alle indtastninger og klikker på Find Rejse 5. Du klikker på disketten og vælger at gemme begge adresser ved at hakke dem af med et flueben 6. Du klikker på Se Rejseplan for den nederste rejse 7. Du klikker på (Se på kort) og kan nu se en beskrivelse af gåruten 8. Du klikker på et af de fem fotolinks 9. Du klikker på Live Kort i bunden af menuen 2

3 Indholdsfortegnelse Susanne Tvedergaard Kristensen - stve Jeppe Boutrup - jbou Kenni Odelheim - kkin Cameline Bolbroe - camb 1. Præsentation af case (kkin) Fremtidens Rejseplan Rejseplanens konkurrence Problemstilling 5 2. Analyse af Rejseplanen (kkin) Find hvad du skal bruge og smut så igen Målgruppe 7 3. Metodisk tilgang (stve) Designproces Idé generering Rejseplanens brugerundersøgelse Brainstorm Sketching Mock-up (camb) Wireframes Html som prototype for en applikation Første brugerundersøgelse (jbou) Beskrivelse af 1. brugsscenarie Udførsel af 1. brugerscenarie Reflektioner og videreudvilking af app en Spørgeskemaundersøgelse (kkin) Konklusion og redesign af applikation Anden brugerundersøgelse (stve) Hovedpointer fra brugerundersøgelsen Forslag til ændringer Refleksioner og videreudvikling af app en Fremtidens Rejseplan (camb) Design Farvevalg og visuel identitet Ikoner, symbolik og grafik i en applikation 33 8.HTML/CSS 35 (kkin) 8.1 Applikationen - generelt XHTML Mobile 1.0 vs. XHTML Strict 1.0 (jbou) Bundmenuen - <div id= bmenu > Lag på lag Street View (kkin) Knapper med Javascript Den færdige prototype (camb) Konklusion (stve) Perspektivering (jbou) Litteratur Bilag 45 3

4 4

5 Applikation til Rejseplanen 1. Præsentation af case 1.1 Fremtidens Rejseplan Rejseplanen.dk er danskernes foretrukne website til information om rejser fra A til B med kollektiv transport. Med flere end 10 mio. opslag om måneden er Rejseplanen.dk (RP) en af de mest benyttede hjemmesider i Danmark. Hjemmesiden blev lanceret den 1. oktober 1998 og er i dag Danmarks næststørste offentlige site, kun overgået af dmi.dk. RP indeholder data fra alle danske tog- og busselskaber foruden de fleste færger, og ejerkredsen bag RP er de regionale trafikselskaber, DSB, Movia samt Metroselskabet (web ref. 1). Så hver måned får mere end 10 mio. danskere leveret rejseforslag via web, mobil, touch screens, som stemmegenkendelse og som link fra andre hjemmesider. Men kan RP blive endnu bedre? Endnu smartere? Eller kan RP måske tænkes på en helt anden måde? 1.2 Rejseplanens konkurrence D. 11. oktober skød RP en konkurrence i gang, hvor vi som studerende, udviklere eller designere har mulighed for at komme med bud på, hvordan RP kan forbedres i fremtiden. Formålet med konkurrencen er at mobilisere landets kreative kræfter og give brugerne mulighed for at føre netop deres geniale idé eller smarte løsning ud i livet (web ref. 2). Den overordnede opgave går ud på at komme med et kvalificeret bud på ideudvikling af RP. Birgitte Lomholt Woolridge fra RP fortæller blandt andet: Vi vil enormt gerne have konkrete bud på design, applikationer, mash-ups, bud på, hvor Rejseplanen kan anvendes i det fysiske liv, hvor vi endnu ikke er. Konkurrencen er således meget åben, men alle indsendte ideer bliver vurderet ud fra følgende tre kategorier: Design, Teknik og Udbredelse. I vurderingen lægges der desuden stor vægt på brugervenlighed samt kriterier som innovation, anvendelighed (hvor bred en appel har idéen/konceptet/ produktet?) og realiserbarhed (web ref. 3). 1.3 Problemstilling Med motivationen på plads, har vi således valgt at tage RP s udfordring op. Opgaven kan umiddelbart gribes an på flere forskellige måder; skal RP kunne mere? Eller mindre? Skal den måske kunne findes andre steder? Med udgangspunkt i de tre hovedkategorier i RP s konkurrencemateriale har vi, i kraft af eksamensopgavens krav og 5

6 kompetencefordelingen i vores gruppe, valgt hovedsagligt at fokusere på punktet udbredelse med et konceptuelt udgangspunkt. Det er altså ikke vores ønske at lave et komplet re-design af RP, men at fokusere på enkelte områder, udvalgt på grundlag af brugernes ønsker og behov med afsæt i en brugerundersøgelse 1 foretaget af RP selv. Flere og flere brugere fjerner sig fra skærmen og tager RP med ud i virkeligheden. Dermed dukker der nye brugerbehov op og andre krav til, hvad RP skal kunne. Danskerne er faktisk blandt de mest avancerede brugere af mobile enheder og er generelt førende i adfærd på nettet. Netop derfor bliver RP konstant udfordret på teknologier, aktuelt iphone og Android: Vores mål er hele tiden at være der, hvor brugerne er, også rent teknisk, fortæller Birgitte Lomholt Woolridge fra RP (web ref. 4). Som det ser ud nu, findes RP allerede på IPhone, men vores research viser, at man ikke har formået, at matche brugernes krav i forhold til, hvad app en b.la. skal kunne. Derfor ser vi det som en interessant udfordring at udvikle et koncept, der kan gøre det nemmere for brugeren at anvende RP på farten. Med de betragtninger in mente, er formålet med dette projekt at: Udvikle et kvalificeret bud på RP med udgangspunkt i en applikation, der kan forbedre brugerens oplevelse og interaktion med RP via hans/hendes smartphone. 2. Analyse af Rejseplanen 2.1 Find hvad du skal bruge og smut så igen RP er en søgemaskine. Den giver information til kunder/passagerer men har som sådan ikke kontakt til kunderne. Generelt er formålet med søgemaskiner, at man finder det, man har brug for og så smutter igen. På RP søger man også en rejse og er væk igen. En webgenre som søgemaskinen er med til at generere forskellige forventninger hos brugerne: Genres are generated by the repetition of phenomenological constellations - such as textual context, navigational elements, layout, graphics, the use of dynamic or static images and color range (Engholm 2005:44). Alle disse elementer er altså med til at konstruere, hvad vi som brugere forventer, når vi fx foretager en søgning på RP. Så når vi har med RP at gøre, er det vigtigt, at vi gør os nogle tanker om de mulige konventioner og forventninger, der allerede ligger hos brugeren. Som sagt handler det for brugeren om hurtigt at kunne foretage søgning med det formål at komme fra a til b. Derfor er det ligeledes nødvendigt, at app en og dens undersider er lette, enkle og overskuelige at gå til, så brugerne ikke mister tålmodigheden eller bliver irriterede over, at de ikke får, hvad de vil have. Udfordringen bliver dermed at kende brugerne, for at være i stand til at målrette servicen i den relevante situation. 1 Læs mere om Rejseplanens brugerundersøgelse i afsnit

7 2.2 Målgruppe RP anvendes af en bred skare af den danske befolkning. En brugerundersøgelse fra 2005, som RP selv har foretaget viser, at 95 % af de besøgende efterfølgende køber en billet, når de har foretaget en søgning. En mulighed, som endnu ikke findes til smartphones. Tallene viser desuden, at 60 % af brugerne er kvinder, og at halvdelen af RP s brugere er bilister, som lader bilen stå, når de skal ind til byen (web ref. 5). Undersøgelsen tager desuden fat på brugernes internetvaner og viser, at brugerne er meget digitale. 90 % er på nettet dagligt - og mange flere gange dagligt. Det tal er cirka det dobbelte i forhold til danskere i øvrigt, som senest er opgjort af Danmarks Statistik. Hos RP tror man, at det hænger sammen med, at kunderne i den kollektive transport hører til blandt trendsætterne på internettet (ibid.). En pointe, som er med til at aktualisere behovet for en opdateret RP til smartphone brugere. Vi har valgt at fokusere på en del af RP s overordnede målgruppe; brugere og potentielle brugere af smartphones mellem 20 og 30 år. Det valg har vi truffet på baggrund af opgavens omfang og tidsmæssige begrænsninger. 3. Metodisk tilgang EN MERE FLEKSIBEL MODEL A simple interaction design lifecycle model, Sharp et al., 2002: A simple Interaction design Lifecycle model (Sharp et al. 2002:448) 3.1 Designproces Forud for udskrivelsen af konkurrencen har RP selv foretaget en brugerundersøgelse, hvor man har haft mulighed for at komme med sine bud på ideer til forbedringer, tiltag etc. (web ref. 6). Fordi RP allerede har indsamlet empiri om brugernes ønsker og behov, vurderede vi, at det ikke var nødvendigt med nogen indledende undersøgelser i felten. Vi besluttede os for at vente med at inddrage brugerne i vores designproces til den første prototype var klar. Med inspiration fra en livscyklusmodel(indsæt Interaction Design Lifecycle Model (Sharp et al. 2007:251) lånt fra feltet Interaktionsdesign, planlagde vi designprocessen omkring to brugerinddragelser. Hensigten var at få skabt en proces, som ville give os mulighed for at arbejde iterativt og ud fra brugernes feedback registrere og evaluere hvilke parametre, muligheder og løsninger vi kunne prioritere i den videre udvikling. Den cirkulære livscyklusmodel fokuserer netop på brugen af interaktive prototyper som et afgørende redskab i designprocessen (Sharp et al. 2007:251). Ved at designe prototyper og teste dem, får vi inkorporeret et tidligt fokus på brugerens behov og dermed mulighed for at evaluere, identificere nye behov og redesigne undervejs i processen. Da modellen illustrerer en cirkulær proces, kan evaluering i princippet fortsætte i det uendelige (Sharp et sl. 2007:251). Vi valgte at afgrænse designprocessen til to brugerinddragelser, set i lyset af vores tidsmæssige begrænsninger - men også for at bevare en progression i udviklingen 7

8 3.2 Idé generering Første fase i vores designproces var at få indsigt i brugernes ønsker og behov, for at kickstarte vores ide generering og designproces. Som det første foretog vi derfor en analyse af den allerede eksisterende brugerundersøgelse ved hjælp af en række kreative metoder. I følgende afsnit gennemgår vi vores metodiske proces frem mod udarbejdelsen af den første prototype. 3.3 Rejseplanens brugerundersøgelse Brugerundersøgelsen bestod af en lang række forslag vedrørende alt fra RP s struktur, funktion, design, brugervenlighed etc.(bilag 1). Resultaterne samlede vi i et Excel ark, hvorefter vi hver især gennemgik de forskellige forslag. Via affinity diagramming tematiserede vi ønsker og behov ud fra en vurdering af hhv. antal likes og antal gange et ønske optræder fra forskellige brugeres side. Størstedelen af de ratings der optræder i undersøgelsen, indeholder ganske få likes, hvorfor man ikke kan sige noget om forslagets værdi, da intervallet mellem værdierne bliver for lille. Vi har derfor valgt kun at medtage ratings på 10 likes eller derover. På denne måde får vi et prioriteret overblik over brugernes vurderinger af forslag. Baseret på resultaterne klyngede vi brugernes behov og ønsker ud fra følgende temaer: Personalisering af Rejseplanen Flere brugere efterspørger en mere personlig RP både når det gælder websitet og den eksisterende app til iphones. Muligheden for at oprette en profil og bogmærke sine seneste ruter er bl.a. en funktion flere brugere efterspørger: En iphone App, der opfanger de ruter/stop man typisk bruger, så der ikke skal hentes data hele tiden. At gemme sine favoritadresser, er også et forslag, der går igen iblandt brugerne: Muligheden for at gemme sine mest brugte rejsemål hjem, arbejde, søster så man hurtigt kan få rejseplanen frem på mobilen. Bedre applikationer til iphone og Android Overordnet er der stor efterspørgsel efter en app til android og ikke blot links til web-delen af Rejseplanen. Mange efterspøger en forbedret udgave af app en til iphone. Der er en stor utilfredshed at spore i forhold til brugernes oplevelse af den nuværende app både i forhold til brugervenlighed og tekniske funktioner. Muligheden for at købe billetter på app en er bl.a. en funktion der savnes, ligesom at opdaterede informationer om sporarbejde, forsinkelser osv. er en feature flere brugere efterlyser. 8

9 PERSONLIG REJSEPLAN GPS VISUALISERING APPLIKATION GENERELT MULIGHED FOR AT GEMME SINE MEST BRUGTE REJSEMÅL Find nærmeste station/ stop baseret på GPS position Bedre app til iphone! App til android tak! MYLDRETIDSINFO Køb SMS/E-Billet Under Fra og Til på vil jeg gerne kunne bruge mine tidligere indtastninger - ligesom Google gør det En RESTful hjemmeside, så man kan bogmærke sine søgeresultater (ingen session, der timer ud). PERSONLIG SIDE MED FAVORITADRESSER OG SENESTE RUTER GPS integration, smsbillet integration, vis rute på kort Udnyt GPS til at angive hvor man er! Find automatisk min omtrentlige position Kan man ikke integrere Google Maps på Android telefoner med Rejseplanen? Inkorporere eksisterende webcams på ruter og destinationer EN APP HVORUDFRA GPS LOCATION DEFINERER DEN HURTIGSTE RUTE MED OFFENTLIG TRANSPORT TIL ET GIVET PUNKT. Find rejse via nuværende position (GPS, Mobilmaster m.v. Android, iphone) Vis afgange i nærheden af hvor man er via GPS eller indtastning af adresse/sted/postnr. En app som kombinerer google streetview med en downloadable ruteplan Rejseplanen til Android! Lave en Android App eller en mobil venlig version af rejseplanen Gør det muligt at købe billet direkte i iphone app et til den planlagte rejse EN ANDROID APP LIGESOM DER ER EN TIL IPHONE Man skal kunne bestille billetter direkte i iphone app Bedre mobil-site. Det nuværende er utrolig dårligt til touch telefoner. Gør mobilrejseplanen nemmere En app. til smartphones, som hele tiden orienterer om: aflysninger, forsinkelser, sporændringer - for både bus og tog. Kunne modtage sms er ved f.eks. forsinkelser eller sporændringer Bedre kort og rutevejledning til gåruter Mulighed for at vælge mellem billigste og hurtigste rute. UDVID REJSEPLANEN SÅ MAN KAN SE HVOR FX ENS FACEBOOK-VENNER ER I TOGET Simpelt design, gps integration, sms billet integration Mulighed for at dele ruten med andre og se om nogen jeg kender er i nærheden Tilføj cykelruter JEG SAVNER ET OVERORDNET KORT OVER DEN VALGTE RUTE Vis cykelruter via stier Det ville værre fedt, hvis man kunne se hvilke zoner man skulle igennem Affinity Diagram 9

10 GPS og visualisering Topscorerne i undersøgelsen kan klynges under nøgleordene GPS, Google maps og visualisering. Der er stor efterspørgsel efter en GPS funktion, som kan definere den hurtigste rute med offentlig transport til et givet punkt og vise rute på kort, med zone overlay. Der findes allerede en GPS funktion til iphone app en, som er i stand til at identificere stationer/stop tæt på. Undersøgelsen tyder dog på, at der er efterspørgsel efter en mere interaktiv og visuel udgave. Udover at se på, hvilke forslag der modtog flest ratings, undersøgte vi også hvilke ønsker der blev nævnt flest gange i undersøgelsen. De ønsker som optrådte flest gange indeholdt beskrivelser som App, Android App, Iphone, GPS, mobil samt mulighed for køb af billet og peger derfor på et behov for at forbedre mulighederne for at benytte RP på farten. 3.4 Kritik af Rejseplanens brugerundersøgelse Da RP s brugerundersøgelse er bygget på opfordringen Giv dit bud på Rejseplanens fremtid, mener vi, at der i denne form for spørgsmål ligger en særlig problematik. Ved at stille spørgsmålet på denne måde, med en direkte henvisning til RP, mener vi at brugerne meget hurtigt bevæger sig ind i et lukket mindset. Det kommer let til at handle om konkret funktionalitet i den eksisterende RP, hvorfor forslagene centrerer sig om små ændringer i stedet for at gentænke RP som en helt ny måde at rejse på. Vi kunne forestille os at bevæge os fra spørgsmål, der direkte handler om RP, til spørgsmål der mere generelt tager udgangspunkt i det at rejse samt brugen og betydningen af offentlig transport. Spørgsmål kunne eksempelvis fx være: Hvad bruger du din tid på, når du kører i bus/tog? Hvad er den bedste oplevelse, du har haft på en bus/togtur? Brugerundersøgelsen kunne også inkludere metoder som cultural probes (Gaver et al. 1999) og contextual inquiry (Beyer et al. 1998), hvor man eksempelvis ville bede en bruger føre rejsedagbog over en periode, for at kortlægge brugerens vaner og behov ud fra en konkret oplevet kontekst. Med det in mente har vi alligevel, på grund af den begrænsede tidsramme, valgt at tage udgangspunkt i RP s egen brugerundersøgelse. Havde tidsrammen set anderledes ud, mener vi, at man med fordel kunne tilrettelægge en brugerundersøgelse på en mere hensigtsmæssig måde. Med afsæt i vores research og de identificerede behov, besluttede vi os for at arbejde videre med ideen om at udvikle en app til RP. Hermed tilførte vi vores designproces den første konkrete designramme, som vi tog afsæt i under den første ide udvikling. 10

11 3.5 Brainstorm Generating alternatives is the key principle in most design disciplines (...)The best way to get a good idea, is to get lots of ideas (Sharp et al. 2007:235). Efter at have valgt app som genre, lavede vi en brainstorm over mulige nye funktioner, der kunne forbedre brugbarheden af RP på smartphones. Selvom vi allerede havde fået mange konkrete ideer på bordet fra vores research, valgte vi at fokusere bredt i vores brainstorm - med det formål at få så mange ideer som muligt. Vi ville ikke risikere at sætte os fast på én god idé for tidligt i processen uden først at have afsøgt mulighedsrummet. Udfaldet af vores brainstorm blev, en bred vifte af ideer, problemstillinger og pointer, som vi herefter tog op til diskussion. Brainstorm session 11

12 3.6 Sketching Sketching in the broad sense, as and activity, is not just a byproduct of design. It is central to the design thinking and learning (Buxton 2007). INDSÆT BILLEDE AF SKETCH Med udgangspunkt i diskussionen af forslagene fra RP s brugerundersøgelse, valgte vi en række tematikker ud som blev kædet sammen og udbygget via sketching. En af styrkerne ved sketching, som Buxton (2007) også fremhæver i sin bog, er, at selve visualiseringen giver et rigtig godt overblik og det kan blive muligt for os at spotte, hvilke potentialer og barrierer ideen indeholder. Det var vores formål at udfordre og opstille scenarier, der centrerede sig om brugerens ønsker og behov, men uden at være en direkte overførsel af forslag som jeg kunne godt tænke mig at der var GPS i RP. På denne måde fik vi indkredset nye kombinationer af de funktioner som flest brugere efterspurgte. En række af de koncepter vi i denne fase kom frem til, er beskrevet herunder. Augmented Reality Augmented Reality (AR) er et begreb, der dækker over et digitalt genereret billede af den fysiske virkelighed overlejret med informationer som lyd og grafik. I RP er der en del muligheder for at bruge AR som et brugbart informationslag, der kan give brugeren forskellige oplysninger i forbindelse med en rejse. Ved at se igennem kameraet på sin telefon, kan brugeren fx se informationer om det nærmeste stoppested eller station, afgangstider på et stoppested, eller live rejsebeskrivelser til en destination. Fordelen ved AR er, at omgivelserne opleves i real time og at der derfor ikke er forskelle mellem kort og omgivelser. Fx kan en gade tage sig meget forskelligt ud, alt efter årstiderne, hvis der er vejarbejde eller blot fordi det kan være svært at relatere et kort til virkeligheden, hvis man ikke er stedkendt. Denne problematik vil AR kunne afhjælpe. Finger zoom At relatere til et kort til virkeligheden kan være svært. Ved at benytte Google Street View i forbindelse med RP, vil man kunne skabe et billedbaseret scenarie af rejsen. Her vil brugeren ved hjælp af sine fingre kunne zoome igennem sin rute fra A til B. Sådan kan brugeren finde ud af, hvor man skal dreje, hvordan et hus eller et gadehjørne ser ud og orientere sig bedre i forhold til virkeligheden. Tips til indkøb og tilbud Når man rejser, er det tit kun startdestinationen og endedestinationen man kender. Men hvad med alle de gode tilbud, der er på vejen? Ved at koble RP sammen med tips til indkøb og tilbud, kan man koble erhvervslivet sammen med offentlige transportmidler. Brugeren vil få information, hvis der eksempelvis er et godt tilbud på relevante varer, eller måske opdage en spændende tøjbutik 50 meter nede ad gaden. Man kunne også forestille sig, at brugeren oprettede en særlig interesseprofil så denne kun får informationer om indkøbsmuligheder og tilbud, der er relevante. 12

13 Brugergenererede informationer om destinationer og steder Har du lagt mærke til street art en i tunellen ved Vesterport? Vidste du, at der engang boede en svensk kunstner i et glemt underjordisk lokale under Hovedbanegården? Og kender du historien om søerne og Københavns vandforsyning på Ole Rømers tid, dér hvor du stiger på 2A ved søpavillonen? Nej vel? Men det er der måske nogle andre, der ved. Hvis brugerne havde mulighed for at oprette informationer og historier om særlige steder på ruterne, ville turen måske blive lidt mindre kedelig. Busturen kunne blive til en fortælling om Københavns historie og S-toget kunne blive til et street art galleri. Stærkere relation til gå og cykelruter Mange brugere nævner i RP s brugerundersøgelse et ønske om bedre integration af cykel og gå-ruter. Som udgangspunkt er RP tiltænkt offentlige transportmidler og handler derfor ikke om gå eller cykelruter. Men hvis RP havde en veludført og brugbar gå/cykel funktion fx en bedret navigation vha. fotos af hjørnerne på ens rute, kunne man forestille sig, at mange ville foretrække RP fremfor andre services. På den måde ville flere blive mere opmærksomme på mulighederne for at benytte offentlig tranport. Også kombinationer af rejser, hvor en del af ruten tilbagelægges på cykel eller til fods og en del tilbagelægges med offentlig transport, er en mulighed, der i øjeblikket ikke findes på RP. Surp rejse me! om søndagen I øjeblikket er det gratis at benytte S-toget den første søndag i måneden og at tage en cykel gratis med. Det ses tydeligt på antallet af passagerer især med cykler når man rejser om søndagen. Forudsat at ordningen fortsætter, er der en mulighed for at gøre en rejse til en oplevelse, på en dag, hvor man har god tid og gerne vil opleve noget sammen med sin familie eller venner. I forbindelse med bevægelsen Situationist International, skabte Guy Debord, sidst i havltredserne, begrebet dérive - et andet ord for det franske flâneur (Debord 1981). En dérive er en særlig form for tilfældig vandring, der blev opfattet som en slags analyse af hverdagen. Den var baseret på tilfældige tilstande af strømninger i byen og indskydelser hos den vandrende; en måde at opleve verden på uden at være forudindtaget. Ved at genindføre begrebet dérive i RP i et mere moderne format, kunne man skabe en platform for overraskelsesrejser. En måde at bruge offentlig transport på, som en oplevelse i stedet for kun at være et spørgsmål om at komme fra A til B. Det kunne fx være i form at en rejse-generator, der giver brugeren en rejsebeskrivelse til en tilfældig destination, evt. med en rabat. Kombineret med informationer om særlige steder eller oplevelser på rejsen, ville brugeren få et helt andet indtryk af hvad en rejse med S-toget kan være. Informationerne brugeren får undervejs, kunne både være skabt af professionelle historiefortællere som forfattere og skuespillere eller oprettet af brugerne selv. 13

14 GPS Kort GPS funktionalitet er noget der efterspørges af mange brugere i RP s brugerundersøgelse. For en del mennesker er det et velkendt problem, at det kan være svært at vende kortet den rigtige vej og at orientere sig på en kortbaseret gengivelse af en rute. At integrere GPS funktionalitet er en enkel måde at komme problemet til livs på. Rigtig mange smartphones har allerede integreret GPS. Ved at kombinere et almindeligt kort med gps funktionalitet, bliver det muligt at gengive et kort, så det altid vender mod den valgte destination uafhængigt af, hvordan brugeren vender sin telefon. Rejsekammerat find din ven! Man kunne forestille sig, at en del mennesker sidder i et tog eller en bus, uden at vide, at en ven eller bekendt også sidder i det samme transportmiddel. Måske bor man i nærheden af hinanden og skal til den samme uddannelsesinstitution eller arbejdsplads og måske krydser ens veje hinanden i et af de store trafikknudepunkter som Nørreport eller Hovedbanegården. Ved at inkorporere en lokationstjeneste i RP, vil det være muligt at finde dem, man kender, som også er på farten. På den måde får brugerne mulighed for at mødes og bruge tiden til socialt samvær. Man kunne forestille sig en funktion, der giver besked, når en ven er indenfor en relevant radius, eller en check-in funktion, der giver mulighed for at tjekke ind i en bestemt bus eller et bestemt tog: Louise kører lige nu med 2A mod Kastrup, du kan møde hende hvis du stiger på bussen ved Forum kl. 15:23. Efter analyse af brugerundersøgelsen, brainstorming, sketching og konceptudviklingsfasen havde vi en generel diskussion om indholdet. Fx, fik vi mellem brainstorm fasen og sketching fasen foretaget en lille uformel rundspørge, der tydede på at en idé baseret på kort, hvor brugeren visuelt kunne navigere rundt i billeder af ruten, ikke umiddelbart gjorde navigationen mere forståelig og brugbar - som vi havde forestillet os. Denne valgte vi derfor fra. Overordnet valgte vi således at arbejde videre med følgend: 1. Live Kort med gps funktion 2. Fotos af gadehjørner i rejsebeskrivelsen 3. Nærmeste funktion med mulighed for at vælge rejse herfra 3.7 Mock-up Ved hjælp af et mock-up (bilag 2) af startskærmen til app en, undersøgte vi flow og funktionalitet i vores koncept og sammenholdt det med iphone app ens funktionalitet og fik et overblik over hvilke funktioner, der ville være fine at bevare, samt hvordan de nye funktioner skulle implementeres. I forlængelse af diskussionen om startskærmens organisering og funktionalitet, udarbejdede vi et skema over den samlede app ens indhold, som samtidig fungerede som skelet og udgangspunkt for den første wireframe prototype: 14

15 Introskærm(hjem) Livekort Nærmeste Billet Info Start rejse herfra Indtast rejse fra og til Favoritter (mulighed for at gemme under andet navn) Afgang/Ankomst Søg Live Kompas der vender kortet i forhold til virkeligheden Tidsberegning Afstandsmåling Kort Rejsebeskrivelse Viser nærmeste stoppesteds tavler i området Kan vise stoppestederne på et kort Kan vise afgangstider for stoppestederne Køb billet Oversigt over gyldige billetter Zone notifikation Viser trafikinfo relevant for valgte rejse (forsinkelser, aflyste afgange osv.) Rejsebeskrivelse: Street View stills Navigation til stoppestedet med - Viser X antal rejse senarier bus/tog/til fods - Mulighed for at gemme indtastede rejser - Købe billet til rejsen - Vælge rejsen og vise den i detaljer - Gå tilbage til Indtast rejsen skærm Skema over applikationens funktionalitet I vores koncept fokuserede vi især på, at gøre det let for brugeren at navigere på farten med et særligt fokus på navigation til og fra et offentligt transportmiddel. Konceptet tilbyder flere måder at navigere fra a til b på og søger dermed at samle nogle af de elementer, som allerede er tilgængeligt andre steder, såsom streetview og GPS. Eksempler på mock-up s Hensigten med vores ideer er også at gøre RP mere visuel og dermed bl.a. gøre det nemmere for brugeren at følge sin rejse, mens han/hun er på farten. Sammensætningen af en kontekstuel beskrivelse og en diagrammatisk fremstilling skal også forøge brugervenligheden, gøre RP mere attraktiv og øge tilgængeligheden. 15

16 3.8 Wireframes Til 1. brugerundersøgelse udviklede vi en serie wireframes i værktøjet Hot Gloo (bilag 3). Hot Gloo er en internet app udviklet til at designe online wireframes til interaktive prototyper, så man kan teste et brugerscenarie direkte med en bruger. Vores Wireframes tog udgangspunkt i den første mock-up af startsiden i smartphone app en og indeholdt det nye koncept til RP, baseret på de konceptuelle tilføjelser i app en. Grunden til at udvikle wireframes på dette tidspunkt i vores procesforløb var, at få vores ideer testet og valideret hos brugerne (se nedenstående afsnit). En anden god grund til at udvikle wireframes forholdsvist tidligt i processen er også, at de kan levere en fælles platform for kommunikation og forståelse internt i projektgruppen (Brown 2007). Udover brugertest, kan wireframes altså fungere som et effektivt redskab til formidling af ideer og resultater og give resten af projektgruppen et praj om, hvor vi befinder os i udviklingsprocessen. Wireframes kan have forskellig detaljegrad og udtryk afhængig af, hvad formålet med dem er (Brown 2007). Hovedformålet med vores wireframes var som sagt at teste vores foreløbige koncept med udgangspunkt i et specifikt brugsscenarie. Derfor valgte vi at udarbejde interaktive wireframes og samtidig medtage en vis grad af informations-layout bl.a. ved hjælp af billeder og ikoner. Vi ønskede at give brugeren et indblik i, hvad vores koncept indeholdte og hvordan det fungerede, men uden at bruge for lang tid på at gå i detaljer med typografi og farver. Vi har med andre ord søgt at udarbejde et sæt passende wireframes til formålet 16

17 Eksempler på wireframes 17

18 3.9 Html som prototype for en applikation At bruge html og CSS som basis for en prototype til en app har nogle andre konsekvenser end at lave en prototype i et programmeringssprog som Java. I princippet er der ikke meget, der adskiller en statisk hjemmeside fra en applikationsprototype. Teknisk set opbygges de to typer ens. Forskellen ligger primært i overvejelser, der vedrører skærmdimensioner og opløsning, da der her er en forskel på at opleve et html dokument i et browservindue og på en skærmstørrelse svarende til en Smartphones. Protypen blev derfor udviklet til et IPhone format på 640x960 pixels og/eller HTC Legend på 320x480 pixels. Vores brugerundersøgelse afslørede, at en applikationsprototype opleves anderledes, når den vises i en browser end på en smartphone. Derfor har vi visualiseret oplevelsen af at bruge en smartphone, ved at afmaske et område i borwservinduet på 320x480 pixels. Yderligere har vi valgt at indsætte en foto-mock-up af en Smartphone, så oplevelsen af at bruge telefonen i endnu højere grad forstærkes. Da det er muligt at åbne et html/css dokument via browseren i en Smartphone, valgte vi at udføre anden brugertest på en Smartphone. Det er vores indtryk html/css er en hurtig og let tilgængelig måde at opbygge en working prototype til en app. Ved hjælp af CSS er der mange muligheder for at bearbejde og tilpasse individuelle funktioner i brugerfladen løbende og i relation til brugernes tilkendegivelser under brugertests. I forhold til at arbejde cross-platform, er der også en fordel i prototype fasen i og med, at den samme prototype kan testes på alle Smartphones, der har adgang til internettet. I forhold til fx Photoshop baserede prototyper, er der en interaktiv fordel ved at bruge html/css, idet brugerne direkte kan interagere med knapfunktioner og indtastningsfelter, hvorfor de får en bedre oplevelse af app en i funktion. Vi forestiller os derfor, at html/css kan være et godt udgangspunkt for en første working prototype, som kan danne udgangspunkt for fx en Java-baseret prototype. 18

19 4. Første brugerundersøgelse Fordelen ved at inddrage brugere i sin designproces er, at det giver mulighed for vigtige løbende evalueringer, ændringer og raffineringer i forhold til det endelige produkt (Sharp et al. 2007:236). Som designere og programmører anskuer vi ikke nødvendigvis tingene fra samme vinkel som den gængse bruger, og derfor er brugerinddragelse en uundværlig del af en vellykket produktudvikling, hvad enten produktet er en hjemmeside, en app eller noget helt tredje: If you want a great site, you ve got to test (...) After you ve worked on a site for even a few weeks, you can t see it freshly anymore. You know too much. The only way to find out if it really works is to test it (Krug, 2006, s. 141). I følgende afsnit gennemgår vi vores første brugerundersøgelse, hvordan vi gennemførte den samt, hvilke resultater den kastede af sig. 4.1 Beskrivelse af 1. brugsscenarie Overordnet var vores formål med brugerundersøgelsen at få kommunikeret og afprøvet vores produkts funktion, form og indhold, dvs. grundlæggende at få testet og evalueret vores arbejde. Vi inviterede to brugere til en brugertest. Vi valgte at rekruttere en bruger, som havde erfaring med brug af smartphones og app er og en som ikke havde. Det gjorde vi for at undersøge brugernes forståelse for vores ide på baggrund af deres erfaringer. Vi vurderede, at begge perspektiver ville være interessante for vores videre udvikling af app en, da de to brugere kunne bidrage med forskellige input. Vores app skulle også gerne kunne anvendes af ikke-brugere, som også må anses for potentielle brugere. Man kan argumentere for, at et ideelt design bør kunne aflæses intuitivt og umiddelbart uden forhåndskendskab. På den anden side kan trial and error 2 aspektet også siges at være en essentiel del af det at anvende en smartphone, dvs. at brugeren ved at prøve sig frem, hurtigt lærer, hvordan elementerne fungerer. Det eneste kriterium vi derudover havde, var at brugerne skulle have kendskab til RP og have benyttet enten websiden eller app en flere gange. Vi rekrutterede to brugere: Stefan: 28 år smartphone-bruger studerende på ITU benytter RP et par gange om måneden på sin iphone. Sofie: 23 år ikke-bruger studerende på ITU benytter RP webside nogle gange om måneden. Vores 1. brugerundersøgelse var som sagt en undersøgelse af vores tidlige wireframes. I undersøgelsen havde vi også 2 I feltet inden for computer videnskab kaldes denne tilgang også for Generate and Test (web ref. 7). 19

20 besluttet os for at eksperimentere med forskellige ikoner for at undersøge, hvordan brugerne opfattede og reagerede på disse ikoner. Vi benyttede følgende ikoner: Hjerte: På startsiden havde vi valgt et simpelt ufarvet hjerte som ikon for knappen til favoritter.. Stjerne: Stjernen skulle gøre det muligt for brugeren at gemme de indtastede adresser i favoritter. Transportsymboler: Disse ikoner skulle understøtte rejsebeskrivelsen, som blev fremvist skriftligt. 4.2 Udførsel af 1. brugerscenarie Kort intro til vores produkt og beskrivelse af formålet med sessionen I introduktionen forklarede vi vores interesse for deltagernes erfaringer med RP, samt gav en præsentation af de digitale wireframes. Vi pointerede, at disse blot var en tidlig digital prototype og kritik var mere end velkommen. Indledende interview Interviewet omhandlende persondata samt deltagernes erfaringer, meninger samt forbedringsforslag til RP. Test af Wireframes Selve brugertesten var konstrueret omkring Think Aloud (TA) metoden - en klassisk HCI metode med rødder i den kognitive psykologi (Molich 2000). Formålet med metoden var, at anspore brugerne til at sætte ord på deres oplevelser og tanker med og omkring de viste wireframes, mens de gennemførte testen. En fordel ved TA er netop, at vi ser, hvad brugerne gør, og hvorfor de gør det, mens det gør det. En pointe Jakob Nielsen også fremhæver: The strength of the thinking-aloud method is to show what the users are doing and why they are doing it while they are doing it in order to avoid later rationalizations (Nielsen 1993). Andre metoder, som fx interviews, vil kun vise, hvad brugerne siger de gør, hvilket ikke altid er det samme, som de i virkeligheden gør. Men der er også ulemper ved metoden. Fx siger det ikke noget at måle ydeevnen, dvs. hvor hurtigt det tager for testdeltagerne at løse opgaven, da det sænker hastigheden at skulle sætte ord på sine tanker. Desuden kan testdeltageren få en følelse af at være til eksamen, og dermed løse opgaverne på en anden måde end han/hun ellers ville. For mange vil det også føles unaturligt og forstyrrende at skulle sætte ord på sine tanker, da det sjældent noget man gør (Nielsen 1993). Netop derfor har vi været meget opmærksomme på den setting vi præsenterer for vores testdeltagere. 20

21 Screendump af Camtasia optagelser 21

22 Vi valgte at benytte os af den klassiske udgave af TA med én bruger ad gangen og en serie af opgaver. Opgaven opbyggede vi omkring et fiktivt brugsscenarie (bilag 4), hvor deltagerne blev bedt om at finde en forudbestemt rejse og herigennem benytte sig af og opleve vores konceptuelle features. Derudover havde vi på forhånd defineret, hvilke roller vi havde under testforløbet hvem der var moderator, hvem der var observatører og hvem der tog noter. Vi benyttede Morae software for at optage brugernes navigation igennem de udvalgte wireframes, såvel om deres kommentarer og gestikuleren. Vi anvendte Camtasia (web ref. 8) som testsoftware i samspil med printede udgaver af vores wireframes til brug for kommentarer og sketcher. Afsluttende interview Efter testen blev brugeren stillet nogle få spørgsmål angående deres generelle oplevelse af vores koncept, forslag til forbedringer og om konceptet ville give dem værdi på deres fremtidige rejser. Hvad viste brugerundersøgelsen? I de følgende afsnit gennemgås de erfaringer, vores testpersoner gjorde sig i løbet af de to tests. Resultaterne bliver gennemgået i forhold til tre punkter; navigationen, forståelse for indholdet samt forslag til forbedringer. Afslutningsvis uddyber vi, hvad undersøgelsen medførte i forhold til den videre udvikling af app en. Navigation Hverken Sofie eller Stefan udviste besvær ved at navigere rundt i app en. De opfangede hurtigt, hvad der skulle trykkes på, og navigerede forholdsvis problemfrit fra start til slut. Til tider viste Platformen sig at være en barriere, da en skærm ikke indeholder touchfunktion, som en smartphone gør. Derfor gik begge i stå flere steder. Forståelse af indhold Stefan, den erfarene smartphone bruger, opfattede overraskende hurtigt, hvad de forskellige knapper og symboler betød: Har I lavet favoritter? Det er der da ikke på den rigtige Rejseplan Det er smart! Stjernen på Rejse Oversigten, oplevede han som anonym, hvilket tyder på at design, farver og en evt. tilføjelse af noget hjælpende tekst kunne være nødvendigt, for at opnå den forventede effekt. Sofie, den uerfarne smartphone bruger, udviste større problemer i forhold til forståelsen af indholdet. Hun forstod ikke symbolikken i hjertet og stjernen: De der hjerter ser da ret hyggelige ud. Jeg forestiller mig, de er sådan lidt fluebens agtige, at når man har udfyldt feltet, så kommer der et flueben i hjertet. 22

23 Generalt foretrak Sofie stjernen som ikon for gem og oplevede ikke stjernens udformning som en knap. Jeg synes den virker sådan.. anonym. Så hvis der blev gjort mere opmærksom på den, så tror jeg også, at jeg ville tænke over, at det var noget jeg kunne trykke på. Bundmenuen voldte også problemer hvilket tyder på at en form for ikon er nødvendig for at understøtte teksten. Dog skal det nævnes, at en stor del af det intuitive ved smartphone app s er den førnævnte trial and error tilgang, der anvendes i størstedelen af tilfældene, når folk benytter deres smartphones. Forslag til ændringer Den generelle feedback på app en var positiv, og begge testpersoner udviste stor interesse og tilfredshed ved vores fremstillede wireframe scenarie. De var begge entusiastiske omkring de fremstillede ideer, der i særdeleshed omhandlede streetview billeder af gå ruter, samt et live kort, der var kompas afhængigt og altid viste, hvor man var i forhold til den virkelige verden. Sofie fortæller: For sådan en kortspasser som mig, er det der jo bare guld værd.. Stefan er enig og uddyber: Jeg synes, det er smart, og jeg synes også det er sådan.. intuitivt. Det giver mening ift. den rejse, man skal ud på. Det er jo alle de ting, som man lig som selv tænker.. det burde der jo være. Sofie og Stefan kunne sagtens forestille sig en brugssituation, hvor de ville benytte app en. Stefan siger: ( ) der er nogle funktioner ift. den jeg i forvejen bruger, som I har, som den mangler, som jeg synes, at helt sikkert ville kunne gøre, at jeg ville gå over til jeres 4.3 Reflektioner og videreudvilking af app en Brugerundersøgelsen viste af brugerne savnede en automatisk herfra funktion. Stefan forklarer: Ja altså, jeg synes, det er smart, det der jeg har på min smartphone. Det der med at jeg trykker på fra og så går den ind via GPS og finder hvor jeg er henne. Endvidere viste vores undersøgelse, at søg knappen på forsiden burde have et andet navn, fx Find rejse for at klargøre funktionaliteten. Afgang nu tjek-boksen var heller ikke synlig nok. Derfor skal det overvejes, om denne skal have en anden udformning og placering. Udover rettelserne i Find rejse og Afgang nu, fjernede vi muligheden for at vælge årstal under søgningen. På den nuværende RP kan man ikke gå meget længere end tre måneder frem i tiden, hvilket både Stefan og Sofie heldigvis gjorde os opmærksomme på. Endeligt valgte vi at erstatte de små billeder på gå-rute-beskrivelsen med ikoner grundet billedernes ringe størrelse. Fordi vores valg af ikoner var misvisende besluttede vi at foretage yderligere research vedrørende ikoner i digital navigation. 23

24 5. Spørgeskemaundersøgelse Efter at have foretaget 1. brugerundersøgelse kunne vi konkludere følgende: 1) Ikke begge brugere så en sammenhæng mellem hjerte ikonet og den funktion det skulle repræsentere; favoritter. 2) Det var forvirrende at have forskellige ikoner på forskellige sider til at repræsentere funktioner relateret til favoritter. 3) På trods af sympati for hjertet som ikon for favoritter, var stjernen mere intuitiv og korrekt i brugernes øjne. 4) Trafik ikonerne gav god mening og tjente vores hensigt; at understøtte den skriftlige information. 5) Menuen i bunden skal understøttes af ikoner I forlængelse af vores erfaringer valgte vi at udarbejde et spørgeskema omhandlende ikoners betydning - for at sikre kongruens mellem de valgte ikoner, og hvad der ville give mening for brugerne. Vi oprettede vores spørgeskema i TricTrac (web ref. 9). Vi indledte spørgeskemaet med en kort introduktion; at undersøge ikoners betydning og funktion i online digital navigation. Vi fremsatte et eksempel på et ikon og dets mulige betydning. I spørgeskemaundersøgelsen har vi været opmærksomme på aldersspredning såvel som ejerskab af smartphone. Spørgsmål var alle formuleret på følgende måde: Hvilken funktion og betydning tillægger du nedenstående ikon? - efterfulgt af et billede af et ikon (se nedenfor). 24

25 Ikoner var udvalgt på baggrund af mulig relevans for vores app, samt et par tilfældige ikoner, da vi håbede på, ikke kun at få bekræftet, hvad vi allerede forventede, men også at blive inspireret og få nye input. For at få skemaet besvaret af så mange som mulig, så hurtigt som muligt, benyttede vi alle Facebook til at udsende spørgeskemaet med. Vi erkender, at dette skaber en form for bias, da folk hermed skal være brugere af Facebook. Men da Facebook er en digital platform og vores undersøgelse omhandler ikoner i digital navigation, anså vi ikke denne bias for at være problematisk for vores resultater. Diagram over spørgeskemaundersøgelsens resultater 45 besvarelser i alt BETYDNING FAVORIT KÆRLIGHED 2 GEM 38 HJEM 28 FAVORIT 39 INFORMATION 33 BILLETTER 23 TRANSPORT REJSETIDER 7 SYMBOL 25

26 5.1 Konklusion og redesign af applikation Overordnet var vi tilfredse med resultaterne fra vores undersøgelse, set i lyset af den tid, der var til rådighed. Som nævnt burde vi dog have lagt mere vægt på undersøgelsens fokus ved hvert spørgsmål for at bevare respondentens fokus. Vi fik dog bekræftet en fælles mening bag de forskellige ikoner og implementerede dem efterfølgende i vores html app. Disse ikoner var: Stjerne à Favoritter Diskette à Gem til favoritter Hjem à Home Globus og kompas (blev til kort og kompas) à Live kort Et tog (blev til en bus) à Nærmeste steder at fange en bus/tog og afgangstidspunker Billetter à Køb billetter til din rejse I (i en cirkel) à Information om evt. forsinkelser på din valgte rejse. Inden 2. brugerundersøgelse havde vi desuden implementeret noget grafisk finish på vores bundmenu, således at ikonerne nu lignede knapper, der kunne trykkes på. Indsæt billede af app en Vi genoptog desuden overvejelserne vedrørende vores første idé om en Augmented Reality (se afsnit xxx) funktion på baggrund af en diskussion i gruppen vedrørende app ens styrker og svagheder. Vi overvejede anvendeligheden af vores statiske billeder i forhold til et live billede. Et statisk billede af en vej eller et gadehjørne giver umiddelbart ikke så meget i en brugssituation - sammenlignet med et live billede. Et live billede understøtter brugerens behov for at kunne orientere sig visuelt. Her bliver den tætte relation mellem information og virkelighed videreformidlet, hvorimod et statisk billede giver risiko for bias ift. årstider, vejarbejde etc. Vi var dog i tvivl om, hvorvidt vi skulle implementere et augmented reality kort i stedet for statiske billeder, eller om det skulle være en ny funktion. Og hvor skulle adgangen til funktionen ligge? Vi besluttede at teste dette i 2. brugerundersøgelse og bibeholdte derfor begge funktioner. Foreløbigt kaldte vi funktionen for Live Camera og placerede den i en menu i toppen af Live kortet : For en grundigere gennemgang af undersøgelsen, se bilag 5. 26

27 6. Anden brugerundersøgelse Til vores 2. brugerinddragelse gjorde vi os en række overvejelser, hvorvidt vi skulle inddrage brugere af smartphones såvel som ikke-brugere. Der var fordele og ulemper ved begge scenarier. Valgte vi udelukkende at teste på brugere, risikerede vi at ende op med tre enslydende tests, som blot validerede vores koncept. Resultaterne fra 1. brugertest viste os allerede, at smartphone-brugeren vurderede meget på vores koncept samt hvilke værdier det ville give ham, hvorimod ikke-brugeren havde langt mere fokus på navigationen og de intuitive elementer i vores koncept og manglen på samme. Begge brugere bidrog således med forskellige vigtige aspekter ved vores koncept. Ved at teste ikke-brugere, ville chancen dog være større for at få aha oplevelser, og derfor valgte vi at teste vores koncept på to ikke-brugere samt én bruger. 6.1 Hovedpointer fra brugerundersøgelsen 3 2. brugertest var konstrueret i samme stil som 1. brugertest. Testen indledtes med at et par spørgsmål, guidede deltagerne igennem et brugsscenarie og afsluttede med nogle opfølgende spørgsmål. Undersøgelsen havde til formål at give feedback på navigationen i app en, der denne gang blev testet på en smartphone, for at opnå en mere reel oplevelse. Endvidere ønskede vi feedback på vores valg af ikoner og vores koncept ideer som Live Camera, Live Kort og implementeringen af Google Street View. Ved at udføre undersøgelsen på den korrekte platform og samtidig bevare RP s genkendelige og simple navigation, viste testen ingen problemer med navigationen, til trods for at to af testpersonerne ikke var daglige smartphone brugere. Deltagerne savnede løbende forslag til gadenavne imens de tastede, hvilket er en funktion, der afgjort bør være i et endeligt design. Funktionen har dog ikke været mulig at implementerer. Noget af den feedback vi fik, handlede om, at deltagerne ikke forstod funktionen af info knappen. Endvidere var der blandede meninger om de konceptideer vi ønskede feedback på. Den erfarne smartphone bruger var begejstret for de mange muligheder og var glad for, at man kunne vælge den løsning, der passede én bedst. De uerfarne smartphone brugere, som mente de havde en god stedsans, fandt Street View funktionen unødvendig. De var dog begejstret for Live Kortet. Én af testpersonerne mente desuden, at Live Camera funktionen var uinteressant med mindre det kunne pege ham i retning af andre relevante muligheder fx restauranter, butikker osv. 3 Kun hovedpointer er medtaget her, for grundigere gennemgang se bilag 6. 27

28 28 2. brugerundersøgelse med smartphone

29 6.2 Forslag til ændringer Overordnet var de tre testpersoner positive overfor vores koncept. Alle fandt vores koncept og stil enkel, simpel og ligetil. De fandt mange af de samme gode kvaliteter som på websiden men meget mere simpel. Alle tre opfattede det nuværende oversigtskort på websiden utilstrækkelig og ikke særlig læsevenligt og var derfor meget positive overfor vores live kort, som er mere interaktivt. Generelt syntes de tre testpersoner, at det var et relevant koncept, vi arbejdede på især Martin, som decideret efterlyste en app til RP. Vi hæfter os ved, at både navigationen og den grundlæggende forståelse for indholdet i app en fungerede langt bedre i denne test. Nogle af de samme forslag til ændringer går endvidere igen fra 1. brugertest såsom muligheden for at skræddersy sin rejse med et par enkelte klik samt GPS tracking, der angiver ens nuværende adresse. 6.3 Refleksioner og videreudvikling af app en Først og fremmest har det været interessant at opleve, hvor stor forskel der har været på at teste brugere vs. ikke-brugere. Fokus blev automatisk flyttet fra koncept ideer og selve brugskonteksten til funktionalitet og brugervenlighed, når vi testede ikke-brugere. Det havde selvfølgelig den effekt, at vi fik et mere rigt datamateriale at forholde os til nogle gode perspektiver på en fremtidig app og nogle konkrete forslag, som vi har besluttet os at arbejde videre med i dette projekt. Info knappen ændrer vi til Trafik info et navn som mere præcist indikerer, at her kan du få oplysninger om sporændringer, afgangstider etc. Derudover ændrer vi Hjem knappen til Rejse igen for at gøre betydningen mere præcis og drejede samtidig ikonet 90 grader i urets retning, så det blev en pil pegende mod højre. Camera View ændrede vi til Live View, baseret på en masse gode forslag fra vores tre testpersoner. Derudover har vi valgt at implementere en Herfra funktion på forsiden. Herfra funktionen er baseret på GPS tracking, og vælger den adresse, som vedkommende befinder sig på i det øjeblik, funktionen aktiveres. Ønsket om en Herfra funktion er gået igen under 1. og 2. brugertest, hvilket fik os til at tage det op. Først overvejede vi, om funktionen bare skulle være automatisk, hver gang RP blev aktiveret på mobilen. Designmæssigt ville det være en fordel, da vi i forvejen ikke havde meget plads at gøre godt med og ikke ønskede at proppe app en med alt for meget. Vi blev dog enige om, at der var for stor en risiko for, at brugerne ville finde det irriterende og valgte derfor at implementere funktionen lige over Fra søgefeltet. Vi beholder alle navigationsmuligheder. Som app en ser ud nu, har brugeren mulighed for at vælge mellem flere forskellige navigationsmuligheder afhængig af temperament og behov, hvilket vi anser som en styrke. App en skal være enkel at benytte og det skal være let at komme fra a til b både for brugere med god og dårlig stedsans. 29

30 7. Fremtidens Rejseplan 7.1 Design Grundlæggende har vi designmæssigt valg at lægge os op af RP eksisterende identitet, for at bevare den i forhold til afsender understøttende funktion (Thorlacius, 2007). Som beskrevet i afsnittet om Rejseplanens konkurrence, har vi valgt primært at fokusere på punktet udbredelse, som handler om at gøre Rejseplanen endnu mere tilgængelig på nye måder og/eller steder (web ref. 10). De konceptuelle løsninger vi har valgt, handler om brugerfokuserede forbedringer og tilføjelser med udgangspunkt i RP s og egne brugerundersøgelser. Vores forslag føjer sig til den eksisterende brugergrænseflade samtidig med, at genkendeligheden bevares, da det ikke er vores formål at lave et re-design af RP. Det sagt, er det også vores formål, med mindre ændringer, at styrke den visuelle identitet af RP i app en. Genkendelighed RP er efter eget udsagn kendt af 84% af den danske befolkning (web ref. 11) og ni ud af ti har prøvet RP. Med et så udbredt kendskab har vi vurderet at det var vigtigt at bibeholde RP s grundlæggende identitet, så genkendeligheden bevares. 7.2 Farvevalg og visuel identitet RP s farveskema består på nuværende tidspunkt af en hvid basisfarve gradueret i en gråtone nedefter og de tre primærfarver rød, gul og blå. Farverne rød, gul og blå er gennemgående farver, der stammer fra logoet. Logoets udformning tager udgangspunkt i en historie om at rejse fra A til B, med en destination som mål. Typografisk fremstår navnet i en sans serif type, hvor bogstavet J har karakter af en minuskel i en lidt større punkstørrelse. Dette er sandsynligvis for at skabe karakter af et navnetræk, fremfor blot at være en font. Den røde farve bruges gennemgående kun i logoet eller i ikoner, der refererer til logoet. Den blå farve bruges hovedsagligt som fremhævningsfarve til fonte og den gule farve markerer borders for det valgte menupunkt, mens resten remstår i en mere afdæmpet gråtone. Det er vores formål at styrke den visuelle identitet ved at skabe en bedre balance mellem logo og overordnet farveskema, herunder dominerende farve, fremhævningsfarve og basisfarve. Den hvide baggrund i den eksisterende RP opleves meget neutral, måske endda lidt fad og fordi procentdelen af de tre 30

31 logofarver er vægtet omtrent lige højt, kommer logofarverne til at fremstå indbyrdes ligeværdige og derfor med manglende dynamik. Indtastnings og informationsfelterne adskiller sig heller ikke markant fra basisfarven og da disse felter er en kernefunktion, er det vigtigt at de fremstår som en central og tydelig del af designet. Derfor vil vi gerne skabe et mere konsistent visuelt hierarki, der samtidig markerer RP s visuelle identitet (Lynch et al. 2009). Ved at udskille den gule farve og lade den blive basisfarve, opnås i stedet et kontrastforhold der styrker den visuelle identitet ved at bibeholde farveskemaet, samtidig med at logoet i højere grad fremhæves. Cirklerne i logoet forstørres markant og i placeringen af cirklerne benyttes grebet kontinuitet, til at skabe en spænding ved at kappe en del af cirkelslaget af. Også her siger gestaltloven at mennesker opfatter en hel form, selvom konturerne af den er ødelagt eller kan opfattes tvetydigt. RP s identitet, der knytter sig til selve logoet, bliver nu en helt central del selve brugerfladen. Da en app arbejder indenfor en meget begrænset fysisk størrelse, har det også være målet at gøre afsender tydeligere. Ved at forstørre logoelementerne på en baggrund af den gule basisfarve, skabes en supergrafik der også er let genkendelig på afstand, modsat RP s nuværende meget lille logo. Med det afdæmpede vandmærke i den kraftige gule basisfarve, styrkes den overordnede sammenhængskraft ved hjælp af en gentagelse af RP s identitet. Indtastnings og informationsfelterne lægger sig, med en ganske svag transparent, hen over baggrunden og gør det let for brugeren at orientere sig efter de vigtige informationer. Samtidig har de en grafisk ensartethed, der ifølge gestaltlovene hjælper brugeren til at relatere sammenhængende indhold til hinanden. 31

32 32 Rejseplanens farvecirkler før og nu

33 7.3 Ikoner, symbolik og grafik i en applikation Vigtigheden af at arbejde med knapper og symbolik, blev tydeliggjort igennem vores brugerundersøgelser. Brugerundersøgelsen antydede som tidligere nævnt, at det er vigtigt at forholde sig til eventelle konventioner vedrørende symbolik og fortolkningen af denne, jf Jacob Nielsens mentale modeller(web ref. 12). Med udgangspunkt i resultaterne i undersøgelsen har vi designet en tre knapper med tilhørende ikoner, der bygger på velkendte og simple symboler, for at gøre app ens brugerflade let tilgængelig og umiddelbart forståelig. Det drejer sig om et favoritknap baseret på en stjerne, en gemknap baseret på en floppy disk og en StreetViewknap baseret på Googles lille gule mand, der symboliserer at StreetView er tilgængelig. Symboler er brugt hvor der ikke var tvivl om fortolkningen. Menuen er en kombination af symboler og tekst for at understøtte nye ikontyper som Live Kort og resten af knapperne er tekstbaserede, da vi ikke kan identificere særlige grafiske konventioner eller fortolkningsmønstre vedrørende funktionsknapper som OK find rejse, annuller og afgang nu. At arbejde med HVGA skærmstandard, med en størrelse på 320x430 pixels stiller også nogle krav til enkelheden. At bruge for mange grafiske elementer på en side, skaber uoverskuelighed og gør det svært at navigere på en touchscreen og detaljerede symboler er svære at aflæse. Derfor har vi tilstræbt en generel enkelhed og ensartethed i farveholdning, symboler, hvor symboler har en ensartet farvemætning på en let gradueret grå bagrund. Ikonknapper og tekstknapper 33

34 3. Startskærm 3. Rejseforslag 3. Live Kort Endelige visualisering af Rejseplanens nye applikation 34

35 8. HTML/CSS Det følgende afsnit vil se nærmere på den overordnede tekniske udførelse af app en, som vi udviklede i HTML samt CSS. Dernæst vil der blive kigget nærmere på nogle eksempler, der beskriver nogle konkrete løsninger vi kom frem til, i vores bestræbelser på at løse det tekniske i vores design. 8.1 Applikationen - generelt App en blev udviklet ud fra de formelle krav om, at der skulle benyttes XHTML Strict 1.0 (Robbins 2007) og stylesheets i udførelsen. Initierende undersøgelse af den igangværende prototype viste sig dog at volde problemer, når den blev vist på en smartphone med en begrænset opløsning og særlige måde at afvikle html sider på. En løsning på problemet bliver beskrevet senere. App en er en index fil med 15 undersider. Den er primært struktureret i <div>-elementer, dog med undtagelser, hvor <span> har været brugt i stedet. På CSS siden blev alt formateringen foretaget. Ingen formatering blev brugt i selve HTML dokumenterne. I stylesheetet blev sidens formelle størrelse også defineret. Da siden i sidste ende skulle fungere som en app til en smartphone, og derved også fremvises på en smartphone, blev opløsningen af siden sat til 320x480, da dette var opløsningen af den smartphone vi havde til rådighed til alle vores undersøgelser. Større og nyere smartphones har langt højere opløsninger, men af frygt for dårlig skalering afhængig af, hvilken smartphone der blev anvendt, valgte vi at holde fast på den lavere opløsning og lade alle undersøgelser blive fortaget på denne. App en er grundlæggende defineret som én stor <div> kaldet screen. Dette er gjort for at kunne kontrollere placeringen af alle ovenpå liggende elementer. Inden i screen er området delt op i to nye <div> er. Én kaldet content, der styrer bundmenuen, og én kaldet bmenu, der kontrollerer alt indhold over bundmenuen på app en. Det var nødvendigt for at fastholde menuen det samme sted hele tiden og have en ensartet struktur at arbejde ud fra, da alle undersiderne skulle have et sammenhængende identisk udseende. Som reglerne foreskriver, har <div>-tagget været brugt til unikke elementer. Hvor der har været en gevinst at hente i forhold til genbrug af tags, har <span> været brugt (Robbins 2007). Det viser sig især, når flere tekst- eller grafik elementer har været placeret på samme linje, eller en ensartet venstremargen skulle opnås på flere kolonner. 8.2 XHTML Mobile 1.0 vs. XHTML Strict 1.0 Som nævnt stødte vi tidligt ind i problemer relaterede til platformen, hvorpå app en skulle testes. Da det var en app, vi i teorien var ved at udvikle, var det mest oplagt, at den endelige test blev foretaget i den rette kontekst. Det viste sig ikke at være så ligetil, som forventet. De første tests viste at smartphonen ikke forstod at zoome app en til en korrekt størrelse. Derimod viste den app en i en miniudgave med en masse omkringliggende plads. Da man ikke kunne indstille 35

36 smartphonen til at fokusere på det eneste element, den kunne finde på den loadede side, måtte vi gå i tænkeboks. Nu var dokument typen XHTML Strict 1.0, men for at få smartphonen til at loade siden i korrekt format, skulle dokument typen deklareres til XHTML Mobile 1.0 (web ref. 13). <!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN TR/xhtml1/DTD/xhtml1-strict.dtd > <!DOCTYPE html PUBLIC -//WAPFORUM//DTD XHTML Mobile 1.0//EN wapforum.org/dtd/xhtml-mobile10.dtd > I den endelige udgave af app en, der vil blive afleveret til eksamens bedømmelse, vil siden dog blive valideret med XHTML Strict 1.0, for at opfylde kursets krav til den udviklede side. 8.3 Bundmenuen - <div id= bmenu > Bundmenuen, som nævnt ovenfor, var et gennemgående element i hele app en. Den skulle være til stede på alle sider og være det navigations element, der skulle samle app en og gøre det muligt at navigere frem og tilbage. Grafisk set blev bundmenuen designet som ét billede element. Det gav nogle udfordringer, da bundmenuens enkelte knapper skulle gøres aktive som unikke, enkeltstående links til de andre undersider. Hele billede elementet kunne derfor ikke placeres inde i en <a href= ></a>, da dette ville gøre bundmenuen til det aktivt link. Image maps blev derfor taget i brug, da det gav os muligheden for at definere et område på et grafisk element som et link. Inde i <img>-tagget, der hentede bundmenuen ind, blev et usemap= #bmenu defineret. Dette skulle gøre det efterfølgende image map tag opmærksom på, at det var inde i dette element, at de forskellige links skulle placeres. Den følgende kode beskriver, hvordan image mappet blev defineret. Opbygning af <div/> <map name= bmenu > <area shape= rect coords= 1,1,60,56 href= index.html /> <area shape= rect coords= 63,1,128,56 href= livekort.html /> </map> Et image map kaldet bmenu blev defineret. Det var vigtigt, at mappet hed bmenu ligesom det usemap, der var defineret i <img>-tagget - ellers ville image mappet ikke forstå, hvor det skulle indsætte de definerede links. Inde i tagget bliver to rektangulære områder defineret med de ovenstående koordinater. Koordinaterne skal ses som par: (1,1) og (60,56) for det første link, der henviser til forsiden index.html, og derefter (63,1) og (128,56) for det andet link (Robbins 2007), der henviser til live kortet. 36

37 8.4 Lag på lag En funktion i app en var muligheden for at gemme sine indtastede adresser som favoritter og senere hente dem frem igen. Da funktionen var designet til at skulle fungere som en pop-up, der gjorde alt andet end pop-up vinduet inaktivt, måtte vi finde en måde at simulere et pop-up vindue på. Vi kunne ikke åbne linket i et nyt browser vindue, som en standard pop-up ville have gjort, da hele interaktionen skulle foregå i samme browservindue. Da det var ude af vores fokus at lave det i Flash, hvilket formentligt kunne have løst det på den pæneste måde, begyndte vi at undersøge, hvordan vi kunne placere elementer oven på andre elementer. Når man arbejder med billeder, har men inden for XHTML/CSS muligheden for at placere billeder oven på andre billeder ved at anvende et såkaldt z-index. Denne måde angiver en stack order for, hvilken rækkefølge billederne skal placeres i ovenpå hinanden. Det viste sig hurtigt at være en besværlig løsning, og i stedet for at arbejde med z-index og have flere aktive elementer liggende oven på hinanden, gik vi en helt anden vej. Ved at simulere en funktionel applikation, tog vi et screenshot af, hvordan app en så ud ved normal brug. Billedet blev tilføjet et mørkt, transparent overlay og defineret som baggrund i css en på en tom applikationsside med samme standard mål som resten af app en. Dernæst blev et table indsat (Robbins 2007), der indeholdte lidt information om, hvad man kunne, checkboxe til at markere hvilke adresser man gerne ville gemme, og dernæst to billeder der skulle agere en gem og en annuller knap. <table border= 3 cellspacing= 0 cellpadding= 0 > <tr> <th colspan= 2 >Vælg adresse(r) som skal tilføjes til favoritter</th> </tr> <tr> <td colspan= 2 > <label><input type= checkbox name= adresse1 value= adresse1 />Finlandsgade 34, 2300, Kbh S</label></td> </tr> <tr> <td colspan= 2 ><label><input type= checkbox name= adresse1 value= adresse1 />Tagensvej 118, 2200, Kbh N</label></td> </tr> 37

38 <tr> <td><div id= menuknap1 ><a href= oversigtconfirm.html ><img src= images/ gem.png alt= width= 155 height= 40 /></a></div></td> <td><div id= menuknap2 ><a href= oversigt.html ><img src= images/annuller. png alt= width= 155 height= 40 /></a></div></td> </tr> </table> 8.5 Street View På oversigtssiden over gå ruter var den oprindelige ide, at man skulle kunne se et Google Street View (web ref. 14) billede af det eksakte sted, man skulle dreje. I den første brugerundersøgelse var denne funktion udskiftet med still billeder for at simulere funktionen. Da dette midlertidigt ville være en kedelig løsning i den endelige prototype, fandt vi ud af, at koden til funktionen kunne findes hos Google, da en autogenereret streng, som henviste til den præcise adresse, skulle bruges. En <iframe>, som er en integreret frame på en side, blev defineret af Google med nogle parametre til at styre størrelse, border størrelse, placering og hvorvidt framen kunne scrolle eller ej. <iframe> en blev sat inde i en div for at styre dens placering i app en. Selvom det hele virkede til at fungere, skabte det store problemer, da siden skulle valideres. Parametrene blev fjernet og lagt i stylesheetet og <iframe> en fik et id, der henviste til et element i css en, hvor parametrene blev lagt. Det viste sig, at den omkringliggende <div>, der omkransede <iframe> en var ligegyldig, da disse formateringer kunne ligges i samme element som <iframe> ens. Valideringen viste yderligere, at <iframe> elementet ikke fungerede med XHTML Strict 1.0, og derfor blev en løsning fundet. Ved at definere <iframe> en som et <object> i stedet og angive linket til Google Maps som værende <object> ets data, var vi i stand til at få valideringen til at acceptere de indlejrede Street View elementer. <iframe width= 318 height= 422 frameborder= 0 scrolling= no marginheight= 0 marginwidth= 0 src= maps?f=d&source... ></iframe><br/> <object id= map data= ></ object><br /> #map { width: 318px; height: 422px; 38

39 } border: none; scrolling: no; marginheight: 0; marginwidth: 0; 8.6 Knapper med Javascript Vi ønskede at implementere en button-down effekt på vores ikoner. For at opnå det benyttede vi javascript. På trods af vores kode fungerede fint i browseren, var det ikke muligt at validere den indsatte javascript. Vi var derfor nødsaget til at slette koden og dermed fjerne effekten. En mere dybdegående gennemgang af processen findes i bilag 7. 39

40 9. Den færdige prototype Live Kort Live View En GPS funktion med en menu i toppen. Her kan skiftes mellem standard GPS og Live View, som er en AR version af GPS en. Ny rejse 40 En oversigt over nærliggende busstoppesteder og S-tog/ metrostationer og afgangstider. Find favorit Rejseoversigt - forslag til forskellige rejser Gem adresse i favoritter Live Kort Informerer brugeren om evt. forsinkelser på den pågældende rejse. Zoneoversigt og køb af billet til rejsen.

41 10. Konklusion Med udgangspunkt i RP s konkurrence, har det været vores formål at udvikle et konceptuelt forslag i forlængelse af brugernes ønsker til forbedringer. Data i RP s brugerundersøgelse afslørede tydeligt et behov for bedre at kunne bruge RP, ikke alene foran computeren, men også under selve rejsen. Derfor valgte vi at arbejde med RP til smartphones. Udviklingen af en applikation, med udgangspunkt i allerede eksisterende data, har tilskyndet til en videre og gennemgående brugerdreven iterativ arbejdsproces. Den har vi søgt at understøtte med relevant research. I vores konceptuelle proces har vi gennemgået en række iterationer, som har medført nye muligheder for funktioner i RP, der ville være relevante for brugere på farten. Vi har benyttet os af en kombination af flere metoder af såvel kvantitativ som kvalitativ art, der har ledt os frem til den endelige udvikling af app en. Vores brugerundersøgelser har givet os mulighed for at få indblik i brugernes syn på og oplevelser med vores koncept, og herved modtage vigtige inputs til den videre udvikling. Megen feedback har vi taget til os og benyttet i vores arbejde andet har vi vurderet som værende relevante perspektiver på en fremtidig videreudvikling af app en. Hovedformålet med vores proces har været at udarbejde et koncept, der kan forbedre brugerens oplevelse og interaktion med RP - via hans/hendes smartphone. Vi har udviklet en app, som samler en række koncepter, hvis formål er, at forbedre brugerens oplevelse på farten : app en indeholder en række nye navigationsmuligheder som Street View stills, Live Kort og Live View, der gør det let og overskueligt for brugeren at komme fra a til b samtidig med, at han/hun let kan følge med i sin rejse undervejs. I vores koncept har vi bevidst valgt at kombinere det kontekstuelle med det visuelle, med det formål at forøge brugeroplevelsen og gøre navigationen let tilgængelig. Vores produktforslag er derfor både mobilt, praktisk og effektivt samtidig med, at det samler allerede eksisterende funktioner i en mere overskuelig og let tilgængelig form. Vi vurderer, at vi har udviklet en gennemtestet prototype af en app, som imødekommer et behov hos brugere af smartphones, der anvender RP. Samtidig har vi udviklet et koncept, som også ikke-brugere finder intuitivt og relevant at benytte. App en formidler en brugeroplevelse som ikke allerede eksisterer, men som vores og RP s undersøgelser viser, at der er efterspørgsel efter. 41

42 11. Perspektivering I takt med at smartphones bliver en mere udbredt teknologi, vil apps vil blive en lettere og mere naturlig tilgang til Internettets enorme indhold af information. Denne tendens understøttes af Rejseplanens egen brugerundersøgelse, hvor en stor andel af deltagerne udtrykte behov for an applikation til Android platformen. Vores applikation vil potentielt kunne anvende flere af de nuværende og fremtidige teknologier. Den inkorporerer allerede Augment Reality, i form af Live View funktionen. Denne kan dog udbygges yderligere med trafikinformation, ratings af restauranter, man går forbi, butikkers nuværende tilbud, forslag til sjove oplevelser osv. Vi tror desuden, at de mange muligheder for gå-rute-vejledning både vil føre til mindre tid anvendt på planlægning og mere tid til de egentlige gøremål. Funktionerne vil også føre til større udbredelse af applikationen, da vores empiri har vist, at forskellige typer brugere foretrækker forskellige måder at få serveret rejseinformationen på. 42

43 12. Litteratur Beyer, H., Holzblatt, K. (1998) Contextual Design - Defining customer centered systems. Morgan Kaufmann, San Francisco. Brown, Daniel M. (2007) Communicating Design Developing Web Site Documentation for Design and Planning, s New Riders, California. Buxton, B. (2007) Sketching User Experiences: Getting the Design Right and the Right Design. Morgan Kaufmann. Debor, G. (1981) Situationist International Anthology. Berkeley: Bureau of Public Secrets. Engholm, Ida (2005) Webgenres and styles as socio-cultural indicators an experimental, interdisciplinary dialogue, i proceedings in the making, s Gaver, B., Dunne, T. & Pacenti, E.(1999). Design: Cultural Probes. Interactions 6, 1 (Jan, 1999) (pp ) Gregersen, O. & Wisler-Poulsen, I. (2009). Hvad er Usability? I Usability, p Forlaget Grafisk Litteratur. Krug, S. (2006) Don t make me think. A common sense approach to web usability, 2. ed., s New Riders, Indianapolis. Lynch, P., J. & Horton, S. (2009) Web Style Guide, Basic Design Principles for Creating Web Sites, 3rd edition: Yale University Press. Molich, R. (2000) Brugervenligt webdesign. København: Teknisk Forlag. Nielsen, J. (1993) Usability Engineering. Morgan Kaufmann. San Diego, Californien. Robbins, J. (2007) Learning Web Design. Third Edition. O Reilly. CA Sharp, H., Rogers, Y. & Preece, J. (2007) The Proces of Interaction Design, i Interaction Design beyond human-computer-interaction 2. Ed., s John Wiley & Sons. Thorlacius, L. (2007) Æstetikkens rolle i webdesign. Nordic Review 28 (2007) pp

44 Internethenvisninger Web ref. 1: Rejseplanen, ( ) Web ref. 2: Metronyt, ( ) Web ref. 3: Rejseplanen, ( ) Web ref. 4: DSB, ( ) Web ref. 5: ComOn, ( ) Web ref. 6: Rejseplanen, ( ) Web ref. 7: Wikipedia, ( ) Web ref. 8: Camtasia, ( ) Web ref. 9: TricTrac, ( ) Web ref. 10: Rejseplanen, ( ) Web ref. 11: Rejseplanen, ( ) Web ref. 12: Jakob Nielsen, ( ) Web ref. 13: Wikipedia, ( ) Web ref. 14: Google Maps, ( ) 44

45 13. Bilag Bilag 1 - Rejseplanens brugerundersøgelse 45

46 Bilag 2 - Mock-up s 46

47 Bilag 3 - Wireframes 47

48 48

49 49

50 50