Android Sightseeing. INF5261, sluttrapport, våren Av: Bente K. Nordbø. Tor Anders Johansen. Android Sightseeing, sluttrapport

Transkript

1 Android Sightseeing Av: Bente K. Nordbø Tor Anders Johansen INF5261, sluttrapport, våren

2 1 Innledning Produktide Begreper Relaterte studier Guide TouristGuide Context-Aware Adaptation in a Mobile Tour Guide P-Tour A personal Navigation system for Tourism Context-Aware Content Filtering & Presentation for Pervasive & Mobile Information Systems Relatert til vår egen løsning, Android Sightseeing Oppsummering Teknologi Åpen kildekode og fri programvare Andoid plattformen Introduksjon Arkitektur Utviklingsverktøy Android Sightseeing Målgruppen Data som understøtter valg av målgrupper Metode Designprosessen Identifisering av bruker Personas Utvikling av prototype for Android Sightseeing Liknende produkter

3 9.1 Google applikasjoner Android Market Annet Brukerevaluering Dynamic Tour Guide (DTG) Evaluering og endringer gjort underveis Videreutvikling Oppsummering og konklusjon Referanser

4 1 Innledning 1.1 Produktide Vi har valgt å utvikle en tjeneste for mobiltelefoner, Android Sightseeing, der turister kan få forslag til guidet turistrute via sin mobiltelefon mens de er på oppdagelsesferd i en storby. Dette kan for eksempel være informasjon om attraksjoner som museer, historiske bygninger, kulturinstitusjoner og lignende. Vi ønsker å visualisere informasjonen på en enkel og brukervennlig måte, ved bruk av kart, hvor brukerne i tillegg til å motta informasjonen også selv bidrar til å trekke fram be beste turistmålene. Dette er tenkt som en løsning hvor brukerne anmelder de enkelte turistattraksjonene. Denne gåruten vil genereres dynamisk basert på kriterier som nåværende posisjon, ønsket varighet og hva slags aktiviteter man foretrekker. Vi har valgt Android plattform som har en åpen kildekode. Android er utviklet av Open Handset Alliance. Ettersom Google både står bak Android og Google Maps, gjør dette det blant annet enkelt å utvikle en kartorientert applikasjon. 2 Begreper Vi vil forklare og definere sentrale begreper som blir benyttet i rapporten. Videre vil vi drøfte kontekstbegrepet i lys av en realisering av skreddersydde mobile tjenester Skreddersøm Med skreddersøm mener vi tilpasning til brukeren ut fra informasjon om utdanning, alder og interesser og ønsket aktivitet, samt informasjon om geografisk plassering brukeren befinner seg i Kontekst og kontekstsensitivitet Hva som betraktes som kontekst når en diskuterer problemstillinger knyttet til bruk av samhandlingsteknologi og mobile tjenester for bruker, er til en viss grad avhengig av faglig tilhørighet, noe som gjenspeiles i forskningen på området. Kontekst blir ofte definert gjennom eksempler eller gjennom synonymer som for eksempel omgivelser eller brukerforhold [Dey og Abowd]. En mye brukt definisjon av kontekst er [Dey og Abowd]: Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves. Denne definisjonen synes å være "state-of-the-art", mye referert og anerkjent av de fleste som arbeider innen dette feltet. Dey og Abowd hevder videre at tid, identitet, lokasjon og aktivitet er de fire primære konteksttypene for å beskrive situasjonen til en bestemt entitet. Disse konteksttypene kan igjen finmaskes for å få et mer detaljert bilde av konteksten. For eksempel kan e-postadresse ses på som en sekundær konteksttype, knyttet til primærtypen identitet. Kjernen i denne definisjonen er aktøren og den tekniske applikasjonen. Men, hva er relevant informasjon om tid, identitet, lokasjon og aktivitet som aktøren og den tekniske applikasjonen inngår 4

5 i? Det som anses som relevant informasjon er ikke alltid like entydig selv om vi som individer i et samfunn har en felles kunnskapsbase om vår felles overordnede virkelighet [Berger og Luckman]. En annen kritikk av definisjonen settes fram av [Chena og Kotz] som mener det er et skille mellom aktiv kontekst som er bestemmende for måten en mobil applikasjon tilpasser seg omgivelsen på og passiv kontekst som er relevant, men ikke avgjørende for applikasjonens tilpasning. Chena og Kotz foreslår derfor følgende definisjon av kontekst: Context is the set of environmental states and settings that either determines an application s behavior or in which an application event occurs and is interesting to the user. Dey og Abowd definerer videre kontekstsensitive (context-aware) systemer som følger: A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the user s task. Ut fra klassifiseringen av kontekst som aktiv eller passiv, presenterer Chena og Kotz to definisjoner for kontekstsensitive applikasjoner: Active context awareness: an application automatically adapts to discovered context, by changing the application s behavior. Passive context awareness: an application presents the new or updated context to an interested user or makes the context persistent for the user to retrieve later Semantikk Semantikk er den grenen av lingvistikken (språkvitenskapen) som studerer ordenes betydning. Når vi senere snakker om semantisk sammenlikning så sammenliknes begrepsklasser. Disse begrepsklassene er organisert hierarkisk hvor klasser med en videre betydning er organisert over underklasser som han en smalere / mer spesialisert betydning Åpen kildekode Oftest omtalt med lånebegrepet Open Source fra engelsk og betyr at kildekoden til et dataprogram er gjort tilgjengelig ofte på Internett for alle. Det finnes mange forskjellige lisenser for åpen kildekode, men den mest brukte er GNU General Public License (GPL). 3 Relaterte studier Ulike felter av kontekstavhengige mobile tjenester er blitt drøftet av ulike forfattere. Vi ønsker her å beskrive og drøfte noen av disse løsningene og konseptene som vi mener er relevante og nærliggende for tjenesten vår. Vi vil videre belyse de ulike synspunkter som forfatterne vektlegger ved deres utvikling. Vi anser det som svært relevant å se på lignende løsninger både i form av ferdige løsninger mens ikke minst få et innblikk i hvilke tanker og argumenter som ligger til grunn for deres konsepter. Dette tror vi vil styrke vårt endelige produkt i form av en gjennomtenkt og grundig evaluert løsning. Felles for disse artiklene er fokus på utvikling av mobile tjenester som har til formål å gi brukerne den informasjonen de trenger i de omgivelsene de befinner seg i en form for skreddersydd og 5

6 individuell tilpasset informasjon ut fra den kontekst de befinner seg i. Det poengteres av flere at en dynamisk tilpasset informasjon, som værforhold, åpningstider (evt. ikke-regulære stengninger av museer o.l.), trafikkmeldinger som stengte veier i de respektive områder etc. kan være interessante områder å se nærmere på. [Kaijian Xu et al] presenterer eksisterende teknikker for modellering med utgangspunkt i brukereferanser: Regelbasert En teknikk som eksempelvis kan gi demokratisk informasjon om forbrukers kjøpsatferd av et spesielt produkt i fremtiden. Ved bruk av beslutningstre kan de anslås om personen vil kjøpe produktet eller ikke. I denne modell benyttes demografiske data. Tidligere hendelser basert Modell basert på tidligere kjøpsadferd og historiske data som at ulike produkter har en tendens til å bli anskaffet samtidig. Dette mønsteret kan benyttes til og predikere nye brukeradferdsmønster. Innholdsbasert Baseres på en karakterisering av brukers interesse for deretter å benytte tradisjonelle teknikker for å finne relevant informasjon. Samarbeidende filtrering Å tilby anbefalinger ut fra innsamlede vurderinger (ratingscore) over f.eks. turistattraksjoner fra brukere. Gevinsten er at brukere med samme interesser vil være enige med hverandre i en slik vurdering, uten å bygge en eksplisitt applikasjon for brukerpreferanser. 3.1 Guide GUIDE, eller The GUIDE Project [Keith Cheverst et al], er et kontekstbevisst hypermedia informasjonssystem for bærbare enheter utviklet av Distributed Multimedia Research Group ved Department of Computing, Lancaster University. Systemet fungerer som en kontekst - og lokasjonsbevisst turistguide for byen Lancaster, England, og er et samarbeid mellom universitetet og Tourist Information Center (TIC) i Lancaster Brukere Systemet er tiltenkt for bruk av turister i byen Lancaster. Turister kan få utdelt en bærbar enhet klargjort for bruk ved Tourist Information Center i byen Bruksområde Turistene kan få informasjon om steder og severdigheter i Lancaster basert på hvor de befinner seg i byen, og eventuelle interesser de måtte ha som turister. Systemet kan også brukes til billettbestilling og reservasjoner. 6

7 3.1.3 Funksjonalitet Hovedfunksjonaliteten til GUIDE er å presentere kontekstriktig turistinformasjon om severdigheter og attraksjoner i Lancaster, basert på lokasjon og brukerprofiler. Den gjør dette ved å vise informasjon i en modifisert web browser på en mobil enhet. Filtreringsfunksjoner basert på informasjonsmodellen vil rangere de nærmeste attraksjonene basert på ulike kriterier som nærhet til attraksjon og åpningstider. Når en turist med en GUIDE enhet kommer innen rekkevidde av en aktuell severdighet vil han få den reelvante informasjonen presentert på skjermen. Hvis flere attraksjoner er like i nærheten vil turisten få listet opp attraksjonene slik at han selv kan velge hvilken han ønsker å se nærmere på. Hvis turisten ønsker å få informasjon om steder og attraksjoner han for øyeblikket befinner seg langt unna, støttes dette gjennom et fritekstsøk, som vil returnere informasjon på samme måte som for den automatiske visningen. Turister kan generere omvisninger med GUIDE ved å velge hvilke severdigheter de ønsker å besøke. Systemet beregner da en rute mellom severdighetene basert på bl.a. hvilken rute som vil være mest naturskjønn å følge og hva som er mest tidsbesparende, og viser så denne ruten for turisten. Etter hvert som man følger denne ruten vil systemet lokalisere hvor man er på ruten og vise aktuell informasjon på veien. Hvis turisten ønsker å overstyre den genererte ruten kan han gjøre dette ved og selv velge rekkefølgen på severdighetene, og systemet vil generere nye ruter basert på dette. En interessant funksjon som er bygget inn i dette systemet er muligheten til interaktivitet. Turister kan for eksempel reservere hotellovernattinger eller kjøpe billetter til turer og utstillinger gjennom GUIDE systemet. Siden dette systemets bruksområde strekker seg over en hel by, og lokaliseringen baserer seg på lokasjonsceller, er det designet for å kunne brukes i offline modus, dog med begrenset funksjonalitet. Dette gjøres ved at store deler av informasjonen, og da helst den statiske informasjonen, er lagret lokalt i den bærbare enheten. Når enheten er innenfor dekning vil den sjekke etter oppdateringer av informasjonen for det området den befinner seg i og laste ned denne. På denne måten kan deler av systemet fortsatt brukes selv om man ikke har dekning. Turisten kan også velge å angi hvor han befinner seg ved å velge mellom en rekke bilder som representerer stedene i rundt området hvor han sist ble lokalisert Presentasjon Som nevnt bruker GUIDE en modifisert web browser for å vise informasjonen. Det ble også forsøkt å gi systemet en vennlig personlighet slik at man skulle føle seg mer fortrolig med det og kunne interagere med det som om det var en virkelig guide. GUIDE ønsker derfor turistene hjertelig velkommen, og når de forlater et sted blir de ønsket velkommen tilbake ved en senere anledning. Vanligvis for brukergrensesnitt design anbefales ikke slik antropomorfisk oppførsel av en datamaskin. Men i dette tilfellet har besøkende turister uttrykt at de følte seg forsikret om at systemet gjorde jobben sin. Dette var da helst for ikke-tekniske besøkende og nybegynnere til systemet. For mer vante brukere vil dette valget være mindre passende. Siden dette systemet også fungerer til dels selv om det ikke har forbindelse til server er det implementert en signalindikator lik den man finner på en mobiltelefon for å signalisere til brukeren om han har dekning eller ikke. På denne måten vet alltid brukeren hvilken funksjonalitet han kan forvente av systemet til enhver tid. Han må for eksempel ha dekning for at det skal være mulig å bruke de interaktive tjenestene. 7

8 3.1.5 Teknologi GUIDE systemet er satt sammen av en rekke webservere som hver tjener sitt område av byen. De er utstyrt med trådløse aksesspunkter som kjører IEEE standarden på 2.4GHz radiobåndet. Disse støtter en overføringshastighet på 2 Mbps per enhet. Hver server holder informasjon om sin del av byen og dens attraksjoner, og får oppdateringer og dynamisk innhold via fastlinjer til den sentrale GUIDE webserveren. For å oppdatere innholdet brukes en standard PC for laste opp ny og oppdatert informasjon. Posisjoneringen skjer ved at de mobile enhetene mottar lokasjonsinformasjon som sendes fra strategisk posisjonerte basestasjoner. Denne fremgangsmåten ble valgt fremfor GPS først og fremst fordi det trengte ingen ekstra maskinvare, og fordi det i områder med mye bygninger og andre hinder gjorde det vanskelig å lokalisere enhetene fordi de ikke hadde fri sikt til et tilstrekkelig antall satellitter for posisjonering. Informasjon i systemet Siden utviklerne av systemet bedømte at eksisterende informasjonsmodeller var utilstrekkelige for å representere slik kontekstsensitiv informasjon, bestemte de seg for utvikle sin egen. De hadde fire kriterier som denne informasjonsmodellen måtte kunne dekke: Informasjonen måtte kunne reflektere nåværende kontekst. Med andre ord kunne reagere på hendelser i og utenfor systemet for å holde brukeren oppdatert. Må kunne holde geografisk informasjon og geografisk referert informasjon. Må kunne holde hypertekst informasjon, enten gjennom adresser for globalt bruk, eller ved lokal lagring av informasjonen. Må kunne støtte aktive komponenter som er i stand til å lagre tilstand, og å utføre bestemte handlinger eller imøtekomme spørringer. Modellen ble delt inn i to distinkte deler: Environment Model User Model Environment Model inneholder informasjon om attraksjoner og steder. Den holder informasjon som beskrivelse, tilstand, URL til ekstern informasjon, lokasjoner i nærheten og andre relaterte lokasjoner, og kontekstinformasjon (for eksempel om dette er et historisk sted, maritimt, spisested, underholdning o.l., som kan knyttes opp i mot brukerens interesser). User Model inneholder informasjon om brukeren, personlig informasjon (navn, kjønn, alder), interesser, historie (logg over besøkte steder). Dette knyttet opp i mot informasjonen i Environment Model og lokasjonen skaper grunnlaget for kontekstbevisstheten til systemet. 3.2 TouristGuide TouristGuide [Todd Simcock et al] er et lokasjonsbasert turistguide system bygget av hovedsakelig hyllevare maskinvare og programvare. Denne applikasjonen er et resultat av hovedoppgaven til Stephen Hillenbrand og Todd Simcock i Information Technology Software Engineering ved University of South Australia i Implementasjon av systemet ble støttet av Motorola og tatt i bruk ved Mawson Lakes campus ved University of South Australia og North Terrace precinct i Adelaide sentrum. 8

9 3.2.1 Brukere Systemet er beregnet for turister og besøkende i Adelaide sentrum og universitetet i Sør-Australia. Bruksområde: De besøkende kan finne ut hvor de befinner seg i forhold til interessante steder og attraksjoner, bli guidet rundt i området og få informasjon om severdigheter Funksjonalitet TouristGuide har delt funksjonaliteten til systemet inn i tre distinkte moduser som brukeren kan velge å benytte. Map Mode: Denne modusen består av et kart hvor brukeren kan se hvor han befinner seg i forhold til strukturer og attraksjoner rundt seg. Systemet beregner posisjon og tegner en prikk på kartet hvor brukeren befinner seg. Man kan også velge å få vist bestemte fasiliteter på kartet, som for eksempel telefonkiosker, kafeer, barer, toaletter o.l. Denne modusen kan også kjøres uten lokalisering, og brukeren har da muligheten til å peke/klikke på hotspots på kartet for å få opp informasjon, slik at han slipper å måtte dra til den fysiske lokasjonen for å få tilgang til informasjonen. Guide Mode: Når brukerne benytter denne modusen vises en rute på kartet som følger et sett med interessante relaterte attraksjoner. Attraksjonene er merket på kartet, og når brukeren kommer i nærheten av en attraksjon går den automatisk over i attraction mode. Attraction Mode: I denne modusen presenteres informasjon om attraksjonen til brukeren i form av lyd, bilder og tekstlige beskrivelser i små fokuserte kapitler. Mens brukeren beveger seg rundt vil denne informasjonen hele tiden oppdatere seg for å gjenspeile informasjon om stedet brukeren befinner seg. Systemet har også lagt til rette for enkel skaping av ny ruter og attraksjoner, noe som var et av designmålene for systemet. Målet vårt var å utvikle et rammeverk som ville være svært enkelt å bruke å tilpasse til nye lokasjoner for folk som ikke har en skikkelig IT bakgrunn, ifølge Hillenbrand Presentasjon: TouristGuide benytter en PDA, til å presentere informasjon for brukeren. For å spore brukeren er den koblet til en GPS mottaker. Valget med å benytte en liten håndholdt enhet som en PDA har sine fordeler med tanke på mobilitet, men skaper også store utfordringer når det gjelder brukergrensesnitt og presentasjon av informasjon. Fordeler inkluderer bl.a. at det er enkle enheter som er lette å håndtere. De har få knapper, og det meste av interaksjonen med enheten går via touch screen (trykkfølsom skjerm), noe som overlater det meste av ansvaret for interaksjonen til designeren/utvikleren av applikasjonen. Et av designkriteriene for systemet har derfor vært og kun vise et minimum av, og bare den mest essensielle, informasjonen på skjermen til enhver tid. Som nevnt er systemet delt inn i modusene "map mode", "guide mode" og "attraction mode" som hver presenterer forskjellige lag med informasjon til brukeren. Map mode viser grafisk hvor brukeren er i forhold til omgivelsene. Ved å benytte en nedtrekksmeny får brukeren muligheten til å velge visning av forskjellig informasjon på kartet. Guide mode gjør noe av det samme, men inkorporerer visning av ruter og en automatisk overgang til informasjon om attraksjonene i nærheten. Attraction mode viser tekstlig og billedlig informasjon om attraksjonene av og til kombinert med lyd. Attraction mode viser informasjon 9

10 gjennom HTML sider på skjermen. Egne maler for hvordan denne informasjonen skal presenteres er lagret i systemet. Hvis brukeren ønsker mer informasjon om attraksjonene kan han bla videre ved hjelp av piltaster nederst på skjermen. På denne måten kan brukeren selv avgjøre graden av informasjon han ønsker for hver attraksjon, og man unngår å overvelde brukeren med informasjon. Dette gir et ryddig og effektivt brukergrensesnitt Teknologi TouristGuide systemet baserer lokaliseringen av brukeren på GPS teknologi. Dette fungerer tilstrekkelig siden systemet kun skal fungere i et utendørs miljø. TouristGuide har ingen sentral server, hele systemet er inkorporert i den mobile enheten. All informasjonen ligger lagret i hver enkelt klientenhet, og blir aksessert når GPS koordinatene stemmer over ens med lokasjonen. Dette legger en begrensning på muligheten til dynamisk og oppdatert informasjon. Dette er derfor et av de videre designmålene for systemet. Økt kapasitet i den bærbare enheten med tanke på lagring og prosessering for å håndtere rikere multimedia er også et videre mål for systemet Informasjon i systemet Informasjonsmodellen som blir benyttet i TouristGuide er enkel men effektiv. Et kart for et område blir lagret i form at en bildefil. Koordinater blir lagret for attraksjoner og hot spots. Informasjon om hot spots kan aksessers ved å klikke på bygninger/objekter i map mode. Attraksjoner er severdigheter som inngår som en del av en omvisning i guide mode. Begge viser detaljert informasjon i attraction mode. Både attraksjoner og hot spots lagres med fire sett GPS (x, y) koordinater som danner en firkantet polygon. For attraksjoner blir dette gjort ved at man fysisk stiller seg på det som skal være et hjørne i polygonet og velger å lagre koordinaten for dette punktet. Dette gjør man for hvert av de fire punktene som skal omgi attraksjonen. Det blir så lagret en fil for attraksjonen med disse koordinatene. For hot spots merkes også disse punktene av rundt det aktuelle stedet, men det gjøres på skjerm ved å markere koordinatene på kartet. For hver attraksjon lagres det informasjon i form av en HTML side. Denne informasjonen inkluderer en overskrift/tittel for attraksjonen, et bilde av selve attraksjonen og en tekstlig beskrivelse på opp til femti ord. Denne sparsomme informasjonsmengden støtter opp om prinsippet om og til enhver tid kun vise den mest essensielle informasjonen. Brukeren har mulighet til å gå dypere inn i informasjonen ved å klikke seg videre med piltaster. 3.3 Context-Aware Adaptation in a Mobile Tour Guide Utgangspunktet i denne artikkelen [Ronny Kramer et al] er å lage en dynamisk tur guide (DTG) som leder turister dit de vil og gir dem informasjon om hva de måtte oppdage underveis. Brukeren må lage en interesseprofil, velge startposisjon, sluttposisjon og ønsket varighet på turen. Dette sendes over til serveren som genererer en nær-optimal rute bestående av ett antall destinasjoner, kalt tur bygge blokker (TBB). Man vet at turister ofte blir distrahert vekk fra en planlagt rute. Kanskje finner de en annen attraksjon eller begynner å handle i butikk. Man oppdager avvik fra den planlagte ruten ved avvik over en viss grenseverdi, og beregner deretter en ny rute basert på hastigheten brukeren beveger seg i og gjenværende tid. 10

11 For at brukeren ikke skal trenge se på skjermen hele tiden ser de for seg at brukeren skal navigeres fram til riktig sted ved hjelp av stemmeangivelser på hodetelefoner. Ettersom man ofte kan bevege seg inn mot en destinasjon fra flere retninger ser de for seg at man får opplest forskjellig informasjon ettersom hvilken retning man kommer fra. Bygning X dukker snart opp til Y hvor Y kan være venstre eller høyre. De legger til grunn tre typer kontekst: 1. Personlig kontekst interesser, ganghastighet, nåværende posisjon 2. Lokal kontekst adressen man oppholder seg, vær 3. Tjeneste kontekst severdigheter i nærheten, utstillinger, åpningstider, om det er ledige bord ved nære serveringssteder For å kunne plukke ut de mest interessante destinasjonene så foretar man semantisk sammenlikning. Man bygger først opp en hierarkisk ontologi bestående av en rekke foreldre- og barnklasser. Alle destinasjoner knyttes så opp alle de klasser som best representerer destinasjonen. Brukeren oppretter en interesseprofil ut fra samme ontologi, slik at man kan beregne interesse treff poeng (IMP) for hver enkelt destinasjon. Direkte treff gir full poengsum, mens samme foreldreklasse men forskjellige barnklasse gir halv poengsum. Ettersom beregning av optimal rute er svært ressurskrevende (NP-komplett problem / omreisende handelsmann) har de forsøkt dybde-først-søk for å finne en nær-optimal rute innen 5 sekunder. De har avdekket at ved å plukke ut 10 destinasjoner ut fra 1000 destinasjoner, så vil interesse treff poeng (IMP) man oppnår innen 5 sekunder maksimalt bli redusert med 7 %. Løsningen gwalk er utviklet basert på innholdet av denne artikkelen av de samme forfattere. 3.4 P-Tour A personal Navigation system for Tourism Artikkelen [Atsushi Maruyama et al] diskuterer løsning som generer en nær-optimal rute basert på startposisjon / tidspunkt, rangering av viktigheten på aktiviteter, avstand mellom destinasjoner, ønsket tid på destinasjonene og ønsket sluttposisjon / tidspunkt. Å finne optimal rute er kjent som ett NP-komplett problem (omreisende handelsmann). Man har på forhånd brukt A* algoritmen [R. Korf] til å beregne korteste rute mellom alle enkeltdestinasjoner og lagret dette i en database. Klient applikasjonen sender startposisjon, listen over destinasjoner (med viktighetsgrad og ønsket tid), sluttposisjon/tidspunkt til en server for generering av rute. Man har valgt å bruke en genetisk algoritme [J. H. Holland] for å finne kandidater til ruten. Man har så sammenliknet beste kandidatrute etter 10, 20, 50 og 100 iterasjonen med den optimale ruten. Man har funnet ut at uavhengig av lengden på ruten så avviker den nær-optimale ruten funnet innen 5 sekunder fra den optimale ruten med under 2 %, noe som man regner som tilfredsstillende. Man har også laget en algoritme for å detektere kontekstskifte. Dette kan skje dersom man beveger seg utenfor ruten, hvis forsinkelser gjør at man ikke kan nå neste destinasjon i tide. Dersom kontekstskifte er oppdaget sender man nåværende posisjon og en liste over ikke-besøkte destinasjoner til serveren som beregner en ny rute. 11

12 3.5 Context-Aware Content Filtering & Presentation for Pervasive & Mobile Information Systems De fleste systemer vi ser på er interesseområde-tilpassede løsninger hvor man legger inn spesifikke regler ut fra kunnskap om interesseområdet. I denne artikkelen [Kaijian Xu et al] ser man istedenfor på muligheten for å lage en generell løsning som kan fungere på vilkårlige informasjonstyper. Måten dette gjøres er at man hele tiden logger brukerkontekst i forhold til bruk av systemet. Aktuell brukerkontekst som logges er terminaltype (PC eller mobiltelefon), posisjon, tidspunkt (klokkeslett, dag i uken) og hvordan brukeren bruker systemet / tilpasser systemet. Man velger å lage en kube i en OLAP-database hvor hver konteksttype blir en dimensjon, for hurtig å kunne analysere den store informasjonsmengden slik logging vil medføre. Ettersom man regner nyere loggdata for å bedre representere nåværende situasjon enn gamle data, bør man vekte nyere data høyere eller fjerne gamle data. 3.6 Relatert til vår egen løsning, Android Sightseeing I forhold til vår egen løsning Android Sightseeing, kunne man se for seg at man logger hvordan turister forflytter seg (posisjon og tidspunkt). Man vil f.eks. kunne observere at mange turister oppholder seg lenger tid i området rundt slottet / slottsplassen. På denne måten kan man lære hvor de mest populære turistdestinasjonene er, hvor lang tid man bruker på en destinasjon, hvordan man beveger seg mellom destinasjoner og populære tider (som f.eks. åpningstider) ved en destinasjon. Vi har vurdert at for vår turistguide vil dette ikke være noen god måte å finne fram til mulige turistdestinasjoner, ettersom disse allerede er allment kjente. Vi velger istedenfor selv å bygge en database med aktuelle aktiviteter basert på tilgjengelig turistinformasjon. Vi vil likevel vurdere å benytte logging og analyse av loggede data, i forhold til å avdekke typiske brukermønster. Dette for å forbedre datakvaliteten i vår database. 3.7 Oppsummering Vår erfaring etter å ha gjennomgått en rekke studier innen mobile kontekstavhengige tjenester, er at mange har sluttprodukter som er tilnærmet like. Deres innfallsvinkel til løsninger kan derimot være fra ulike ståsteder. Vi tror at ved en å se en løsning fra ulike synsvinkler vil dette føre til en større forståelse og innsikt i både brukers behov for løsninger og hva slags problemstillinger produktet skal løse i hverdagen. 4 Teknologi Vi har i vårt prosjekt Android Sightseeing valgt å utvikle en tjeneste på Andoid plattform som har en åpen kildekode. Vi ønsker å beskrive i lys av de diskusjoner, debatter og evalueringer som har vært ved bruk av åpen eller lukker kildekode, hvorfor vi i etter en evaluering valgte en plattform med åpen kildekode. 4.1 Åpen kildekode og fri programvare Åpen kildekode (open source) er en samlebetegnelse for systemer hvor gjenbrukbare resultater av programvare-utvikling blir gjort åpent tilgjengelig for alle. Noen velkjente eksempler på denne typen programvare er operativsystemet Linux, web-serveren Apache, nettleseren Firefox. 12

13 Fri programvare (Open source Community) er i følge Richard M. Stallman en ideologi som omfavner mer en bare programmering. Det handler like mye om frihet, kunnskapsdeling og samarbeid. Miljøene rundt fri programvare har i mange år brukt verktøy for deling av kunnskap, først og fremst programkode, men også for utveksling av tanker, ideer og dokumentasjon. Et mye benyttet verktøy for slikt samarbeid er wiki, en programvare som gjør at mange brukere kan legge inn informasjon et sentralt sted om ett eller flere temaer. You see, the purpose of science and technology is to develop useful information for humanity to help people live their lives better. If we promise to withold that information - if we keep it secret - then we are betraying the mission of our field -Richard Stallman Richard M. Stallman regnes å være opphavsmannen til the free software movement". Han hadde på begynnelsen av 80-tallet en idé om å utvikle et komplett operativsystem, til fri benyttelse. Stallman skrev et manifest, en invitasjon til andre om å bli med i prosjektet, og grunnla deretter GNUprosjektet med den hensikt å utvikle et operativsystem, med en mengde tilhørende applikasjoner. Stallman regnes som personen bak de mest utbredte frie lisensene, GNU General Public License Hvordan velger stadig flere selskaper å utvikle programvare for åpne kildekode? «Det generøse mennesket» av den danske forfatteren Tor Nørretranders forsøker å gi en forklaring på hvorfor vi mennesker faktisk er grunnleggende sjenerøse. Vi er sosiale vesener som fra naturens side er skapt for å samarbeide og dele. Han mener det handler om gleden ved å gi og dele. Nørretrander beskriver et menneskesyn langt mer positivt enn det vi er vant til å få servert. Han bruker biologien som argumentasjon når han hevder at vi mennesker langt fra er så egoistiske, kortsiktige og kyniske som økonomer, politikere og media ofte vil ha oss til å være. Det økonomiske mennesket med sin rasjonalitet lever side om side med det sjenerøse mennesket, vareøkonomien side om side med gaveøkonomien Hvorfor åpen kildekode? Åpen kildekode er programvare som distribueres under forutsetning av at også kildekoden skal gjøres tilgjengelig for brukerne, i motsetning til programvare som utelukkende distribueres i binærform, der kildekoden er opphavets strengt bevarte hemmelighet og i noen tilfeller også patentbeskyttet. Motivet for åpen kildekode er at brukerne får innsyn i hvordan programmet fungerer og følgelig kan rette feil og gjøre forbedringer. I tillegg kan man forsikre seg at programmet ikke inneholder udokumenterte funksjoner, noen brukere i det militære og andre følsomme sektorer er spesielt opptatt av. Prinsippet for åpen kildekode er at rettinger og forbedringer skal føres tilbake til opphavet og gjøres tilgjengelige for alle brukere. Dette skal gjøre at programmer distribuert som åpen kildekode raskere oppnår en høy grad av kvalitet, noe som igjen kommer alle brukere til gode. Åpen kildekode forutsetter at det er et stort fellesskap som bidrar til utviklingen. 13

14 Modellen ligger til grunn for blant andre operativsystemet Linux, verdens mest utbredte webserver Apache Web Server, e-posttjeneren sendmail og nettleseren Mozilla. Det finnes flere lisenser som tilfredsstiller kravene til åpen kildekode slik de er formalisert av organisasjonen Open Source Initiative (OSI), fra blant andre GNU og BSD (Berkeley Software Distribution). Kommersielle programvarehus mener åpen kildekode ikke passer til all slags programvare, blant annet fordi forretningsmodellen er mangelfull og fordi de ikke vil gi konkurrenter innsyn i forretningshemmeligheter nedfelt i koden. Noen kommersielle aktører, blant dem Microsoft, har iverksatt initiativ, gjerne kalt shared source, som i begrenset omfang og under bestemte forutsetninger kan gi utenforstående innsyn i deres kildekode. En av grunnene til at programvare som Apache-webserveren og nettleseren Firefox kan oppleves som sikrere enn de stengte proprietære alternativene, er av den grunn at kildekoden er tilgjengelig for alle og det derigjennom kan være er enklere å oppdage sikkerhets-hull, samt at flere kan utbedre feil som oppdages Raskere tetting av sikkerhetshull i åpen-kildekode-miljøet Sikkerhet ved hjelp av hemmeligholdelse (stengt kildekode) kan oppleves vanskelig i det lange løp. I slike programmer kan en mengde feil gjemme seg bort uten å bli oppdaget ettersom kildekoden ikke er allment tilgjengelig for programmerere. Selv for et team på Microsofts størrelse kan det være umulig å konkurrere med det åpne markedet og de tusenvis av utviklere som benytter åpen kildekode hver dag i prosjektene sine Gjør det enklere å samarbeide I situasjon hvor du har en spesiell programvare som trenger å kommunisere med en annen programvare kan det være lett å ende opp med å erstatte den fordi det ikke var mulig, enten fordi leverandøren ikke eksisterer lenger, at de har sluttet å støtte programmet, eller at de har et lukket format som ingen andre enn de som laget formatet aner hvordan fungerer. Disse problemstilinger kan løses enkelt ved åpen kildekode, der andre fora kan skrive programvare som kommuniserer med via eksisterende systemene, uansett hvor langt inn i fremtiden du bestemmer deg for å gjøre det, og uansett om programvaren opprinnelig var skrevet for å løse et slikt system eller ikke Deling av infrastruktur-kostnader er fornuftig Innenfor publiseringssystemer er infrastruktur nødvendig, men produserer ikke inntekter i seg selv. Det er tjenestene du legger til på toppen som gjør hele forskjellen og derfor er det fornuftig å dele denne infrastrukturen med andre firmaer. På denne måten kan hvert firma spesialisere seg i visse deler av infrastrukturen, og perfeksjonere tilnærmingen og implementasjon over lengre tid, samt at andre firmaer kan gjøre det samme med sine respektive deler av systemet Åpen kildekode gjør deg uavhengig av en spesifikk leverandør Med løsninger bygget på åpen kildekode kan det være større fleksibilitet når en skal velge en annen leverandør og dermed stå en friere til å bytte til den leverandøren som passer deg best. 14

15 5 Andoid plattformen Siden vårt valg landet på Android som klientplattform for vår tjeneste, og vil her utgreie de viktigste egenskapene ved plattformen. 5.1 Introduksjon Android-utviklingen er ledet av Google, med bistand fra Open Handset Alliance. Open Handset Allicance (Open Handset Alliance) består av 47 teknologi- og mobiltelefonselskaper. Målet til gruppen er å øke innovasjonshastigheten med hensyn til mobil programvare og maskinvare, å tilby en mer omfattende brukeropplevelse til en lavere pris. Man tar telefoner slik de er i dag, men gjør det mulig å tilpasse dem slik man kan gjøre på en skrivebordsdatamaskin. Android som plattform består av operativ system, ett applikasjonsrammeverk og nøkkelapplikasjoner. Figur 1 Samsung I7500 Utviklingsplattformen lisensieres under en Apache lisens, noe som betyr at den er åpen kildekode. Det er gitt ut en SDK (programvare utviklingspakke) for å støtte utviklingen av Android-applikasjoner. Alle Android-applikasjoner blir skrevet i programmeringsspråket Java. I tillegg er det lagt opp til bruk av XML, blant annet til konfigurasjon og for utforming av brukergrensesnitt. Informasjonen om Android kommer fra det offisielle nettstedet for Android. 5.2 Arkitektur Android sin arkitektur kan deles inn i fem deler: applikasjoner, applikasjonsrammeverk, bibliotek, Android kjøremiljø og Linux-kjernen. Android kommer med en rekke essensielle applikasjoner for en moderne mobiltelefon: e-post klient, kalender, kontaktliste, kart og nettleser. Tredjepartsapplikasjonene vil ligge under den samme delen av arkitekturen, og er altså likestilt med nøkkelapplikasjonene som følger med plattformen. Android-arkitekturen inneholder et rammeverk for applikasjoner. De sentrale applikasjonene fra Google, nevnt ovenfor, benytter seg også av dette rammeverket. Målet med dette laget i arkitekturen er å gjøre det enklere å lage applikasjoner. Rammeverket gjør det mulig for en applikasjon å dele sin funksjonalitet med andre applikasjoner. Android inkluderer også flere biblioteker, som er tilgjengelig gjennom applikasjonsrammeverket. Et par eksempler her er SQLite, en lettvekts databasemotor, en integrert nettleser basert på WebKit, biblioteker for akselerert 2-D og 3-D (OpenGL) grafikk, og mediabibliotek som støtter avspilling flere populære lyd- og videoformater. Android kjøremiljøet inkluderer et kjernebibliotek som inneholder det meste av funksjonaliteten man har tilgjengelig i programmeringsspråket Java. Hver Androidapplikasjon blir kjørt i sin egen prosess og som en egen instans i en Dalvik virtuell maskin, som er optimalisert for minnebegrensningene Android telefoner har. Det at Android har sin egen virtuelle maskin, gjør at applikasjoner skrevet for Android ikke er ikke kompatible med Suns virtuelle maskin og deres Java ME-plattform. Android er avhengig av Linux-kjerne versjon 2.6 for kjernefunksjonalitet som sikkerhet, minnehåndtering, prosesshåndtering, nettverkslag og drivere. Android støtter mobilteknologier i maskinvare som GSM, blåtann, EDGE, 3G, Wi-Fi, kamera, GPS, kompass and akselerometer. 15

16 Det som gjør Android ekstra spennende for utvikling av vår applikasjon er at den er tett integrert mot Google Maps, slik at man svært raskt og enkelt kan bygge videre på Google Maps sin funksjonalitet. I tillegg har alle Android telefoner innebygd kompass som gjør at man kan utvikle funksjonalitet hvor man f.eks. får opp informasjon om hver historiske bygning man ser når man snur seg rundt på ett torg. 5.3 Utviklingsverktøy Utviklingspakken til Android heter Android Software Development Kit (SDK) og som tilrettelegger bruk av de nevnte komponentene arkitekturen består av. Utviklingen av applikasjoner gjøres fra Eclipse IDE. Plattformen inkluderer også en emulator, verktøy for feilsøking, verktøy for å optimalisere minne og ytelse, samt eksempelkildekode for ett sett applikasjoner som benytter seg av ett vidt spekter av funksjonaliteten i Android 6 Android Sightseeing Vi ønsker å se nærmere på vår typiske bruker av vår mobile løsning Android Sightseeing. Vi har valgt å benytte anerkjente teknikker for definering av bruker (personas) og støtter oss på empiri fra forskning innen mobilbruk i ulike alderssegmenter [Halvorsrud Ragnhild, Natvig Jon E og Kvale Kvale (2006)] 6.1 Målgruppen Målgruppen er i utgangspunkt alle som er på storbyferie, men innefor denne totale gruppen finnes det visse identifikasjoner på våre typiske brukere Primærbruker Nedenfor har vi listet opp karakteristikk som vi mener definerer primærbrukeren: Ca. alder mellom år. Personer som er innovatører. Tidlig adapsjon av nye produkter. Personer som reiser ofte. Dette kan både være i jobb og privat. Høy utdanning. God økonomi. Personer som er impulsive og ikke langtidsplanleggere. 6.2 Data som understøtter valg av målgrupper Vi vil følger konvensjonene til Statistisk sentralbyrå (Ugreninov 2005): Seniorer: alle personer i alderen 50 år og oppover Eldre: alle personer i alderen 67 år og oppover Middelaldrende: personer i aldersspennet år Figur 2 16

17 6.2.1 Mobiltelefon Ca. 92 % av befolkningen i Norge hadde tilgang til mobiltelefon i Andelen som har tilgang til mobiltelefon blant de yngre eldre (67-79 år) ligger på ca. 70 % - langt lavere enn gjennomsnittet. Det går et markant skille mellom sekstiåringene (ca. 90 %) og syttiåringene (ca 70 %) når det gjelder tilgang til mobiltelefon. Når det gjelder bruk av mobiltelefonen har de eldre hatt en meget beskjeden utvikling i tidsrommet Andelen som hadde en privat mobilsamtale en gjennomsnittsdag i 2005 var på 21 % blant de yngre eldre, mot 60 % for gjennomsnittet. Men fra 2003 til 2005 kan vi se en økning på lik linje med gjennomsnittet i befolkningen. Innenfor dette tidsrommet er det den middelaldrende befolkningen som øker desidert mest. De eldre sender SMS i meget beskjeden grad, sammenlignet med befolkningen for øvrig. Andelen som sender SMS daglig blant sekstiåringene, syttiåringene og åttiåringene er på henholdsvis 43 %, 23 % og 11 %, mot 69 % totalt i befolkningen. Data om at det er et markant skille i mellom 60 åringer og 70 i mobile tjenester åringer mener vi understøter vårt valg av målgrupper som er opp til 66 år (Halvorsrud, R., Natvig, Jon E. og Kvale (2006) De middelaldrende (50-66) Fortsatt i full vigør Dette er en gruppe som nødig vil kalles eldre og som i høy grad er aktive. Denne gruppen utgjør 19,8 % av befolkningen i Norge, totalt personer Salz (2006) argumenterer for at teleoperatører bør ta seniorsegmentet mer på alvor. De fleste operatørene ser nemlig ut til å ha fokus på ungdomsgruppen, bl.a. med nye musikktjenester, med den følge at voksne kundegrupper føler seg lite hjemme i de tilbudene som finnes. Det virker som man ikke har innsett at kundegruppen over 50 år har vokst opp med de største musikalske legendene innen rock. Saltz siterer også fra en større markedsundersøkelse fra USA som hevder at telekommarkedet har potensial for en vesentlig vekst (7,7 %) ved å tilby seniorsegmentet tjenester som er innrettet mot kundenes virkelige behov. Figur 3 Andel personer med tilgang til egen mobiltelefon i forhold til alder (Evjemo et al. 2006) viser status for tilgang til mobiltelefon i 2006 innenfor ulike aldersgrupper. I gjennomsnitt sier over 92 % at de eier eller disponerer en mobiltelefon. Andelen personer som sier de kan låne en telefon er relativt uavhengig av alder. Tar vi med disse, stiger utbredelsen til nesten 95 %. Rundt 5 % oppgir at de aldri benytter mobiltelefon. De fleste av disse (2/3) finner vi i aldersgruppene over 60 år. Figur 3 Andel personer med tilgang til egen mobiltelefon i forhold til alder (Evjemo et al. 2006) 17

18 Det er et skille som eksisterer mellom 60-åringene og 70-åringene, der utbredelsen er henholdsvis 92 % og 70 %. På bakgrunn av disse data tror vi at det spesielt er viktig å være oppmerksom på den økende gruppen i segmentet år, som vi være en interessant målgruppe for mobile tjenester i tiden fremover. 7 Metode Vi vil se nærmere på metoder for identifisering av bruker, samt deres behov for mobile løsninger i hverdagen. Før vi starter utviklingen av nye produkter og løsninger er det viktig å ha klarhet i brukers behov. Gjennom slike behovsanalyser kan det blir det enklere å identifisere de fellestrekk og krav til funksjonalitet som er nødvendig for løsningen, og som igjen kan gjøre produktet til en suksess. 7.1 Designprosessen Figur 4 Interaksjonsmodell skisserer utviklingsprosedyren i designprosessen vår. Vi har i prosessen i stor grad støttet oss empiriske data og forskningsresultater innen fagfeltet [Marko Modsching et al (2006)] og ikke selv utarbeidet brukerundersøkelser og evalueringer. Dette grunnet manglende ressurser i form av økonomiske muligheter, samt begrenset tid. Et viktig moment I designprosessen er involvering av bruker. Det er alltid en avveining i hvor stor grad det er nødvendig og både praktisk og ressursmessig hensiktmessig med en sterk brukerinvolvering. Vi har i d tillegg benyttet teknikken personas som en erstatning for en reel bruker. Siden personas gir en dekkende beskrivelse av en reel bruker, mener vi denne metoden er dekkende i sin anvendelse. Det vi har vektlagt ved definering av personas er: Hvem er bruker? Hva er brukers behov? Figur 4 Interaksjonsmodell Videre har vi sett på fire basis aktiviteter i designprosessen (Figur 4 Interaksjonsmodell) som ansees som basiselementer: 1. Identifisere brukerbehov og etablere kravspesifikasjon 2. Velge mellom alternativer (evaluere) 3. Utvikling av produktet/ tjenesten 4. Designe en mulig løsning ((re)-design) 18

19 7.2 Identifisering av bruker Det er mange måter å identifisere brukers behov som ved brukertester, intervjuer av brukere, diskusjoner med interessegrupper og spørreundersøkelser. En av teknikkene som har fått en betydelig anvendelse er bruk av personas [Calabria, 2004]. Det vil si å definere en typisk bruker av produktet vårt som er representativ for sin gruppe. 7.3 Personas Julie 27 Julie Wilhelmsen 27 år er født og oppvokst i Oslo og bor nå i sin egen leilighet på Majorstuen. Julie er utdannet fysiker fra Universitet i Oslo og jobber til daglig ved Rikshospitalet i Oslo. Hennes store interesse er sport, både vinter og sommeraktiviteter og i særdeleshet dans. Hun har danset klassisk ballet siden hun var fem år og trener fortsatt tre ganger i uken. Julie var lenge i tvil om hvilke yrkesvalg hun skulle velge, men bestemte seg til slutt for å studere realfag som var hennes sterke fag. Da kunne hun ha dansen som en kjær hobby. Julie er en veldig positiv og impulsiv jente som gjerne tar ting på sparket. Hun har en stor venneflokk som hun er flink til å holde kontakten med og inviterer gjerne på lange middager ut i de sene timer. Reise og oppleve nye kulturer og gjerne innslag av shopping, er noe som Julie bruker mye av ferier og helger til. Storbyer i Europa og andre deler av verden er hennes fremste reisemål og gjerne med hele jentegjengen Hans-Petter 39 og kjæresten Anne 23 Hans Petter Knarvik 39 år, kommer opprinnelig fra Åndalsnes i Møre og Romsdal og har bodd i Oslo siden han startet sine studier ved Musikkhøyskolen som 22 åring. Hans Petter har hovedfag fra NMH i utøving improvisert musikk/jazz, med trompet som hovedinstrument. Han har vært utøvende musiker siden han avsluttet sine studier. Han er en anerkjent jazztrompetist, komponist og produsent. I tillegg er han en etterspurt solist både i Norge og utlandet og har storbyer over hele verden som sitt arbeidsfelt. Hans Petter har ikke rukket å stifte familie ennå. Hans kjæreste Anne og også musiker med fiolin som instrument. Utenom naturopplevelser hjemme i Norge er parets viktige inspirasjonskilde kunst og kulturopplevelser. Siden begge har mange reisedager i året og arbeidstidene ikke alltid er forutbestemte, syns de begge det er viktig å benytte hver ledig tid til kulturopplevelser i storbyen. 19

20 7.3.3 Per og Stine 55 og 54 år Per og Stine Hansen-Dahl bor i Asker utenfor Oslo. De traff på videregående og har vært sammen siden. Per er utdannet ingeniør og Stine er jordmor. Paret har tre voksne barn. De to eldste er ferdig utdannet og har flyttet hjemmefra. Den yngste gutten bor fortsatt hjemme i eneboligen i Asker. Etter mange år med ferier og helger der barna var førsteprioritet og altoppslukende, har Per og Stine nå fått tid til seg selv. De har god økonomi de kan tenke seg å bruke mer tid sammen til reiser, gjerne med kunst og kulturopplevelser. Per er teknofreak og har alltid de siste nye innen ny teknologi og bruker alle fasiliteter med stor iver.. 8 Utvikling av prototype for Android Sightseeing Vi vil utvikle et konsept for mobil sightseeing ved bruk av Android plattformen. Som en del av konseptet utvikler vi en applikasjon som skal fungere som en vandrende turistguide, en dynamisk guide som til en hver tid vi gi deg den informasjonen som er relevant i det området du befinner deg. Det vil også tilrettelegges en modul for interaksjon med brukeren Ny sightseeingtur Vår prototype består foreløpig av realistiske skjermbilder som viser applikasjonen i tenkt bruk. Første skjermbilde (Figur 5 Ny sightseeingtur) viser oppstart av ny sightseeingtur med utgangspunkt i Oslo sentrum. Her må man ta stiling til ønsket varighet på turen i form av estimert tid ved ganghastighet. Deretter får man opp ett sett med idogrammer som representerer forskjellige aktiveter som for eksempel museer, historiske bygninger, kulturelle institusjoner, etc. Som vist på skjermbildet så vil disse idogrammene være selvforklarende. Hele applikasjonen er optimalisert for å betjenes med fingrene, med ekstra store knapper og andre kontroller, som muliggjør bruk av applikasjonen mens man er i bevegelse. Når skjermbildet er ferdig utfylt trykket man på knappen for å starte turen. Applikasjonen vet hvor du befinner deg ved hjelp av posisjonering basert på GPS satellietter og / eller nærhet til basestasjoner. Figur 5 Ny sightseeingtur 20

21 De inntastede data samt inneværende posisjon sendes til serveren som beregner en optimal sightseeing rute i nærheten av der du befinner deg, basert på ønskede kriterier for varighet og aktiviteter. Ved generering av ruter kan vurdering fra brukere (stemmer) bli vektlagt. Oslo er bare ett eksempel, og tilsvarende dynamiske sightseeing turer vil generert uansett hvilken storby man befinner seg i Underveis i sightseeingtur Etter at man har startet en ny tur (beskrevet ovenfor) vil man få opp ett kart med sightseeing ruten (Figur 6 Kart). Dette kartet viser sightseeingturen i sin helhet med de aktiviteter man skal besøke underveis. Skjermen vil vise aktuell informasjon som for eksempel neste aktivitet, estimert tid/avstand igjen til neste aktivitet og estimert tid/avstand igjen av hele sightseeingturen (rullerende informasjon). Underveis i en sightseeingtur vil man se ett person ikon som viser nåværende posisjon. Figur 6 Kart Sightseeing ruten i eksempelet har følgende 6 aktiviteter: Ibsenmuseet (A) Nobelinstituttet (B) Litteraturhuset (C) Kunstnernes hus (D) National Theateret (E) Slottet (F) Ett problem med kartdata er at de er tilpasset bilnavigasjon, mens gående kan gå steder der det ikke er markert med veier. Dette vil gjøre at rekkefølgen på aktivitene ikke alltid vil være helt optimal. Og derfor må man også vurdere hvorvidt man skal vise ruten langs veier, eller kun vise en rett linje fram til det neste neste målet, hvor brukeren selv oppfordres til å finne en optimal rute mot målet På en aktivitet Figur 7 Aktivitet 21

22 Når man kommer til en aktivitet (Figur 7 Aktivitet) vil mobiltelefonen varsle om dette med lyd og/eller vibrering, og informasjon om aktiviteten vil fylle skjermen. Dette vil gjerne være informasjon som er innhentet fra aktivitetens egen hjemmeside eller åpne informasjonskilder som for eksempel WikiPedia og WikiTravel. Eksempelet (Figur 7 Aktivitet) viser informasjonen som kommer opp når man ankommer aktiviteten Ibsenmuseet (A) Vurdering Etter at man er ferdig med hver aktivitet vil det komme opp ett skjermbilde hvor man kan vurdere aktiviteten (Figur 8 Vurdering). Her gir man en karakter fra 1 til 5: Figur 9 Ibsen museet Bra Meget bra Meget dårlig Dårlig Middels I tillegg kan man legge inn en kommentar (valgfritt) før man stemmer (sender inn sin aktivitetsvurdering). Det vil være mulig å skru av aktivitetsvurderingen, men ettersom vi ønsker vurdering fra flest mulig brukere vil den i utgangspunktet være påskrudd. Figur 8 Vurdering 22

23 9 Liknende produkter En viktig del av forarbeidet før vi utvikler en ny løsning, er å undersøke om lignende produkter/ tjenester allerede er utviklet i det eksisterende markedet for mobile tjenester. For å skaffe oss en god oversikt over det til enhver tid gjeldende tjenester som finnes tilgjengelig, har vi søkt etter informasjon via internett, samt kontaktet fagpersoner innen forskningsfeltet., Klaus ten Hagen, gwalk og Ingvar Tjøstheim, Norsk Regnesentral. De produktene vi har definert som konkurrenter er produkter som er ferdig utviklet. 9.1 Google applikasjoner Google Maps (Google Maps)som med sin kobling til Wikipedia gir deg kartutsnitt med integrerte koordinatorer til Wikipedia for mer informasjon om severdigheter. Google Latitude (Google Latitude) er et sosialt nettverk basert på Google Maps som kan lastes ned for mobil (kommer på alle mobiler plattformer). Denne modulen gir deg mulighet for å kunne se hvor dine venner befinner seg via GPS posisjonering. 9.2 Android Market Android har en egen markedsplass. Alle som registrer seg som utviklere (koster USD25) kan publisere sine applikasjoner der. Reiseapplikasjoner på Android Market: And Nav AndNav er en navigasjonsapplikasjon som støtter veipunkter, satellittbilder, POI, favoritter, kontakter, 5-dagers værmelding, en "Hvor er jeg nå?"-funksjon og mye mer. Man kan også få gådireksjoner. Alt det rett ut av lommen Route-Sharing Produktet Route-Sharing leveres forhåndsinstallert på Android-telefonen G1 fra T-Mobile. Den er en integrert løsning på telefonen med en standard kart og tale for ruteinstruksjon gwalk gwalk tilbyr hjelp til tre ulike faser i en turist opplevelse: planlegging av en rute på forhånd (drøm) lokasjonsbasert informasjon, bilder, tale og hjelp til navigasjon underveis på turen (handling) muligheten for å lage en individuell dagbok fra turen (minner) Vi har vært i kontakt med Prof. Dr.-Ing. Klaus ten Hagen, en av utviklerne som står bak gwalk, og har også satt oss inn i hans forskning rundt kontekstbasert tilpasning av Mobile Tour [Guide Hagen, K. ten (2008)] Figur 10 gwalk i bruk 23