Web sider for hurtigruten

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

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

3. 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-)

4. 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)

5. Likevel • Til tross for at vi som brukere kan ha • 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

6. 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å

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

8. 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

9. 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

10. 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

11. 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

12. 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…)

13. 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?

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

15. 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

16. 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

17. Rundreisepassasjer • Karakteristika: • 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

18. Distansepassasjer • Eksempler: • 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?

19. 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)

20. 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.

21. 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

22. 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

23. 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

24. 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

25. 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

26. ”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)

27. 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”

28. 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

29. 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)

30. 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

31. 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

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

33. 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

34. 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 • …

35. 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

36. 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)

37. 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”

38. 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)

39. 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)

40. 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

41. 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

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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. Nye muligheter produkt - ”The long tail”