Lokasjons- og kontekstbaserte tjenester - Department of Computer ...

Lokasjons- og kontekstbaserte tjenester - Department of Computer ... Lokasjons- og kontekstbaserte tjenester - Department of Computer ...

17.11.2012 Views

4 PROTOTYPING 57 Figur 14: Fumble : Lokasjon. – Type: For enklere ˚a kunne gruppere og søke i tilgjengelig informasjon har Fumble adoptert type-begrepet fra Gazetteers. Dette gjør at det er enkelt ˚a finne alle tjenester som er knyttet til en type, og man trenger derfor ikke søke igjennom all informasjonen[16] for ˚a f˚a fram spesifikk informasjon. Funksjonen gjør det mulig ˚a opprette en ny type som øyeblikkelig blir tilgjengelig for ny informasjon (se punktet under). Fumble implementerer kun et niv˚a med typer, da dette viser hvordan en slik oppdeling er med p˚a ˚a gruppere informasjonen. Gazetteers deler opp i flere niv˚aer av typer, der første niv˚a gir et bredt søk, mens niv˚a lengre ned gir et smalt søk. – Legg til informasjon: Dette er den viktigste administrative funksjonen i informasjonsdelen. Ved ˚a fylle ut feltene under “Add information” knyttes informasjonen som blir lagt inn til den lokasjonen som er oppgitt. N˚ar en bruker befinner seg p˚a angitt lokasjon, vil informasjonen være tilgjengelig for brukeren (se punktet under). For ˚a legge inn informasjon, m˚a brukeren avgjøre om denne er av en type som allerede eksisterer, eller om det m˚a opprettes en ny type for denne tjenesten (se punktet over). Det viktigste steget i denne funksjonen er ˚a avgjøre p˚a hvilket niv˚a tjenesten skal være: Skal den alltid være tilgjengelig (global)? Eller skal den kun være tilgjengelig i et bestemt rom? Et feil valg her kan føre til at informasjon ikke kommer opp, eller kommer opp selv om brukeren ikke har nytte av den ut i fra gjeldene lokasjon. Det m˚a ogs˚a knyttes et navn til informasjonen, som skal beskrive hva slags omr˚ade informasjonen er ment ˚a dekke og hva slags type informasjon det er snakk om. Dette er tatt med for ˚a forenkle gjenfinningsarbeidet n˚ar informasjon eksisterer i systemet. Et siste punkt som m˚a være med er “Alternative description”. Informasjon kan ikke eksistere i systemet uten en alternativ beskrivelse. Grunnen til dette er at hvis det ikke

58 4 PROTOTYPING knyttes en URL til informasjonen, er det denne beskrivelsen som dukker opp i systemet. Her er det mulig˚a skrive inn flere linjer med informasjon (ved ˚a trykke enter i feltet), og for ˚a kunne legge inn dekkende beskrivelser. URL, som er det siste feltet, er et valgfritt felt. Hvis det eksisterer en webside for informasjonen eller tjenesten, kan denne legges inn her, hvis ikke s˚a kan den være blank. Hvis den er blank er det bare den alternative beskrivelsen som inneholder en beskrivelse av informasjonen. Knyttes det derimot en webside til informasjonen, kan brukeren enkelt klikke seg fram til denne (se punktet under). Denne koblingen til eksterne websider er viktig for at et slikt system skal integreres enkelt med eksisterende systemer. Det argumenteres for en slik kobling i [8]. – Tilgjengelig informasjon: Dette er den viktigste brukerfunksjonen i informasjonsdelen, og det er denne funksjonen en bruker ville ha hatt tilgang til i et ferdig system. Mesteparten av metodene beskrevet her er implementert for ˚a gjøre denne funksjonen tilgjengelig. Denne funksjonen gjør Fumble i stand til ˚a presentere hva som befinner seg “her”. Dette er alts˚a hovedfunksjonen i et kontekstavhengig system. Det ble valgt en tre-visning (tree view) som grunnlag for presentasjonen, fordi dette er foresl˚att som den beste m˚aten ˚a vise hierarkisk data p˚a i .NET. I tre-visningen finner vi igjen de samme niv˚aene som vi kjenner fra lokasjonsdelen, med unntak av “Campus” og lokasjonsnavnet. Grunnen til dette er at lokasjonsdelen antar at det er “Gløshaugen” det er snakk om som campus uansett, og informasjonsdelen opererer med relasjoner p˚a romniv˚a, ikke innad i rommene. Begge disse forskjellene ville ikke eksistert i et ferdig system. Funksjonen f˚ar lokasjon fra lokasjonsdelen av programmet, og benytter dette til ˚a avgjøre hva som skal presenteres som tilgjengelig informasjon. Global informasjon eller globale tjenester blir undersøkt først, det vil i praksis si at prototypen sjekker om det finnes noen relasjoner til “Campus”-niv˚aet. Dette blir gjennomført uansett, alts˚a uavhengig av om lokasjon er tilgjengelig eller ikke (avsnitt 6.4). S˚a sjekkes hvert niv˚a for relasjoner, først bygning, s˚a etasje og til slutt rom. Relasjoner som oppfyller kravet til posisjon blir hentet fra databasen og presentert i en tre visning (Tree view) som vist i Figur 15. • Nettleser: Siden det ble valgt ˚a presentere informasjon vha. websider og integrere Fumble mot andre webbaserte system, ble en nettleser implementert. Alternativt ville ha vært ˚a la gjeldende nettleser 26 p˚a klienten starte for ˚a presentere informasjonen\tjenestene. Ulempen ville da være at det kunne bli mange ˚apne nettlesere, og brukeren bli oversvømt av informasjon. Fordelen er at brukeren kan bruke den nettleseren de vanligvis bruker. Ved ˚a integrere en nettleser har programmet full kontroll over hva som blir presentert. 26 Gjeldene nettleser vil ofte være Internet Explorer, men kan ha blitt erstattet av feks. Opera eller FireFox.

4 PROTOTYPING 57<br />

Figur 14: Fumble : Lokasjon.<br />

– Type: For enklere ˚a kunne gruppere <strong>og</strong> søke i tilgjengelig informasjon<br />

har Fumble adoptert type-begrepet fra Gazetteers. Dette gjør at det er<br />

enkelt ˚a finne alle <strong>tjenester</strong> som er knyttet til en type, <strong>og</strong> man trenger<br />

derfor ikke søke igjennom all informasjonen[16] for ˚a f˚a fram spesifikk<br />

informasjon. Funksjonen gjør det mulig ˚a opprette en ny type som øyeblikkelig<br />

blir tilgjengelig for ny informasjon (se punktet under). Fumble<br />

implementerer kun et niv˚a med typer, da dette viser hvordan en slik<br />

oppdeling er med p˚a ˚a gruppere informasjonen. Gazetteers deler opp i<br />

flere niv˚aer av typer, der første niv˚a gir et bredt søk, mens niv˚a lengre<br />

ned gir et smalt søk.<br />

– Legg til informasjon: Dette er den viktigste administrative funksjonen<br />

i informasjonsdelen. Ved ˚a fylle ut feltene under “Add information”<br />

knyttes informasjonen som blir lagt inn til den lokasjonen som er<br />

oppgitt. N˚ar en bruker befinner seg p˚a angitt lokasjon, vil informasjonen<br />

være tilgjengelig for brukeren (se punktet under). For ˚a legge inn<br />

informasjon, m˚a brukeren avgjøre om denne er av en type som allerede<br />

eksisterer, eller om det m˚a opprettes en ny type for denne tjenesten<br />

(se punktet over). Det viktigste steget i denne funksjonen er ˚a avgjøre<br />

p˚a hvilket niv˚a tjenesten skal være: Skal den alltid være tilgjengelig<br />

(global)? Eller skal den kun være tilgjengelig i et bestemt rom? Et feil<br />

valg her kan føre til at informasjon ikke kommer opp, eller kommer opp<br />

selv om brukeren ikke har nytte av den ut i fra gjeldene lokasjon. Det<br />

m˚a <strong>og</strong>s˚a knyttes et navn til informasjonen, som skal beskrive hva slags<br />

omr˚ade informasjonen er ment ˚a dekke <strong>og</strong> hva slags type informasjon<br />

det er snakk om. Dette er tatt med for ˚a forenkle gjenfinningsarbeidet<br />

n˚ar informasjon eksisterer i systemet. Et siste punkt som m˚a være med<br />

er “Alternative description”. Informasjon kan ikke eksistere i systemet<br />

uten en alternativ beskrivelse. Grunnen til dette er at hvis det ikke

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!