moBillettTM
Et flybillettsystem for mobiltelefon
Gruppen:
Anita Andersen (anitaan)
P?l Backe (paalbac)
Therese
Engen (theree)
Mads Lien (madsl)
Thomas Viken (thomavik)
Rapportstruktur
1. Bakgrunn med undring
2. Fremgangsm?te
3. Kontakter
4. Veiledende tidsplan
5. Brukergrensesnitt
5.1. Begrensninger i brukergrensesnittet for
mobile enheter
6. Serversiden
6.1. Struktur
7. Klientsiden
7.1. Struktur
7.2. Skjermbilder (kommer i sluttrapport)
8. Unders?kelse (kommer i sluttrapport)
8.1. Utvalg
8.2. Resultater
9. Diskusjon (kommer i sluttrapport)
10. Konklusjon (kommer i sluttrapport)
11. Referanser
Bakgrunn
Den tr?dl?se teknologien har hatt en ekstremt rask utvikling over de siste ?rene. Stadig kommer det nye mobile tekniske innretninger som du bare m? ha. Mobiltelefonen er den mest kj?re og ogs? den som fikk det hele til virkelig ? ta av. Det har n? blitt s? vanlig med mobiltelefon at til og med bestemor har en i veska. Og du kan ikke bevege deg noe sted uten at du merker dem. De er overalt. De ringer p? bussen, p? kino, i butikken, i parken og under middagen p? en restaurant. Hvor enn folk befinner seg er det ? begrave nesa i sin nye Nokia eller Sony Ericsson helt n?dvendig og veldig akseptert. For ny telefon er noe man m? ha. I Norge bytter vi mobiltelefon gjennomsnittlig hvert 2. ?r. Den raske utskiftningen er vel ikke akkurat mot produsentens ?nske og man kan kanskje spekulere i om ikke dette er den tiden en vanlig telefon er laget for ? holde.
Uansett er markedet for mobiltelefoni og mobile tjenester enormt og voksende. Med ny teknologi tar man sikte p? at denne veksten vil fortsette. Stadig st?rre datamengder skal sendes og overf?ringshastigheten ?kes i takt. Dette ?pner for nye tjenester og bruksomr?der som kan treffe et st?rre og st?rre segment i markedet. Det finnes allerede et ganske stort utvalg av mobile tjenester vi har ? velge mellom. De mest popul?re er i dag kj?p av logoer og ringetoner via sms. Det kan imidlertid virke som om dette er i ferd med ? forandre seg. Telefonene blir kraftigere, de har mer minne, st?rre skjerm og er blitt betraktelig bedre p? grafikk og lyd. Dette legger grunnlaget for helt andre typer tjenester enn man er vant til fra tidligere. WAP, som kom i 1999, var et tidlig fors?k p? en teknologi som sikrer et mer grafisk grensesnitt. Det var en hard start med store investeringer som viste seg ? ikke v?re spesielt l?nnsomme. Det er vanskelig ? sette fingeren p? hva som skyltes dette, men kanskje det lille utvalget av tjenester og den d?rlige grafiske evnen til telefonene kan v?re noen av ?rsakene. Med WAP 2.0 (2001) begynner man endelig ? se en ?kende interesse og bruk. Det synes helt klart at et rikere grensesnitt er viktig og at grafikk er en stor faktor for ? oppn? dette.
Tidvis d?rlig forbindelse og en del noe useri?se tjenester er noe som gjerne assosieres med mobiltelefoni. Etter en massiv utbygging av mobilnettene og stadig nye tjenestetilbud kan det se ut som dette bildet er i ferd med ? snu. Sammen med ?kt sikkerhet p? dataoverf?ringer har mobiltelefonen blitt en p?litelig innretning for flere og flere. Med st?tte for Java i de fleste nyere telefoner har mulighetene ?pnet seg enda mer. Lokale applikasjoner, som kan tilby informasjon og funksjonalitet ogs? uten ? v?re p? nett er i ferd med ? finne sin posisjon i markedet. Denne teknologien gj?r det mulig ? tilby et utseende som likner mer p? Internettjenester, som de fleste av oss er kjent med fra f?r. Dette kan v?re noen av de viktigste faktorene n? det gjelder spredningen av nye mobile tjenester og bringer oss til v?r undring:
Kan man skape
troverdighet gjennom teknologi og grensesnitt?
Fremgangsm?te
For ? unders?ke gruppens problemstilling vil vi utvikle en prototyp for
flybillettbestilling. Denne prototypen skal gruppen teste p? et lite antall
brukere. Dette vil gi oss et grunnlag for ? gi et svar p? gruppens sp?rsm?l.
Samtidig vil vi holde kontakten med n?ringslivet og andre eksterne
kontaktpersoner.
Kontakter
Kjell Myksvoll, Telenor
Anders Spilling, Leder for terminalavdelingen, Telenor
Sigurd Sandvin, Informasjonssjef, Telenor
Carl St?rmer, Markedsdirekt?r, Norwegian
Kjersti Havsen, Braathens
Kari Aanonsen, Telenor (tidligere jobbet i Braathens)
Claes Kanold, SAS
Anders Kluge, UiO
Veiledende tidsplan
22. januar: Oppstart INF5260
Hver mandag kl. 14: moBillett prosjektm?te
12. februar: Innlevering prosjektskisse/undringsdokument
19. februar: M?te med Anders Kluge
3. mars: Tilbakemelding undringsdokument
29. mars: M?te med Anders Spilling, Telenor
1. april: Innlevering midtrapport
Uke 17: Ferdig prototyp
Uke 18: Gjennomf?re brukerunders?kelse
13. mai: Levere sluttrapport
Brukergrensesnitt
Gruppen fokuserer p? brukergrensesnitt. Spesielt med tanke p? hva som er viktig i et brukergrensesnitt for ? skape troverdighet overfor bruker. Det er grensesnittet bruker vil forholde seg til, og det er viktig at bruker har tiltro til interaksjonen med grensesnittet. Et lite troverdig brukergrensesnitt kan f?re til mindre bruk av applikasjonen. Dette blir spesielt viktig n?r applikasjonen gjelder pengetransaksjoner og betaling. Samtidig m? grensesnittet balanseres i forhold til funksjonalitet og kompleksitet. For mye funksjonalitet og kompleksitet kan gj?re brukergrensesnittet vanskelig ? bruke, og skape mistillit hos bruker. Samtidig ?nsker man alltid ? f? med all n?dvendig funksjonalitet. Under utviklingen av en prototyp vil gruppen, p? bakgrunn av v?rt fokus, bruke mindre tid til ? utvikle en sikker applikasjon, men mer tid p? ? utvikle et brukergrensesnitt som fremst?r som sikkert for bruker.
Gruppens hypotese er at av dagens kjente teknologier for mobiltelefoner egner J2ME seg best til utvikling av et troverdig brukergrensesnitt.?
Som utgangspunkt for gruppens brukergrensesnitt benytter vi Shneiderman?s (1997) 8 regler for generell design av brukergrensesnitt. I sluttrapporten vil vi ogs? reflektere over og vurdere brukergrensesnittet til gruppens prototyp i forhold til disse punktene.
1. Etterstreb konsistens.
I brukergrensesnitt er det viktig ? v?re konsistent i forhold rekkef?lge, menyer og knapper. Ogs? farger, skrift og layout b?r v?re konsistent.
2. Muliggj?r snarveier
Ved gjentagende bruk vil bruker ha behov for ? hoppe over enkle valg som ikke trenger ? gj?res hver gang.
3. Gi informative tilbakemeldinger
For hver handling som gj?res som f?rer til at en funksjon settes i gang b?r bruker f? informasjon om dette. Kravet til de informative tilbakemeldingene ?ker med kompleksiteten til funksjonen som utf?res.
4. Design dialoger med en klart definert slutt
Dialoger b?r grupperes slik at en sekvens med dialoger avsluttes f?r en ny p?begynnes.
5. Tilby enkel feilh?ndtering
Systemet b?r sikre at bruker ikke kan gj?re store feil. Hvis bruker for eksempel fyller inn en ugyldig verdi b?r han f? tilbakemelding p? hvilke verdier som er gyldige.
6. Tilby reversering av handlinger
Bruker b?r til enhver tid ha mulighet til ? angre p? en handling ved ? kunne g? tilbake til forrige steg, skjermbilde eller lignende. Hvis en handling ikke er reverserbar b?r det gj?res klart for bruker f?r handlingen utf?res.
7. Tilby bruker f?lelsen av kontroll
Bruker vil f?le seg mer komfortabel med og ha mer tillit til brukergrensesnittet hvis hun har f?lelsen av at hun selv har kontrollen og ikke programmet.?
8. Reduser bruk av korttidsminne hos bruker
Mennesker kan holde 7 +-2 ting i korttidsminnet. Dette tilsier at brukergrensesnitt b?r holdes s? enkle som mulig, og uten at bruker m? huske mange ting for ? utf?re handlinger.
Ben Shneiderman har ogs? noen holdepunkter for ? sikre god data input. Vi vil ta disse med i vurderingen under utviklingen av v?r prototyp.
- Konsistens i datainput transaksjoner
- Begrense kravene til input fra bruker
- Minimere bruk av korttidsminne
- Kompatibilitet av datainput med skjermbildet
- Fleksibilitet i forhold til brukerkontroll av datainput
Begrensninger
i brukergrensesnittet for mobile enheter
Mobile enheter har en del begrensninger i forhold til brukergrensesnitt. Den viktigste og mest utslagsgivende er sannsynligvis st?rrelsen. De aller fleste mobile enheter har sm? skjermer som vil begrense mulighetene i forhold til brukergrensesnitt. For eksempel er det f? mobiltelefoner i dag som kan vise mer en 4-5 linjer i et skjermbilde. I tillegg kan skjermoppl?sningen v?re begrenset. Dette m? selvf?lgelig tas hensyn til i utvikling av mobile applikasjoner. Et eksempel p? dette kan hentes fra Heath & Luff artikkelen ?Mobility in Collaboration? (1998) hvor det ble gjort fors?k med bruk av mobile enheter p? London Underground. Her fant man at skjermbildet p? den mobile enheten var for begrenset for arbeidet som skulle gj?res, og at man m?tte kombinere med andre artefakter for ? oppn? tilfredsstillende resultater.
Mobile enheter har ogs? begrensede muligheter for inntasting. De fleste mobiltelefoner har kun noen f? taster i tillegg til nummertastene. Det vil derfor v?re naturlig ? unng? inntasting av ord i den grad det er mulig.?
Mobile enheter har p? grunn av sin st?rrelse og vekt lite prosessor- og minnekraft i forhold til en PC. Man kan derfor ikke regne med ? kunne utvikle applikasjoner som er like komplekse som PC-applikasjoner
Serversiden
For ? f? et helhetlig perspektiv innen utvikling av mobile informasjonssystemer er det ?nskelig ? utvikle en enkel serverside i tillegg til en mer avansert klientside. I forhold til gruppens hovedfokus: ?Troverdighet basert p? brukergrensesnitt og teknologi? vil prosjektet konsentreres mer om utformingen av klienten enn serveren. P? en annen side vil serveren ha en sentral rolle for tydeliggj?ring av klientens kommunikasjon mot database. En viktig motivasjonsfaktor har, helt fra starten av prosjektet, v?rt ? tenke muligheter for ? utvikle en trelagsarkitektur med kommunikasjonsm?nsteret: mobil klient ? applikasjonsserver ? database.
?
Etter samtale med kontaktpersoner i n?ringslivet og etter prosjektgruppens eget ?nske vil det, i tillegg til utvikling, ogs? fokuseres sterkt p? rapportering av problemer og utfordringer underveis i prosjektet. Dette vil spesielt dreie seg om kommunikasjon mellom klient - applikasjonsserver og grensesnittproblematikk. Det vil ogs? v?re interessant ? se p? mulighetene som foreligger p? serversiden og p? kommunikasjonssiden i videre arbeid med mobile informasjonssystemer etter prosjektets slutt.
Serverens konkrete arbeidsoppgave i moBillett-systemet er ? ta imot foresp?rsler fra mobile klienter og behandle disse dataene. Deretter hente informasjon fra database basert p? klientens foresp?rsel og sende denne informasjonen tilbake til klienten. Scenarioet vil typisk v?re at klienten registrerer ?nsket avgangsby, ankomstby, tid for avreise, antall personer og evt. ?nske om returbillett til serveren. Serveren kobler seg opp og sender sp?rringer til databasen p? bakgrunn av data sendt fra klienten. Flight-nummer, tid, og pris returneres til klienten.
For ? muliggj?re kommunikasjon fra
mobil/emulator til server over nett benyttes det en applikasjonsserver, Tomcat[1].
Denne har til hensikt ? sikre kommunikasjonen og tilgangen p? Servlet [2]klassene
p? serveren. Teknologien og implementeringen av denne vil bli n?rmere beskrevet
i sluttrapporten.
Klient
???????????
Gruppen har
s? vidt begynt ? programmere en "smart" klient. Denne inneholder
brukergrensesnittet og forretningslogikken og er derfor relativt avansert.
Forel?pig har gruppen laget skjelettet til grensesnittet, og eksperimentert med
ulike layouts, menyvalg og skriftst?rrelser. Spesielt? er det vurdert? hvor knappene b?r v?re plassert og hvilke
muligheter for GUI som tilbys i J2ME. Det er tatt h?yde for reglene Shneiderman(1997) foresl?r for utforming av grensesnitt.
Disse kommer? til ? bli benyttet ved
videre utvikling. Det er viktig at designen fremmer sikkerhet og logikk. For
eksempel er det viktig at sidene? ligner
flyselskapets webside.
F?rste gang
brukeren skal ta i bruk programmet m? det lastes ned fra flyselskapets
nettside. Her vil brukeren registrere seg, og programmet blir sendt til
telefonen. Registreningssiden og nedlastingsfunksjonen kommer ikke til ? bli
implementert, ettersom denne delen vil bli lagt p? flyselskapets internettside.
S? vil brukeren taste inn et firesifret passord hver gang systemet? tas i bruk. Dette er en sikkerhetsprosedyre
for ? identifisere brukeren. Serveren tar seg av autentifisering av telefonen.
Etter identifiseringen kommer man til programmets hovedside der man kan
bestille flybilletter, se lagrede flyruter og lese info fra flyselskapet .
Etter man har foretatt en bestilling vil denne ligge lokalt p? telefonen, slik
at brukeren n?r som helst har tilgang til ? se den. Denne funksjonaliteten har
gruppen ikke implementert enn?. Har den reisende behov for det, skal det v?re
mulig ? lagre flyruter som foretas ofte under brukerens personlige profil.
Dette vil eventuelt bli implementert senere. Det er viktig at brukeren har
kontroll over sin egen bestilling. For ? st?tte dette har man blant annet
mulighet til ? g? tilbake til forrige side og f? beskjed om n?r bestilling og
betaling er foretatt. Brukeren m? ogs? kunne ta telefonen og motta sms uten at
bestillingsrutinen m? starte p? nytt.
Systemet
vil foreta feilsjekking? og gi
tilbakemelding ang?ende riktig inntasting av dato, klokkeslett, destinasjon, og
andre kritiske datafelter. For at brukeren skal slippe ? taste inn mye data
under bestillingen, har vi benyttet oss av "drop-down"
menyer der dette er mulig. Slike menyer er de fleste kjent med fra internett, og kan dermed f?re til at tilvenningsfasen til
programmet blir kortere.
Vi tenker
oss en del muligheter rundt ulike funksjoner, men begrensningene i? implementeringen er avhengig av kursets
varighet.?
Referanser
Luff,
P. and Heath, C. (1998). Mobility in Collaboration. In Proceedings of CSCW '98
November 14-18, Seattle
Shneiderman B. (1997) ?Designing
the User Interface: Strategies for Effective Human-Computer Interaction? 3rd
Edition, Addison-Wesley
Professional,