Web sider for hurtigruten Kai A. Olsen Høgskolen i Molde/Universitetet i Bergen

Opplegg Litt om Web Fokusere på Hurtigrutens behov Historikk Teknologi Prinsipper Bruk Fokusere på Hurtigrutens behov Målsetting Brukergrupper Funksjonalitet Nye muligheter

Web historikk Datamaskinteknologi (PC, nettverk) – 1970 Akseptabel pris PC (1990-) Standarder for nettoverføring og Web -TCP (1980-), IP, HTTP, HTML (1990-) Nettleser (1993-) ”last mile” nettverk (ADSL, 2000-) Utbredelse (2000-)

Web applikasjoner er krevende Mange av brukerne har liten kompetanse Ingen mulighet til å skolere brukerne Brukergrensesnittene må være intuitive Ingen kontroll med brukernes utstyr (PC, skjerm, linjehastighet), selv om vi nok kan sette visse minimumskrav Ingen kontroll med brukernes programvare (nettleser, operativsystem)

Likevel Til tross for at vi som brukere kan ha Har vi krav til sidene: Liten IT kompetanse Liten trening i å bruke datamaskinen Være helt ny på Hurtigrutens Web-sider Har vi krav til sidene: Vi forventer å få dekket vårt informasjonsbehov Vi forventer at ”alt” kan gjøres på Web Vi forventer at dette kan gjøres nå! Uten altfor stor innsats

Vi vil ha Oversiktlige sider Som gir oss all den informasjonen vi måtte trenge Som er lett å bruke Som krever et minimum av inntasting Der det (nesten) ikke er mulig å gjøre feil Sider vi stoler på

Er dette urimelig? Nei, dette er mulig å oppnå i dag med: og med Moderne Web-teknologi Kopling til underliggende databaser Godt strukturerte sider Utnytte fagkunnskap innen brukergrensesnitt (user interface) design Utnytte standarder og med Testing!

Hurtigrutens Web-sider Store svakheter ved dagens sider for Hurtigruten Men likevel bruke disse som et utgangspunkt for den funksjonaliteten som kreves PS: Vi skal her kun vurdere Hurtigrute-delen av Hurtigruten Group: For å forenkle For at denne er mest krevende

Før vi starter Ideer om målsetting for Web-sidene Idé om hvem som skal bruke sidene Dette blir skisser fra min side, men vil likevel gi en idé om framgangs-måten

Målsetting Hvilke mål skal Hurtigruten ha for de nye sidene? Muligheter: Selge 20% av billettene over Internett (unngår gebyr til reisebyrå, høyere pris, nå nye kundegrupper) Øke belegget med 10% utenom sesongen (nye kundegrupper, Internett-tilbud) Vise at en er en moderne og oppegående bedrift Møte framtiden, når alle booker på Internett

Risikoanalyser for Web satsing ”Risikoanalyse”/fallgruver: Konkurrerer vi med våre samarbeidspartnere (reisebyråer m.m.)? Hva vil det koste å utvikle sidene? Risikoreduksjon – muligheter: I utgangspunktet samme priser på nett som i reisebyrå (unntatt noen tilbud utenom sesongen) Begrense utviklingskostnadene ved å utvikle systemet i faser, der vi starter med det mest nødvendige. Prioriterer funksjonalitet

Mulige brukergrupper Potensielle kunder i Norge og i utlandet Som har Internett-tilgang Som har et minimum av kunnskap i bruk av Internett Kunder, de som har reist med Hurtigruten tidligere (også de som har vist interesse for Hurtigruten) Reisebyråer Passasjerer (de som er ombord) Andre (ansatte, skipsinteresserte…)

Oppdeling i grupper Naturlig å skille på språk (norsk, engelsk, tysk…) Naturlig å skille mellom nye og tidligere kunder Naturlig å skille ut de som er ombord i et skip Skal vi skille mellom”rundreise”- og ”distanse”-passasjerer?

Tidligere kunder Innloggingsmulighet Vi kan ta vare på data om: Tidligere reiser Maler (standardreiser) Reiseforslag Betalingsinformasjon Vi kan sende: Tilbud Generell informasjon

Passasjerer (de som er ombord) Kan være interessert i å: Se faktura (har vi betalt for frokost?) Få oppdaterte rutetider (når kommer vi til Bergen?) Informasjon om de stedene som passeres (Hvor høy er Hestmannen?) Dagens middagsmeny, bestilling av bord til middag, bestilling av sightseeing, …? Kan sendes over lokalnett ombord

To typer passasjerer? Skal vi skille ut rundreise (turist) og distansepassasjerer (jobb, m.m.)? Ordene ”rundreise” og ”distansereise” (port-to-port) sier ikke mye Når det er vanskelig å finne ord som beskriver hver gruppe klart og entydig ..kan det være et tegn på at det ikke er noe klart skille

Rundreisepassasjer Karakteristika: Får tilbud om: Turist Reiser for fornøyelsens skyld Bergen-Kirkenes-Bergen, Bergen-Kirkenes, eller en annen strekning Får tilbud om: Totalpakke, kanskje inkl. fly Sightseeingsinformasjon Alle måltider

Distansepassasjer Eksempler: Turist som kjører en kortere strekning Jobbreise: N.N. , reiser Svolvær-Bodø t/r en gang pr. uke Jobbreise: Undertegnede, som tar Hurtigruten til Bergen av og til istedenfor fly Turist som kjører en kortere strekning N.N. er ikke turist, men bortsett fra denne kategorien er det kanskje ingen forskjell mellom rundreise og distansereisepassasjerer?

Jobbreise Kan ha interesse av komplett pakke med måltider Kan ha interesse av pakke der fly er inkludert Kan ha interesse av å delta på sightseeing (om ikke nå, så neste gang når hun drar på ferie med familien)

Kunstig skille? Er det egentlig noe poeng å skille mellom ”rundreise” og ”distansereise”? Kan ikke dette i stedet løses ved at en under bestilling får valg mellom et sett av ferdige pakker, eventuelt å komponere sin egen reise Det siste alternativet er aktuelt for jobb- og mange turistreiser.

Brukergrupper Viktig å legge mye arbeid i dette Definer typiske brukere, f.eks: Hans Muller fra Tyskland, 50 år, konen Eva bruker rullator, god økonomi, er interessert i å ta Hurtigruten fra Bergen til Kirkenes, snakker tysk, bruker Internett bank, …. og studer hvordan de planlagte Web-sidene vil dekke deres behov

Vi har nå Ideer om mål (som selvfølgelig må utarbeides i samarbeid med ledelsen) Ideer om brukergrupper Ideer om hva som kreves av en moderne Web side og kan sette opp mulige krav for Hurtigrutens Web-sider

Mulige krav Det skal være lett å finne Hurtigrutens Web-sider på nettet ved bruk av de vanlige søkemotorene Det skal være gode søkemuligheter internt på sidene Sidene skal være tilgjengelig 24 timer i døgnet Sidene skal gi tillit Sidene skal følge de standarder som gjelder for moderne Web-sider Sidene skal kunne brukes av de mest vanlige nettleserne (Internet Explorer, Firefox, Opera) De skal være mulig å bruke sidene fra en PDA/mobiltelefon (noe begrenset funksjonalitet aksepteres) Sidene skal skape interesse for å reise med Hurtigruten Sidene skal gi alle relevant opplysninger om skipene og reisen Det skal gå kjapt å foreta en billettbestilling

Standardisering Logo øverst til venstre på siden Klikker en her kommer en til startsiden Søkemulighet (i Hurtigrutens sider) øverst til høyre Prioritere interne søk Meny øverst og/eller til venstre Entydige menytermer Unngå menyer som ligner på reklame (”banner ads”) Mulighetene til å gå tilbake uten å miste informasjon Logge inn for å unngå å måtte gjenta informasjon

Krav til booking Det skal være lett å foreta en booking Booking skal kunne utføres inntil skipet forlater (kommer til) kaia Alle interessante og relevante opplysninger skal gis Mulighetene for å gjøre feil skal minimaliseres En skal kunne endre på enkeltdeler uten å måtte gjenta hele bestillingen

”Lett å foreta en booking” Vagt mål, men det kan kvantifiseres: Av et antall relevante testpersoner skal 90% klare å gjennomføre en booking innen 10 minutter Dette kan legges inn i kravspesifikasjonen, sammen med: en detaljert beskrivelse av hvordan testen skal gjennomføres (prøvekaniner, oppgaver, utstyr…) hvem som skal utføre testen (vanligvis en tredjepart)

Hvordan skal en oppnå dette kravet Krever erfarne utviklere Krever ideer fra Hurtigruten om hva som skal prioriteres Krever klar beskrivelse av funksjonalitet og – slik jeg ville gjøre dette: Først utvikle bookingsystemet uten ”design”, dvs. full prioritering av funksjonalitet Dernest legge på ”glans og glitter”

Booking i detalj Brukeren skal forta valg: ferdige pakker eller spesifisering (”customization”): avreisested ankomststed lugar måltider sightseeing Da er det viktig at: Konsekvenser av valgene er klargjort

Ferdige pakker Kan settes opp som ”take it or leave it” eller med muligheter til tilpassninger I praksis kan dette ordnes ved at systemet behandler dette som spesifisering, men der en rekke verdier er satt på forhånd Brukeren kan nå endre på noen av disse (f.eks. flytte middag fra første til andre bordsetting)

Spesifisering - steder Når vi har valgt avgangssted og ankomststed vil vi få opp den komplette seilingsplanen mellom disse to stedene Seilingsplanen vil stå på nettsidene under videre steg

Spesifisering – valg av lugar Balansering: Vi vil ha finest mulig lugar Vi vil betale minst mulig For at vi skal kunne gjøre dette må vi ha informasjon om: Lugaren (type, plassering, bad, senger), kan gis med tekst og bilder Pris pr døgn Selvfølgelig må systemet markere ledige, men det kan være aktuelt å vise andre lugartyper System vil foreslå lugar fra avgang til ankomst. Dette er markert med skravering i ruteplanen. Brukeren kan redusere lugartiden. Pris oppdateres etter at lugar er valgt

Eksempel – kan vi gjøre det slik? Dvs. bruke tekst og bilder for å vise lugar-alternativene

Spesifisering - måltider Systemet vil foreslå de måltider som er mulig å ta - gitt avgangstidspunkt og ankomsttidspunkt Dette kan være angitt med fargekoder i ruteplanen Brukeren kan redusere antall måltider Pris oppdateres etter at måltider er valgt

Eksempel (skisse) Valg av måltider er avhengig av reiserute Orker vi å gå til frokost før 10.00 når vi legger oss kl. 0400? Skal vi se Rørvik må vi velge første bordsetting denne dagen …

Spesifisering - sightseeing Systemet vil foreslå mulige ekskursjoner basert på seilingsplanen Det gis informasjon om hver ekskursjon Brukeren kan markere det som ønskes forhåndsbestilt Pris oppdateres med valgte ekskursjoner

Spesifisering - betaling Pris for hver del og sum vises før betaling Bruker har mulighet til å gå tilbake og endre på hvilken som helst del av bestillingen Brukeren bekrefter bestillingen Først nå gis person- og kredittkortopplysninger Bruker kan velge om dette skal gjøres som en registrering i systemet (slik at han kan gå tilbake for eventuelt å endre på reisen)

Når kan vi bestille Fra 1 år (?) i forveien Inntil skipet forlater/kommer til kaia Det kan realiseres ved at all booking (fra kunde, administrasjon, ombord) foregår mot den samme databasen Krever nett-tilknytning fra skipet, i hvert fall når dette ligger i havn (WLAN) Mobildekning kan brukes i unntakssituasjoner Krever at skipets posisjon er kjent for bookingsystemet Kan gi oss ”last minute sales”

Innlogging/registrering Valgfritt Dvs. det bør være mulig å kjøpe en billett uten å være registrert som bruker Men er en registrert kan en logge inn tidlig i prosessen (jfr. bestilling av flybillett)

Med et enkelt og oversiktlig system Vil vi kunne selge flere billetter over Web Rette salget mer mot enkeltkunder enn mot grupper (og dermed oppnå høyere pris) Redusere administrative omkostninger Ta vare på data om tidligere kunder (tilbud, rabatter, service ombord)

Testing De ferdige sidene må testes Av utviklerne (teknisk sjekk) Av potensielle kunder (brukergrensesnitt, intuivitet, effektivitet) Testresultatene bør inngå i kravspesifikasjonen og bør være en del av en akseptansetest

Testoppgaver (eksempler) Finn Web-adressen til Hurtigruten Finn ut navnet på sørgående hurtigrute som kommer til Tromsø i dag Normal og billigste billettpris med og uten lugar fra Tromsø til Bergen Hva det koster å ta med bilen i tillegg Hva en ferietur fra Bergen til Kirkenes vil koste, med fly på returen Hvilke skip som har konferansefasiliteter og hvilken kapasitet disse har Bestille billett Finne billigste reise

Hvem er kompetent Hvem er kompetent til å kommentere brukervennligheten? Passasjerer Ansatte Potensielle kunder Altså hvem som helst

Vedlikehold Ha et apparat for kontinuerlig utvikling/vedlikehold Lag et system for å ta imot respons fra ansatte og kunder Belønn respons (premie) Lag en ”ombudsmannsordning”: en egen ansatt tar imot tilbakemeldingene fører statistikk, m.m. tar opp tilbakemeldingene med utviklerne ”representerer” kundene i den påfølgende diskusjon

Når vet vi at vi har suksess? Når andelen bestillinger på Web øker Når klagene minker Men ikke forvent å få ros for gode sider! Kundene forventer at Web-sider fungerer Suksesskriteriet blir da fravær av klager

Nye muligheter En fare er at vi bruker Web som effektiviseringsredskap, og glemmer nye muligheter Den fellen har SAS og bankene gått i (kun standard tjenester) Mens f.eks. Norwegian tilbyr nye muligheter (som lavpriskalender) Amazon tilbyr kundeanmeldelser, kopler sammen bøker (”de som kjøpte denne kjøpte også…”) Vi skal se på potensielle nye muligheter for Hurtigruten

Nye muligheter - salg Et eksempel – e-savers (en idé fra USAir): Jeg har lagt inn en ”potensiell” bestilling, Molde-Trondheim, med fin lugar, bil og frokost med avreise fredag kveld Har oppgitt epost og SMS adresse Kl. 12 dagen før sender Hurtigruten et tilbud på pris. De som responderer først får billetten

Hva kan vi oppnå Selge billetter som vi sannsynligvis ikke ville ha solgt til vanlig pris Utnytte ledig kapasitet Ha fortjeneste på tilleggssalg (mat, m.m.) Skape interesse for Hurtigruten

Nye muligheter - informasjon Ved å oppgi mobilnr og krysse av for SMS kan Hurtigruten sende oppdatert informasjon om avgangstider. Det kan være kjekt om du venter på båten Kan sende SMS med data om stedene skipet passerer: ut fra hva passasjeren har sagt seg interessert i

Nye muligheter - sesongvariasjoner Det er svært enkelt å tilpasse Web-sidene til sesongene For eksempel: sommerpriser, høstpriser, etc. (gjerne helt dynamisk) vinterbilder om vinteren, sommerbilder om sommeren

Nye muligheter produkt - ”The long tail”

”The long tail” Amazon: Eksempel: Ikke mulig uten Internett "We sold more books today that didn't sell at all yesterday than we sold today of all the books that did sell yesterday. Eksempel: ”Touching the void”, Joe Simpson, kom ut i 1988. Fikk gode anmeldelser, solgte litt, ble snart glemt. ”Into thin Air”, Jon Krakauer, 10 år senere, fikk mye oppmerksomhet Hva skjedde: Simpsons bok begynte å selge, ny utgave, Amazon koplet sammen bøkene, ble bestseller, film Ikke mulig uten Internett Grunnfilosofi: Vi er forskjellige, Internett/Web aksepterer det For Hurtigruten: Kan vi utvikle individuelle tilbud?

Nye muligheter produkt? Hvordan kan vi utnytte ideen mot Hurtigruten Tradisjonell markedsføring, brosjyrer, annonser, m.m. er kostbart Da kan vi kun markedsføre tilbud som er interessant for store kundegrupper Web markedsføring er langt billigere, spesielt om vi har gode underliggende system Da kan vi tilby spesialtilbud

Eksempel: Hurtigrute & fjellturer Utnytte mulighetene for flotte fjellturer langs kysten En mer aktiv ferie enn kun å være ombord Passasjeren kan velge ”stop-over” steder. Må ha samarbeid med hotell. Kan la turistene gå på egenhånd (med turbeskrivelser) eller tilby guiding.

Eksempel: Hurtigrute & fisketur Stop-over på småsteder langs kysten Hotellovernatting eller rorbu i fiskevær Fiske fra svaberg eller fra båt Samarbeid med båtutleie og med dem som arranger havfisketurer Idé: Gi turistene nærkontakt med kystkulturen

Vi utnytter her At det går en Hurtigrute hver dag At det er mange aktiviteter langs kysten Retter markedsføringen mot nye grupper som ønsker mer aktiv ferie Personlig tilpassning av ferien

Hva kreves Et fleksibelt bestillingssystem, slik at en passasjer kan gå i land og fortsette turen med en annen båt Et basissystem der vi kan kople oss til andre bestillingssystem (hotell) (kan forenkles ved at vi har forhåndsbooking av et antall rom som da kan håndteres av eget system) Et Web system der vi linker oss videre til andre sider (hotell, båtutleie, etc.) Ideen må være at det er lett for administrasjonen å sette opp slike pakker

Ikke gjør alt på en gang Utvikle systemet i faser, f.eks.: Fase 1: Godt billettbestillingssystem Fase 2: Tilleggstjenester (for passasjerer, for faste kunder, m.m.) Fase 3: Nye muligheter men ha en idé om framtidig funksjonalitet allerede fra starten