INF5260 - Vår 2004

 

 

 

 

 

 

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.

  1. Konsistens i datainput transaksjoner
  2. Begrense kravene til input fra bruker
  3. Minimere bruk av korttidsminne
  4. Kompatibilitet av datainput med skjermbildet
  5. 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, Boston, USA

 

 

 


[1] Applikasjonsserver som f�lger med Sun One Studio 4.

[2] Klasse p� serveren som kan motta data fra klient over nett og sp�rre p� database.