Øving 4 Brukergrensesnitt 1. Fleksible flybillettbestillingssystem Dagens flybillettbestillingssystem på nett gjør det enkelt for det gjennomsnittlige mennesket å bestille reiser selv. Slike systemet fungerer utmerket når all data som dato, tidspunkt og destinasjon er formalisert, og fast bestemt på forhånd. Kunden legger inn avreise og ankomst, velger passende datoer og evt. preferanser. Deretter presenteres mulighetene. Til gjengjeld fremstår det samme systemet som lite fleksibelt når deler (eller hele) av denne dataen er ukjent. Det vil si at når mennesker har flere potensielle muligheter er systemet mindre hjelpsomt. Selve reisen kan altså være fleksibel med tanke på destinasjon, datoer, antall dager o.l. Dette skyldes at systemet avhenger av innput (kundens valg og preferanser) for å presentere tilbudene til flyselskapet. Når innput en ikke er formalisert og ikke eksisterer, mangler systemet noe å forholde seg til. For å realisere et fleksibelt brukergrensesnitt må den ikke-konkrete innput en formaliseres (i hvert fall til en viss grad) slik at systemet tar utgangspunkt i kundens preferanser. Preferansene kan være i forhold til prisgruppe, destinasjon osv. Det fins flere alternativer for et slikt fleksibelt brukergrensesnitt, og mitt presenteres i neste avsnitt. Nettsidene til flyselskaper inneholder mye forskjellig. Eksempler på innhold kan være en support-side, aktuelle tilbud, reisetips, reisemål, hotellordninger, bedriftsavtaler osv. Dette har ikke jeg tatt hensyn til i mitt forslag til et fleksibelt brukergrensesnitt; jeg har kun fokusert på selve bestillingssystemet. I likhet med dagens systemer, er mitt bestillingssystem også en slags søkemotor hvor bruker fyller data inn i nødvendig felt, og systemet finner passende tilbud. Mitt forslag er skissert til venstre. Tanken er en slags kombinasjon av en dynamisk meny og søkemotor. Dette brukergrensesnittet skal la Side 1 av 7
brukere/kunder velge sin ideelle reise. Jeg har tre felt med stjerne bak som representerer obligatoriske felt; dvs. felt som må fylles ut. Kun avreise-destinasjon er absolutt nødvendig å fylle inn, dersom en ikke har bestemt ankomst-destinasjon. Det betyr at man kan skrive inn en spesifikk til-destinasjon, men man må ikke. Deretter vil passende kandidater til søket dukke opp i søkeresultater. Under antall reisende velger man tall på hvert valg, og aktuell reiseklasse tilslutt. Når det gjelder reisedatoer har man to alternativer. Man skal krysse av på den som er aktuell, dvs når man har bestemte faste datoer for reise velger man første, mens hvis datoer er fleksible velger man 2. valg. For å vise hva som egentlig er forskjellen mellom de to datovalgene med tanke på brukergrensesnittet: Hvis en skal reise en bestemt tur fra Bergen til London fra 7.mars 2014 til 9.mars 2014, fyller man ut Til- og Fra-feltene, velger antall reisende, krysser av på bestemt dato og tilslutt velger reiseklasse. Siden det er en dynamisk meny er ideen at det skal dukke opp to nye felt under bestemt dato, slik at man kan velge dato for utreise og retur ut fra en kalender. Samtidig forsvinner ikke valget fleksibel dato, i tilfelle en krysset av med feil på bestemt dato. På samme måte forsvinner ikke-bestemt datovalget dersom en krysser av på fleksibel dato. Hvis man trykker på fleksibel dato, vil det dukke opp felt som er mer fleksible enn to konkrete avreise- og ankomst-datoer. Ideelt er disse nye feltene tre nye valg hvor man kan velge om reisen skal vare et bestemt antall dager, være innenfor et bestemt tidsrom,eller fra spesifikke ukedager. På denne måten kan en velge om reisen skal vare i 6 dager, være mellom mars og juni eller fra en vilkårlig tirsdag til lørdag. Side 2 av 7
Tanken er at etter nødvendige felt er fylt inn, og de som er fleksible er tilpasset kundens etterspørsel, skal det komme opp en side med tilbud/søkeresultater. Siden dette kan føre til ekstremt mange tilbud (avhengig av hvor mange fleksibelt felt er blitt tatt i bruk), er ideen at brukeren skal kunne sile ut aktuelle tilbud. Dette skal være mulig ved på siden med søkeresultater, skal det være filtre på toppen eller på siden av søkene. Eksempler på filtre som kan brukes, er pris (lav til høy), verdensdel, land, antall mellomlandinger og lignende. Etterhvert som brukeren velger passende filtre vil mengden tilbud trolig minke. Tilslutt skal brukeren ha en rekke aktuelle tilbud som er tilpasset brukerens preferanser. For å gjøre billettbestillingsystemer mer fleksible må ikke-konkret data formaliseres. Jeg tok utgangspunkt i dagens vellykkede flybillettbestillingssystemer og valgte å legge til fleksible felt. De fremste eksemplene slike felt i dette brukergrensesnittet er fleksible datoer og til-destinasjon. Disse ble altså lagt til for å oppnå mest mulig fleksibilitet. Samtidig krever dette mer forarbeid (før søk) og etterarbeid (etter søk) av brukerne. Forarbeid fordi flere felt som måtte fylles inn, oppstod. Etterarbeid ettersom et slikt oppsett kan potensielt føre til mange sider med resultater å gå gjennom, og derfor ble filtre lagt inn. Man ser altså at for å oppnå mer fleksibilitet, ble det her innført flere innput-felt. Dette går på bekostningen av enkelheten og dermed brukervennligheten. Brukeren må fylle flere felt inn, foreta mer tastetrykk og bruke mer tid bruke tid både før og etter søket, for å benytte slike fleksible søk. Innføringen av slike nye felt innebærer også forklaring slik at de må forstås for å brukes riktig av brukerne. Dette brukergrensesnittet krever altså endel tid før og etter billettsøkingen, og sammenlignet med dagens rett-fram systemer framstår det som relativt tungvint. Side 3 av 7
2. Ruteinformasjon Nedenfor er det skissert en plan over/mitt forslag til hvordan en kan foreta en reise fra Oslo til Høyteknologisenteret i Bergen. I oppgaveteksten nevnes det ikke helt detaljert hvor i Oslo en starter reisen sin. Her har jeg (i likhet med Napoli-eksempelet) begynt direkte på avreistestedene. Denne reiseplanen har i utgangspunktet samme format/stil som planen oppgitt i oppgaveteksten. Reisetidene er tatt fra Skyss, Flybussen, Avinor og NSB sine nettsider. Det kan og bør nevnes at brukervennligheten til slike planer blir påvirket av kvaliteten til en rekke punkter, som f.eks. hvilken informasjon som er tilgjengelig. Dermed er det naturlig at slike kritiske momenter bør også vurderes. Denne vurderingen er gjort avslutningsvis. Side 4 av 7
Se på skissen på forrige side. Nå skal det ses nærmere på brukervennligheten til planen, som da presenteres i de etterfølgende avsnittene. Det første positive punktet er at planen har et relativt enkelt format (i forhold til bystruktur osv.) rent visuelt. Videre er den satt opp kronologisk med hensyn på reiserute; begynner på topp og avslutter nederst, en rett-frem oppbygning. Denne logiske oppbygningen bidrar til å gjøre ruten klarere for brukerne. Videre er det oppgitt omtrentlige reisetider. Dette er positivt fordi brukere kan sammenligne reisetidene og vurdere de transportmulighetene som passer best ut fra det. Måten planen er utformet på, gjør at det gir en grei oversikt over transport-alternativene. Den viser mestepartene av de mulige måtene samt alle kombinasjonsmuligheter en har for å komme fra Oslo til Bergen på. For eksempel er det mulig å velge mellom fly, buss, tog eller å kjøre privat, samtidig som det er fullt mulig å kombinere flere av disse på flere mulige måter. Videre er det satt opp/markert felles knutepunkter, det vil si stasjoner, slik at brukerne kan velge den transportmuligheten som passer best.. Planen har flere negative enn positive punkter som gjør den mindre brukervennlig. Sånn sett er det også som følge av kravet om kort og konsis / lite informasjon. Planen forteller for eksempel ikke noe om hvilke buss- og bybanestopp som er aktuelle, i hvilken retning disse skal tas, og hvordan man faktisk skal bruke transporten (kort/kontant/billett), hvordan man får tak i disse eller hvor ofte de ulike transportmulighetene har avganger. Slik informasjon kunne vært gunstig å ha med, i hvert fall noen få setninger om dette for f.eks. førstegangs reisende i Bergen med minimal erfaring og kunnskap om busselskap i Bergen (Skyss, Tide osv.). Et eksempel på dette kan være at hvis en ikke vet når toget går, og en kommer rett etter det aktuelle toget har gått, risikerer en å vente i flere timer. Skjer dette midtvinters er det da dessverre ekstra ergerlig. Samtidig kan dette argumenteres med at det unnlatelsen bidrar til det enkle formatet. Det er også lite informasjon om alternativer dersom en velger å bruke privat transport. Det står ikke noe som helst en burde kjøre på E16 eller andre kjøremuligheter. Videre har planen heller ikke nevnt snarveier som en ta for å gå til fots fra busstasjonen til Høyteknologisenteret, eller at det er flere bussforbindelser fra Galleriet. Å gå av på et stopp (buss/bybane) på Danmarksplass er også et alternativ. Dette utgjør flere reisemuligheter samtidig som det krever litt mer forkunnskaper (brukere må vite hvilken retning og hvilken vei de skal gå). Det er altså ikke tatt hensyn til. Side 5 av 7
Videre har dette også sammenheng med neste kritiske punkt: geografisk plassering av "stasjonene" på planen. En kan stille spørsmål ved nøyaktigheten til planen med tanke på geografisk plassering samtidig som man kan argumentere mot den. Geografisk sett, ligger Høyteknologisenteret mellom Flesland og Bergen busstasjon, men ikke ifølge planen. Eller egentlig tar ikke planen hensyn til det i det hele tatt ettersom den kun presenterer alternativer for å komme frem til Høyteknologisenteret. Dette er bra for den enkle strukturen som gjør planen lett oppfattelig. Samtidig er det negativt fordi den ikke sier noe om geografisk beliggenhet. Det vil si at hvis noen vil gå til fots til Høyteknolgisenteret fra jernbanestasjonen, må dette være kunnskap som vedkommende har fra før eller skaffer seg på andre måter. Dersom en valgte reisemåte er privatbil fra Oslo til Bergen, er det enda et punkt som planen tar så godt som intet hensyn til. Den nevner ikke hvor mye det bygges for tiden i Bergen halve byen er revet ned, bybane bygging pågår for fullt, innfartsårer inn til Bergen sentrum er i ferd med å bli oppgradert til rene mototveier (en kan trygt si at Høyteknologisenteret ligger i Bergen sentrum). Store deler av byen er i forandring. Det er rimelig å anslå at mange av disse byggestedene/anleggsstedene rundt om i Bergen opererer med sprenging av fjellmasser med påfølgende stengte veier til forskjellige tider på døgnet (feks ved vågsbotn i Åsane pågår det oppgradering av vei og her kommer både E16/E39 og fortsetter inntil Bergen sentrum). Dette gjelder også for reise til Bergen med buss eller taxi innad i byen ettersom det kan påvirke reisetiden. Planen opererer med oppgitte reisetider, men har hverken opplyst om eller tatt hensyn til at ytre faktorer som kan endre disse. Med dette menes forhold som f.eks. snøstorm med påfølgende stengte fjelloverganger vinterstid. Planen har heller ikke nevnt hvorvidt en kan benytte seg av spesial tilrettelagede plattformer for som f.eks rullestolbruker og blinde. Med bakgrunn i dette, burde brukerne på ett eller annet tidspunkt også vurdere hvilken transportform som er mest hensiktsmessig etter hvor mye bagasje en har og hvor mye "margin" en har til rådighet dersom forsinkelser forårsaket av ytre faktorer oppstår. Dette er relevant fordi at mens både fly og buss kan bli utsatt for forsinkelser og kanselleringer, blir tog ett mer sikrere transport-alterantiv. Forsåvidt kan det samme sies om privatbil dersom en da på forhånd tar hensyn til eventuell forsinkelse som kan oppstå grunnet være kolonnekjøring, evt. stengte fjelloverganger som medfører omgkjøring eller endret reiserute. Slik informasjon er nyttig å nevne, i hvert fall ett par setninger. Side 6 av 7
En oppsummering av det hele er at denne reiseplanen kan betraktes som middels til lite brukervennlig avhengig av hva en vektlegger. Det mest brukervennlige er den enkle, rettfram strukturen med felles knutepunkter samtidig som det er oppgitt noenlunde reisetider. Det som trekker ned brukervennligheten er hovedsakelig mangel på nyttig informasjon som navn på aktuelle bybanestopp eller hvilke alternativer som fins dersom en velger å kjøre privat. Side 7 av 7