Undersøgelse og udvikling af mobil menustrukturer og manøvrering ved hjælp af accelerometer og touchskærm

Transkript

1 Undersøgelse og udvikling af mobil menustrukturer og manøvrering ved hjælp af accelerometer og touchskærm Forfatter: Michael Christian Valentin van Zanten Bachelorprojekt, 1. september 2009 Vejledere Jakob Eg Larsen Morten Proschowsky

2 Abstract This report deals with the blue skies investigation of mobile interaction and how to improve this. We discuss different ways of improving the interaction. Including redefining parts of the menu structure and implementing an accelerometer based interaction. The report includes different suggestions for accelerometer based interaction and weighs the pros and the cons, before selecting one to investigate further. The report explains in depth how the design goes from a low-fi - to a high-fi prototype and how the the different designs are tested by users. Finally the report finishes with a future work section that discusses how the design can be improved and other ways of improving interaction.

3 Resume I denne opgave gennemgår vi udviklingen af et blue skies udviklingsprojekt til en HTC Touch Diamond. Projektet er delt op i fire afsnit omkring udviklingen af vores produkt, et afsnit omkring fremtidigt arbejde og et afsluttende afsnit med en konklusion. De fire første afsnit beskriver hver især en iteration der er foregået i produktudviklingen. I første iteration førte testpersoner dagbog over deres mobilforbrug, som blev afsluttet med et ustruktureret interview. Ud fra disse interviews blev to koncepter udviklet til low-fi prototyper og diskuteret i en fokusgruppe. I anden iteration blev det ene koncept udvalgt på baggrund af fokusgruppens kommentarer. Low-fi prototypen for det valgte koncept blev videreudviklet og testet med verbal rapportering, specielt menustrukturen havde fokus i denne test. Med kommentarerne fra verbal rapportering blev prototypen overført fra papir til elektronisk udgave og den gik fra at være low-fi til high-fi, udviklet på en specialiseret platform. Brugerne var ikke tilfredse med konceptet, og der blev foretaget en brainstorming og tre nye koncepter blev fremlagt. Et af disse blev udvalgt og videreudviklet. Samtidig blev der eksperimenteret med tilt-baseret scroll i telefonbogen samt implementeret taktilt feedback i form af rystelser. Prototypen blev da testet udenfor laboratorium for at bedømme det i mere naturlige omgivelser. Det gav en række nye punkter, der kunne arbejdes videre med og som er beskrevet i fremtidigt arbejde.

4 INDHOLDSFORTEGNELSE 0. Introduktion Problemformulering Opgavebeskrivelse Første iteration Teori Processen Dataindsamling metoder Interview Fokusgruppe Spørgeskemaer Observation af brugere Kombination af metoder Analyse metode Definering af krav og kravspecifikation Designfase Brainwriting Skitsering af ideer Første dataindsamling Analyse af problem Valg af metoder til dataindsamling Diagram over telefonens opbygning Finde testpersoner Udforme første testrunde Pilottest Første dataanalyse Analyse af dagbog Analyse af interviews Opsamling Diskussion af metode Brugerkarakteristikker... 22

5 Målgruppe Personas Scenarier Formulering af Krav Design Brainwriting Skitsering af ideer Valg af design Kravspecifikation Diagram over kommende prototype Første Prototype Den fysiske prototype Funktionaliteten i prototypen Evaluering af første prototype Valg af metode Forberedelse Spørgsmål til evalueringen Analyse af evalueringen Resultater fra første iteration Første ide + andre ideer Anden ide Anden iteration Teori Free form gestures Prototyper Low fidelity prototyper High fidelity prototyper Sammenligning Anden dataindsamling Reformulering af krav & kravspecifikation Redesign Anden Prototype... 45

6 2.6. Evaluering af anden prototype Valg af metode Forberedelse Analyse af evalueringen Resultater fra 2. iteration Tredje iteration Teori High Fidelity prototyper PC Baseret Generel mobilplatform Specialiseret platform Teori om.net cf Tilt Hvordan måles tilt af telefonen? Bevægelser Tredje dataindsamling Valg af metode Udvikling af spørgeskema Pilottest Resultater fra spørgeskema Reformulering af krav & kravspecifikation Use cases Redesign Tredje Prototype menustruktur Brug af accelerometer Algoritme til at beregne tilt Algoritme til at beregne ryst Automatisk start af kameraet Forstørrelse af knapper ved tilt i glidende overgang Evaluering af tredje prototype Valg af metode... 66

7 Forberedelse Analyse af evalueringen Resultater fra 3. iteration Fjerde iteration Ideer Accelerometer Touchskærm Teori Anvendelse af tilt til scroll Redesign Fjerde Prototype Evaluering af fjerde prototype Analyse Resultater fra fjerde iteration Fremtidigt arbejde Taktil feedback Free form gestures Forbedringer af prototypen Start forskel I GVektor påvirker vinklen Understøttelse af konceptuel model Ufrivillige bevægelser Fokus skift ved tryk på fysisk knap Designets begrænsninger Afslutning Konklusion Referenceliste Artikler Links Bøger Appendiks A Første iteration Appendiks A1 Hovedspg til 1. dataindsamling Appendiks A2 Introduktion til dagbog

8 8.3. Appendiks A3 Checkliste til interview Appendiks A4 Resultater fra interview Appendiks A5 Brugerkarakteristikker Appendiks A6 Personas Appendiks A7 Liste af funktioner i telefon Appendiks A8 - Skitser Appendiks A9 Valg af design Appendiks A10 Kravspecifikation Appendiks A11 Diagrammer Appendiks A12 - Skærmbilleder første prototype Appendiks B Anden iteration Appendiks B1 Reformulerede krav Appendiks B2 Reformuleret kravspecifikation Appendiks B3 - Diagrammer Appendiks B4 - Skærmbilleder fra 2. prototype Appendiks B4 Opgaver til test Appendiks B5 Checkliste til interview Appendiks C Tredje iteration Appendiks C1 Spørgeskema Appendiks C2 Reformulerede krav Appendiks C3 Reformuleret kravspecifikation Appendiks C4 Use cases Appendiks C5 skærmbilleder fra prototype Appendiks D Fjerde iteration Appendiks D1 Skærmbilleder af prototype Appendiks D2 - Opgaver Appendiks D3 - Checkliste til interview Appendiks E Rå data 1. iteration Appendiks F Rå data 2. iteration Appendiks G Rå data 3. iteration Appendiks H - Rå data 4. Iteration Appendiks I Kildekode

9 Introduktion 1 0. Introduktion

10 2 Problemformulering 0.1. PROBLEMFORMULERING Undersøgelse og udvikling af mobil menustrukturer og manøvrering ved hjælp af accelerometer og touchskærm. Mobiltelefonen har i det senere år haft en enorm vækst i antallet af personer, der bruger den og til hvilke formål de bliver brugt. En moderne mobil kan langt mere end bare at modtage og foretage opkald. En typisk telefon indeholder funktionaliteter som f.eks. kalender, spil, browser, osv. Det stiller nye krav til mobil telefonens interaktion med brugeren. Samtidig er teknologier som accelerometer og touchscreen begyndt at blive standard i nye telefon modeller. Disse nye teknologier giver mulighed for en alternativ interaktion der bedre kan opfylde brugerens behov og krav. Vi vil undersøge folks interaktion med mobiltelefoner, hvor vi særligt har henblik på accelerometer og en touch brugerflade. Med udgangspunkt i undersøgelserne og de to teknologier, vil vi igennem en brugerorienteret udviklingsproces udarbejde en funktionel prototype til en mobiltelefon - der både har accelerator og touchskærm. Vi har følgende udviklingsmål med prototypen, prototypen skal: Være et forslag til en alternativ menustruktur og interaktion på en mobil brugerflade. Forsøge at gøre interaktionen med mobiltelefonen lettere at bruge Forsøge at gøre interaktionen med mobiltelefonen mindre opmærksomhedskrævende Afvikles på en HTC Touch Diamond Da målet er en funktionel prototype vil hovedparten af implementeringen være fuldført, dog med det forbehold, at der kan forekomme visse fejl, mangler og kompromis. En del af processen er også at sætte sig ind i.net(compact)-frameworket og programmeringssproget C# for at kunne udvikle til mobiltelefonen. Formålet med dette projekt er derfor at: Erhverve baggrundsinformation om folks brug af mobiltelefoner og deres forskellige funktioner Erhverve viden om folks interaktion vha. touchscreen og accelerometer Bruge den indsamlede viden til at formulere kravspecifikation og use cases Opstille en model med aktivitetsdiagrammer, klassediagrammer og FSM Udvikle en prototype på baggrund af ovenstående Foretage en evaluering af prototypen vha. brugertests Evt. gentage dataindsamlingen Videreudvikling af prototypen på baggrund af evalueringen og den evt. dataindsamling Denne proces vil blive gentaget et antal gange og udgør grundlaget for den iterative proces. I gennemløbet af hver enkelt iteration, vil use cases, kravspecifikation mm. blive revurderet

11 Introduktion 3 fra iteration til iteration. De vil derfor blive mere og mere specificerede, og kan derfor føre til ændringer i programfunktionalitet. Vores programdesign vil derfor tillade denne iterative designmetode. Vi vil derfor lægge stor vægt både på processen og den funktionelle prototype i processen og i rapporten. Projektet svarer til 15ECTS point pr deltager.

12 4 Opgavebeskrivelse 0.2. OPGAVEBESKRIVELSE Dette projekt bygger i høj grad på brugerinput. Vi vil derfor inddrage testpersoner igennem hele processen fra start til slut. Formålet med dette er, at tage udgangspunkt i deltagernes informationer, sammen med vores egen erfaring indenfor området samt vores tekniske viden. Erfaringer fra tidligere projekter siger at sammenkoblingen mellem disse, giver et bedre slutresultat end uden testpersonernes input. Hvordan processen igennem projektet vil være, vil blive beskrevet nærmere i starten af 1. iteration. Som kort oversigt over hele processen, er der herunder vist en oversigt over den endelige proces. Formålet med dette er, at kunne overskue hele processen fra start af. Dette er tilføjet til sidst i processen. Dataindsamling Prototype Evaluering Resultat Eventuelt 1. iteration 2. iteration 3. iteration 4. iteration Dagbog (1-2 dage) Skitsering af ideer fra brainwriting Papirprototype med enkelte sider, der viser de overordnede ideer Fokusgruppe til diskussion af valg af overordnet design En række kommentarer til hvordan vores ideer er, hvad der er vigtigt og deltagernes holdninger Diagram over original telefon Ingen dataindsamling Start med at tage beslutning om designet ud fra resultat fra evaluering. Fuld papirprototype Verbal rapportering med efterfølgende ustruktureret interview Kommentarer til prototypens overordnede ide og til designet. Diagram over opbygningen af vores program indtil videre Ingen dataindsamling. Indsamling af viden indenfor programmeringsteknikker vi bruger Elektronisk version af papir-prototypen fra 2. Iteration. Overordnede design er implementeret, med kendte mangler Verbal rapportering og efterfølgende interview Kommentarer til prototypen. Diagram over opbygningen af vores program indtil videre Ingen dataindsamling. Indsamling af viden fra artikler Elektronisk færdig prototype Verbal rapportering, test og efterfølgende interview Resultatet er et indtryk af hvor brugbart produk-tet er. Desuden også ideer til fremtidigt arbejde. Denne rapport illustrerer projektets proces kronologisk, og forklarer derfor hvilke skridt vi har taget samt rækkefølgen for disse. Efter beskrivelsen af de fire iterationer kommer et afsnit om fremtidigt arbejde og rapporten bliver derefter afsluttet med en konklusion.

13 Introduktion 5 I løbet af processen valgte min bachelorpartner at skifte uddannelse. Dele af rapporten er hovedsageligt skrevet af hende, og det må vi hellere kreditere hende for. De afsnit som Bettina Jørgensen overvejende har skrevet er: 5.1 Taktil feedback Touchskærm Samt sektionen omkring implementering af tilt i 4.4 Fjerde Prototype

14

15 Første iteration 7 1. Første iteration

16 8 Teori 1.1. TEORI PROCESSEN Udgangspunktet for denne proces er den simple interaktionsmodel, der itererer over det samme forløb gentagne gange for at optimere resultatet: Find krav behov og (Re)design Evaluering Lav prototype Færdige produkt FIGUR SIMPEL INTERAKTIONSMODEL [150 S. 448] Formålet med opgaven er, at lave en proof of concept prototype [112]. For at gå fra en ide til en brugbar prototype, skal der foretages et vist antal iterationer. I denne udviklingsproces har vi foretaget fire. Den første iteration bliver brugt til at danne et overblik over hvordan testpersonerne bruger deres mobiltelefon, samt generere ideer til designet af prototypen. Iterationen er vigtig, da det giver viden omkring hvordan folk generelt bruger deres mobiltelefoner, og danner et godt grundlag for det videre arbejde. Anden iteration vil blive brugt til, at omsætte ideen fra prototypen til en papirversion. Dette gør ideen visuel og samtidigt let tilgængelig for testdeltagerne. Derfor kan man let lave store ændringer i prototypen, hvis der er behov. Tidligere erfaringer siger desuden at brugere typisk vil komme med flere kommentarer til en low-fi prototype 1. I den tredje iteration vil vi omdanne prototypen til en elektronisk version. Formålet med denne iteration er, at bevise ideerne og pointerne i prototypen, og teste om de virker i praksis. Prototypen vil dog stadig ikke være fuldt implementeret, så der er stadig mulighed for større ændringer. Det er stadig de mest basale funktioner og ideer der er implementeret. I den fjerde iteration vil vi arbejde med kommentarer fra evalueringen i tredje iteration. De essentielle funktionaliteter er udviklet, og er klar til at blive testet. 1 Se afsnittet Low fidelity prototyper

17 Første iteration 9 Ved at gennemløbe disse fire iterationer er produktet bearbejdet i en sådan grad at man kan udtale sig om nytteværdien. Fordelen ved at arbejde på denne måde i iterationer er, at man vil kunne fortsætte arbejdet direkte i en næste iteration. Derfor bliver rapporten også afsluttet med et afsnit om fremtidigt arbejde indeholdende produktets væsentligste mangler og vores ideer til hvordan produktet skal videreføres.

18 10 Teori DATAINDSAMLING METODER Der findes en række forskellige metoder til anvendelse i en dataindsamling. Her vil vi præsentere en række af dem, forklare hvad de indebærer samt i hvilke situationer de vil være brugbare. Disse metoder er de samme, der senere vil blive brugt i evalueringsdelen. De forskellige metoder kan varierer mellem kvalitative kvantitative. En metode kaldes hovedsagelig kvalitativ, hvis dataindsamlingens resultat skal være meget detaljeret, men ikke nødvendigvis have mange forskellige personers svar. En analyse, der hovedsagelig er kvalitativ, kan derfor f.eks. bruges hvis man ønsker dybdegående kendskab til hvordan personer benytter webshops. En metode er hovedsagelig kvantitativ, hvis det er antallet af deltagende personer, der vejer mest. Det kan f.eks. være, hvis der skal laves en statistisk undersøgelse. Uanset metoden, er det altid en fordel, at foretage en pilottest. Dette betyder, at inden selve testrunden går i gang, bliver testen afprøvet på en testperson. På den måde, er det muligt, at få feedback inden selve testen, så der kan laves forbedringer. Dette spiller en stor rolle, f.eks. hvis man sender spørgeskemaer ud til mange mennesker. Der kan opstå fejl eller uklarheder, der gør, at resultatet fra undersøgelsen ikke er så brugbar som forventet. En pilottest fungerer altså som den almindelige test, udelukkende med en efterfølgende snak, om hvad der kan forbedres. For at kunne foretage analysen er det vigtigt at have dokumenteret svarene fra dataindsamlingen. Til dette formål kan man enten optage lyden (f.eks. til interview), videooptage, tage noter gennem forløbet, automatisk logs (til brug på computere eller telefoner) eller en kombination af disse. Det er altså ikke en bestemt metode, der altid er den bedst mulige. Det afhænger både af hvilken metode valgt til dataindsamlingen, og personlige præferencer INTERVIEW Interview er hovedsageligt en kvalitativ metode. Det er muligt, at gøre metoden mere eller mindre kvalitativ, ved at variere antallet af testdeltagere, men som regel er det ikke en særlig kvantitativ metode. Interview kan blive opdelt i tre undergrupper [150 s. 298]: Ustrukturerede, semistrukturerede og strukturerede. Det er ikke en klar opdeling, men kan derimod betragtes som et spektrum, der spænder fra ustrukturerede til strukturerede interviews. Et ustruktureret interview kan i høj grad betragtes som en samtale. Intervieweren har en række områder, der gerne skal diskuteres og har derfor forberedt en række åbne spørgsmål 2 til interviewet. I et ustruktureret interview vil både intervieweren og interview-deltageren kunne påvirke interviewet, og komme med nye inputs. Fordelen ved et hovedsageligt ustruktureret interview er, at man kan opnå en dyb forståelse for området. Desuden kan der dukke nye og uventede informationer op. Ulempen ved et ustruktureret interview er, at det er meget svært at analysere. Samtidigt er det svært at sammenligne med andre interviews, da alle interviews på denne måde vil være forskellige. 2 Åbne spørgsmål er spørgsmål, der lægger op til et dybdegående og detaljeret svar

19 Første iteration 11 Et ustruktureret interview vil være brugbart f.eks. i starten af en proces, hvor designet stadig er på ide stadiet og andre idéer stadig udforskes. Et struktureret interview er derimod mere som et mundtligt spørgeskema 3. Det er altså meget lukkede spørgsmål 4, ofte også med en række svarmuligheder. Der er derfor ikke som i et ustruktureret interview plads til diskussioner og længere udredninger, men det er udelukkende et simpelt svar der ønskes. Fordelen ved et struktureret interview er, at det er muligt, at få svar på nogle meget specifikke spørgsmål, hvilket man ofte ønsker senere i processen. Dette gør også, at svarene på spørgsmålene er meget nemme at sammenligne. På den måde er det muligt, at udtale sig kvantitativt om brugere. En ulempe er, at du ikke frit kan ændre/udvide interviewet, hvis svarene til spørgsmålene ikke er brugbare. Et struktureret interview vil derfor være brugbart til, at finde svaret på f.eks. et specifikt designspørgsmål. Som en kombination af strukturerede og ustrukturerede interviews er semi-strukturerede. Det er en metode, der inkluderer fordelene ved begge andre metoder. Interviewereren har derfor stadig en række spørgsmål, der er en kombination af både åbne og lukkede spørgsmål. Fordelen ved at benytte et semistruktureret interview er derfor, at man har en række faste spørgsmål, men samtidigt er det muligt, at lade interviewet udvikle sig i nye retninger. Desuden er det en brugbar metode til at lave undersøgelser, hvis man ikke helt er sikker på, hvilke ting er de interessante FOKUSGRUPPE Fokusgrupper er en forsamling af mennesker der diskuterer forskellige aspekter omkring et design. Metoden har sine ligheder med et interview og fokusgrupper er ligesom interview en overvejende kvalitativ metode. I en fokusgruppe består normalt af 3-7 personer, der bliver interviewet. Formålet med en fokusgruppe er derfor for intervieweren, at starte og lede en diskussion mellem deltagerne. Det er vigtigt at der bliver opbygget en indbyrdes dialog mellem deltagerne og de ikke primært henvender sig til intervieweren. Derfor er vigtigt at overveje hvilke personer, en fokusgruppe består af. Dels for at sikre en god dialog hvor der ikke er nogen der overtager samtalen, dels fordi man typisk vil have forskellige mindre grupper i målgruppen repræsenteret. Fordelen ved en fokusgruppe er, at de spørgsmål der bliver stillet, måske på overfladen virker simple, men ved diskussion kan man få mange forskellige svar fra de forskellige personer. Man kan også nå en dybere diskussion ved at afholde disse grupper, end hvis man interviewede de enkelte personer hver for sig. 3 Se Spørgeskemaer 4 Lukkede spørgsmål er spørgsmål, der lægger op til præcise svar (ofte ja/nej eller et af på forhånd definerede svar)

20 12 Teori SPØRGESKEMAER Spørgeskemaer er hovedsageligt en kvantitativ metode, da man på den måde når ud til mange deltagere, og får derfor svar på de samme spørgsmål mange gange. Derimod er det ikke så brugbart som kvalitativ metode, da spørgeskemaerne i så fald vil være meget lange, og derfor vil deltagerne skulle bruge lang tid på at besvare dem. Spørgeskemaer er altså en metode, der er anvendelig, når man gerne vil have de samme relativt lukkede spørgsmål ud til en lang række mennesker. Ud over det, kan det også være en fordel at bruge spørgeskemaer, hvis man skal lave dataindsamling for personer, der rent fysisk ikke er tæt på. Ved at bruge spørgeskemaer, kan man derfor nemt nå sine målgrupper. En ting der er meget vigtig, når man bruger spørgeskemaer er udviklingen af disse. Det er meget vigtigt, at spørgeskemaerne er meget tydeligt formuleret, og at der ingen uklarheder. Det er den eneste af metoderne, hvor man som dataindsamler ikke har direkte kontakt til deltageren, og derfor er det ikke muligt, at udrede eventuelle misforståelser OBSERVATION AF BRUGERE Når man observerer brugere som dataindsamling, er det en hovedsagelig kvalitativ metode. Fra hver observationsrunde vil man få mange informationer om deltageren, men indsamlingen af data eller behandling af disse vil typisk også være tilsvarende mere tidskrævende. Observation adskiller sig fra andre metoder, idet man lægger vægt på testdeltageres handlinger og ikke deres udsagn. Det giver to store fordele. Data bliver registreret i nuet og resultaterne er derfor mindre påvirket af testdeltagernes hukommelse, og det er derfor mindre sandsynligt, at der opstår hukommelsesfejl 5 Testdeltagerens subjektive påvirkning af resultater kan ved nogle metoder kan helt elimineres, ved at lave en objektiv betragtning af handlingerne. Hvis der kun bliver brugt de andre metoder, risikeres der, at deltageren selv udelader detaljer, der kan være vigtige for dataindsamlingen og evalueringen. En tredje fordel er, at observation er et meget fleksibelt værktøj. Det kan derfor bruges i mange forskellige situationer og samtidigt også i hvilken som helst del af processen. Et af de steder, hvor man kan variere en observation meget, er i hvilket miljø den foregår. Det kan enten være i et kontrolleret miljø (i et lokale indrettet til sådanne tests) eller det kan være i et naturligt miljø (f.eks. på en station). Dette gør både en stor forskel, i hvordan testen skal forberedes og hvordan den bliver udført. Desuden giver de forskellige muligheder. I et kontrolleret miljø, har man mulighed for, at forberede i meget høj grad. 5 Se [152] for mere information omkring den menneskelige hukomelse

21 Første iteration 13 Samtidigt er der ro og ingen forstyrrende elementer under testen. Hvis man derimod afholder testen ude i mindre kontrollerede situationer, er det sværere at forberede hvordan testen bliver afholdt, men til gengæld får man nogle meget realistiske resultater af hvordan produktet bliver brugt. Ved software til mobiltelefoner spiller omgivelser en langt større rolle, end det ville gøre ved software til pc ere. Brug af mobiltelefoner foregår typisk simultant med andre oplevelser, som f.eks. at færdes i trafikken eller andre opgaver der tager en del af din opmærksomhed. Direkte observation Direkte observation er det ultimative feltstudie, hvor deltagere betragtes i deres naturlige omgivelser. Observatøren betragter brugere på offentlige steder og ser hvordan de interagerer med en given teknologi. Brugerne vil være tilfældige mennesker, der ikke er informeret om, at de bliver overvåget. Det giver det mest realistiske billede af brugen af et produkt. Desværre egner den sig dårligt til mobiltelefoner, dels fordi apparaterne er meget små og derfor svære at observere og dels fordi mobiltelefonen bliver betragtet som en meget personlig ting, og der derfor opstår et etisk dilemma for observatøren. Ud over det, kan man heller ikke få så mange informationer om, hvorfor personerne gør som de gør. Verbal rapportering Verbal rapportering er en test, der benytter observation. Det er dog lidt anderledes end udelukkende observation, da testdeltageren under testen skal forklare hvad personen gør, hvad formålet med handlingen er samt hvilken reaktion personen forventer. Deltageren fortæller altså under hele testen, så man kan følge med i handlingerne og forstå hvorfor personen gør sådan. Under testen vil det være muligt for testlederen at stille uddybende spørgsmål. Man skal dog være varsom, med hvor mange spørgsmål der bliver stillet, samt ikke at gøre det, så det forstyrrer testdeltageren. Dagbøger En måde at få observationer fra naturlige situationer er, ved at benytte dagbøger. På den måde kan testdeltageren notere i dagbogen hvor tit og hvordan opgaven bliver udført samt hvor svært det var. Fordelen ved at bruge en dagbogsmetode er, at man kan lave en undersøgelse, der dels kan strække sig over meget lang tid, men også kan være en test af opgaver man laver mange gange om dagen (af korte tidsperioder). Det er også en metode, der ikke kræver mange tekniske midler, og er simpel for alle at udføre. En anden fordel er, at man (i modsætning til f.eks. interview 6 ) ikke er ligeså afhængig af deltagernes hukommelse. Den mest markante ulemper ved dagbøger er, at det kræver en relativ stor indsats fra testdeltagerne, specielt hvis testen løber over en længerevarende periode, samt at deltagerne muligvis undlader at skrive detaljer ned, der er vigtige for undersøgelsen, men som i deres egne øje er ligegyldige. 6 Se Interview

22 14 Teori Interaktion logs En anden brugbar metode kan være, at logge data fra den testede applikation. Dette kan ske f.eks. på en computer eller en telefon, hvor man kan optage alt, hvad der sker. Metoden er meget anvendelig, hvis man f.eks. vil måle, om der er tidsmæssige forbedringer ved at tilføje features, eller hvis man vil have informationer om, hvad der er sket i applikationen (hvad der er trykket på osv.) En fordel ved at bruge denne metode er, at man ikke forstyrrer deltageren mens testen foregår. Derfor kan personen koncentrere sig fuldt ud, uden forstyrrelser. Ud over det, giver det nogle meget præcise resultater, der kan sammenlignes direkte (f.eks. hvis det er tidsintervaller der bliver målt). Det gør det selvfølgelig samtidigt til en større opgave at analysere dataen KOMBINATION AF METODER Som nævnt er de forskellige metoder brugbare i forskellige situationer. Dette betyder dog ikke, at der kun er én metode, der er den bedste. I mange situationer er en blanding af flere metoder bedst. Det kan f.eks. være en kombination af en kvantitativ metode og en kvalitativ. Det kunne også være en kombination af f.eks. en observation med et efterfølgende interview. Ved at udnytte forskellige metoders styrker på denne måde, kan man tit få mange informationer, der ellers var gået tabt ANALYSE METODE Eftersom dataindsamlingen var opdelt i kvalitative og kvantitative metoder, vil dataanalysen naturligvis være afhængig af typen af metode. Hvis metoden er kvantitativ, består analysen af, at behandle de indsamlede data vha. matematiske redskaber og statiske analyser. Hvis den benyttede metode derimod er kvalitativ, er analysen anderledes. Som start er det vigtigt, at danne sig et overordnet indtryk af den indsamlede data. Det er muligt, at der allerede fra start af har vist sig nogle mønstre. Det er dog vigtigt, at få underbygget disse mønstre fra data fra indsamlingen DEFINERING AF KRAV OG KRAVSPECIFIKATION En af de essentielle dele i udarbejdelsen af et design, når man arbejder med brugerorienteret udvikling er, at opstille en række krav. Disse krav er krav fra brugernes side. Det vil altså sige, overordnede krav, som løser brugernes behov. Disse er vigtige at have med, da processen tager udgangspunkt i brugernes behov og ønsker. For at formulere disse krav, er det vigtigt at forstå så meget som muligt om brugerne, deres ønsker, deres behov og hvordan det udviklede produkt løser problemer i deres hverdag. Dette ender i en liste, der overordnet beskriver brugernes krav. Ud over det er det en fordel, at formulere en kravspecifikation. En kravspecifikation er, i modsætning til listen af krav, krav direkte til produktet. Den indeholder derfor mange

23 Første iteration 15 forskellige typer af krav Funktionelle krav, miljømæssige krav, brugervenlighedskrav, osv. Det er altså en lang og detaljeret liste, der tilsammen formulerer hvordan programmet skal se ud. Det er en prioriteret liste, der indeholder en lang række punkter. Det er dog vigtigt at pointere, at det ikke er alle kravene i kravspecifikationen, der skal løses i det endelige produkt. Det skal nærmere ses som en plan for, hvordan produktet ville være, hvis der ingen tidsbegrænsninger var på projektet. Både kravspecifikationen og listen af krav bliver revurderet i hver iteration. De vil derfor både blive længere eftersom der opnås en større mængde viden og mere detaljerede efter forskellige designideer bliver afprøvet hos testdeltagere DESIGNFASE BRAINWRITING Brainwriting i den form vi benytter os af det minder i teorien om brainstorming. Formålet med de to metoder er i hvert fald det samme. Formålet er, at komme med så mange ideer på så kort tid som muligt i en gruppe. Dette inkluderer derfor både brugbare og ikke-brugbare ideer. Hovedformålet er bare, at komme frem til så mange ideer som muligt. Forskellen mellem de to metoder er dog, hvordan disse ideer kommer frem. I en brainstorming sidder hele gruppen (dette fungerer kun i grupper) sammen og siger alle ideer højt, mens én person skriver alle ideerne der bliver sagt ned. Dette er en meget brugbar metode, da man i fællesskab kan finde på en masse ideer på kort tid. Der er dog også nogle ulemper, der kan opstå ved at bruge denne metode. Det er f.eks. at personen, der noterer ideerne har svært ved at komme med egne ideer. Andre ulemper kan være, at andre personer i gruppen kan have svært ved at komme til orde eller at nogle ideer kan gå tabt, da ideerne ikke bliver skrevet så hurtigt op, som de kommer. Derfor bliver der nogle gange brugt en anderledes metode, brainwriting, der tager højde for nogle af disse ulemper. I brainwriting sidder hver person i et givent tidsinterval, og skriver alle ideer ned på små kort (som vist Figur Brainwriting, hvor gule post-it s er brugt). FIGUR BRAINWRITING Ideen er så, at få skrevet så mange kort som muligt i den tidsperiode. Formålet med øvelsen er altså at opnå det størst mulige kvalitative udbytte. Når tiden er gået, præsenterer personerne deres egne ideer på kortene, der så bliver samlet til en stor mængde af ideer. Disse kan så blive brugt til beslutning af design. Fordelene ved denne metode er, at den i modsætning til brainstorming giver alle deltagerne plads til, at komme til orde. Desuden giver det tid til hver enkelt ide kan blive skrevet ved, og først til sidst blive præsenteret i gruppen. Derved løser brainwriting de ulemper brainstorming kan have. Modsat kan

24 16 Teori brainwriting have den ulempe, at man derved ikke på samme måde bruger hinandens ideer til, at komme videre med. Dette vil dog ikke være så stort et problem, hvis man efter præsentationen af ideerne arbejder videre med dem, og tager alle nye ideer, der kommer efterfølgende med SKITSERING AF IDEER Efter brainwriting (eller brainstorming) er resultatet en lang række ideer. Det er som regel mange meget forskellige ideer. Mange af dem er ikke andet end bare en tanke, der i virkeligheden ikke er meget gennemtænkt. Derfor er det vigtigt, for at kunne arbejde videre med dem, og kunne formulere et design ud fra dem, at få dem uddybet. For at visualisere ideerne, kan det derfor være brugbart, at skitsere hver ide for sig. Skitseringen indebærer derfor en forklaring af ideen. Et eksempel på en sådan skitse er Figur eksempel på skitse. FIGUR EKSEMPEL PÅ SKITSE Skitsering af ideer gør det dels nemmere formidle ideen ud til andre mennesker, da visuelle forklaringer ofte er lettere at forstå. Ud over det, giver selve det at tegne skitsen mulighed for en gennemtænkning af ideen. Ideerne fra brainwritingen er ofte meget overordnede og uigennemtænkte. Derfor giver det en naturlig mulighed for, at gennemtænke hvordan ideen skal være og hvad formålet med den skal være. Desuden giver skitserne ligeledes et godt udgangspunkt for sammenligning af ideer. Visualiseringerne gør at, der nemt kan diskuteres og derfor også sammenlignes. Dette danner et godt grundlag for valg af design af prototype.

25 Første iteration FØRSTE DATAINDSAMLING ANALYSE AF PROBLEM Formålet med den første iteration er, at danne os et overblik over testdeltagernes brug af egne mobiltelefoner, og ud fra det udvikle et overordnet design. Hovedspørgsmålet i denne iteration er derfor: Hvordan bruger testdeltagerne mobiltelefonen og dens funktioner samt hvilke generelle problemer opstår i interaktionen? For at besvare dette spørgsmål, startes der med en analyse af problemet. Spørgsmålet bliver derfor delt op i underspørgsmål, der tilsammen giver svaret på hovedspørgsmålet. Disse underspørgsmål er stadig overordnede spørgsmål, vi gerne vil have svar på (og derfor ikke direkte spørgsmål til brugerne): - Hvilken baggrund har deltageren - både personlige oplysninger og erfaring med mobiltelefoner? - Hvilke funktioner bruger deltagerne mest i egne telefoner? - Hvor ofte bruges de forskellige funktioner? - Problemer med telefonen i tidligere situationer - Forslag til løsninger for vores projekt ud fra egen telefon - Ønsker til hvilke funktioner der skulle være nemmere på deres egen telefon - og som er vigtige at have med i vores Disse underspørgsmål er inddelt i yderligere i direkte spørgsmål til testdeltagerne (vedlagt Appendiks A1 Hovedspg til 1. dataindsamling). Disse spørgsmål vil blive brugt i dataindsamlingen. Billedet til højre viser de forskellige spørgsmål under analysen. Det er ikke alle underspørgsmål, der kan omsættes til direkte spørgsmål til brugeren. De spørgsmål må besvares på en anden måde. FIGUR POST IT'S MED SPØRGSMÅL I det næste afsnit, vil vi foretage valg af hvilke metoder der vil blive benyttet i dataindsamlingen VALG AF METODER TIL DATAINDSAMLING For at bestemme metoden (metoderne) til brug i dataindsamlingen, tager vi udgangspunkt i spørgsmålene fra analysen af problemet. Som dataindsamling vil en kvalitativ metode i denne situation give os det bedste resultat, da det ikke er et statistisk svar vi er ude efter, men udelukkende tendenser og deltagernes personlige kommentarer. En del af spørgsmålene er dog ikke lette for en person at svare på, hvis spurgt direkte. Det

26 18 Første dataindsamling kan dels skyldes, at deltagerne aldrig har overvejet emnet, eller at det ville have krævet at man holdt regnskab for at få den viden. Man risikerer at svarene er upræcise og farvede af deltagernes egne ideer, hvis de udelukkende stammer fra interview. Ud over det, kan vaner i deltagernes brug af mobiltelefonen påvirke deres svar, så værdifulde informationer og detaljer kunne blive udeladt. Det er derfor nødvendigt, at benytte sig af en metode, hvor man kan observere brugeren imens han/hun bruger telefonen i "naturlige" omgivelser (Se Observation af brugere). En faktor, der er vigtig at inddrage, er tidsbegrænsning. Som nævnt tidligere kan observationer være uhyre tidskrævende. Det gælder især ved mobiltelefoner, hvor brugen er sporadisk og spredt over hele dagen. Situationen er den, at vi ønsker kvantitativ information om folks mobilbrug, uden et stort tidsforbrug for os som observatører. Derudover er der en række af kvalitative spørgsmål, vi ønsker svar på. I denne situation bliver de optimale resultater opnået ved at kombinere de to metoder dagbog og interview. En dagbog ville i dette tilfælde være en notesbog, testpersonerne skulle have med i løbet af 1 eller 2 dage, hvor testdeltagerne skriver ned, hver gang de bruger telefonen. De skal derfor skrive ned hvilken funktion de bruger, og hvordan de bruger den. Ud fra det, giver det dels deltageren grundlag til at forklare brugen af mobiltelefonen, samt giver testafholderen bedre indblik i deltagerens brug af mobiltelefonen. I et ustruktureret interview vil vi efterfølgende udnytte den erhvervede viden. På baggrund af testdeltagernes beskrivelser og oplevelser kan vi udforme spørgsmålene til interviewet. For at gøre svarene fra dagbøgerne så brugbare som muligt, er det også nødvendigt, at indkredse mulighederne for testdeltagerne. Hvis der ikke er retningslinjer for hvad, der skal skrives og hvordan, vil det kunne være meget uoverskueligt for deltagerne og risikoen for vigtig data går tabt øges. Derfor er en vigtig ting, at udforme en god vejledning/introduktion. På den måde kan man forklare brugeren, hvorfor det er vigtigt, at alle informationer bliver skrevet ned, og hvordan det skal gøres. Introduktionen kan ses i 8.2 Appendiks A2 Introduktion til dagbog DIAGRAM OVER TELEFONENS OPBYGNING For at danne os et overblik over hvordan en telefon kan være opbygget, har vi taget udgangspunkt i en HTC Diamond touch 7. Ud fra denne telefon, har vi lavet et diagram over alle funktioner og navigations muligheder. Ud fra det vil vi dels foretage nogle overvejelser om, hvordan vi vil lave vores menustruktur, og dels også finde ud af, hvordan vores program 7 Man kan læse mere om telefonen på [111]

27 Første iteration 19 skal "sættes ind" i telefonen. Det er tydeligt at den nuværende interaktion i telefonen er yderst kompleks. Der er utroligt mange valgmuligheder, hvilket blandt andet skyldes brugen af Windows Mobile platformen. Diagrammet er vedlagt i 8.11 Appendiks A11 Diagrammer FINDE TESTPERSONER For at få bedst mulig udbytte af vores første dataindsamling, skal vi vælge de testpersoner, hvor vi kan få mest mulig data ud fra de metoder, vi har valgt at bruge. I vores valg af testpersoner har der derfor været to aktuelle kriterier. Vi ønsker: Testedeltagere der bruger mobilen mere end bare sporadisk. Enkelte mobilbrugere har et meget lille mobilforbrug. Ved at fravælge disse, får vi mere og bedre data da uregelmæssigheder er mindre sandsynlige i en large sample. Testdeltagere med et vist kendskab til mobiler og til nye mobilteknologier. Disse brugere vil bedre kunne relatere til de teknologier, vi har valgt at arbejde med og evt. også kunne hjælpe os med ideer til det kommende produkt, vi skal udvikle. Vi ønsker derfor en overvægt af testpersoner, der har en udvidet viden indenfor brugen af mobiltelefoner og har erfaring indenfor området. For at opfylde dette, har vi valgt, at hovedparten af vores testdeltagere er studerende på vores egen retning (Softwareteknologi). Begrundelsen for det er, at de studerende på denne retning alle har en god teknisk baggrund, og ofte også har nyere mobiltelefoner, som de bruger i hverdagen. Vi har valgt at bruge 6 testdeltagere i denne dataindsamling, samt en pilottest. De fire af seks er studerende på DTU, en person arbejder som it-supporter og en ergoterapeut. Deltageren i pilottesten studerer også på Softwareteknologi-retningen UDFORME FØRSTE TESTRUNDE Til dagbogdelen af testen, skal der laves en grundig introduktion, som instruerer deltagerne i hvordan de skal bruge dagbogen, og hvilke ting der skal noteres. Introduktionen kan læses i 8.2 Appendiks A2 Introduktion til dagbog. Som opfølgning på dette, har vi besluttet at foretage et mindre ustruktureret interview. I det giver vi deltagerne mulighed for, at komme med ønsker og holdninger til hvordan en mobiltelefon skal være opbygget. Checklisten til interviewet kan ses i 8.3 Appendiks A3 Checkliste til interview PILOTTEST Som start på testen har vi valgt at lave en pilottest. Formålet med pilottesten er, at finpudse vores test. Det kommer i dette tilfælde ikke til at være en "hel test", da princippet i testen er det samme, uanset tidsperioden. Derfor er der skåret ned på selve dagbogdelen, så dagbogdelen udelukkende løber over 1-2 timer. Efter pilottesten er der foretaget mindre ændringer i vores introduktion til testen.

28 20 Første dataanalyse 1.3. FØRSTE DATAANALYSE I den første dataanalyse er formålet, at omdanne den viden vi har fået fra dataindsamlingen til en liste af krav fra brugeren til vores første prototype. Den første del af analysen består af en kort opsummering af de resultater, vi fik fra dataindsamlingen. I den anden del drages der overordnede konklusioner ud fra de tendenser, der er fundet i dataindsamlingen. Dette vil resultere i en række brugerkarakteristikker, scenarier og personas. Det leder derfor op til næste afsnit, som er opstilling af krav samt kravspecifikation ANALYSE AF DAGBOG For at danne os et overblik over hvilke funktioner telefonen hovedsageligt bliver brugt til for vores testpersoner, vil vi se på hvilke ting der oftest er blevet noteret i dagbogen. Derfor har vi lavet et skema over de forskellige ting, både pr. testperson og et samlet antal. t1 t2 t3 t4 t5 t6 i alt Se klokken SMS Internet Foretog opkald Modtog opkald Ændre tilstand Bruge alarm Radio ANALYSE AF INTERVIEWS For at kunne danne os et overblik over hvilke tendenser, der har været i interviewet, sammenlignes svarene på de enkelte spørgsmål på tværs af interviewene. Der bliver set bort fra de irrelevante spørgsmål, som f.eks. alder, stilling. Andre spørgsmål er blevet slået sammen, da de forekom ens og testdeltagerne ikke kunne skelne mellem dem. Vi har ikke inkluderet kommentarer/ønsker til tekniske ting på den enkelte telefon. Resultaterne fra interviewene er vedlagt i 8.4 Appendiks A4 Resultater fra interview.

29 Første iteration OPSAMLING Ud fra denne dataanalyse har vi dannet os et overblik over, hvilke funktioner der hyppigst bliver brugt, samt hvilke ting testdeltagerne fandt vigtigst at have på telefonen. På baggrund af det vil vi i næste afsnit, forsøge at drage nogle overordnede generaliseringer, hvor der ud fra deltagernes svar vil blive lavet nogle brugerkarakteristikker og fastlagt en målgruppe, produktet er rettet mod DISKUSSION AF METODE I denne dataindsamling er der blevet brugt en kombination af dagbog og interview. Formålet med det var, at give deltagerne mulighed for at overveje hvordan de bruger mobiltelefonen og derved have god baggrund til et interview. Ud over det, kan det også give et sandfærdigt billede af, hvordan telefonen i virkeligheden bliver brugt. Det er ikke sikkert, at deltagerne selv er klar over, hvor meget de bruger den og hvilke funktioner der bliver brugt mest. Metoden var meget brugbar. Testdeltagerne skulle føre dagbog i 1 døgn. Vi vurderede, at hvis der skulle bruges flere dage på det, så ville det tage så meget af deltagernes tid, at det blev besværligt. Grunden til dette er, at det er ekstra arbejde, hver gang man bruger telefonen. Hvis det blev for meget arbejde, kunne man risikere, at der ikke ville blive ført dagbog hver gang, eller at hver note ikke bliver uddybet helt. Det ville medføre tab af mange nyttige informationer, som testdeltagerne ville kunne finde irrelevante, og derfor ikke ville notere. Tilbagemeldinger fra alle testdeltagere var positive, det vil sige at det ikke var til stor gene at føre dagbogen. Vi mener at metoden var brugbar og resultater fra denne gode.

30 22 Første dataanalyse BRUGERKARAKTERISTIKKER Brugerkarakteristikkerne er opdelt i 5 forskellige brugere: Den teknisk begejstrede bruger, Den seriøse bruger, Medarbejderen, Den øvede bruger og Teenageren. To af brugerkarakteristikkerne: Teknisk begejstret bruger - Bruger telefonen meget i hverdagen - Ønsker at telefonen skal kunne tilpasses i høj grad - Stor teknisk viden - Bruger mange forskellige funktionaliteter i telefonen - Bruger også telefonen som underholdning - Synes det er vigtigt, at telefonen har et pænt udseende år Den seriøse bruger - Bruger telefonen meget i hverdagen - Stor teknisk viden - Synes teknisk funktionalitet er vigtigst - Bruger mange forskellige funktionaliteter i telefonen - Bruger udelukkende telefonen til praktiske ting år Alle brugerkarakteristikkerne er vedlagt i 8.5 Appendiks A5 Brugerkarakteristikker

31 Første iteration MÅLGRUPPE Målgruppen for produktet bliver valgt med udgangspunkt i brugernes behov og forventninger. Det er derfor ikke nødvendigvis alle de beskrevne brugergruppe, der vil indgå i målgruppen. Grundet valget af en telefon med indbygget touchskærm og accelerometer, forventer vi at brugerne af vores produkt skal have telefon af en sådan type. Ud over det, forventer vi også, at brugerne har erfaring i brugen af mobiltelefoner. Disse kriterier udelukker automatisk den uøvede bruger fra målgruppen. Der er desuden lagt vægt på, at det ikke er et redskab, der skal bruges for at gøre telefonen mere praktisk at bruge. Det skal lægge op til, at være en sjovere og nemmere at bruge. Derfor bliver medarbejderen også udelukket af målgruppen. Vi har valgt, at målgruppen skal bestå af de tre sidste personkarakteristikker: Teknisk begejstret bruger, Den seriøse bruger og Teenageren. På den måde rammer vi mange personer, der er vant til at bruge telefonen i mange forskellige sammenhænge. Samtidigt får vi også en gruppe, hvis krav og forventninger stemmer godt overens med vores egne forventninger til produktet PERSONAS Personas er en udmærket måde at skabe en affektiv forbindelse mellem udvikleren og brugeren. På denne måde gøres det nemmere for udvikleren at relatere til og definere en enkelt målgruppe ud fra en såkaldt prototype for denne. Denne prototype person gør det nemmere at træffe valg om hvad, der har værdi for en brugergruppe. De tre personas er defineret ud fra vores målgruppe og dækker typiske personas for denne. Den ene persona er beskrevet herunder. Martin er 21 år og er IT studerende på Danmarks Tekniske Universitet. Han bor på kollegium og lever primært af sin SU. På trods af sin lave indkomst har Martin altid en af de nyeste mobiler. Martin har nemlig stor forkærlighed for elektronik og såkaldte gadgets og går op i den nyeste teknologi med liv og sjæl "Fremtiden er her nu" elsker Martin at citere. For ham er mobilen ligeså meget et "legetøj" som et værktøj. Han udforsker gerne de forskellige funktioner og elsker at sætte sit personlige præg på telefonen vha. indstillinger. Jo mere den kan indstilles des bedre "Det er super smart!". Martins drømmetelefon er en, der er sjov at bruge og som udnytter det nyeste "li'r" på en smart måde. Alle personas er vedlagt i 8.6 Appendiks A6 Personas

32 24 Første dataanalyse SCENARIER Ud fra de personkarakteristikker vi har valgt, vil vi uddybe dem i med et scenarie tilknyttet hver af dem: Teknisk begejstret bruger Martin sidder til en forelæsning på universitetet. I pausen hiver Martin sin mobiltelefon frem og begynder at surfe på internettet. Hans sidekammerat bliver interesseret i Martins nye mobil og Martin viser alle de forskellige features frem, indtil forelæseren afbryder ham ved at starte undervisningen. Den seriøse bruger Eigil er på vej hjem fra sit arbejde. Han kan godt lide at bruge togturen til noget konstruktivt og tager derfor sin mobiltelefon frem, for at skrive en liste over ting han mangler. Mens han skriver listen, kommer han i tanke om, at han skal ringe til en af sine venner. Han går derfor væk fra sin indkøbsliste og ringer til sin ven. Efter opkaldet færdiggør Eigil sin liste. Teenageren Louise er en moderne mester i multitasking. Hun sidder og kigger på sin lærer, mens hun under bordet er i gang med at sende sms er til sine veninder. Louise er så vant til at bruge sin telefon, at hun kan navigere fra hovedmenuen ind til skriv sms, og derfra skrive en SMS mens hun kun lejlighedsvis kigger på skærmen. Det er også nødvendigt i hendes situation, hvor læreren ikke værdsætter mobilbrug i timerne.

33 Første iteration FORMULERING AF KRAV Ud fra vores resultater fra dataanalysen, har vi her opskrevet en liste af krav fra brugerens synspunkt. Det er ikke krav, der direkte kan omsættes til et produkt, men det er nærmere retningsliner for produktet. Listen er derfor indtil videre ret overordnet, og bygger udelukkende på hvilke forventninger og ønsker vores testdeltagere har givet udtryk for. I de følgende iterationer, vil denne liste blive udvidet og specificeret yderligere. - Hurtig adgang til de mest brugte funktioner - Menustrukturen skal være overskuelig - Let at lære at bruge - Let at bruge - Kan bruges uden fuld opmærksomhed - Kan bruges med udelukkende periodisk opmærksomhed - Skal kunne gøres personlig - Skal let kunne skiftes mellem lyd/lydløs - Let at se hvad klokken er - Skal understøtte genkendelse frem for genkaldelse - Systemets model skal være genkendelig og logisk forbrugeren - Skal være spændende at bruge

34 26 Design 1.5. DESIGN BRAINWRITING Da valget af design er utrolig vigtigt for produktet, og det ikke er muligt, at finde designet ved en dataindsamling, må det blive fundet på en anden måde. Vi har derfor valgt, at bruge brainwriting ( Brainwriting) til at finde så mange ideer som muligt. Ideerne fra Brainwriting: - En spiral så man ser hvordan man bevæger sig op/ned i menustrukturen, samt en oversigt over hvor man er - Gestures der angiver, hvor i systemet man befinder sig, så hvis man vil f.eks. højere op, så bevæger man telefonen opad - Struktur der er bygget op, så der er en tydelig visuel sammenhæng - som en tørresnor hvor alle tingene hænger sammen og det kan ses når der bevæges fra det ene til det andet - Flere menuer efter funktion - Store ikoner som eneste på telefonen - Ren brugerindstillet menu, så man kan lave genveje til alt på telefonen og lægge det i menuen. Samtidigt kan man ændre på telefonens struktur, så alt kan flyttes rundt på - Kombinationen af tilt og ryst til at vælge i menu - Flere menusider, så der f.eks. er en menuside for f.eks. sms så man kan skrive den direkte i menuen - Brug af kugle til at manøvrere rundt. Ruller hen til det ikon man vælger - Vibrerende feedback ved valg af knapper, så man kan mærke det. Kan også kombineres med lyd - Hurtig menu og langsom menu. Hurtig menu har f.eks. 4 brugerdefinerede genveje, og langsom menu indeholder hele menustruktur - Touch gestures som genveje - Funktion efter telefon-situation, f.eks. ved kamera - Free form gestures - Selv kunne vælge hvor avanceret telefonen er, så man kan tilføje funktioner og muligheder på samme måde som applikationer - MP løsningen

35 Første iteration SKITSERING AF IDEER De forskellige ideer er blevet skitseret. Ud fra dem, vil vi vælge hvilken/hvilke ideer der skal bruges i prototypen. En af skitserne er vist her: Alle skitserne er vedlagt i 8.8 Appendiks A8 - Skitser.

36 28 Design VALG AF DESIGN For hver af de forskellige designs, har vi listet de fordele og ulemper 8. På baggrund af disse fordele og ulemper kan designet vælges. Det er muligt at kombinere flere af ideerne. Først skal et overordnet design ud fra de forskellige. Dette bliver udbygget, ved at kombinere den med nogle andre ideer. For at vælge det overordnede design, leder vi efter en ide, der er stor nok til at kunne danne et grundlag. Umiddelbart er det #5 mp-forslaget eller #12 Applikationer direkte menuen, der egner sig som grundidéer. Ud over det synes vi, at det kunne være spændende at arbejde med #2 Tilvalg af avancerede funktioner, #6 Gestures til at navigere i menuen, #10 Taktilt og audio feedback, #13 Touch gestures genveje og #14 Funktion efter situation KRAVSPECIFIKATION Ud fra de resultater vi fik i dataindsamlingen, samt vores krav, har vi formuleret en prioriteret kravspecifikation. De første 5 punkter i listen er vist her: 1. Løsningsmålet i denne opgave er, at udvikle en proof of concept prototype, der fungerer som menusystem for en mobiltelefon 2. Via systemet skal telefonens funktioner kunne tilgås. Løsningen skal være designet til en mobiltelefon, der har indbygget touchskærm og accelerometer 3. Løsningen skal inkorporere ny teknologi som f.eks. tilt eller touch for at give en alternativ interaktion 4. Systemets model skal være genkendelig og logisk forbrugeren 5. Telefonen skal være let at lære at bruge. For at dette er opfyldt, skal en erfaren bruger indenfor mobiltelefoni kunne sætte sig ind i systemet på max 5 min Den fulde kravspecifaktion er vedlagt i 8.10 Appendiks A10 Kravspecifikation. 8 Se 8.9 Appendiks A9 Valg af design

37 Første iteration DIAGRAM OVER KOMMENDE PROTOTYPE Da prototypen kun er i designfasen endnu, er den ikke ret udbygget. Det er derfor kun de øverste dele af strukturen, der er lavet sider til. Resten af siderne er udelukkende lavet som fejl-sider. De beviser dog strukturen i ideerne, og kan anvendes til evaluering af produktet. FIGUR OVERSIGT OVER INTERAKTION

38 30 Første Prototype 1.6. FØRSTE PROTOTYPE DEN FYSISKE PROTOTYPE I denne iteration er formålet, at finde grundideerne i vores færdige prototype. Derfor er der ikke nogen grund til, at lave en meget detaljeret prototype. Hvis der bliver brugt meget lang tid på, at udforme den første prototype, vil det også blive så meget sværere at lave drastiske ændringer i designet. Derfor er vores 1. Prototype både bredt og overfladisk udformet. Ud over det har vi valgt, at lave prototypen i pap/papir. Ved at gøre dette, giver det mulighed for, at have et fysisk objekt at evaluere over. Samtidigt er det dog ikke en prototype, som deltagerne i evalueringen vil have problemer med, at kommentere på. Det er tydeligt for enhver, at det ikke er en prototype, der er lagt mange dages arbejde i, og derved er det nemmere at ændre selv store ting. Prototypen skal illustrere en telefon hvorpå programmet kører. Derfor har vi valgt, at prototypen skal være en telefon lavet af pap, og siderne i telefonen som man vælger imellem skal være slides, der kan skubbes i eller hives ud FIGUR PROTOTYPEN af telefonen nemt. På den måde dannes der en følelse af, at stå med en telefon med programmet i. Telefonen vil ikke komme til at have den samme størrelse som telefonen, applikationen skal implementeres på, men den vil have en størrelse, der er mere brugbar i evalueringen. Den fysiske prototype er en smule større end den mobiltelefon vi har planlagt at udvikle til (Figur viser prototypen). Det er en potentiel faldgrube, da størrelse af skærm er en væsentlig faktor i design til mobiltelefoner. Ved at være opmærksomme på dette håber vi på at undgå diverse fejl, både i den kommende evaluering og i næste redesign FUNKTIONALITETEN I PROTOTYPEN Det endelige design er ikke besluttet endnu, da der blev uvalgt to forskellige hovedkoncepter tidligere. Derfor forløber evalueringen af prototypen anderledes end forventet. Oprindeligt var planen at afholde test/interview hvor testdeltagere bruger prototypen og ud fra deres svar, videreudvikle prototypen i den næste iteration. Da begge ideer kunne være brugbare, tages der udgangspunkt i begge ideer, og inkludere valget FIGUR SKÆRMBILLEDER FRA PROTOTYPEN

39 Første iteration 31 mellem de to i evalueringen. Derfor vil evalueringen hovedsageligt bestå af en diskussion af ideerne, og vil munde ud i et valg samt kommentarer til dette. To af skærmbillederne fra prototypen er vist på Figur Første ide: Ikonerne placeres i en cirkel. Når telefonen tiltes i en retning forstørres ikonet der tiltes mod. Naboerne til det forstørrede ikon bliver også forstørret alt efter hvor der bliver tiltet. FIGUR CIRKEL MED FUNKTIONER FIGUR CIRKEL MED FUNKTIONER II Anden ide: Hovedmenuen i anden ide er mere klassisk. Selve ikonerne er opstillet i et grid og de aktiveres ved at man trykker på dem. Der er ingen forstørrelse eller lignende. Når telefonen bliver tiltet skifter telefonen side. På den måde kan der være hurtig adgang til de mest brugte funktioner. FIGUR MENUBILLEDE FIGUR SMS BILLEDE

40 32 Første Prototype Fælles for de to ideer er implementeringen af shake control hvor man kan styre telefonen ved at ryste denne. Den del af prototypen vil blive gennemgået yderligere i afsnittet Brug af accelerometer Et andet koncept som ikke kan implementeres, men som prototypen skal lægge op til diskussion om, er funktion efter situation. Dette koncept bygger på at du holder et kamera anderledes end du holder en telefon. Man kunne udnytte dette ved at aktivere mobiltelefonens kamera når telefonen bliver holdt så den er liggende.

41 Første iteration EVALUERING AF FØRSTE PROTOTYPE VALG AF METODE Formålet med denne evaluering er ikke udelukkende at teste prototypen. Evalueringen skal også bruges til at vurdere de foreslåede ideer og på baggrund af dette, hjælpe med at udvælge den bedste løsning. For at få det bedste resultat afholdes evalueringen med testdeltagerne ikke enkeltvis. I stedet vil vi benytte en fokusgruppe, hvor de forskellige muligheder kan blive diskuteret mellem deltagerne. På den måde, forventer vi, at få mere information og debat, end man ville kunne opnå ved at lave f.eks. verbal rapportering og interviews (1.1.2 Dataindsamling - metoder) FORBEREDELSE En fokusgruppe kræver forberedelse især da, prototypen og dens ideer skal præsenteres på en sådan måde at udbyttet fra fokusgruppen er maksimalt. Fokusgruppen vil bestå af 5 personer. Formålet med denne evaluering er, at få en ide om hvordan testdeltagerne tager imod de to forskellige ideer. Gennemgangen af ideerne foregår således: 1. Første koncept bliver præsenteret vha. et slideshow der viser nogle af siderne i prototypen og vores gennemgang af principperne i ideerne. 2. Testdeltagerne får udleveret en papirsprototype som første koncept kan afprøves på. (Som nævnt tidligere er prototypen langt fra færdig implementeret og det kræver en del fantasi forestille sig det færdige koncept) 3. Testdeltagerne får mulighed for indbyrdes at diskutere løsningen 4. Ovenstående gentages med andet koncept 5. De to koncepter/ideer sammenlignes og diskuteres igen. Da formålet med denne evaluering er, at høre deltagernes diskussion af produkterne, ønsker vi at ende med en masse ideer og holdninger til hvordan produktet skal udvikles SPØRGSMÅL TIL EVALUERINGEN Da metoden til denne evaluering er en fokusgruppe, håber vi på, at få en diskussion i gang for hver af ideerne, samt en sammenligning. Derfor vil vi gerne have svar på følgende spørgsmål: - Hvilke fordele er der til hhv. den ene eller den anden ide? - Hvilke ulemper er der til hver af ideerne? - Forslag til forbedringer af ideerne? - Andre ideer?

42 34 Evaluering af første prototype ANALYSE AF EVALUERINGEN For at få mest muligt ud af fokusgruppen, er der en person der styrer fokusgruppen, og en person der skriver ned, hvad der bliver sagt. På den måde, indsamles der en række forskellige kommentarer, overvejelser, bekymringer og lignende. Dette er så resultatet af fokusgruppen en række kommentarer. Det vil vi så i næste iteration forsøge, at konkludere ud fra. I denne evaluering skal der bedømmes to forskellige designs, og ikke kun et. Resultatet vil derfor være en række kommentarer til hver af de to ideer, der så i næste iteration skal sammenlignes, og ud fra det, skal der tages en beslutning om det endelige design. Som resultat er kommentarerne fra fokusgruppen inddelt i de to ideer, og listet i næste afsnit.

43 Første iteration RESULTATER FRA FØRSTE ITERATION FØRSTE IDE + ANDRE IDEER - Det er vigtigt, at man ikke bruger ryst-funktionen ved en fejl - Det er en god ide, at bruge ryst til f.eks. at gå tilbage i menuen - Det er en god ide, at have ikonerne i en cirkel - Hvis der er pladsmangel til ikonerne, kan man lave to ringe - Der skal være stor fokus på, at det skal være nemt at se hvilke ikoner der er hvilke - Der skal være stor fokus på, at det skal være muligt, at ramme alle ikoner på skærmen ved kun at bruge den hånd telefonen bliver holdt i - Der skal være stor fokus på, at det skal være nemt at manøvrere rundt i menuen uden at komme til at f.eks. vippe telefonen eller andre ting der kan misfortolkes af telefonen - Man kan evt. tilføje, at ikonerne skal kunne spejlvendes, hvis brugeren er venstrehåndet frem for højrehåndet - Det vil være en god ide, hvis man selv kan bestemme hvor ikonerne skal være på skærmen - Det vil være en god ide, selv at kunne bestemme hvilke ikoner der skal være på skærmen - En anden løsning end at vippe for at vælge i menuen kunne være, at holde med fingeren, og så vælge ved at slippe - Det skal overvejes hvordan man låser telefonen - En anden ide kan være, at have en kugle rullende rundt på skærmen, og visuelt se hvad der bliver valgt - Det er en god ide, at kunne starte med en basisversion af telefonen, og så kunne vælge funktioner til og fra - Det er vigtigt, at kunne indstille telefonmenuen i meget høj grad - Det kunne være en god ting, hvis man kunne vælge et ikon på skærmen uden at se på skærmen - Det vil være en fordel, at kunne vælge mellem t9 og qwerty-tastatur på telefonen - Man kan evt. indstille alarm/ur ved at se et analogt ur og så bruge tilt til at indstille det - Det vil evt. kunne laves, at bestemte applikationer starter ved at vende telefonen ANDEN IDE - Skal skifte side ved at svirpe telefonen enten til den ene eller anden side - Kan evt. tage telefonen ved at svirpe til den ene side, og afvise ved at svirpe til den anden side - Man kan evt. bruge fingeren til at skifte mellem siderne i stedet for tilt - Man kan bruge både fingeren til at skifte mellem siderne samt tilt

44 36 Resultater fra første iteration - Menuen kan være opbygget, så der er flere sider både til højre og venstre for 'hovedsiden' - Der skal være meget stor fokus på at man ikke kommer til at tabe telefonen når man bruger menuen - specielt hvis man ofte skal svirpe telefonen. - Vi skal overveje om man let skal kunne gå en side tilbage - Kunne evt. kombineres med den første ide

45 Anden iteration Anden iteration

46 38 Teori 2.1. TEORI FREE FORM GESTURES Med introduktionen af accelerometer til moderne mobiltelefoner, er en helt ny interaktionsform blevet muliggjort. Og det gælder ikke kun mobiltelefoner. En af de mest populære konsoller pt. (2009) er Nintendo wii en [108]. Wii ens controlller (wiimote) har også tre indbyggede accelerometre. Ved brug af disse accelerometre kan den mærke, hvordan du holder og bevæger den. Wii moten bruges til at simulere bevægelser, såsom et golfslag, et tennis slag, bowling, mm. Og med simuleringen af disse bevægelser kan man spille et simuleret spil golf mod dine venner. Moderne telefoner er ikke fuldstændig lig en wiimote, men mobiler som IPhone [109], HTC Touch Magic [110] og flere kan ligeledes bruges til at simulere golfslag og lignende. I modsætning til på en touchscreen gælder det ikke, at der findes et sæt gestures der, for alle mennesker, intuitivt er forbundet til en given handling. I nogle situationer forekommer det brugeren naturligt at benytte free form gestures det gælder at aktivere mobilen, tænde for lyset, sætte på lydløs og indstille lyd niveauet, slette objekter, zoome, gå til næste/forrige object/skærm og ja/nej confirmation. Der er også nogle gestures, der er mere intuitive for brugeren at benytte end andre. Det gælder blandt andet: dreje, ryste, tilte, flippe telefonen, flytte telefonen til venstre/højre/op/ned, mm. Ovenstående informationer kommer fra en guide fra Nokia[102]. Nokias guide siger altså, udtrykt på en anderledes måde, at det med free form gestures ikke er muligt at simulere en handling, der foregår på mobiltelefonen. Fordi der ikke er en direkte intuitiv kobling mellem free form gestures og handlingen de udfører, er det vigtigt at man indirekte skaber sammenhæng. Det gøres ved at skabe en interaktion, der benytter brugerens konceptuelle model fra andre situationer. Hvor man i flere nintendo wii spil bruger controlleren til at simulere rigtige situationer, skal man ved free form gestures bruge simulering af rigtige situationer som metafor for forskellige kommandoer. Et godt eksempel på dette er Sony Ericssons shake control [103]. I musikafspilleren kan du vælge at blande musiknumrene ved at ryste telefonen. De har i denne implementering taget den fysiske situation, hvor du blander ting ved at ryste dem (så som ved: drinks, terning kast, osv.) og brugt dette koncept i deres model for musikafspilleren til at blande numre. Ved at benytte denne overførsel, skaber de en situation, der nemt bliver inkorporeret i brugeres mentale model. Ved brug af free form gestures 9 i prototyper vil vi prøve, at overholde disse designretningslinjer så vidt muligt. 9 Se afsnit Free form gestures

47 Anden iteration PROTOTYPER I vores projekt har vi valgt, at benytte os af prototyper løbende i processen. Ud over det vil det endelige produkt i projektet være en proof of concept prototype. Det vil altså sige, at vi ikke ender med et helt færdig udviklet og testet program, men derimod en prototype der er gennemarbejdet. En prototype kan være mange forskellige ting. Det kan være en papirbaseret skærm, en række skærmbilleder, en video man kan interagere med, eller meget andet. Fælles for dem alle er dog, at prototyperne medvirker til at illustrere en bestemt ide, og ud fra den gives mulighed for at diskutere ideen. En prototype er derfor god til, at fremvise ideen for de involverede personer. På den måde, kan man vise ideen som noget fysisk i modsætningen til udelukkende at være nødt til at forklare. Ud over det er en prototype også brugbar i en designproces. Det kan i det tilfælde godt være, at det kun er udvikleren af produktet, der kommer til at bruge prototypen, men det kan være meget brugbart for at forestille sig hele produktet. Et eksempel på dette er, fra da PalmPilot blev udviklet 10. Prototypen var lavet som et stykke træ, der repræsenterede telefonen. Ved at have denne med i dagligdagen, kunne udvikleren sætte sig ind i, hvilke funktioner der var nødvendige for telefonen, hvilke ulemper der var, og mange andre ting. Ved som udvikler selv at bruge en prototype, er det altså nemt at finde oplysninger, der ellers enten ville have været svære at finde, eller først var blevet fundet sent i processen. En tredje mulig udnyttelse af prototypen er, ved at teste på mulige brugere. Ved at bruge en prototype kan man visualisere en ide, der derfor kan blive testet af personer udefra. På den måde, sikrer man sig løbende, at produktet er brugbart, og i overensstemmelse med de kommende brugeres forventninger LOW FIDELITY PROTOTYPER En low fidelity prototype er en prototype, der er lavet af materialer som pap, papir, træ osv. Det er en meget simpel model af det koncept, der skal udvikles. Den slags prototyper er brugbare, da de er meget simple og da de materialer de er lavet af også er billige. En af forcerne ved en low fidelity prototype, er at de er meget fleksible, og nemme at ændre. Hvis der bliver fundet store fejl eller f.eks. problemer i selve strukturen på programmet, kan man derfor uden problemer ændre dette. Det er også derfor, at en low fidelety prototype er brugbar tidligt i processen. Derudover har brugere en tendens til at kommentere på selve modellen frem for udseendet, hvis man anvender en low fi prototype. Der er flere forskellige måder at bruge low fidelity prototyper på. Vi vil dog kun beskrive den ene her (Resten kan ses forklaret i [150 side ]). 10 Se [150 side 530]

48 40 Teori En af de metoder der er brugbare, når produktet enten er på en computer eller en telefon, er Index kort. Ideen i denne metode er, at de forskellige skærmbilleder (eller lignende) bliver tegnet på kort. Under testen kan deltagerne så manøvrere rundt i systemet, ved at bestemme hvad de vil gøre, og ud fra det vil testafholderen vise de passende skærmbilleder. Dette er brugbart overfor testdeltagere, da det giver dem mulighed for, at afprøve systemet, og derfor nemmere kan sætte sig ind i det HIGH FIDELITY PROTOTYPER High fidelity prototyper ligner, i modsætning til low fidelity prototyper, i høj grad slutproduktet. Den er derfor ikke længere lavet af pap og papir, men af de samme materialer som slutproduktet. Det vil altså sige, at hvis slutproduktet er elektronisk, vil prototypen ligeledes være det. I modsætning til low fidelity prototyper, er disse også mest brugbare længere henne i processen. De skal bruges, når de grundlæggende koncepter er på plads, og de fleste af de større designmæssige beslutninger er taget. Når dette er sket, tages papir-prototypen, og laves til en high fidelity prototype. Low fidelity prototype High fidelity prototype SAMMENLIGNING Fordele Billig at udvikle Mulighed for at vise koncepter God først i proces Nem at ændre design Komplet funktionalitet Kan håndteres alene God til test Minder om endelige produkt Brugbar sent i processen Ulemper Ingen check for fejl Upræcis Kan ikke håndteres alene Kan være svært at forstille sig navigationen og flowet Svært at usability-teste Dyrere at udvikle Svært at ændre i design Tager lang tid at udvikle Ud fra disse fordele og ulemper kan man finde ud af, hvilken type der er brug for i de forskellige situationer. Desuden er det muligt at finde ud af, hvilke ting man skal være opmærksom på.

49 Anden iteration ANDEN DATAINDSAMLING Da vi i 1. iteration valgte, at lave en fokusgruppe mener vi, at vi har nok data til at videreudvikle prototypen til en fuld model. Derfor har vi valgt, ikke at have en dataindsamlingsrunde i denne iteration, men i stedet tage udgangspunkt i resultatet fra den første evalueringsrunde. I evalueringen af den 1. prototype, var formålet at finde frem til hvilken af de to grundideer, deltagerne helst så implementeret i en videre prototype. Derfor har vi ud fra resultaterne i evalueringen opstillet ideerne med deres fordele og ulemper, så et valg kan blive foretaget på baggrund af disse. Om den første ide (menuen opbygget som cirkel) havde deltagerne bl.a. disse kommentarer: Sjov og spændende løsning Ny og uafprøvet ide, der ikke nødvendigvis er så brugbar som den er sjov Det er en god ide, at bruge ryst til f.eks. at gå tilbage i menuen Man kan have mange ikoner på skærmen Positivt hvis man kan indstille mange ting i menuen selv Speciel fokus på ergonomiske komplikationer ved telefonen Om den anden ide (menu med applikationer direkte i) havde deltagerne bl.a. disse kommentarer: Traditionel løsning Delvist en afprøvet løsning der virker, men ikke nødvendigvis er sjov at bruge (nogle dele der er nye, men ikke det overordnede) Vil gerne bruge svirp med telefonen for at skifte mellem skærmene i menuen Man kan have mange ikoner på skærmen Godt at have hurtige genveje til applikationer Ingen ergonomiske udfordringer Nervøsitet for at tabe telefonen ved udførelse af free form gestures Fælles for begge ideer Det er en god ide, at kunne starte med en basisversion af telefonen, og så kunne vælge funktioner til Det er vigtigt, at kunne indstille telefonmenuen i høj grad Det vil evt. kunne laves, at bestemte applikationer starter ved f.eks. at vende telefonen Positiv indstilling overfor brug af free form gestures

50 42 Anden dataindsamling Sammenligning Det er ikke umiddelbart muligt at implementere begge designs, da de indeholder modstridende elementer. Vi vil derfor foretage en vægtet vurdering af de to designs på baggrund af resultaterne af evalueringen og vores personlig og professionelle vurdering. Ideerne er meget forskellige i deres udformning. På den ene side har vi en ide som er relativ sikker i sit design, dele af den er afprøvet og de nye funktionaliteter vil ikke være kritiske for brugerens interaktion med mobiltelefonen. Der er begrænsede ergonomiske problematikker og brugerne syntes generelt at ideen var god. På den anden side har vi et uafprøvet design, som ikke findes i nogen moderne telefon. Ideen er uafprøvet og der er flere problematikker mht. hvordan man holder på telefonen, og hvordan den kan vendes og drejes i hånden. Den alternative interaktion vil have store implikationer for brugeren. Er denne ikke tilfredsstillende, vil det ikke være muligt at benytte telefonen overhovedet. Til gengæld udtrykte flere af personerne i fokusgruppen entusiasme for designet, og alle syntes det var en meget god ide. Designet passer ligeledes til den målgruppe, der er valgt til projektet. Derfor har vi besluttet, at tage udgangspunkt i denne ide, og så bygge ovenpå med nogle af de generelle ideer. Med det i mente, har vi foretaget det valg, at arbejde videre med cirkel-interaktionen. Kommentarerne fra fokusgruppen vil blive brugt til yderligere at specificere kravene til designet.

51 Anden iteration REFORMULERING AF KRAV & KRAVSPECIFIKATION Ud fra de informationer vi har fået fra evalueringen af den 1. prototype samt det valgte design, vil vi nu reformulere først kravlisten og dernæst vores kravspecifikation. Kravlisten er reformuleret med udgangspunkt i resultaterne i evalueringen. Det vil altså sige, at de bekymringer/kommentarer deltagerne gav udtryk for, er grundlaget for ændringen af listen. De reformulerede krav er vedlagt i 9.1 Appendiks B1 Reofrmulerede krav. Der er lavet flere ændringer i kravspecifikationen end i kravlisten, da det er mere specifikke krav i kravspecifikationen. Derfor er der dels blevet tilføjet krav, der bygger på det valgte design for prototypen. Dette er f.eks. krav til hvordan systemet skal fungere. Ud over det, er der ligesom i kravlisten blevet tilføjet krav, der kommer fra resultaterne fra evalueringen i første iteration. Den reformulerede kravspecifikation er vedlagt i 9.2 Appendiks B2 Reformuleret kravspecifikation.

52 44 Redesign 2.4. REDESIGN I den første iterations prototype var udpræget horisontal og havde det formål at blive sammenlignet med andre koncepter. Den anden iterations prototype vil gå væk fra den horisontale implementering og arbejde med en model, der er både dybere og bredere. Et naturligt følge af dette er at prototypen vil være langt mere omfattende, og inkludere flere funktionaliteter, der efter al sandsynlighed også skal indgå i den endelige prototype. Begrundelsen for dette er, at vi vil stræbe efter at gøre navigationsmulighederne fra hovedmenuen så meget lig det endelige produkts som muligt. Ved at simulere virkeligheden bedre, opnår vi en bedre indlevelse og forståelse fra testdeltagerens side. Det er yderligere muligt for testdeltageren selv at foretage nogle valgmuligheder og giver muligheden for, at det bliver en reel test med interaktion frem for en fremvisning af en prototype, som deltageren kun hypotetisk kan forholde sig til. De inkluderede funktioner er valgt ud fra deres vigtighed 11, og modellen er derfor ikke komplet. Dels er det meget tidskrævende, at skulle lave og specielt teste alle de enkelte undersider til hovedmenuen, dels er det primært den grundlæggende navigations-ide, der skal testes i denne iteration. Den tid det tager, i forhold til det udbytte vi får, gør, at denne model ikke er bredere, end den er. En del af testen af prototypen går derfor også ud på, hvilke funktionaliteter testdeltageren mangler i den nuværende model, og man der igennem skaber grundlaget for at inkludere disse i næste prototype. Da idéen stadig befinder sig på et tidligt stadium, og den ønskes bedre gennemtestet før den bliver implementeret elektronisk, er valget faldet på en papirsprototype igen. En simplificeret state machine i afsnittet 2.5 Anden Prototype viser navigations-mønsteret. 11 Prioriteret af os

53 Anden iteration ANDEN PROTOTYPE 2. prototype er, som nævnt tidligere, en papirprototype hvis primære formål er, at undersøge om den basale menustruktur er på plads og om der er belæg for videreudvikling af konceptet omkring navigation vha. tilt. Et diagram over menustrukturen i den nye prototype ser således ud: Skift Ny aftale Ny aftale Ny aftale Ny aftale Musikafspiler oversigt Kalender dagsvisning Skift Kalender månedsvisning Skift Kalender ugesvisning Internet browser Spille musik Se kalender Se kalender Se kalender samtale Skriv Web browser oversigt Ny note Ny note Noter oversigt Noter Foto Album Foto Album Tag/se billede Se liste Tag billeder Kamera Liste af programmer Programmer på hjul Indstillinger Indstillinger Find kontakt Telefonbog Tilføj/fjern Indstillinger Opkald Kamera SMS Opkald Find kontakt SMS Programmer Indstillinger Opkald SMS oversigt Alarm Find kontakt Seneste opkald Rediger Internet Musik Rediger Rediger Kalender Fotoalbum Se samtale SMS Alarm oversigt Rediger Rediger alarm Rediger Alarm Tilføj/fjern funktion Rediger Kontakter Rediger Noter SMS samtale Skriv SMS Ny + Tilføj alarm Indstil deltaljer lys Lys Indstillinger Indstillinger Lyd Indstil deltaljer lyd Indstil baggrundsbillede Baggrundbillede Netværk Indstil deltaljer netværk Generelt Indstil tid/dato Sprog Knapper Slå pinkode Til/fra FIGUR DIAGRAM OVER OPBYGNING

54 46 Anden Prototype I første iteration var det først og fremmest en fremvisning, der var vigtigt, og selve menustrukturen og siderne var der ikke blevet fokuseret på. Som det kan ses på diagrammet ovenover, er det nu ændret. På Figur Telefonens hovedmenu ses hovedmenuen på telefonen, hvor de forskellige ikoner kan vælges. FIGUR TELEFONENS HOVEDMENU Generelt er prototypens sider og setup præget af tidligere erfaringer med computere og mobiltelefoner. De fleste sider er derfor ikke nævneværdige, f.eks. ses det her hvordan menusiderne telefonbog og kalender ligner typiske sider i en mobiltelefon. Der er dog nogle ting, der gør den mærkbart anderledes fra en klassisk mobiltelefon og de bliver gennemgået herunder. FIGUR SKÆRMBILLEDER SMS samtaler En SMS bliver klassificeret som Modtaget, Sendt eller som et udkast. Det bærer mobiltelefonen præg af, hvor SMS'er typisk er inddelt i tre forskellige sider "Indbakke", "Udbakke" og "Udkast". Det giver ikke alene flere menupunkter, men personlig erfaring siger også, at det er besværligt at følge med i SMS-udveksling, uden at skulle besøge "Indbakke" og "Udbakke" i en zigzaggende bevægelse. En mulig løsning til dette, som vi har valgt at inkludere i denne prototype, er at oprette en side, "SMS samtaler", i stedet. SMS samtaler indeholder dine korrespondancer med dine enkelte kontakter grupperet efter seneste kontakter. Har du haft en lang SMS udveksling med en person, vil der kun være en

55 Anden iteration 47 "entry" for personen. Vælges denne, vil du komme ind i en SMS-samtale hvor både sendte og modtagne beskeder vises. I denne samtale kan du vælge at skrive en ny besked, det indtastede materiale bliver automatisk til et udkast, så hvis du går væk fra samtalen, uden at have sendt det du senest har indtastet, bliver det gemt, og vises igen næste gang du går ind i denne. I forbindelse med SMS kan det nævnes, at vi er gået væk fra MMS'er i klassisk forstand. I en typisk mobiltelefon vil der være en sektion for MMS'er og en sektion for SMS'er. I en MMS vil der både være en indbakke, udbakke osv. Men rent konceptuelt hvad adskiller så en MMS fra en SMS? Prisen for at sende den måske, men lad os kaste et blik på andre typer af besked-udvekslinger og se, om det kan give os inspiration. I ens verden adskiller man ikke s på baggrund af, om de har vedhæftede filer eller ej. I denne prototype har vi valgt at lave samme koncept. En MMS er simpelthen en klassisk besked, hvor der bliver vedhæftet en eller flere filer. Vi håber på at denne efterligning af strukturen er logisk for brugerne, fordi gevinsterne indenfor simplificering af menustrukturen er mærkbar. I en klassisk mobiltelefon vil der være seks menupunkter 2x3 (MMS + SMS)x(Indbakke + Udbakke + Udkast). I denne model er der et Samtaler. Rent navigationsmæssigt vil der være en øjeblikkelig effekt, og det vil også være muligt at undersøge, om det umiddelbart giver konceptuelt mening, men flere eventuelle fordele og ulemper vil først være mærkbare efter længerevarende brug, og det kan derfor være lidt besværligt at undersøge i tests med kortere varighed. Free form gestures i form af ryst I denne prototype er der inkorporeret free form gestures i form af ryst. Et ryst vil tage dig tilbage i menustrukturen, enten til forrige side eller til hovedmenuen alt efter situationen. Fordi vi arbejder med en papirsprototype, er det interview-afholderen, der afgør hvornår telefonen bliver rystet. Der bliver derfor ikke taget hensyn til ufrivillige ryst og lignende. Det giver meget lidt mening, hvis interviewafholderen skal gå ind og fortolke på bevægelserne, der bliver foretaget og vurdere, om de er korrekte eller ej. I stedet er det testdeltagerens intentioner, der er afgørende. Først senere i processen vil der blive defineret, hvordan bevægelser skal foretages, det ligger i naturlig forlængelse af en elektronisk implementering af prototypen.

56 48 Evaluering af anden prototype 2.6. EVALUERING AF ANDEN PROTOTYPE VALG AF METODE Formålet med denne evalueringsrunde er at afprøve vores prototype. I denne iteration er prototypen udviklet så, der næsten er fuldt uddybet, og derfor har vi valgt, at lade et antal deltagere bruge teste den med verbal rapportering som metode. Som opfølgning på det, afsluttes der med et interview. Interviewets formål skal derfor være, at følge op på de ting testdeltagerne har oplevet i forbindelse med testen. Det skal bruges til, at udlede hvad deltagerne synes om produktet, samt hvordan de synes, det kan forbedres FORBEREDELSE Som forberedelse til evalueringen, skal vi dels se på hvilke opgaver testdeltagerne skal udføre, dels hvad vi gerne vil vide mere om. Ud fra denne evaluering vil vi gerne have svar på følgende spørgsmål: Kan produktet nemt bruges uden megen introduktion? Kan produktet være brugbart? Kan deltagerne lide produktet? Positive/negative ting ved produktet Flere muligheder for videreudvikling For at få svar på disse spørgsmål, starter vi som sagt med verbal rapportering. I den forbindelse har vi lavet 5 opgaver, som skal vise nogenlunde, hvordan systemet er bygget op. Disse opgaver er basale opgaver, der er fundet ud fra resultatet fra den første iteration, hvor vi fandt ud af, hvilke funktioner på telefonen, der bliver brugt mest. Formålet er dog udelukkende, at give testdeltagerne en ide om hvordan systemet fungerer. Opgaverne er lagt i 9.5 Appendiks B4 Opgaver til test. Som opfølgning har vi lavet et interview. Checklisten er også vedlagt i 9.6 Appendiks B5 Checkliste til interview ANALYSE AF EVALUERINGEN Ud fra svarene i evalueringen, laves der nu en liste af de relevante kommentarer. Vi har gennemgået alle svarene fra interviewene, samt hvilke problemer eller spørgsmål der er kommet frem under opgaverne. I analysen er der taget højde for, at det stadig er en papir-prototype, der testes på. Da det er det, og skærmbillederne ligeledes er lavet af karton, har deltagerne ikke fået en "virkelig" oplevelse af systemet. Det kan derfor være svært for brugerne at forestille sig, hvordan det kommer til at fungere. Dette bliver der taget højde for, når de nye kommentarer bliver inkluderet i krav & kravspecifikation i næste iteration. Kommentarerne der kom fra 2. Iteration er listet i næste afsnit.

57 Anden iteration RESULTATER FRA 2. ITERATION Ikonerne skal være mere forskellige end de er nu I kalenderen skal der være en knap til gem (af nye aftaler) Der skal være opmærksomhed på, om de ændringer man er i gang med at lave, skal gemmes når man ryster telefonen Usikkerhed om hvordan tilt og ryst kommer til at fungere Usikkerhed om man skal vende telefonen den ene eller den anden vej under tilt (så man vipper den hen mod ikonerne der skal forstørres eller væk fra) Usikkerhed om man kan navigere under andre ting vha. tilt (f.eks. ved scroll og andre ting) Der skal være ur og dato på startsiden Når man bruger browseren, skal den huske den sidst besøgte side, og automatisk opdatere til den Der kunne godt være en playliste i musikafspilleren, så lige så snart musikafspilleren starter, starter musikken også. Ud over det, kan man så også have en fuld liste over alle musiknumrene Der skal være fokus på, at man ikke kommer til at ryste telefonen (eller lignende) uden at det er meningen Der burde være forklaring under ikonerne, for at beskrive hvad de gør Under seneste opkald skal der stå dato og tidspunkt for opkaldet Under seneste opkald skal der stå angivet hvilket af personens telefonnumre, der er ringet fra (mobil, hjemme, arbejde osv.) Kan også bruge en tilbage-knap for at komme tilbage Der skal være fokus på, at man kan bruge menuen (med tilt og ryst som input) i alle forskellige situationer Man skal kunne vælge T9-tastatur til Hvordan vil det være, hvis man vil sætte et baggrundsbillede på - hvordan fungerer det med ikonerne i menuen?

58

59 Tredje iteration Tredje iteration

60 52 Teori 3.1. TEORI HIGH FIDELITY PROTOTYPER I forbindelse med overgangen fra low fi til high fi prototype er det vigtigt fra start af, at gøre sig klart hvilken platform, der skal udvikles til. Bogen Mobile Interaction and Design[151 s ] gennemgår tre forskellige platforme, som der kan udvikles til PC Baseret Udvikling af applikation på en PC kan være en fordel, da det både er nemt og hurtigt. Flere programmeringsværktøjer som f.eks. Microsofts Visual Studio har emulatorer og specialiserede frameworks, der støtter brugeren i udvikling af applikationer. + Kræver ingen hardware - Har adgang til tastatur og mus, det har mobiltelefonen ikke. Det kan give et forkert billede af interaktionen. - Mobiltelefoner har unikt hardware som PC en ikke kan simulere. Det kan være fysiske knapper, joysticks, eller anden unik hardware. - Har mere processorkraft og hukommelse til rådighed end en mobiltelefon GENEREL MOBILPLATFORM Generel mobilplatform er, når man udvikler til en allerede eksisterende platform. Fordelen er umiddelbar. Man har en reel mobil enhed, hvor applikationen kan afvikles og kan derfor afprøve applikationen på en reel mobiltelefon. Denne udvikling kan vise sig at være mangelfuld eller utilstrækkelig, hvis applikationen er meget afhængig af hvilken hardware, den bliver kørt på. + Hardwaren er allerede til rådighed - Det kræves, at hardwaren allerede er til rådighed - Hvis målet er hardware, der adskiller sig fra den, du udvikler på, kan der opstå implementeringsproblemer. - Hvis den endelige hardware adskiller sig fra den, man udvikler på, risikerer man ikke at fange fejl, der bunder i koblingen mellem software og hardware SPECIALISERET PLATFORM Nogle applikationer er meget afhængige af hardwaren, de skal afvikles på. Det kan skyldes, at applikationen bruger hardware, der ikke er til rådighed i eksisterende modeller eller som adskiller sig fra eksisterende modeller. Det har hidtil ofte har været situationen for udviklerne. + Adgang til specifik hardware og 100% match med denne + Fejl der bunder i koblingen mellem hardware og software bliver fundet - En hardware prototype skal udvikles, eller skal være udviklet, så der kan afprøves på denne.

61 Tredje iteration TEORI OM.NET CF Selvom fokus ikke er på programmeringsprocessen i denne opgave, vil der alligevel være en kort gennemgang af.net Compact framework, som er det framework, der bliver benyttet, når man skriver applikationer til en mobiltelefon, der anvender Windows mobile operativ systemet. ".NET Framework er Microsofts omfattende og sammenhængende programmeringsmodel for opbygning af programmer, der har visuelt flotte brugeroplevelser, problemfri og sikker kommunikation og evnen til at modellere en række forretningsprocesser." [106].NET framework'et er et softwareframework til udvikling af programmer og applikationer til windowsplatformen. Det indeholder biblioteker med mange standardobjekter og -løsninger til standard problematikker..net frameworket rækker videre end som så, men denne simple og overfladiske forklaring er passende i denne opgave, hvor der ikke bliver lagt vægt på selve programmeringsprocessen..net compact framework er en delmængde af.net frameworket, specielt designet til enheder som mobiltelefoner, PDA er og andre enheder med begrænsede ressourcer. Selve frameworket er specialdesignet til at begrænse brug af hukommelse og batteriforbrug. Frameworket giver mulighed for at lave eksterne kald der bliver afviklet som native code 12. Det betyder du fra dit program via et eksternt kald kan få telefonen til at vibrere, indstille tid og andre lignende ting. En del af objekterne og værktøjerne som er en del af.net frameworket er ikke at finde i.net cf. Det gælder blandt andet GDI+ 13, hvilket gør at mange standard grafiske komponenter skal skrives og modificeres individuelt af den respektive programmør. [107] TILT HVORDAN MÅLES TILT AF TELEFONEN? En HTC TouchDiamond indeholder tre accellerometre i hver deres akse på telefonen og ingen gyroskoper. Fordi der ingen gyroskoper findes i telefonen, betyder det at telefonen ikke direkte har nogen ide om, hvordan den bliver vendt og drejet. Det er viden om denne tilstand, som en stor del af vores løsning bygger på, så et alternativ må findes. Accelerometerne måler hver især accelerationen langs deres specifikke akse. En på tværs af telefonen (ax), en på langs af telefonen (ay) og en igennem telefonen (az). Den reelle acceleration [G] kan da betegnes som vektoren (ax, ay, az). Det skal nævnes at der er en vis usikkerhed på G. Illustrationerne viser akserne og accelerationen. 12 Native code er kode der er kompileret til at køre på en specifik processor. Native code adskiller sig fra bytecode der bliver kørt af en virtual machine. 13 Den Graphics Device Interface (GDI+) er et Microsoft Windows applikations-programmerings interfaces og operativsystemets kernekomponent ansvarlig for repræsenterer grafiske objekter og videresende dem til outputenheder såsom skærme og printere.

62 54 Teori FIGUR ILLUSTRATION FRA [104] FIGUR ILLUSTRATION FRA [105] Illustrationerne viser også hvorfor, det kan lade sig gøre, at måle at måle tilt. Tyngdekraften gør, at der i hviletilstand vil være en påvirkning af telefonen. Hvis telefonen er placeret fladt på et bord gælder der at: G = 0,0, g k hvor g er tyngdeaccelerationen og k er en konstant for telefonens måde at behandle accelerations data på. I det softwareprodukt vi bruger, gælder der at k = 1. Som følge af denne definition gælder der også, at en mobiltelefon placeret på højkant får G = 0, g, 0 Så ved hjælp af denne tyngdeacceleration, kan man måle, hvordan telefonen bliver tiltet. Hvis vi definerer at telefonen drejer rundt om planet udspændt af x og z samt y, z gælder der at Lign 1: a x = g cos φ sin(θ) Lign 2: a y = g sin φ Lign 3: a z = g cos φ cos(θ)

63 Tredje iteration 55 Komplikationer Der findes to komplikationer ved at bruge accelerometer til måling af tilt. Det første er, at hvis du har placeret mobiltelefonen sådan, at en af dens akser er parallelle med tyngdekraften, vil tiltningen langs en af de andre akser ikke være målbar. Et eksempel på dette kan gives ved placering af mobilen fladt ned på et bord. Du kan nu (i teorien) snurre telefonen uden at det ændrer på a. Med andre ord vil ax ikke ændre sig. Det er illustreret i lign 1 og 3 da φ i dette tilfælde er 90 og cos(φ) derfor er lig nul. Man kan se bort fra denne situation, da telefonen i realitet aldrig vil være perfekt placeret, sådan at et accelerometer er helt parallel med tyngdekraften. Den anden komplikation er mere presserende og udgør en reel problematik. Ved at benytte accelerometer bliver telefonen følsom overfor accelerationspåvirkninger fra din omverden. Sidder du f.eks. i bus, bil, tog eller fly kan du risikere, at disse sætter farten op eller bremser og derved påvirker telefonens målinger. Dette element vil vi overveje at undersøge BEVÆGELSER En ting, der er værd at overveje mht. måling af acceleration, er fiktive kræfter. Fiktive kræfter "opstår" når et objekt bevæger sig i et koordinatsystem, der ikke er et initialsystem. Et eksempel er når man står op i bussen, og man mærker en kraft fremad når bussen bremser. Det skyldes, som nævnt før, at bussen ikke er et initialsystem. Initialsystemet i dette tilfælde er jorden, og det er faktisk ens fødder, der bliver påvirket af en kraft fra bussen, som man så forsøger at fordele i hele kroppen. Det samme er tilfældet med accelerometeret. Bevæges telefonen hurtigt fremad, vil accelerometeret blive påvirket af en bagudrettet kraft som så giver udslag i GVektoren. Det har stor konsekvens for implementeringen af free form gestures.

64 56 Tredje dataindsamling 3.2. TREDJE DATAINDSAMLING I denne iteration har vi besluttet, ikke at lave en almindelig dataindsamling. I stedet har vi besluttet, at lave en undersøgelse af hvilke ikoner, der vil være bedst egnede til at bruge i vores menu. Grunden til dette er, at vi gerne vil gerne bruge ikoner som er letforståelige. For at gøre dette, vil vi derfor gerne have holdninger og forslag fra eventuelle brugere. Denne dataindsamling vil ikke have dataanalyse som direkte efterfølgelse af dataindsamlingen. Hvilket skyldes, at vi har sat længere tid af til, at lave dataindsamlingen (vente på at få resultaterne tilbage fra undersøgelsen). Desuden er det ikke nødvendigt at have resultaterne (samt foretage dataanalysen) for at gå videre i denne iteration. Dataanalysen vil derfor blive gennemført i parallel med videreudviklingen af prototypen VALG AF METODE For at indsamle ideer til, hvordan ikonerne kan se ud i menuen, vil vi spørge en række brugere og ud fra denne kvantitativ undersøgelse, se om der er nogle generelle træk. Som kvantitativ metode har vi valgt at benytte os af spørgeskemaer. Da formålet med dataindsamlingen er, at få en række forslag og ideer fra deltagerne, har vi valgt ikke at lave et traditionelt spørgeskema (med en liste af svarmuligheder til hvert spørgsmål). I stedet skal deltagerne tegne deres forslag og lignende. Til spørgeskemaet har vi besluttet, at have et minimum af 20 deltagere. Det synes vi er det minimale antal, for at kunne danne sammenhænge og se fællestræk UDVIKLING AF SPØRGESKEMA Ud fra brugernes tidligere svar og på baggrund af vores personlige erfaring med funktioner der er til rådighed på mobiltelefoner blev der lavet en liste over typisk anvendte funktioner. De blev skrevet ned på en liste og brugeren blev bedt om at prioritere funktionerne efter vigtighed og tegne et muligt ikon til den funktion. For ikke at påvirke testpersonerne er standardudtryk for de forskellige funktioner blevet brugt. Det forventes at test deltagernes svar er påvirket af deres tidligere erfaringer med mobiltelefoner og specielt af deres nuværende telefon. Med andre ord forventes det at ikonerne er meget lig de allerede eksisterende ikoner fra deres personlige mobiltelefon. Derfor bliver der i spørgeskemaet også spurgt om hvilken mobiltelefon testdeltageren ejer. Spørgeskemaet er vedlagt i 10.1 Appendiks C1 Spørgeskema.

65 Tredje iteration PILOTTEST Pilottesten forløb uden problemer. Deltagerens eneste kommentar var, at spørgeskemaet eventuelt kunne have været bygget op med forslag i ikoner, som man så skulle vælge imellem i stedet for. Dette har vi valgt ikke at gøre, da vi ikke vil påvirke folk på nogen måde i beslutningen RESULTATER FRA SPØRGESKEMA Som nævnt tidligere i processen blev indsamlingen af svar på spørgeskema, foretaget parallelt med udviklingen af tredje prototype. Man kan i høj grad betragte udarbejdelsen af ikoner som et sideprojekt. Efter et par enkelte spørgeskemasvar blev det da også besluttet, at det var for perifert i forhold til resten af opgaven og at fokus hellere skulle ligge på koncepter omkring brugen af accelerometer. Det vil sige, at de ikoner der bliver præsenteret i løbet af opgaven, er valgt og udviklet på baggrund af personlige meninger og erfaringer. Det betyder, at der kan opstå usikkerhed omkring kvaliteten af ikonerne i en sådan grad at verifikation af ikonernes kvalitet kræves. Hvis det er tilfældet vil kvaliteten af ikoner testes ved en naming method 14 som beskrevet i artiklen Making a Completely Icon-based Menu in Mobile Devices to become True: A User-centered Design Approach for its Development[15]. Hvis ikonerne ikke giver anledning til nogen forvirring, vil dette emne ikke have fokus i resten af opgaven. Da kun enkelte svar på spørgeskemaet blev indhentet og disse ikke er blevet behandlet kan de ikke findes i appendiks. 14 Naming method er en test hvor testdeltageren udelukkende bliver præsenteret for ikonet og ud fra det skal afgøre ikonets betydning

66 58 Reformulering af krav & kravspecifikation 3.3. REFORMULERING AF KRAV & KRAVSPECIFIKATION I forbindelse med evalueringen i 2. Iteration skal kravene til produktet samt kravspecifikationen opdateres. Præcis som det er foregået i de tidligere iterationer. Som man kan læse ud af resultaterne i 2. Iteration, er hovedparten af kommentarerne utroligt detaljerede eller af teknisk art. Derfor er kun et krav blevet føjet til den allerede eksisterende liste. Det betyder ikke at kommentarerne ikke har haft nogen værdi, det skal snarere ses som at listen med krav der er blevet udarbejdet er mere overordnede. De specifikke kommentarer brugerne er kommet med vil blive medtaget i produktets videre udvikling. Det ene nye krav der blev optaget til kravlisten var lyder således Ikonerne skal være tydelige og lette at forstå. Desuden skal de være lette at skelne fra hinanden. En opdateret liste med krav kan findes i 10.2 Appendiks C2 Reformulerede krav.

67 Tredje iteration USE CASES Use cases kan være utroligt vigtige i softwareudvikling. De viser typiske interaktioner med mobiltelefonen og fortæller noget om brugerens handlinger og mål. På den måde hjælper de til med, at definere og uddybe hvad softwaren skal understøtte. Netop fordi de definerer hvad softwaren skal kunne, er det praktisk at bygge diverse test ovenpå use cases, da de derved kan fungere som kvalitetskontrol. De use cases vi har formuleret, er bygget på de scenarier vi beskrev i 1. Iteration. Scenarier er meget generelle og giver et godt overblik og en god indlevelse i problemstillingen, hvor use cases er mere specifikke. Derudover er use cases ne også bygget på de data, der blev indhentet i 1. Iteration med de dagbøger, der blev ført. Et eksempel på en use case der er udarbejdet er Use case 1 : Skriv en sms Primært succescenarie: 1. Menuen vises 2. Sms vælges 3. "Ny sms" vælges 4. Navnet på modtageren tastes ind og vælges 5. Beskeden skrives og sendes 6. Menuen vises igen Alternativt forløb: 4a. Navnet på modtageren vælges fra telefonbog Der er i alt lavet elleve use cases som kan læses i 10.4 Appendiks C4 Use cases, en liste over dem kan ses herunder Use case 1 : Skriv en sms Use case 2 - Svar på en sms Use case 3 : Foretage et opkald fra telefonbogen Use case 4 : Foretag opkald via de seneste opkald Use case 5 : Sæt alarmen Use case 6 : Tag et billede Use case 7 : Se et gammelt billede Use case 8 : Find telefonnummeret til en kontakt (i telefonbogen) Use case 9 : Opret en kontakt i telefonbogen Use case 10 : Slå et ikon til på menuen Use case 11 : Skriv en note

68 60 Redesign 3.5. REDESIGN I denne tredje iteration overfører vi vores papirsprototype til en elektronisk prototype. Det primære formål med dette redesign, er at implementere tilt-navigationen og shake control på en sådan måde, at testdeltagere i en kommende evaluering vil kunne bruge dem i praksis. Ved at bruge løsningerne i praksis forsvinder det abstraktionsniveau, der var aktuelt i papirsprototyperne og den reelle interaktion registreres, samt brugernes holdninger til denne. Samtidig vil prototypen blive både bredere og dybere, i den forstand at der både vil indgå flere funktionaliteter, såsom musikafspiller samtidig med at de tidligere funktionaliteter vil blive implementeret, så brugeren bedre kan interagere med disse.

69 Tredje iteration TREDJE PROTOTYPE Som nævnt i afsnittet High Fidelity prototyper, er der tre platforme til rådighed, når den elektroniske prototype skal udvikles: PC-baseret, generel mobilplatform og specialiseret platform. Der er et generelt ønske om at udvikle en applikation, der er så uafhængig af platformen som muligt, det gør både programmet mere fleksibelt og tillader derudover en nemmere migration til andre platforme. Der er dog visse kerneelementer, der er baseret på unik hardware til denne specifikke telefon. De tre accelerometere og den centrale brug af disse bevirker, at den optimale platform til udvikling, er den specialiserede platform. Heldigvis er hardwaren allerede til rådighed i dens færdigbyggede tilstand, hvilket gør brugen af den specialiserede platform meget smertefrit. Som det kan læses ud af afsnittet 3.5 Redesign, er det hovedsageligt navigationen og menustrukturen, der er fokus på MENUSTRUKTUR Den overordnede menustruktur er stadig meget lig den fra 2. Iteration. Den mest markante forskel ligger i dybden af implementeringen. Da vi migrerede til en applikation, der bliver kørt på telefonens styresystem, opstod muligheden for at udnytte de programmer, der allerede er til rådighed. Det vil sige, at i stedet for at udvikle en del af applikationen, så den kan fungere som kamera, kan vi starte telefonens kamera op og køre det som en ekstern proces. Fordi vores program kører i baggrunden, er det stadig til en vis grad muligt, at kontrollere det eksterne program. Det bliver udnyttet i forbindelse med shake control, hvor et program lukkes ned, hvis telefonen bliver rystet. Eksempler på eksterne applikationer der bliver udnyttet er: kalender, foto album, kamera, musikafspiller, , og browser. FIGUR SKÆRMBILLEDER FRA TELEFONENS INDBYGGEDE APPLIKATIONER På grund af brugen af eksterne applikationer, vil udseendet af visse områder af menustrukturen blive ændret. Hovedparten af de øvrige sider er lavet, så de ligner eller bygger videre på designet fra 2. Iteration, og den primære forskel ligger kun i, at de nu eksisterer på skærm frem for papir.

70 62 Tredje Prototype FIGUR SKÆRMBILLEDER FRA 2. OG 3. ITERATION FIGUR SKÆRMBILLEDER FRA 2. OG 3. ITERATION Vi kan nu vende os mod implementeringen af tiltbaseret navigation BRUG AF ACCELEROMETER ALGORITME TIL AT BEREGNE TILT Som nævnt tidligere ønskes der en implementering af en algoritme, der beregner tilt og som bruger dette til at ændre størrelsen på ikonerne. Som forklaret i teoriafsnittet kan vinklen, telefonen holdes i, beregnes ved at aflæse GVektoren i givne intervaller. Ved hver aflæsning

71 Tredje iteration 63 gennemløbes en række udregninger, som afgør telefonens situation. Denne algoritme vil blive gennemgået herunder. 1. GVektoren aflæses 2. Der laves en 2D-vektor, som vil blive benævnt V. Da man udelukkende ud fra x- og x- og y- komponenten kan afgøre om telefonen bliver tiltet og rystet ser vi bort fra z- komponenten. 3. Længden af V findes. Dette skal bruges, for at kunne skelne mellem aktiv tilt, og normale (og ufrivillige) bevægelser. Længden kan også udnyttes, hvis der ønskes en funktionalitet, hvor ikonernes størrelse afhænger af hvor meget der bliver tiltet. 4. For hvert ikon findes cosinus-værdien mellem V og vektoren mellem centrum af cirklen og midten af ikonet, (retningsvektoren[r]). Det gøres ved at normalisere de to vektorer og finde prikproduktet mellem disse. Cosinus-værdien, der fortæller noget om vinklen mellem de to vektorer, vil spænde mellem -1 og 1, hvor -1 betyder at de to vektorer er modsatrettede og 1 betyder at de er ensrettede. 5. Ikonernes størrelse redefineres nu mht. cosinus-værdien. Forstørrelsen er beskrevet i afsnit Forstørrelse af knapper ved tilt i glidende overgang Da telefonen som regel ikke ligger fladt ned på et bord, når den bliver brugt, skal dette tages med ind i overvejelserne. Derfor har vi valgt, at menuen i denne prototype skal udregnes ud fra den vinkel, telefonen bliver holdt i, når applikationen starter. Den vinkel bliver sat til (0,0,0) i rummet. Det er altså ud fra denne, at alle bevægelser vil blive opfattet. Dette betyder i praksis, at hvis man har startet telefonen, mens man står op, skal man ikke vippe telefonen så meget som i forhold til en vandret flade. Som nævnt i teoriafsnittet omkring tilt, vil ydre kræfter påvirke GVektoren, og derved også alle udregningerne, der bruges til at beregne tilt med. Derfor har vi testet dette, ved at bruge systemet under kørsel i bil. Det havde målbar virkning på GVektoren, at bilen accelererede, men det var ikke nogen stor forskel. Vi kunne konkludere, at det stadig var muligt at bruge systemet, så derfor vælger vi i denne rapport at se bort fra denne opgave ALGORITME TIL AT BEREGNE RYST For at afgøre om telefonen bliver rystet, skal GVektoren og timeren ligeledes bruges. Fremgangsmåden er relativ simpel i dette tilfælde. Se på GVektoren i forhold til GVektoren ved sidste måling. Er den relative acceleration af i xy-planet af en hvis størrelse, så har man lavet et halvt ryst. Det bliver til en helt ryst, når den relative acceleration bliver af en hvis størrelse igen, og GVektoren er modsat rettet den forrige GVektor.

72 64 Tredje Prototype Distance(newV, oldv) <= n Distance(newV, oldv) <= n OR 0 <= DotP(newV, oldv) n < Distance(newV, oldv) AND Initial state n < Distance(newV, oldv) Halfshake Shaking DotP(newV,oldV) < AUTOMATISK START AF KAMERAET Da en mobil på mange måder er flere forskellige enheder der er slået sammen i et (telefon, kamera, computer, osv.), kunne man undersøge, om det giver mening at bruge dette i designet. Vi har prøvet at udnytte, at man holder et kamera anderledes, end man holder en telefon. Et kamera vil typisk bliver vendt, så det ligger ned så at sige. Denne måde at holde telefonen på kan registreres ved hjælp af accelerationsmålingerne. Det er blevet implementeret i prototypen, så hvis telefonen holdes tilpas længe i en given position, startes kameraet. FIGUR KAMERA FORSTØRRELSE AF KNAPPER VED TILT I GLIDENDE OVERGANG For at menuen rummer plads til flest mulige ikoner, og derved, er så brugbar som muligt, er ikonerne små fra start. Når telefonen så bliver tiltet i en retning, vil ikonerne i denne retning blive forstørret. For at lave denne forstørrelse så "pæn" som muligt, har vi valgt at lade ikonerne blive forstørret i en glidende overgang. Jo tættere retningsvektoren er på G- vektoren des større bliver ikonerne.

73 Tredje iteration 65 FIGUR SKÆRMBILLEDER AF FORSTØRRELSEN AF IKONER Som beskrevet tidligere udregnes cosinus-værdien mellem de to vektorer. Er værdien mindre end en given størrelse n, bliver ikonets størrelse en standard minimumstørrelse. Er ikonet større end dette, ganges cosinus-værdien på en standard maksimumstørrelse, og dette bliver ikonets nye dimensioner. For at der bliver dannet en glidende overgang mellem de små ikoner og de forstørrede ikoner, må der gælde at: n = Minimum størrelse Maksimum størrelse Da man sjældent holder telefonen helt stille i hånden, vil denne løsning i sig selv ikke være god at bruge. Selv små bevægelser fra hånden, vil vise sig som udsving i ikonernes størrelse. Derfor vil ikonerne i praksis konstant ændre størrelse. For at undgå dette har vi indlagt en lille "buffer" der gør, at hvis det kun er meget små bevægelser, der bliver foretaget med telefonen, vil størrelserne ikke ændre sig. For at finde den bedst mulige værdi for hvor store bevægelserne skal være, har vi forsøgt os frem. Hvis værdien bliver for stor, vil det nemlig virke som om, at telefonen er sløv og ikke reagerer. I evalueringen af prototypen vil dette blive afsløret.

74 66 Evaluering af tredje prototype 3.7. EVALUERING AF TREDJE PROTOTYPE VALG AF METODE Formålet med denne evaluering er, at teste den prototype vi har lavet i denne iteration. Vi har lavet en prototype, der stemmer nogenlunde overens med den prototype vi sluttede 2. iteration med i papir. Denne er dog elektronisk, og vi har derfor taget en række tekniske valg. I denne evaluering vil vi derfor dels undersøge, hvordan denne prototype fungerer indtil videre, og dels hvordan der skal arbejdes videre. Vi har valgt, at lave evalueringen med verbal rapportering, samt kombinere dette med et interview. Dette gør at testdeltagerne først kan danne sig et indtryk af, hvordan prototypen fungerer, og komme med kommentarer mens denne bliver brugt. Derefter vil interviewet blive brugt til, at få flere og uddybende reaktioner fra deltagerne FORBEREDELSE Som forberedelse til evalueringen, laver vi en liste af funktioner vi gerne vil have testet, samt en række spørgsmål vi ønsker svar på. Ud fra denne evaluering vil vi gerne have svar på: Kan produktet nemt bruges uden megen introduktion? Fungerer menudesignet i praksis? Fungerer ryst som tilbage-knap i praksis? Er produktet brugbart? Kan deltagerne lide produktet nu det er i elektronisk form? Positive/negative ting ved produktet Flere muligheder for videreudvikling Mange af disse spørgsmål er de samme som til evalueringen i 2. iteration. Grunden til dette er, at prototyperne i de to iterationer minder meget om hinanden i funktionalitet, men forskellen er om de er elektroniske eller papir-udgaver. Derfor er hovedformålet med evalueringen i denne runde, at undersøge om konceptet virker i den elektroniske version, da man i papirversionen primært skulle forestille sig hvordan det ville være ANALYSE AF EVALUERINGEN Den nuværende brug af tilt forstørrer ikonerne, så de er nemmere at ramme med fingrene. Brugeren skal dog stadig trykke på det enkelte ikon for at navigere. En vigtig pointe som flere udtrykker er WIIFM (What s In It For Me?). Da der stadig skal trykkes på de enkelte ikoner, følte flere brugere, at det ikke gav en mærkbar fordel. Med andre ord har vores nuværende forslag, hvor man bruger tilt til navigering, ingen umiddelbar nytteværdi. Vores overvejelser omkring dette vil blive beskrevet i næste iteration.

75 Tredje iteration 67 Andre kommentarer knytter sig til selve implementeringen af tilt-baseret navigation. For eksempel fremgår det ikke tydeligt hvilket ikon, der er i fokus. På trods af at størrelsen indikerer dette, kunne der være anden form for feedback, der også indikerer dette eller det visuelle feedback kunne ændres. Derudover var der kommentarer omkring at fokus flimrede mellem ikonerne. Det vil typisk ske tilt fokus er på grænsen mellem to ikoner, hvor de skiftevis er de største ikoner. Det sker selvom vi har prøvet at tage højde for dette. Brug af ryst til at gå tilbage i systemet var en ting, som flere brugere udtrykte deres mistro til under anden iteration. Under denne evaluering har flere brugere udtrykt deres tilfredshed med denne funktion. Det forekom naturligt, for hovedparten af brugerne, at bruge denne funktion. Der opstod sjældent ufrivillige ryst og implementeringen af denne funktion viste sig under nuværende testforhold 15 at være god. Utroligt meget af utilfredsheden omkring modellen bunder i det SIP (Software Input Panel), som er standard i Windows mobile. Flere brugere var vant til T9 tastatur fra deres nuværende mobiltelefon og hovedparten udtrykte at tastaturet var alt for småt til mobilen. Der var problemer med at ramme tasterne, og der var kun visuelt feedback fra tastaturet. Ydermere var det problematisk at få tastaturet til at komme frem kun ved brug af fingrene. Der er også en lang række andre kommentarer, der ligesom den om SIP ikke knytter sig direkte til vores model. De spænder fra kosmetiske til brugervenlighedsproblemer. F.eks. har flere testdeltagere haft problemer med at benytte standard scrollbaren i Windows mobile, da denne er for smal på HTC Touch Diamonds display. En liste over samtlige resultater fra evalueringen kan ses i næste afsnit 3.8 Resultater fra 3. iteration. FIGUR SKÆRMBILLEDE FRA NOTER 15 Vi skriver her under nuværende testforhold da man i den løbende evaluering af et produkt bør teste det i dets rette omgivelser. Der bliver fokuseret på dette i afsnittet 4.5 Evaluering af fjerde prototype

76 68 Resultater fra 3. iteration 3.8. RESULTATER FRA 3. ITERATION Det kunne godt være muligt, at bruge en knap til at vælge det ikon der er fokuseret på Tastaturet skal laves bedre Tastaturet skal poppe op når man er på en side der skal bruges tastatur på Tastaturet skal forsvinde automatisk når man går væk fra en side, hvor tastaturet bruges Der kunne godt være en besked med, at sms'en er sendt Overveje mulighederne for bedre løsning for menuen (ift. tilt) Gøre tilt brugbar, så brugere føler det som en gevinst Der skal arbejdes med vinklen for kameraets autostart Sæt alarm/ur ved drag/drop Ved start af sæt alarm/ur skal tiden stå over uret I indstil ur/alarm skal den inderste viser gøres større, så man kan bruge finger til at indstille med Alarmerne sorteret efter tidspunkt Scroll-bar er for tynd til at bruge Note kan evt. tilføjes en gem-knap Skal kunne gemme et nummer fra opkaldsfunktionen Ikonerne på menuen flimrer Det fokuserede ikon skal markeres Man skal kunne indstille hvor mange ikoner man har på menuen Man skal kunne søge i telefonbogens kontakter Der skal være en tastatur-lås Kalenderikon kunne vise den korrekte dato Ved at klikke på uret (eller evt. holde fingeren der i et par sekunder) kan man komme ind til indstillinger af uret Se på om man kan bruge landscape-mode i telefonen Kamera-ikon sættes så den er aktiv når man lægger telefonen ned

77 Fjerde iteration Fjerde iteration

78 70 Ideer 4.1. IDEER ACCELEROMETER En anden funktion hvor vi vil undersøge brugen af accelerometer er, når man scroll er i en lang liste. På mange mobiltelefoner kræver det at scoll e, dels brug af begge hænder, men også en vis portion opmærksomhed. Derfor undersøger vi muligheden for, at bruge accelerometeret til at måle, hvor meget man tilter telefonen. På den måde, kan man ved at vippe telefonen (altså kun nødvendighed for at bruge én hånd) manøvrere rundt i en liste. En sådan liste kunne være i telefonbogen, hvor man tit har brug for at scroll e op eller ned. Vi vil derfor undersøge hvilke muligheder der er, for at gøre dette, samt undersøge hvordan man gør den så let at bruge som muligt TOUCHSKÆRM En af ulemperne ved at have mobiltelefoner uden et fysisk tastatur er, at keyboardet udelukkende bliver vist på touchskærmen. Det er smart i forhold til plads på telefonen, men det er en udfordring, da man så udelukkende bygger interaktionen på det synlige, og ikke på andre sanser (som man f.eks. gør på et "fysisk" tastatur, hvor man både kan mærke knapperne, ved hvordan det føles at trykke på den, og kan høre når de bliver anvendt). Derfor vil det være spændende, at undersøge muligheden for, at tilføre informationer til de andre sanser - høre- og følesansen. For at gøre dette, vil vi undersøge, hvordan man kan tilføje den slags feedback samt implementere det.

79 Fjerde iteration TEORI ANVENDELSE AF TILT TIL SCROLL Flere artikler omhandler implementering af tilt til at scroll e med, både i en og to dimensioner. Vi vil her fokusere på endimensionel scrolling og telefonbogen, som er et godt eksempel på dette. Scroll med position control En mulighed er scroll med position control. Den vinkel mobiltelefonen holdes i afgør, hvor i telefonbogen man er. Mængden af kontakter i telefonbogen vil gøre, at hver kontakt vil have et utroligt småt vinkelinterval til rådighed. I artiklen "Tilt and Feel: Scrolling with Vibrotactile Display" [29] løser de dette problem ved, at man samtidig holder den fysiske knap med begyndelsesbogstavet nede, hvilket reducerer antallet af kontakter mærkbart. Telefonen vi arbejder med har intet fysisk tastatur, hvilket gør at SIP skal bruges. Det gør at interaktionen ikke længere hovedsageligt foregår vha. tilt, derudover optager SIP-tastaturet en væsentlig del af skærmen, når det er fremme. Der er alt i alt en del komplikationer ved implementeringen af scroll med position control. Rate controlled scrolling Det andet alternativ til scrolling vha. tilt er rate controlled scrolling. Ved at tilte telefonen bevæger du dig relativt i listen. Der findes flere måder at implementere rate controlled scrolling. I en simpel implementering vil hastigheden, hvorved der scroll es i listen være konstant. I lidt mere avancerede implementeringer vil hastigheden, hvorved der scroll es accellerere alt efter hvor meget og hvor længe telefonen tiltes. Speed dependent auto zooming[3] understøtter den variable hastighed ved, at zoome ind og ud alt efter hastigheden hvorved der scroll es. Det øger tiden der er til rådighed til at fokusere på de enkelte objekter på listen. De to mest markante problematikker, der bliver nævnt i forbindelse med rate controlled scrolling er - Overshooting. Man kommer længere ned på listen end intentionen og det er besværligt at bevæge sig den modsatte vej. - Længden af listen. Med rate controlled scrolling vil der være langt til midten af listen. Man kan, som nævnt tidligere, begrænset antallet af elementer i listen ved at indtaste startbogstavet på kontakten, men som det også er nævnt tidligere er det mere besværligt med en telefon uden et fysisk tastatur. I forbindelse med scrolling generelt er der lavet flere eksperimenter med at give feedback. En basiside til rate controlled scrolling er, at øge vibrationen des hurtigere der scroll es. Man kan overveje, hvor meget det gavner, da man allerede får visuelt feedback omkring hastigheden.

80 72 Teori I position control scrolling kunne man vibrere, alt efter hvor langt nede man er i listen. Det er måske en smule anvendeligt. De bedste ideer kommer dog i form af at programmet, vha. machine learning, registrerer hvilke kontakter der er de mest anvendte. Når en hyppigt anvendt kontakt nærmer sig gives der signal om dette. Med taktilt feedback[29] kan det være med et ryst der varierer i varighed eller bølgelængde alt efter hyppigheden. Ved visuelt feedback kan det implementeres, ved at gøre de hyppige objekter større, så de derved er lettere at se og langt mere markante.

81 Fjerde iteration REDESIGN I evalueringen af prototypen i den tredje iteration blev det klart at brugerne ikke følte at den tiltbaserede navigation i dets nuværende giver et positivt bidrag i interaktionen. Den lave nytteværdi af det aspekt af designet er en af de væsentligste kommentarer. Konsekvensen af dette er en brainstorming, hvor der er kommet tre alternative forslag til det nuværende design. Design 1: Automatisk valg vha. tilt. Denne implementering er meget lig den nuværende. Ved at tilte telefonen fokuseres et ikon. Er et ikon fokuseret i tilstrækkelig lang tid svarer det til at klikke på et ikon i den nuværende model. Det betyder at man kun behøver at benytte tilt til at navigere med og derfor kan navigere ved brug af en enkelt hånd og en enkelt type bevægelse. Denne implementering ligger utroligt tæt op ad Ipod keyboardet beskrevet i [57]. Den primære forskel er at der i denne løsningsmodel bruges ipod hjulet (vha touch) til at fokusere, hvor man i denne bruger tilt. Forskellen mellem touch og tilt i denne sammenhæng er mærkbare. I Ipod keyboardet løsning kan du deaktivere selektions processen ved at stoppe med at røre Ipod hjulet, hvilket må betragtes som relativt simpelt, stoppes en tilt selektions proces ved at holde telefonen i en bestemt vinkel indtil telefonen låser, det må betragtes som relativt besværligt. Derfor er der ved en tiltbaseret implementering nævneværdi chance for ufrivillige "klik" på ikoner. + Bruger kun tilt til at navigere med - Stor risiko for uintentionelle valg - Kan være besværligt at fokusere vha. tilt - Betragtningsvinkel Design 2: Fokusering vha. tilt, valg vha. central knap Dette design er også meget lig den nuværende. Ved at tilte telefonen fokuseres (og evt. forstørres) et ikon. Ved tryk på central knap, fysisk eller software implementeret, "klikkes" der på ikonet som trykkede man på det. Man skal både tilte og trykke på en central knap ved denne navigation. Derved skal der bruges to forskellige interaktionsmåder, men ved det korrekte valg af en central knap, kan dette måske spille en mindre rolle. Sandsynligheden for at lave et uintentionelt valg ved denne implementering er minimal og hvis en fysisk knap bliver brugt som udvælgelsesknap, behøver man ikke røre selve skærmen, hvilket har en del fordele. + Kan aktiveres et sted, skærmen behøves ikke berøres + Lille risiko for uintentionelle valg - Bruger både tilt og fysisk knap - Kan være besværligt at fokusere vha. tilt - Betragtningsvinkel

82 74 Redesign Design 3: Fokus vha. finger En anden mulighed er at beholde ikonerne i en cirkel, men at fokusere på touch i stedet for tilt. Ideen med at ikonerne forstørres, når de bliver fokuseret fastholdes. Interaktionsmetoden bliver skiftet, så du ikke længere fokuserer ved at tilte telefonen, men derimod fokuserer ved at lade en finger eller lignende, glide over et objekt. At et objekt bliver fokuseret når en finger/mus glider over denne, må betragtes som meget almindeligt og lidt af en standard. Det er en klassisk problematik omkring touchscreens, at der ved fingerbrug ofte bliver skygget for indholdet. På grund af dette er der allerede udviklet en del redskaber, der prøver at afhjælpe dette brugervenlighedsproblem og som man kunne benytte til udvikling af denne løsningsmodel. En af de bedre løsninger er Shift [23] Ved denne implementering er der kun brug for touchscreen i interaktionen. Risikoen for at vælge et ikon uintentionelt må betegnes som minimal. Det der trækker mest ned for denne model, er dens mangel på originalitet. + Kun brug af touch screen + Lille risiko for uintentionelle valg - Fingeren skygger for det der vælges (halvt løst) - Uoriginalt De tre løsningsmodeller er alle gode alternativer til den nuværende. Man kunne afprøve de tre idéer indbyrdes og igennem brugertests afgøre, hvilken der er bedst, målt ud fra brugertilfredshed og hastighed. Det vigtigste er dog ikke, hvordan de nye løsninger klarer sig indbyrdes, men derimod hvordan de klarer sig i forhold til den nuværende interaktion. Derfor kommer der andre kriterier i spil. Innovation, anvendelse af ny teknologi i mobiltelefoner, samt brugervenlighed (i form af brugertilfredshed) er de kriterier der vejer tungest. Løsningsforslag 1 bliver valgt fra med den begrundelse, at den på baggrund af uintentionelle valg indeholder mange potentielle bruger gener. I løsningsforslag 3 er selve forstørrelsen og det at ikonerne befinder sig i en cirkel nyt i forhold til de klassiske menuer. Det er dog tvivlsomt om det ved en klassisk touch udvælgelse er profitabelt at have ikonerne i en cirkel og om denne ide i det hele taget indeholder meget nyskabelse. I løsningsforslag 2 virker brugen af både tilt og en knap ikke som en stor gene. Specielt ved valg af den rigtige knap til udvælgelse, kan konceptet forhåbentligt forekomme meget naturligt. Derudover er løsningsforslaget et meget naturligt næste skridt i udviklingsprocessen for den nuværende ide og designkoncepterne er derfor relativt ens. Derfor tilvælger vi denne model og det er denne implementering, redesignet fokuserer på.

83 Fjerde iteration FJERDE PROTOTYPE Den største interaktionsmæssige forskel i den nye prototype bliver implementeringen af den udvalgte ide fra afsnittet 4.3 Redesign. Vi har valgt, at den fysiske runde knap skal anvendes som udvælgelsesknap. Den er placeret centralt og ligger umiddelbart ergonomisk tilfredsstillende for tommelfingeren. Den er specielt god fordi, den støtter en praktisk måde at holde på telefonen. Det fokuserede ikon bliver "klikket" på, når man trykker på den runde knap. Selve implementeringen og konceptet er ligetil. Det interessante dukker først op under evalueringen, hvor konceptet bliver afprøvet i praksis. I tidligere prototyper blev det forsøgt at ignorere ændringer i G-vektoren, der var for små, for at forhindre at fokus hopper frem og tilbage, når den befinder sig på en grænseværdi. Det har vist sig, ikke at være nok i sig selv. Derfor er der i den nye prototype taget forbehold for disse kommentarer, og der er blevet foretaget en del ændringer. For det første er forstørrelsesprocessen ændret, således at ikonerne beholder samme størrelse. Hvilket forhåbentligt giver et indtryk af en mere stabil menu. Ikonerne er ændret så deres look ligner mere en knap. De har nu fået en kant rundt om og knappen skifter farve når den bliver fokuseret. Det giver et indtryk af at knappen bliver trykket ned, lidt ligesom man kender det fra standard-knapper i computerprogrammer. Ændringen af dette udseende og forstørrelsesprocessen tydeliggør forhåbentligt hvilket ikon der er fokuseret. FIGUR SKÆRMBILLEDE AF GAMMEL MENU FIGUR SKÆRMBILLEDE AF NY MENU Derudover er der blevet ændret på måden, man finder det fokuserede ikon. Tidligere var det sådan, at man ved en grænseværdi mellem to ikoner typisk ville opleve at fokus hoppede frem og tilbage, selvom du holdt telefonen i en fast position. Det fokuserede ikon findes ved at regne cosinus-værdien ud mellem den normaliserede tilt vektor og den

84 76 Fjerde Prototype normaliserede vektor fra cirkelens midte til ikonet. Der er blevet lavet en lille buffer, der er til fordel for det fokuserede ikon ved at lægge en værdi til dets cosinus-værdi. Der vil stadig eksistere grænseværdier, men i det tilfælde hvor du er tæt på grænseværdien og overskrider den, så du går fra det fokuserede ikon til dets nabo, vil du ikke længere befinde dig på grænsen, da den er rykket til fordel for det nye fokuserede ikon. Bufferværdien er noget vi har sat efter vores subjektive mening. Er denne for høj vil skift fra fokuseret ikon til nabo forekomme trægt og besværligt, bliver den sat for lav risikerer man at fokus hopper frem og tilbage igen. Det er vi yderst opmærksomme på i den kommende evaluering. En anden ting der er ændret, i forhold til den tidligere prototype, er at der er implementeret taktilt feedback. Hver gang fokus rammer et ikon vil der være et ryst der indikerer skiftet. Det er en minimal ændring og teorien omkring taktilt feedback vil blive gennemgået i afsnittet 5.1 Taktil feedback. Vi har valgt, at implementere Rate controlled scrolling. Den taktile feedback vil angive hvor hurtigt der bliver scoll et. Derved ønsker vi, at give brugerne større føling med, hvad der sker. Metoden til at sammenkoble de to tager udgangspunkt i startvinklen (når programmet startes). Hvis telefonen holdes i denne vinkel, bliver der hverken scoll et op eller ned i listen. Den er i en slags ligevægt. Hvis telefonen derimod bliver holdt i en vinkel, der er så markant anderledes, at det ikke kan stamme fra ryst med hånden, bliver der hhv. scroll et op eller ned. Denne nedre grænse for hvor meget telefonen skal vippes, skal testes for, at kunne sætte den rigtigt så den hverken er for følsom eller for svær at påvirke. Når telefonen vippes scroll es der hurtigere eller langsommere i forhold til hvor meget telefonens vinkel. Derfor udregnes en værdi, der angiver scroll-hastighed ud fra vinklen givet af g-vektoren fra accelerometeret. Scroll-hastighed når der scroll es hhv. op eller ned i listen ikke skal være det samme. Den primære grund til dette er betragtningsvinklen, som varier i forhold til om du vipper telefonen den ene eller den anden vej og derved om du scroll er op eller ned. Som nævnt tidligere er der på forsøgsbasis tilføjet taktilt feedback til listen i telefonbogen. Denne vibrotaktile feedback indikerer, hvor hurtigt der scroll es i listen. Dette er stadig på teststadiet og skal optimeres og man kunne overveje feedback, der udtrykte andet end hastigheden af scroll, hvis der blev foretaget flere iterationer. Derefter kan man så lave en lang række tests, hvor der sammenlignes mellem en liste med eller uden taktil feedback.

85 Fjerde iteration EVALUERING AF FJERDE PROTOTYPE Igennem hele rapporten og processen har det stået klart, at det ikke er tilstrækkeligt at lave evalueringer i et laboratorium. For at finde den reelle værdi af vores produkt, skal det afprøves i virkelige situationer. Laboratoriumtest er meget udbytterige og som det også er blevet vist i rapporten udpeger de mange problemer og kritiske emner i et design, men under evalueringer i det naturlige miljø hvor produktet skal bruges, belyses problemstillinger der hidtil har været usete. Som nævnt tidligere er det ekstra vigtigt med mobiltelefoner, da de oftest vil blive brugt i situationer, hvor de ikke har brugerens fulde opmærksomhed. Ulemperne ved observationer i det naturlige miljø er, som nævnt i Observation af brugere, at de er utroligt tidskrævende, svære at kontrollere og derved svære at reproducere. På trods af de uvurderlige data en sådan test kunne generere, må vi erkende, at vi hverken har tid eller ressourcer til at lade en mobiltelefonsbruger benytte telefonen en hel dag og registrere dette. Heldigvis er vi ikke de første der står i denne situation. I artiklen Gestural and Audio Metaphors as a Means of Control for Mobile Devices [12], hvor forfatterne blandt andet ønsker, at undersøge styring af en musikafspiller på mobiltelefonen vha. gestures på touchskærmen, lader de testpersonerne bevæge sig i gang med forhindringer. FIGUR BANEN FRA TESTEN I ARTIKLEN [12] Mens de går i gangen skiftes de til at løse opgaver ved brug af touch interfacet og medieplayerens eget interface. Bagefter sammenlignes tiden det har taget at gå ruten, i forhold til når de gik og intet andet lavede. Det danner basis for sammenligningsgrundlag. I samme artikel laver de også en alternativ test, hvor testpersonen skal stå på en stepmaskine og benytte den, samtidig med at han udfører bestemte opgaver. Denne variant skal simulere hvor nemt, det er at benytte designet, mens man er i bevægelse. Ligesom i tidligere iterationer er der en række spørgsmål, vi ønsker svar på. Til den kommende evaluering er der følgende spørgsmål - Er prototypen blevet brugbar efter vi har ændret på interaktionen? - Kan prototypen bruges når du er i bevægelse? - Hvordan fungerer tilt styret scrolling

86 78 Evaluering af fjerde prototype - Hvad synes brugerne om den nuværende taktile feedback De spørgsmål der vejer tungest er, om den nye tilt-baserede navigation har en nytteværdi, og om det er anvendeligt, mens man er i bevægelse. De er nemlig afgørende for, om der skal arbejdes videre med det nuværende design eller om det skal tages op til genovervejelse. Projektet med endimensionel scrolling knytter sig ikke specifikt til tidligere arbejde, og kan derfor testes uden at kende nytteværdien for navigationen. For at teste hvordan prototypen klarer sig i bevægelse, skal deltagerne gå på et fortov, mens de bruger telefonen. De ruter der er valgt, indeholder et minimum af trafik, og det er derfor hovedsageligt selve det at gå, der kræver opmærksomhed. Det betyder også, at selvom ruterne er forskellige, varierer byrden på deltagerne minimalt. Testen af endimensionel scrolling vha. tilt bliver testet i laboratorium, hvor deltageren sidder ned og foretager testen ANALYSE I evalueringen af tredje prototype blev det klart at brugerne ikke fandt nytteværdig i designet. I denne fjerde prototype, hvor udvælgelsen af ikoner er modificeret så der bliver valgt vha. tilt og en central knap, er dette ændret. Det er en utrolig vigtig ting så vi vil godt gentage dette: flertallet af testdeltagere finder prototypen brugbar! Desværre er prototypen mindre brugbar i gående tilstand. Flere testdeltagere havde problemer med, at fokus skiftede for meget. Det hoppede midlertidigt frem og så tilbage. Det gjorde det svært at vælge det rigtige ikon og testdeltagerne satsede nogle gange, hvor de trykkede, og håbede på det rigtige ikon ville blive valgt. Andre testdeltagere havde problemer med at vælge ikoner der var placeret klokken 3 og klokken 9 i cirklen, men nemt ved at vælge ikoner der var placeret klokken 6 og klokken 12. Fælles for disse testdeltagere var, at der i udgangspunktet var en stor vinkel mellem telefonen og den horisontale linje. Det har betydning for måling af tilt og dette vil blive nævnt i Start forskel I GVektor påvirker vinklen. Deltagere udtalte også at der var for mange ikoner, og at det var for svært at vælge dem. Det kunne være et symptom på de tidligere problemer og behøver faktisk ikke være et problem i sig selv. Andre testdeltagere havde problemer med at fokus skiftede, når de trykkede den fysiske knap ind for at vælge. Det har bestemt en negativ effekt på designet, men kan også afhjælpes. Der vil også komme mere om dette i 5 Fremtidigt arbejde. Endimensionel scroll i telefonbog har en del problemer. Blandt andet blev der overshootet en del og der var i nogle tilfælde problemer med at vælge den rigtige kontakt.

87 Fjerde iteration 79 Kommentarerne omkring brugen var dog overvejende positive. Derfor er endimensionel scroll bestemt en ting, der er værd at arbejde videre med. Positivt var det også, at der opstod et minimum af uintentionelle ryst. Specielt når man tager i betragtning at scroll i telefonbog og ryst kunne være meget overlappende. Der skal dog stadig være fokus på dette i fremtidige prototyper.

88 80 Resultater fra fjerde iteration 4.6. RESULTATER FRA FJERDE ITERATION - Fokus skifter for meget mellem ikonerne. Specielt når man går - Der er blevet udtrykt tilfredshed med den måde man vælger ikoner på. - Der er tilfredshed med det taktile feedback - Det er ikke synligt hvordan telefonen skal vendes og drejes for at vælge ikoner. - Der bliver overshootet meget i telefonbogen, men hovedparten er tilfredse med tilt scrolling. - Tilt navigation skal muligvis kunne slås til og fra - Der er for mange ikoner. For svært at skifte mellem dem. - Fokus skifter i sidste øjeblik, når den fysiske knap bliver trykket ned - Ikonerne kunne godt være mere tydelige (så man ikke kan være i tvivl om, hvad de betyder) - De fysiske knapper kunne godt være bedre integreret i applikationen - Tilføjes større fejlretning - Få uintentionelle ryst

89 Fremtidigt arbejde Fremtidigt arbejde

90 82 Taktil feedback I dette afsnit vil vi beskrive nogle af de funktioner, vi gerne ville implementere, hvis vi havde tiden og de tekniske muligheder for det. Desuden vil vi også beskrive, hvordan prototypen kunne forbedres, hvis vi skulle arbejde videre på dette projekt, i flere iterationer TAKTIL FEEDBACK En af de funktioner, vi gerne så implementeret i vores applikation er taktil feedback. De fleste nyere mobiltelefoner har i dag touchskærm. Dette er en fordel i mange forskellige situationer, men det udgør også nogle nye udfordringer. Touchskærme på telefoner bliver større og større. Flere designere har derfor valgt at fjerne det fysiske tastatur på telefonen, og i stedet bruge en del af skærmen som tastatur. Dette giver problemer når man bruger tastaturet. Undersøgelser 16 viser at det er langt hurtigere at taste på et fysisk tastatur, end på en touchskærm. Grunden til dette er det feedback man får fra fysiske knapper. Derfor ville det gøre en stor forskel for brugerne af telefonen, hvis man kunne simulere knapper på skærmen. Da det er en glas-skærm, vil man ikke rent fysisk kunne lave noget lignende (og skærmen bliver også brugt til andet end tastatur). Derfor er der blevet lavet undersøgelser, hvor taktilt feedback bliver anvendt. I de situationer, bliver telefonens mulighed for vibration udnyttet. Ved at lade telefonen vibrere i meget kort tid 17 vil det ikke føles som en vibration, men nærmere som et klik. Det vil altså sige, at man ved at bruge den indbyggede vibrationsfunktion, vil kunne simulere feedback, som man kan mærke i telefonen. Der er en række forskellige udnyttelser af dette. Ulempen ved udelukkende at bruge telefonens indbyggede vibrator er, at den kun kan være tændt eller slukket, hvilket begrænser mulighederne for feedback. Vi skal nu kigge på en anden løsning der bruger telefonens højtaler. I alle mobiltelefoner, er der højttaler, og når de afspiller visse lyde, kan vibrationerne mærkes. Du har måske selv oplevet det i situationer, hvor du kunne mærke bassen fra højtalere. Det er ikke så tydeligt i de fleste telefoner, men der eksisterer telefoner, som har en speciel forstærker af disse lyde. Telefonen som er brugt i dette projekt har ikke denne forstærker men i de telefoner 18 hvor det forefindes vil det kunne udnyttes til taktilt feedback. Grunden til at det virker er, at det ikke er alle udsendte frekvenser der kan høres med det menneskelige øre. De frekvenser der ligger mellem ca. 100 og 300hz vil ikke kunne blive hørt. De vil dog (med det rette udstyr) kunne mærkes ved at telefonen vibrerer. For at simulere et fysisk tastatur, er der forskellige overvejelser for, hvornår vibrationerne skal bruges. Hvis man bruger et fysisk tastatur på en mobiltelefon, kan man mærke knapperne når man enten: 16 Bl.a. [48] 17 Cirka ms) 18 [47], [46], [40], [35], [38]

91 Fremtidigt arbejde 83 Kører fingeren hen over knapperne uden at trykke nogen ned eller Trykker en knap ned De to situationer skal betragtes hver for sig, da de indeholder nogle forskellige elementer og forskellige overvejelser i forbindelse med implementeringen. I den første situation kan man mærke knapperne, hvis man udelukkende kører en finger let hen over skærmen. Dette vil kunne simuleres ved, at have forskellige vibrationer på forskellige punkter. Nedenfor er en tegning af to knapper. Der er markeret 4 punkter på denne. Ved punkt 1 og 3 rammes en kant. Derfor skal der være en kort vibration, der antyder, at man har ramt kanten. Ved punkt 2 holdes fingeren direkte over en knap (den er ikke trykket ned ). Her skal det føles at fingeren er over en knap ligesom på et fysisk tastatur, hvor man der kan mærke at knappen er ru. Ved punkt 4 er der ingen feedback, da man ikke kan mærke nogen knapper. FIGUR VIBRATION OVER KNAPPERNE HENVISNING! For at illustrere hvordan frekvenserne (styrken af vibrationen) er i de forskellige situationer, har vi herunder lavet et diagram over det. Der er ikke sat frekvensstyrker på, da dette ville blive undersøgt i den situation hvor det ville blive brugt. Der er i stedet angivet, om der er ingen, let eller moderat vibration i de forskellige situationer. FIGUR VIBRATION VED FINGER OVER TASTER Hvis man derimod klikker på en af knapperne på tastaturet, skal denne også føles som en rigtig knap. Derfor er der i (Henvisning!) beskrevet hvordan man ville gøre dette. Tegningen herunder viser hvordan vibrationen ville være. Idet knappen bliver trykket ned, kommer der en kort men kraftig vibration. Dette simulerer det der kan mærkes, hvis en virkelig knap bliver trykket helt i bund. I den situation, vil man kunne mærke det når knappen rammer bunden, og man ved at knappen er holdt inde. Derefter har vi markeret en let vibration så længe knappen bliver holdt nede. På den måde kan man tydeligt mærke forskel på, at holde en knap nede og at slippe den igen. Når knappen så bliver sluppet, vil der igen ingen vibration være.

92 84 Taktil feedback Hvis vi ville implementere dette, ville vi teste om det gav mening, at udsende endnu en kort vibration idet knappen bliver sluppet, hvis det ikke er tydeligt som det er beskrevet. FIGUR VIBRATION VED TRYK PÅ TAST

93 Fremtidigt arbejde FREE FORM GESTURES Da der i telefonen er et indbygget accelerometer, ville det være oplagt, at udnytte denne viden til at forbedre interaktionen. Det kunne som tidligere nævnt være at lave free form gestures. Der er mange muligheder for, hvilke former for free form gestures man kan lave, men spørgsmålet er, om de medfører en forbedret interaktion, eller de udelukkende bliver implementeret for at vise, at det er muligt. Derfor vil vi gerne undersøge mulighederne for at udnytte free form gestures i et tilfælde, hvor det vil være til gavn. Lang de fleste applikationer på en mobiltelefon kræver, at man kigger på skærmen. Da free form gestures besværliggør visuel kontakt, på grund af betragtnings vinkel og bevægelse, er de bedst brugt i tilfælde, hvor visuel feedback ikke er en nødvendighed. Musikafspilleren er et godt eksempel på dette og der er før lavet mobiltelefoner hvor musikafspilleren bliver styret netop af free form gestures[103]. Vi vil kort gennemgå noget teori omkring implementationen. De to gestures vi hidtil har koncentreret os mest om er tilt og ryst. Indtil prototypen i 4. iteration har de to bevægelse ikke overlappet i nogen del af menuen. Det har med andre ord enten været ryst eller været tilt, som har kunnet påvirke programmet. I forbindelse med implementeringen af tilt-baseret scrolling i telefonbogen ophørte denne adskillelse og det førte til komplikationer. Men kan flere bevægelser være implementeret på samme tid? Det vil vi nu undersøge. Først i forbindelse med højre flyt kaldet HFlyt, af mobilen. Fra tidligere afsnit ved vi at state machinen for ryst ser således ud: Distance(newV, oldv) <= n Distance(newV, oldv) <= n OR 0 <= DotP(newV, oldv) n < Distance(newV, oldv) AND Initial state n < Distance(newV, oldv) Halfshake Shaking DotP(newV,oldV) < 0 FIGUR STATE MACHINE FOR RYST Når ryst er den eneste bevægelse der var implementeret er denne definition fuldt ud funktionsdygtig, men i kombination med HFlyt opstår der interferens. Skal de to bevægelser adskilles, synes der at være to mulige løsninger: 1. Telefonen kan ikke længere rystes i horisontal retning. Denne bevægelse er nu forbeholdt højre (og venstre flyt). 2. Man kan se på timingen og længden af bevægelsen Løsning 2 er den mest fleksible af de to muligheder, og det er den, der vil blive arbejdet videre på. I HFlyt vil telefonen hvile et stykke tid efter, at den er flyttet til højre, før den

94 86 Free form gestures returnerer til startpositionen. Det er ikke tilfældet med ryst, der straks vil bevæge sig tilbage igen. n < Distance(newV, oldv) AND L.Acc Relax State 1 Distance(newV, oldv) < n n <= Distance(newV, oldv) Relax State 2 n <= Distance(newV, oldv) Distance(newV, oldv < n) Shaking n < Distance(newV, oldv) AND R.Acc Shaking n < Distance(newV, oldv) AND DotP(newV,oldV) < 0 Relax State 3 Distance(newV, oldv < n) n < Distance(newV, oldv) AND R.Acc HalfShake! R.Acc. AND n < Distance(newV, oldv) Waiting for new input state R.Acc. AND n < Distance(newV, oldv) 1/3 Shake L.Acc 2/3 Shake Distance(newV, oldv) <= n Distance(newV, oldv) <= n RightMove Distance(newV, oldv) <= n OR 0 <= DotP(newV, oldv) Distance(newV, oldv) <= n! L.Acc n < Distance(newV, oldv) AND! R.Acc n < Distance(newV, oldv) AND! R.Acc Distance(newV, oldv) <= n OR! L.Acc Allerede med to free form gestures, er statemachinen blevet en hel del mere kompleks. Det er tilfældet selvom det er muligt, som state machinen illustrerer, at lave HFlyt selvom du ikke laver den korrekte bevægelse. Det skyldes meget fleksible krav til accelerationerne. Teoretisk set skulle man kræve, at accelerationerne var af en sådan art, at telefonens hastighed i hvile-positionen er nul, af praktiske grunde vil dette ikke være muligt. Grunden til dette vil blive forklaret nedenunder. Komplikationer med free form gestures En af de største komplikationer ved implementeringen af free form gestures på denne telefon er regnekraften i telefonen. Målingerne og genkendelsen af free form gestures sker i parallel med de øvrige processer bliver afviklet. Med en processor med begrænset regnekraft kommer de to ofte i karambolage. Derfor er intervallet, hvorved der bliver målt på GVektoren forholdsvis stort. I free form gestures, hvor det er øjeblikspostionen, der er den afgørende faktor, er ikke følsomme overfor dette. Det er GVektoren nu der er afgørende, og ikke de bevægelser der foregik inden. I den situation hvor man ønsker at registrere en længere bevægelse, bliver det mere kompliceret. Det er typisk ikke en enkel specifik accelerationsmåling, der afgør, om det er den ene eller den anden gesture brugeren forsøger at udføre. Det virkeligt afgørende er mobiltelefonens position som en funktion af tiden. Ved et tidsinterval der nærmer sig nul omdannes accelerationsmålingerne til en præcis stedfunktion, så kan man med sikkerhed registrere og genkende bevægelsen. Forskellene mellem et lille og et stort tidsinterval for målingerne kan illustreres med de to figurer, der er dannet ved ens accelerations vektorer. Hvis der bliver målt uendeligt mange gange under en cirkelbevægelse, bliver det også

95 Fremtidigt arbejde 87 registreret som en cirkel. Bliver der derimod kun målt fire gange, risikerer man at få en firkant i stedet. Se Figur Genkendelse af figurer. FIGUR GENKENDELSE AF FIGURER Det kan være ret uheldigt og gør det svært at kende forskel på de forskellige gestures. Skal der derfor implementeres flere gestures simultant, er det vigtigt enten at have en hurtig processor eller begrænse den kode, der skal afvikles i parallel. Eller begge! Flere programmører har måttet erfare, at implementeringen af free form gestures ikke er helt triviel. Blandt andet i spil som Wii sports kan du holde din Wiimote som en fiskestang i stedet for en golfkølle og stadig få udmærkede resultater. Det kommer i konflikt med simuleringen af virkeligheden, men gameplayet er stadig intakt. Værre er det for Xboxspillet Lips 19, hvor du kan udføre flere af de forskelligt definerede gestures ved at ryste mikrofonen intenst nok, hvilket bestemt ikke har været intentionen fra start af. 19 Lips er et karaoke sangspil, hvor du skal ramme tonerne i sangen så præcist som muligt. Derudover kan du få bonuspoint, ved at lave specifikke free form gestures med mikrofonen når symbolet for dem vises på skærmen

96 88 Forbedringer af prototypen 5.3. FORBEDRINGER AF PROTOTYPEN START FORSKEL I GVEKTOR PÅVIRKER VINKLEN. Allerede i teorien i tredje iteration var der betragtninger omkring hvordan startvinklen kunne påvirke målingen af tilt. Så længe tyngdekraften er den eneste kraftpåvirkning gælder der at: Lign 1: a x = g cos φ sin(θ) Lign 2: a y = g sin φ Lign 3: a z = g cos φ cos(θ) Det er ud fra disse ligninger klart at den samme ændring i vinklen i forskellige udgangspunkt vil give uens forskelle i accelerationen. Et eksempel på dette er: ay = sin g sin 0 g = 1,70 m s 2 ay = sin g sin 40 g = 1,21 m s 2 Udgangspunktet spiller også en stor rolle for lign 1. θ vil typisk være nul i udgangspunktet hvis telefonen bliver holdt på en normal måde. Men udgangspunktet spiller igen en rolle i form af φ. Derfor burde man strengt taget kigge på forskelle i vinkler frem for forskelle i acceleration. Hvis dette er for beregningskrævende for telefonen, burde man som minimum gange en faktor på accelerationsværdierne alt efter udgangspunktet. Denne optimering af tiltmålingen er noget, der er vigtigt i det fremtidige arbejde UNDERSTØTTELSE AF KONCEPTUEL MODEL En ting der er meget essentiel i udarbejdelsen af brugervenlige produkter, er understøttelsen af brugerens konceptuelle model. En korrekt konceptuel model bevirker, at der er få uklarheder for brugeren, og at programmet bliver nemt at bruge og relatere til. Man kan hjælpe brugeren til at opdage den reelle model for systemet vha. feedback. Spørgsmålet er så om det er gjort ordentligt i dette projekt. Grundideen der består af at tilte telefonen og derved vælge et ikon, synes at være nemt at relatere til, men der er en lang række ting, der kunne forbedres. For eksempel en indikator af hvor meget telefonen er tiltet, hvor langt man er fra udgangspunktet (nulpunktet) og hvor meget telefonen skal tiltes for at vælge et ikon. Det er alt sammen spørgsmål, der er værd at undersøge nærmere. En implementeringsmulighed der er nævnt tidligere, er en udvælgelse af ikoner med en kugle, som man styrer med tyngdekraften. Den er også beskrevet i Kenneth Ahrensberg rapport[56]. En ulempe ved Kugle-ideen er, at kuglen bevæger sig relativt, hvorimod designet er bygget på statiske placeringer af telefonen. Derfor vil den konceptuelle model bryde med det virkelige design. En anden løsning der synes mere oplagt er, at lave en slags kompas. Kompasnålen vil da

97 Fremtidigt arbejde 89 udtrykke, hvordan telefonen bliver holdt. Samtidigt kunne længden af nålen variere, alt efter hvor meget telefonen er tiltet. Denne konceptuelle model synes at stemme bedre overens med designet, og ville være den der ville blive fokuseret på i første omgang UFRIVILLIGE BEVÆGELSER De små rystelser der forekommer, når man går, havde en stor effekt på navigationen i prototypen fra fjerde iteration. En del af disse gener vil blive løst, ved at tage højde for telefonens vinkel i udgangspositionen, men ikke alle. De små accelerationer som kun bliver målt et øjeblik vil stadig få telefonens fokus til at hoppe rundt. En løsning på dette kunne være at foretage mange målinger. Da kunne GVektoren betragtes ikke kun ud fra dets øjeblikkelige værdi men ud fra dets historik, og man vil kunne vurdere om bevægelser er ufrivillige og momentære eller om de er bevidste. En overregularisation vil betyde at telefonen forekommer træg, så igen er det et spørgsmål om at finde den rette balance FOKUS SKIFT VED TRYK PÅ FYSISK KNAP Nogle brugere vil opleve at fokus skifter imens de trykker på den fysiske knap. Igen kunne man håbe, at de øvrige tiltag vil stoppe dette fænomen. Det er dog ikke sikkert. Ved en statisk undersøgelse kunne man finde gennemsnitsværdien og spredningen for tiden det tager fra en bruger begynder at trykke på knappen til telefonen registrere trykket. Er spredningen tilpas lille, kunne man vælge ikke at klikke på det ikon, der er fokuseret når telefonen registrerer trykket, men derimod det ikon der fokuseret for et tidsinterval siden, der nogenlunde svarer til gennemsnitstiden for et tryk. Derved vil man vælge det rigtige ikon, selvom trykket på den fysiske knap får fokus til at skifte ufrivilligt.

98 90 Designets begrænsninger 5.4. DESIGNETS BEGRÆNSNINGER Gennem de tidligere iterationer og med implementeringen af de øvrige ændringer i prototypen der er beskrevet i 5.3 Forbedringer af prototypen vil designet være optimeret i en sådan grad, at det kan bruges i hverdagen. Det er derfor nye aspekter af designet, der skal fokuseres på, hvis det skal effektiviseres yderligere. En ting der kunne være meget aktuelt at undersøge er forholdet mellem tid for udvælgelse og antallet af ikoner. Altså hvordan antallet af ikoner påvirker den tid, det tager at vælge et ikon. Jo flere ikoner der er, des mindre et interval er der til hvert ikon, og derfor er det sværere at vælge. Der kommer flere og flere applikationer og en hurtig tilgang til disse er vigtigt, derfor er dette så interessant at undersøge. Et aspekt i forbindelse med designet der kunne være interessant at undersøge er, hvordan ikonernes placering i cirklen påvirker udvælgelsestiden og evt. også hvor behageligt det er, at vælge de enkelte ikoner. Ud fra denne test kunne man optimere placeringen af de enkelte ikoner, så de ikoner der var nemme at vælge, er de der bliver brugt hyppigst. Det vil uden tvivl give en bedre interaktion og forbedre designets ydelse.

99 Afslutning Afslutning

100 92 Konklusion 6.1. KONKLUSION Denne rapport har gennemgået den udviklingsproces, der er foretaget for at skabe et brugercentreret produkt. Produktet bestod af en forbedring af den nuværende interaktion på en HTC Touch Diamond. Testdeltageres brug af mobiltelefoner og de individuelle applikationer på mobiltelefoner blev registreret med dagbøger som testdeltagerne førte i en 24 timers periode, for at undersøge folks interaktion med deres mobiltelefoner. Dette blev afsluttet med et interview der kastede yderligere lys på, hvad testpersonerne brugte deres mobiltelefonen til og hvad de forventede af en mobiltelefon. Med udgangspunkt i den eksisterende menustruktur er der blevet lavet diagrammer, der beskriver den nuværende interaktion og navigation på telefonen. Ikke alene var denne menustruktur uoverskuelig, men den var også svær at bruge. Vha. design-ideer og brugertest er vi kommet frem til at denne interaktion kan simplificeres betydeligt. Blandt andet kan indbakke, udbakke og udkast for SMS'er kombineres i et menupunkt. Derudover kan man betragte en MMS som en SMS med en vedhæftet fil, hvilket stemmer overens med modellen for s. På baggrund af disse simplificeringer og yderligere ideer, blev der udviklet en prototype, der kunne brugertestes. Disse brugertests har været afgørende for den videre udvikling i projektet. Gennem hele processen er prototypernes kvalitet blevet testet vha. verbal rapportering for at sikre et højt niveau og at de rette forbedring blev lavet. Ud af disse iterationer er der kommet en prototype, som gør det muligt at navigere ved brug af tilt og en enkelt fysisk knap. Det kan videre kombineres med endimensionel tilt, som også er blevet implementeret i prototypen. Det har på nuværende tidspunkt ikke været muligt at lave en telefon, der er mindre opmærksomhedskrævende. Der er dog blevet udviklet en prototype, der fungerer hovedsageligt vha. tilt, som brugerne finder brugbar. Med de ændringer der er beskrevet i fremtidigt arbejde forventer vi at prototypen vil nå op på et stadium, hvor den er mindre opmærksomhedskrævende end det nuværende design. Derudover har vi i fremtidigt design beskrevet andre forbedringer, der kunne højne brugeroplevelsen.

101 Referenceliste Referenceliste

102 94 Artikler 7.1. ARTIKLER [1] : Halo: a Technique for Visualizing Off-Screen Locations (Patrick Baudisch, Ruth Rosenholtz) [2]: Multi-Context Photo Browsing on Mobile Devices Based on Tilt Dynamics(Sung-Jung Cho,Roderick Murray-Smith,Yeun-Bae Kim) [3]: Tilt-Based Automatic Zooming and Scaling in Mobile Devices a state-space implementation (Parisa Eslambolchilar1, Roderick Murray-Smith) [4]: WEST: A Web Browser for Small Terminals (Staffan Björk,Lars Erik Holmquist,Johan Redström,Ivan Bretan,Rolf Danielsson,Jussi Karlgren,Kristofer Franzén) [5]: WebThumb: Interaction Techniques for Small-Screen Browsers (Jacob O. Wobbrock, Jodi Forlizzi, Scott E. Hudson, Brad A. Myers) [6]: SmartView: Enhanced Document Viewer for Mobile Devices (Natasa Milic-Frayling,Ralph Sommerer ) [7]: SenSay: A Context-Aware Mobile Phone (Daniel Siewiorek, Asim Smailagic, Junichi Furukawa, Neema Moraveji, Kathryn Reiger, and Jeremy Shaffer ) [8]: Tilt Menu: Using the 3D Orientation Information of Pen Devices to Extend the Selection Capability of Pen-based User Interfaces (Feng Tian1, Lishuang Xu1, Hongan Wang1, 2, Xiaolong Zhang3, Yuanyuan Liu1, Vidya Setlur4, Guozhong Dai) *9+: Multimodal Eyes-Free Interaction Techniques for Wearable Devices (Stephen Brewster, Joanna Lumsden, Marek Bell, Malcolm Hall and Stuart Tasker) [10]: Wrist Rotation for Interaction in Mobile Contexts (Andrew Crossan, John Williamson, Stephen Brewster, Rod Murray-Smith ) [11]: Culturally Adapted Mobile Phone Interface Design: Correlation between Categorization Style and Menu Structure (Ji Hye Kim,Kun Pyo Lee ) [12]: Gestural and Audio Metaphors as a Means of Control for Mobile Devices (Antti Pirhonen,Stephen Brewster and Christopher Holguin ) [13]: Improving Mobile Internet Usability (George Buchanan, Sarah Farrant, Matt Jones, Harold Thimbleby3Gary Marsden,Michael Pazzani ) [14]: Walk n Scroll: A Comparison of Software-based Navigation Techniques for Different Levels of Mobility (Bonnie MacKay, David Dearman, Kori Inkpen and Carolyn Watters ) [15]: Making a Completely Icon-based Menu in Mobile Devices to become True: A Usercentered Design Approach for its Development (Sabine Schröder,Martina Ziefle )

103 Referenceliste 95 [16]: Mobile Interaction Using Paperweight Metaphor (Itiro Siio, Hitomi Tsujita) [17]: Web Clipping: Compression Heuristics for Displaying Text on a PDA (PEDRO GOMES, SÉRGIO TOSTÃO, DANIEL GONÇALVES, JOAQUIM JORGE) [18]: Multimodal Feedback for Tilt Controlled Speed Dependent Automatic Zooming (Parisa Eslambolchilar, John Williamson2,Rod Murray-Smith) [19]: Power Browser: Efficient Web Browsing for PDAs (Orkut Buyukkokten, Hector Garcia Molina, Andreas Paepcke, Terry Winograd) [20]: Model-Based Evaluation of Exper t Cell Phone Menu Interaction (ROBERT ST. AMANT and THOMAS E. HORTON) [21]: Summary Thumbnails: Readable Overviews for Small Screen Web Browsers ( Heidi Lam, Patrick Baudisch) [22]: Tapping and Rubbing: Exploring New Dimensions of Tactile Feedback with Voice Coil Motors (Kevin A. Li1, Patrick Baudisch3, William G. Griswold1, James D. Hollan) [23]: Shift: A Technique for Operating Pen-Based Interfaces Using Touch (Daniel Vogel,Patrick Baudisch) [24]: Precise Selection Techniques for Multi-Touch Screens (Hrvoje Benko,Andrew D. Wilson, Patrick Baudisch) [25]: Collapse-to-Zoom: Viewing Web Pages on Small Screen Devices by Interactively Removing Irrelevant Content (Patrick Baudisch1, Xing Xie2, Chong Wang3, and Wei-Ying Ma2) [26]: Accelerometer-based gesture control for a design environment (Juha Kela,Panu Korpipää, Jani Mäntyjärvi, Sanna Kallio, Giuseppe Savino, Luca Jozzo Sergio Di Marca) [27]: One-Handed Touchscreen Input for Legacy Applications(Amy K. Karlson and Benjamin B. Bederson) [28]: Can we do without GUIs? Gesture and speech interaction with a patient information system (Eamonn O Neill, Manasawee Kaenampornpan,Vassilis Kostakos, Andrew Warr, Dawn Woodgate) [29]: Tilt and Feel: Scrolling with Vibrotactile Display (Ian Oakley, Jussi Ängeslevä, Stephen Hughes, Sile O Modhrain ) [30]: Squeeze me, Hold me, Tilt me! An Exploration of Manipulative User Interfaces (Beverly L. Harrison, Kenneth P. Fishkin, Anuj Gujar, Carlos Mochon, Roy Want)

104 96 Artikler [31]: High Precision Touch Screen Interaction (Pär-Anders Albilsson, Shumin Zhai) [32]: Performance optimization of virtual keyboards (Shumin Zhai, Michael Hunter, Barton A. Smith) [33]: The design space og input devices (Stuart K. Card, Jock D. Mackinlay, George G. Robertson) [34]: Modelling human performance of pen stroke gestures ( Xiang Cao, Shimin Zhai) [35]: Tactile interfaces for small touch screens (I Poupyrev, S Maruyama) [36]: Tactile feedback for mobile interactions (S Brewster, F Chohan, L Brown) [37]: A role for haptics in mobile interaction: initial design using a handheld tactile display prototype (J Luk, J Pasquero, S Little, K MacLean, V Lévesque, V Hayward) [38]: TouchEngine: A tactile display for handheld devices (Ivan Poupyrev, Shigeaki Maruyama, Jun Rekimoto) [39]: Tactile vitual buttons for mobile devices (Andrew Nashel, Sharif Razzaque) [40]: Feel-good touch: Finding the most pleasant tactile feedback for a mobile touch screen button (Emilia Koskinen, Topi Kaaresoja, Pauli Laitinen) [41]: Dynamics and probability text entry (John Williamson, Roderick Murray-Smith) [42]: Investigting the effevtiveness og tactile feedback for mobile touchscreens (Eve Hoggan, Stephen A. Brewster, Jody Johnston) [43]: Tangible bits: Towards seamless interfaces between people, bits and atoms (Hiroshi Ishii, Brygg Ullmer) [44]: Design and development of an everyday hand gesture interface (Zoltán Prekopcsák, Péter Halácsy, Csaba Gáspár-Papanek) [45]: Designing Audio and tactile crossmodal icons for mobile devices (Eve Hoggan, Stephen Brewster) [46]: Investigating the effectiveness of tactile feedback for mobile touchscreens (Eve Hoggan, Stephen A. Brewster, Jody Johnston) [47]: Audio-haptic feedback in mobile phones (Angela Chang, Conor O'Sullivan) [48]: The performance of touch screen soft buttons (Seungyon "Claire" Lee, Shumin Zhai)

105 Referenceliste 97 [49]: The Role of Kinesthetic Reference Frame in Two-Handed Input Performance (Ravin Balakrishnan, KenHinckley) [50]: Gestural and Audio Metaphors as a Means of Control for Mobile Devices (Antti Pirhonen, Stephen Brewster and Christopher Holguin) [51]: Text entry using soft keyboards (I. SCOTT MACKENZIE, SHAWN X. ZHANG and R. WILLIAM SOUKOREFF) [52]: Snap-Crackle-Pop: Tactile Feedback for Mobile Touch Screens (Topi Kaaresoja, Lorna M. Brown, Jukka Linjama) [53]: Multidimensional Tactons for Non-Visual Information Presentation in Mobile Devices (Lorna M. Brown, Stephen A. Brewster and Helen C. Purchase) [54]: Ambient touch: Designing tactile interfaces for handheld devices (Ivan Poupyrev, Shigeaki Maruyama, Jun Rekimoto) [55]: Designing audio and tactile crossmodal icons for mobile devices (Eve Hoggan, Stephen Brewster) [56]: Literature study of mobile platform accelerometers (Kenneth Ahrensberg) [57] An intuitive text input method for touch wheels. In: Proceedings of ACM CHI 2006 Conference on Human Factors in Computing Systems 2006 (Proschowsky, Schultz and Jacobsen) 7.2. LINKS [100]: _MDK379.dbp.asp?iForum=9&iNoteRoot=68327&iNote= februar 2009 [101]: februar 2009 [102]: Design and User Experience Library v index.jsp?topic=/ Design_and_User_Experience_Library/GUID-F18BEFA6-A E- B6C6- DD489DB7937E.html- 25. juli 2009 [103]: cc=dk&lc=da juli 2009 [104]: juli 2009 [105]: juli 2009

106 98 Bøger [106]: 6/8-09 (oversat af CVZ) [107]: 6. august 2009 [108]: august 2009 [109]: august 2009 [110]: august 2009 [111]: august 2009 [112]: august BØGER [150]: Interaction design - Beyond human-computer interaction 2. ed (Sharp, Rogers, Preece) [151]: Mobile Interaction Design 1. ed (Jones, Marsden) [152]: Cognition Exploring The Science Of The Mind 3.ed (Daniel Reisberg)

107 Appendiks A Første iteration Appendiks A Første iteration

108 100 Appendiks A1 Hovedspg til 1. dataindsamling 8.1. APPENDIKS A1 HOVEDSPG TIL 1. DATAINDSAMLING Hovedspørgsmål: Hvordan bruger testdeltagerne mobiltelefonen og dens funktioner samt hvilke generelle problemer opstår i interaktionen? Hvilken baggrund har deltageren - både personlige oplysninger og erfaring med mobiltelefoner? Hvordan navigerer du til den funktion Top 5(?) prioriteret liste over de mest brugte funktioner Hvilke funktioner deltagerne bruger mest i egne telefoner Hvor ofte bruges de forskellige funktioner? Problemer med telefonen i tidligere situationer Har du stået i en situation, hvor du ville gøre noget på mobilen, men ikke kunne Oplever du nogle irritationsmomenter ved brug af mobilen? Forslag til løsninger for vores projekt ud fra egen telefon Nævn 3 gode ting Nævn 3 ting der kunne forbedres Ønsker til hvilke funktioner der skulle være nemmere på deres egen telefon - og som er vigtige at have med i vores Hvis du skulle vælge at have genvej til 8 funktioner på telefonen, hvilke skulle det så være? Hvis du skulle gøre en ting nemmere på telefonen, hvad skulle det så være? 8.2. APPENDIKS A2 INTRODUKTION TIL DAGBOG Dette er en undersøgelse af hvordan folk bruger deres mobiltelefoner. Det er en del af vores bachelorprojekt, hvor vi vil forsøge at forbedre menusystemer og navigation i forhold til mobiltelefoner. Vores mål med denne undersøgelse er at få viden om hvilke funktioner i mobiltelefonen, der er de mest brugte og i den forbindelse hvordan man løser typiske opgaver på telefonen. I den forbindelse er vi interesserede i hvordan du bruger din mobiltelefon. Derfor beder vi dig om, at føre en "mobil-dagbog". Det vil sige, at du i løbet af 1-2 døgn (valgfrit) skal skrive alle de ting du bruger din mobiltelefon til ned. Det skal altså være kortere notater, hvor du beskriver dit "mål" og hvordan du opnåede det. For hver gang du benytter din mobiltelefon skal du skrive en notits i dagbogen, hvor du beskriver dine handlinger. Hvis du laver en handling flere gange (f.eks. sende en sms), skal det kun beskrives en enkelt gang. Ved samme handling senere, kan der henvises tilbage til den grundige forklaring. Du må ikke være bange for, at skrive ligegyldige informationer. Vi ønsker at vide så meget som muligt, hvilket også vil sige, at vi er interesserede i at vide når noget ikke går som planlagt. derfor må alle fejl/problemer også meget gerne blive noteret.

109 Appendiks A Første iteration 101 Et eksempel på en note i dagbogen kunne være: "Note #: 1 Mål: Jeg har fået en sms og ønsker at læse denne Handlinger: Jeg låser mobilen op ved at trykke * og derefter 9 Jeg trykker vælg Jeg trykker ok Jeg læser beskeden Jeg trykker tilbage og lægger telefonen tilbage i lommen" Fremtidige noter hvor jeg benytter samme fremgangsmåde kan så skrives således "Note #: 4 Se note 1" Et andet eksempel er "Note #: 6 Mål: Jeg vil gerne sende en besked til min ven Handlinger: Jeg låser mobilen op ved at trykke * og derefter 9 Jeg trykker "menu" Jeg vælger "besked" i menuen og trykker vælg Jeg vælger "korte meddelser" Jeg trykker "opret" Jeg skriver "beskeden" Jeg vælger "funktion" Jeg vælger "send kun" Jeg trykker "funktion" Jeg vælger "telefonbog" jeg finder min ven i telefonbogen og trykker vælg Jeg trykker "funktion" jeg vælger "send" Jeg trykker "tilbage" og lægger telefonen tilbage i lommen" Formålet med denne undersøgelse er som sagt, at finde ud af, hvordan de bliver brugt. Som opfølgning på de ting du har noteret i dagbogen, vil vi gerne afslutte med et interview. I den forbindelse vil vi gerne stille en række spørgsmål til både de ting der er noteret i dagbogen, men også hvis vi har andre uddybende spørgsmål. De informationer vi får fra både dagbogen og interviewet, vil vi bruge til at lave en prototype. Vi vil altså tage udgangspunkt i de problemer vi finder, og vil forsøge at lave en løsning, der både løser problemerne, men også sætter de vigtigste/mest brugte funktioner i centrum.

110 102 Appendiks A3 Checkliste til interview I denne test er det vigtigt, at det ikke er en test af dig! Det er en test af hvordan mobiltelefoner er at bruge og forstå. Derfor er det også vigtigt, at vi hører både om de vigtige ting, men også om hvornår det ikke gik som forventet. På forhånd tak! Med venlig hilsen Christian og Bettina 8.3. APPENDIKS A3 CHECKLISTE TIL INTERVIEW Alder Stilling Mobil kendskab? Mobil? Har den mobile touch/accelerometer? Hvilke funktioner på mobilen synes du selv du bruger mest? Top 5 Har du stået i situation hvor din mobil ikke levede op til dine forventninger? Oplever du irritationsmomenter ved brug af mobilen Hvis du skulle vælge at have genvej til 3 ting på din mobil telefon hvad skulle det så være Nævn tre gode ting ved din mobil Nævn tre ting du ville forbedre hvis du kunne Er der noget du mener din mobil mangler Hvad synes du om at føre mobil dagbog? Har du yderligere kommentarer? 8.4. APPENDIKS A4 RESULTATER FRA INTERVIEW Mobil kendskab? Evt på en skala fra 1 til 5 4: 2 5: 1 Mellem 4 og 5: 2 Har den mobile touch/accelerometer? Touchskærm ja: 3 Touchskærm nej: 3 Accelerometer ja: 2 Accelerometer nej: 4 Hvilke funktioner på mobilen synes du selv du bruger mest? Top 5 Sms - 6 Internet - 2 Se hvad klokken er - 2

111 Appendiks A Første iteration 103 Modtage opkald - 1 Ringe - 6 Læse s - 2 Spille spil - 2 Musikafspiller/radio - 3 Ændre status - 1 Alarm - 3 Regnemaskine -1 Kamera -1 Har du stået i situation hvor din mobil ikke levede op til dine forventninger? - Sende s - Ville gerne læse i telefonbogen under en samtale - Kunne godt tænke mig, at kunne have flere indtalte beskeder på telefonsvareren - Tastaturlåsen bliver slået fra i lommen, så den ringer selv op - Ikke helt simpelt at låse tastaturet Oplever du irritationsmomenter ved brug af mobilen - Touchskærmen kan være svær at stryre, da det kræver stor nøjagtighed - Standartopsætninten er irriterende, fordi man skal trykke for mange taster for at lave noget - Kan ikke slå den fra, så den ikke vibrerer mere - Ordbogen kunne godt være lidt bedre Hvis du skulle vælge at have genvej til 3 ting på din mobil telefon hvad skulle det så være sms - 5 Internet - 1 Opkald - 2 Telefonbog Indbakke - 2 Noter - 1 Kalender - 2 Musikafspiller - 1 Kamera - 1 Hurtigknap til kamera - 1 Bogmærker til hjemmeside - 1 Sende sms til specifik person - 1 Nævn tre gode ting ved din mobil - Den kan de ting jeg har brug for - Den er lækker at bruge og ser lækker ud - Godt kamera - Godt at den har touchskærm - Gode applikationer - Kan hente mail

112 104 Appendiks A5 Brugerkarakteristikker - Den fylder ikke meget - Kan se hvad klokken er - Musikafspilleren - At have et helt keyboard at skrive på - Den er hurtig - Let at skrive sms'er - Kan ændre en del ude på "skrivebordet", så der kan lægges genveje direkte - 3g Nævn tre ting du ville forbedre hvis du kunne - Bedre touchskærm - Kameraet kunne være bedre - -applikationen kunne godt være bedre - Større skærm - En hurtig indbakke, så den ikke bliver langsommere, fordi der er mange beskeder i indbakken - Større valgfrihed, så der kan laves genveje til alle funktioner på telefonen, i stedet for en kort liste Har du yderligere kommentarer? - Kan godt lide at have en liste af applikationer i bunden af skærmen (genveje) - Synes telefonen burde være meget responsive, så telefonen reagerer med det samme, hvis man gør noget på skærmen - Posistivt hvis accelerometer kunne blive brugt - Vil gerne kunne gøre telefonen mere personlig, så egne genveje kunne laves mm. - Der kunne godt være et valg mellem om menuen skal vises som liste eller grid - Det kunne godt være mere brugerdefineret, så man selv kan indstille sin telefon mere end man kan nu 8.5. APPENDIKS A5 BRUGERKARAKTERISTIKKER Teknisk begejstret bruger - Bruger telefonen meget i hverdagen - Ønsker at telefonen skal kunne tilpasses i høj grad - Stor teknisk viden - Bruger mange forskellige funktionaliteter i telefonen - Bruger også telefonen som underholdning - Synes det er vigtigt, at telefonen har et pænt udseende år Den seriøse bruger - Bruger telefonen meget i hverdagen - Stor teknisk viden

113 Appendiks A Første iteration Synes teknisk funktionalitet er vigtigst - Bruger mange forskellige funktionaliteter i telefonen - Bruger udelukkende telefonen til praktiske ting år Medarbejderen - Bruger primært telefonen som arbejdstelefon - Lægger stor vægt på hvor hurtig telefonen er - Har stort kendskab til de funktioner der bliver brugt mest - Det funktionelle er i højsædet både indvendigt og udvendigt - Bruger udelukkende telefonen til praktiske formål - Bruger kun telefonen som et redskab år Den uøvede bruger - Bruger kun telefonen sporadisk - Bruger kun få af telefonen funktioner - Har et begrænset kendskab til telefoner - Bruger udelukkende telefonens basisfunktioner - Bruger kun telefonen i praktisk øjemed - 30-? Teenageren - Bruger telefonen meget i hverdagen - Lægger stor vægt på at have den nyeste teknologi - Har begrænset teknisk viden - Bruger hovedsageligt enkelte funktioner i telefonen - Bruger i høj grad telefonen som underholdning år 8.6. APPENDIKS A6 PERSONAS Martin er 21 år og er IT studerende på Danmarks Tekniske Universitet. Han bor på kollegium og lever primært af sin SU. På trods af sin lave indkomst har Martin altid en af de nyeste mobiler. Martin har nemlig stor forkærlighed for elektronik og såkaldte gadgets og går op i den nyeste teknologi med liv og sjæl "Fremtiden er her nu" elsker Martin at citere. For ham er mobilen legeså meget et "legetøj" som et værktøj. Han udforsker gerne de forskellige funktioner og elsker at sætte sit personlige præg på telefonen vha indstillinger.

114 106 Appendiks A7 Liste af funktioner i telefon Jo mere den kan indstilles des bedre "Det er super smart!". Martins drømmetelefon er en, der er sjov at bruge og som udnytter det nyeste "li'r" på en smart måde. Eigil er 29 år og er lige blevet færdig med sin uddannelse. Eigil har et godt kendskab til mobiltelefoner, og et relativt godt kendskab til hvad der rører sig på mobilfronten. Eigil går med skjorte og slips til hverdag og det er vigtigt at hans telefon også har et pænt ydre. Han bruger også et bredt spektrum af mobilens funktioner. Kalenderen er tidligere blevet brugt til at organisere tiden mellem studie, arbejde og fritidsaktiviteter og derudover bruger han funktioner som vejret, browser og mange flere udover standard-funktionerne såsom opkald og sms. På trods af hans meget brede brug af mobilen, er der enkelte ting, han ikke bruger "Jeg har ikke brug for at tage billeder eller spille spil med min telefon" har han udtalt. "Så vil jeg hellere læse nyheder på nettet" Julie er 16 år og er godt igennem 1.G. Hun er vant til at bruge telefonen rigtigt meget og kan navigere hen til det mest brugte funktioner uden at kigge på telefonen. SMS'en er hendes mest brugte funktion, og det er den, hun bruger, når hun skal finde ud af, hvilke lektier hun har for til i morgen, hvad hendes veninder laver eller hvis hun skal kontakte en sød fyr. "Det er bare nemmere og hurtigere lige at skrive en sms". Derudover bruger telefonen til at ringe, underholdning og til at tage billeder "Det er smart at man kan til billeder med mobilen hvis man ser noget sjovt". Såvel telefonens indre som ydre spiller en rolle for Julie "Det føles bare godt at have en ny telefon der ser pæn ud og som kan nogle seje ting" 8.7. APPENDIKS A7 LISTE AF FUNKTIONER I TELEFON Skriv besked Læs besked Slet besked Se Indbakke Se udbakke Se udkast Send MMS Læs MMS Slet besked Se MMS indbakke Se MMS udbakke Se MMS udkast Skriv Se inbakke Se udbakke Se udkast Hent

115 Appendiks A Første iteration 107 Ring op Se telefonbog Se favorit kontakter Tilføj kontakt Rediger kontakt Tilføj outlook kontakt Se billeder Tag billede Se videoer Optag video Kalender månedsvisning Kalender ugevisning Kalender dagsvisning Skriv Note Rediger note Se noter Indstillinger MP3 player Sæt alarm Stopur Lommeregner Gå på internettet 8.8. APPENDIKS A8 - SKITSER

116 108 Appendiks A8 - Skitser

117 Appendiks A Første iteration 109

118 110 Appendiks A8 - Skitser

119 Appendiks A Første iteration APPENDIKS A9 VALG AF DESIGN 1. Tilvalg af avancerede funktionaliteter Fordele: - Kan justeres til brugerens behov og teknisk viden - Kan skære funktioner fra man ikke bruger - Bliver gjort personlig og brugerdefineret - Hvis indstillet rigtigt, er telefonen nemmere at bruge for ikke øvede brugere Ulemper: - Kan være besværligt at skulle indstille den - Kan være irriterende at skulle aktivere en ting før man kan bruge det - Kan betyde at designet skifter, fordi der bliver tilføjet ting 2. En spiral at manøvrere ud fra Fordele: - Spændende ide - Kan understøtte tilt

120 112 Appendiks A9 Valg af design Ulemper: - Kan være anderledes hvad folk forstår ved systemet - Ved ikke hvordan det skal implementeres 3. Flere menuer alt efter funktion Fordele: - Giver mere plads - Man kan gruppere de forskellige funktioner/applikationer - Gøre mere personlig - Gør det nemmere overskue mulighederne i telefonen - Kunne understøtte tilt Ulemper: - Man skal vide hvad der er i de forskellige undermenuer - Man kan se det hele på en gang 4. Hurtig menu og langsom menu Fordele: - Hurtig og nem adgang til de mest brugte applikationer Ulemper: - Alt er ikke samlet samme sted - Kan give forvirring over hvor i menuen man befinder sig - Den langsomme menu kan have for mange ting med, som er svære at overskue 5. MP forslaget Fordele: - Tillader adgang til mange funktioner hurtigt - Sjov at bruge - Kan benytte tilt - Effektiv at bruge, når du er vant til systemet Ulemper: - Kræver meget opmærksomhed - Ligner MP's ide så meget 6. Gestures til at navigere i menu Fordele: - Bruger tilt - Spændende - Efterligner normale bevægelser Ulemper: - Ikke specielt hurtig - Besværlig at bruge

121 Appendiks A Første iteration Ikke så privat 7. Kugleinteraktion Fordele: - Bruger tilt - Sjov at bruge - Efterligner en virkelig situation Ulemper: - Ide fra andet sted - Skal bruge for meget opmærksomhed - Virker som underholdning 8. Menuen hænger sammen vha snore Fordele: - Giver et overblik over hvordan menuen hænger sammen - Tiltaler et bestemt publikum - Ligner noget man kender - Giver et overblik over menustrukturen Ulemper: - Ikke nem at bruge for alle - Skal have fuld koncentration - Skal have stor skærm for fuld udbytte 9. Ren brugerindstillet menu Fordele: - Man får adgang til det man har brug for - Har adgang til de mest brugte programmer - Kan let kombineres med andre ideer - Kan gøres personlig Ulemper: - Kræver arbejde for at indstille den 10. Taktilt og audioativt feedback Fordele: - Simulerer rigtige knapper - Giver feedback Ulemper: - Kan genere brugeren hvis ikke implementeret ordentligt

122 114 Appendiks A9 Valg af design 11. Free form gestures som input Fordele: - Bruger tilt - Giver mulighed for brug uden 100% koncentration - Sjov at bruge - Mulighed for at lave direkte genveje - Giver mange muligheder for input Ulemper: - Ved dårlig implementation, kan man komme til at gøre noget ufrivilligt - Man skal huske de forskellige gestures - Nogle gestures kan være svære at udføre for alle 12. Applikationer direkte i menuen Fordele: - Hurtig adgang til det der bilver brugt mest - Kan gøres personlig - Kan understøtte tilt Ulemper: - Bryder skellet mellem menu og applikationer - Kan skabe forvirring over hvor i systemet man befinder sig 13. Touch gestures genveje Fordele: - Bruger tilt - Giver mulighed for brug uden 100% koncentration - Sjov at bruge - Mulighed for at lave direkte genveje - Giver mange muligheder for input Ulemper: - Ved dårlig implementation, kan man komme til at gøre noget ufrivilligt - Man skal huske de forskellige gestures 14. Funktion efter situation Fordele: - Hurtig at bruge de indstillede funktioner - Nem at bruge - Understøtter brugerens ide om hvad en telefon vs kamera er og hvordan det bruges - Deler menuen op så der er en til kameraet, der ikke er med i resten af menuen

123 Appendiks A Første iteration 115 Ulemper: - Kan komme til at lappe ind over gestures - hvis sådanne eksisterer - Er afslørende for hvad man laver 15. Udelukkende store ikoner Fordele: - Simpelt system - Nem at lære/bruge Ulemper: - Kan være for simpel for erfarne brugere APPENDIKS A10 KRAVSPECIFIKATION 1) Løsnigsmålet i denne opgave er, at udvikle en funktionel prototype, der fungerer som menusystem for en mobiltelefon. 2) Via systemet skal telefonens funktioner kunne tilgås. Løsningen skal være designet til en mobiltelefon, der har indbygget touchskærm og accelerometer. 3) Løsningen skal indkorporere ny teknologi som f.eks tilt eller touch for at give en alternativ interaktion. 4) Systemets model skal være genkendelig og logisk forbrugeren 5) Telefonen skal være let at lære at bruge. For at dette er opfyldt, skal en erfaren bruger indenfor mobiltelefoni kunne sætte sig ind i systemet på max 5 min. 6) Systemet skal give hurtig adgang til de mest brugte funktioner på telefonen (sms, ringe, alarm, musik, klokken, internet, telefonbog) 7) Man skal kunne navigere med telefonen uden at give den fuld opmærksomhed. 8) Det skal være muligt at bruge telefonen i situationer med udelukkende periodisk opmærksomhed 9) Systemet skal understøtte genkendelse frem for genkaldelse. Dvs at brugeren skal i de fleste tilfælde have vist sine muligheder. 10) Menustrukturen på telefonen skal være logisk for brugeren 11) Prototypen skal udvikles i tæt samarbejde med brugere, og skal derfor ende med et produkt, der lever op til en række brugervenlighedkrav. 12) Telefonen skal være let at bruge. Dette bliver vurderet ud fra en brugervenlighedstest, hvor 4 ud af 6 deltagere skal kunne finde ud af de basale funktioner uden hjælpe (alle får dog en kort introduktion). 13) Systemet skal kunne tilpasses den enkelte bruger. Det skal f.eks. være muligt at lave

124 116 Appendiks A11 Diagrammer personlige genveje. 14) Det skal være meget let at se hvad klokken er 15) Skal let kunne skiftes mellem lyd/lydløs 16) Systemet skal være spændende at bruge. Hoveddelen af deltagerne i evalueringen skal udtale sig positivt om produktet. 17) Programmet skal lære af hvilke valg brugeren foretager, for at kunne blive bedre optimeret til brugeren 18) En alternativ musikafspiller der fungerer vha. touch gestures og free form gestures kan laves 19) En alternativ sms oversigt kan laves hvor indbakke, udbakke og udkast kombineres APPENDIKS A11 DIAGRAMMER Oversigt over telefonens menustruktur Telefon Stemmestyring sms Lås mms Lyse og meddelser Knapper Idag Input Ur og alarm Ny voic Ejeroplysninger Menuer Personlig System Forbindelser Åbn Kontaktperson Besvar Besvar Svar til alle Indstillinger Outlook kontaktperson Sim kontaktperson Onenote mobile Power point mobile Excel Mobile Word Mobile Programmer Telefon Menu Ny Før til foretrukne Fjern foretrukken Flere Menu Slet Videresend Kontaktpersoner Tilføj ny foretrukken Alle kontaktpersoner Skift billede TV Film Film Office Mobile Kalender Menu Luk Meddelsestype Google maps Google maps I dag Google maps I dag Start Personer Beskeder Skriv besked Funktioner Sorter efter Fra Skype Skype Skype Administer mapper Modtaget Kamera Kamera Objekter Tøm slettet post Svar Tøm slettet post Emne Nulstil sms/mms Noter Nulstil min mail Menu Ny note Kalender Ny konto Ny Ny konto Funktioner Indstillinger Menu Svar Indstillinger Monkey Island Messenger Synkroniser Radio Notesblok Fjern Alle Programmer Slet Indstillinger Mapper Mapper Menu Flere Data Kommunikationer Baggrund Lyd Synkroniser data Ny Konto Konti... Sms/mms Sms/mms Gå til Bluetooth Enheder Trådløse netværk I dag Ny mail Konti Send modtag Gå til Outlook Min mail Outlook Min mail Hjemmeside Mere 5 dage Vejr Menu Slet Besvar Sorter efter Om Indstillinger Fahrenheit Opdater nu Fjern by Tilføj by Menu Mail Indbakke Udbakke Flere?? indbakke Menu Besvar Sorter efter Ny Svar til alle Videresend Meddelsestype Fra Modtaget Emne Tilføj til afspilningsliste Købte Alle sange Afspilningsliste Kunstnere Bogmærker Afspilning Menu Komponister Genrer Album Afspilning Op Bibliotek Musik Internet Billeder og video Flere Browser Start webbrowser Album Diasshow Tilføj til Lydbooster Egenskaber afspilningsliste Bland Gentag Menu Tag billede Optag video Album Menu Op / Ned / Play Blandet fra Blandet til Gentag en Gentag alt Gentag ikke Diasshow Indstil til foretrukken Slet emner Send Gem i kontaktpersoner Egenskaber Indstillinger Hjælp Oversigt over menustrukturen I første prototype.

125 Appendiks A Første iteration 117

126 118 Appendiks A12 - Skærmbilleder første prototype APPENDIKS A12 - SKÆRMBILLEDER FØRSTE PROTOTYPE

127 Appendiks B Anden iteration Appendiks B Anden iteration

128 120 Appendiks B1 Reformulerede krav 9.1. APPENDIKS B1 REFORMULEREDE KRAV Hurtig adgang til de mest brugte funktioner Menustrukturen skal være overskuelig Let at lære Let at bruge Kan bruges uden fuld opmærksomhed Kan bruges med udelukkende periodisk opmærksomhed Skal kunne gøres personlig Skal være muligt, at indstille mange ting i menuen Skal let kunne skiftes mellem lyd/lydløs Let at se hvad klokken er Skal understøtte genkendelse frem for genkaldelse Systemets model skal være genkendelig og logisk forbrugeren Skal være spændende at bruge Skal være stor fokus på ergonimiske udfordninger Skal være stor fokus på, at der sker så få fejl som muligt (ved f.eks. at komme til at ryste telefonen ved en fejl) De mest brugte funktioner skal være de nemmeste at tilgå (være tættest på fingeren eller lignende) Systemet må meget gerne understøtte brug af free form gestures 9.2. APPENDIKS B2 REFORMULERET KRAVSPECIFIKATION Løsnigsmålet i denne opgave er, at udvikle en funktionel prototype, der fungerer som menusystem for en mobiltelefon. Via systemet skal telefonens funktioner kunne tilgås. Løsningen skal være designet til en mobiltelefon, der har indbygget touchskærm og accelerometer. Løsningen skal indkorporere ny teknologi som f.eks tilt eller touch for at give en alternativ interaktion Menuen skal være bygget op, så ikonerne former en cirkel Ved tryk på et ikon skal det aktiveres Når telefonen vippes, skal ikonerne i den tilsvarende side forstørres Systemets model skal være genkendelig og logisk forbrugeren Telefonen skal være let at lære at bruge. For at dette er opfyldt, skal en erfaren bruger indenfor mobiltelefoni kunne sætte sig ind i systemet på max 5 min. Systemet skal give hurtig adgang til de mest brugte funktioner på telefonen (sms, ringe, alarm, musik, klokken, internet, telefonbog) Ved ryst skal der gås tilbage til det forrige skærmbillede Man skal kunne navigere med telefonen uden at give den fuld opmærksomhed

129 Appendiks B Anden iteration 121 Det skal være muligt at bruge telefonen i situationer med udelukkende periodisk opmærksomhed Der skal være stor fokus på ergonomiske udfordringer ved modellen Der skal være stor fokus på, at der sker så få fejl som muligt (ved f.eks. at komme til at ryste telefonen ved en fejl) De mest brugte funktioner skal være nemme at få ved brug af kun en enkelt hånd Systemet skal understøtte genkendelse frem for genkaldelse. Dvs at brugeren skal i de fleste tilfælde have vist sine muligheder Alle de mest brugte funktioner skal have et ikon direkte på skivebordet Menustrukturen på telefonen skal være logisk for brugeren Alle undermenuer skal ligeldes være bygget op som en cirkel Prototypen skal udvikles i tæt samarbejde med brugere, og skal derfor ende med et produkt, der lever op til en række brugervenlighedkrav Systemet skal være bygget op som en basis version, og det skal være muligt at vælge flere muligheder til Telefonen skal være let at bruge. Dette bliver vurderet ud fra en brugervenlighedstest, hvor 4 ud af 6 deltagere skal kunne finde ud af de basale funktioner uden hjælpe (alle får dog en kort introduktion) Systemet skal kunne tilpasses den enkelte bruger. Det skal f.eks. være muligt at lave personlige genveje Systemet skal være spændende at bruge. Hoveddelen af deltagerne i evalueringen skal udtale sig positivt om produktet Det skal være meget let at se hvad klokken er Der skal implementeres en række free form gestures Der skal implementeres en række touch gestures Skal let kunne skiftes mellem lyd/lydløs Hvis telefonen vendes vandret fra menuen, skal kameraet startes Programmet skal lære af hvilke valg brugeren foretager, for at kunne blive bedre optimeret til brugeren En alternativ musikafspiller der fungerer vha. touch gestures og free form gestures kan laves En alternativ sms oversigt kan laves hvor indbakke, udbakke og udkast kombineres

130 122 Appendiks B3 - Diagrammer 9.3. APPENDIKS B3 - DIAGRAMMER Oversigt over menustrukturen i anden iteration Skift Ny aftale Ny aftale Ny aftale Ny aftale Musikafspiler oversigt Kalender dagsvisning Skift Kalender månedsvisning Skift Kalender ugesvisning Internet browser Spille musik Se kalender Se kalender Se kalender samtale Skriv Web browser oversigt Ny note Ny note Noter oversigt Noter Foto Album Foto Album Tag/se billede Se liste Tag billeder Kamera Liste af programmer Programmer på hjul Indstillinger Indstillinger Find kontakt Telefonbog Tilføj/fjern Indstillinger Opkald Kamera SMS Opkald Find kontakt SMS Programmer Indstillinger Opkald SMS oversigt Alarm Find kontakt Seneste opkald Internet Rediger Musik Rediger Rediger Kalender Fotoalbum Se samtale SMS Alarm oversigt Rediger Rediger alarm Rediger Alarm Tilføj/fjern funktion Rediger Kontakter Rediger Noter SMS samtale Skriv SMS Ny + Tilføj alarm Lys Indstillinger Lyd Indstil deltaljer lyd Indstillinger Indstil baggrundsbillede Baggrundbillede Netværk Indstil deltaljer netværk Generelt Indstil tid/dato Sprog Knapper Slå pinkode Til/fra

131 Appendiks B Anden iteration APPENDIKS B4 - SKÆRMBILLEDER FRA 2. PROTOTYPE

132 124 Appendiks B4 - Skærmbilleder fra 2. prototype

133 Appendiks B Anden iteration 125

134 126 Appendiks B4 - Skærmbilleder fra 2. prototype

135 Appendiks B Anden iteration APPENDIKS B4 OPGAVER TIL TEST 1) Send en besked til Esben. 2) Tag et billede. 3) Sæt alarmen til kl 7.00 hver mandag. 4) Du skal til frisøren kl 13 på mandag. Skriv dette ind i kalenderen. 5) Ring op til Esben APPENDIKS B5 CHECKLISTE TIL INTERVIEW Køn? Alder? Stilling? Hvilken mobiltelefon har du nu? Er du overordnet tilfreds med din mobiltelefon? Hvad synes du om at menuen er bygget op som en cirkel? Hvad synes du om strukturen i systemet? Hvad synes du om, at bruge tilt til at styre menuen med? Hvad synes du om, at skulle ryste telefonen for at gå tilbage? Hvad synes du om produktet? Nævn tre gode ting? Nævn tre ting der kan forbedres? Hvad var overflødigt? Savnede du noget? Kunne du forestille dig en anden måde at få oplysningerne præsenteret på?

136

137 Appendiks C Tredje iteration Appendiks C Tredje iteration

138 130 Appendiks C1 Spørgeskema APPENDIKS C1 SPØRGESKEMA Spørgeskemaets hovedformål er, at finde de bedste ikoner til menuen. For at gøre dette, bruger vi interviewet til at lægge op til, at deltagerne selv foreslår hvordan ikonerne skal se ud. Spørgeskemaet: Alder: Stilling: Mobiltelefon: Prioriter disse funktioner i en mobiltelefon samt tegn et ikon for det, som du synes det burde være: - Sms - Telefon - Kamera - Alarm - Indstillinger - Internet - Musik - Kontakter - - Kalender - Noter - Fotoalbum Mange tak fordi du var villig til at ofre tid på at besvare vores spørgsmål APPENDIKS C2 REFORMULEREDE KRAV Hurtig adgang til de mest brugte funktioner Menustrukturen skal være overskuelig Let at lære Let at bruge Kan bruges uden fuld opmærksomhed Kan bruges med udelukkende periodisk opmærksomhed Skal kunne gøres personlig Skal være muligt, at indstille mange ting i menuen Skal let kunne skiftes mellem lyd/lydløs Let at se hvad klokken er Skal understøtte genkendelse frem for genkaldelse Systemets model skal være genkendelig og logisk forbrugeren Skal være spændende at bruge

139 Appendiks C Tredje iteration 131 Skal være stor fokus på ergonomiske udfordringer Skal være stor fokus på, at der sker så få fejl som muligt (ved f.eks. at komme til at ryste telefonen ved en fejl) De mest brugte funktioner skal være de nemmeste at tilgå (være tættest på fingeren eller lignende) Systemet må meget gerne understøtte brug af free form gestures APPENDIKS C3 REFORMULERET KRAVSPECIFIKATION 1. Løsnigsmålet i denne opgave er, at udvikle en funktionel prototype, der fungerer som menusystem for en mobiltelefon 2. Via systemet skal telefonens funktioner kunne tilgås. Løsningen skal være designet til en mobiltelefon, der har indbygget touchskærm og accelerometer 3. Løsningen skal indkorporere ny teknologi som f.eks tilt eller touch for at give en alternativ interaktion 4. Menuen skal være bygget op, så ikonerne former en cirkel 5. Ved tryk på et ikon skal det aktiveres 6. Ikonerne skal være tydelige og lette at forstå. Desuden skal de være lette at skelne fra hinanden 7. Når telefonen vippes, skal ikonerne i den tilsvarende side forstørres 8. Systemets model skal være genkendelig og logisk for brugeren 9. Telefonen skal være let at lære at bruge. For at dette er opfyldt, skal en erfaren bruger indenfor mobiltelefoni kunne sætte sig ind i systemet på max 5 min. 10. Systemet skal give hurtig adgang til de mest brugte funktioner på telefonen (sms, ringe, alarm, musik, klokken, internet, telefonbog) 11. Ved ryst skal der gås tilbage til det forrige skærmbillede 12. Man skal kunne navigere med telefonen uden at give den fuld opmærksomhed 13. Det skal være muligt at bruge telefonen i situationer med udelukkende periodisk opmærksomhed 14. Der skal være stor fokus på ergonomiske udfordringer ved modellen 15. Der skal være stor fokus på, at der sker så få fejl som muligt (ved f.eks. at komme til at ryste telefonen ved en fejl) 16. De mest brugte funktioner skal være nemme at få ved brug af kun en enkelt hånd 17. Systemet skal understøtte genkendelse frem for genkaldelse. Dvs at brugeren skal i de fleste tilfælde have vist sine muligheder 18. Alle de mest brugte funktioner skal have et ikon direkte på skivebordet 19. Menustrukturen på telefonen skal være logisk for brugeren 20. Alle undermenuer skal ligeldes være bygget op som en cirkel 21. Prototypen skal udvikles i tæt samarbejde med brugere, og skal derfor ende med et produkt, der lever op til en række brugervenlighedkrav 22. Systemet skal være bygget op som en basis version, og det skal være muligt at vælge flere muligheder til 23. Telefonen skal være let at bruge. Dette bliver vurderet ud fra en brugervenlighedstest, hvor 4 ud af 6 deltagere skal kunne finde ud af de basale funktioner uden hjælpe (alle får dog en kort introduktion)

140 132 Appendiks C4 Use cases 24. Systemet skal kunne tilpasses den enkelte bruger. Det skal f.eks. være muligt at lave personlige genveje 25. Systemet skal være spændende at bruge. Hoveddelen af deltagerne i evalueringen skal udtale sig positivt om produktet 26. Det skal være meget let at se hvad klokken er 27. Der skal implementeres en række free form gestures 28. Der skal implementeres en række touch gestures 29. Skal let kunne skiftes mellem lyd/lydløs 30. Hvis telefonen vendes vandret fra menuen, skal kameraet startes 31. Programmet skal lære af hvilke valg brugeren foretager, for at kunne blive bedre optimeret til brugeren 32. En alternativ musikafspiller der fungerer vha. touch gestures og free form gestures kan laves 33. En alternativ smsoversigt kan laves hvor indbakke, udbakke og udkast kombineres APPENDIKS C4 USE CASES Use case 1 : Skriv en sms Primært succescenarie: 1. Menuen vises 2. Sms vælges 3. "Ny sms" vælges 4. Navnet på modtageren tastes ind og vælges 5. Beskeden skrives og sendes 6. Menuen vises igen Alternativt forløb: 4a. Navnet på modtageren vælges fra telefonbog Use case 2 - Svar på en sms Primært succescenarie: 1. Menuen vises 2. På menuen vises at der er modtaget ny sms 3. Vis sms'en i samtale med modatgeren 4. Der trykkes på indtastningsfeltet 5. Beskeden skrives og sendes 6. Menuen vises igen Alternativt forløb: Use case 3 : Foretage et opkald fra telefonbogen Primært succescenarie: 1. Menuen vises 2. Telefonbog vælges

141 Appendiks C Tredje iteration Personen vælges 4. Telefonen ringer op 5. Samtalen foretages 6. Samtalen lukkes 7. Menuen vises Alternativt forløb: 4a Personen har flere numre, et nummer vælges 4½a Telefonen ringer op. Use case 4 : Foretag opkald via de seneste opkald Primært succescenarie: 1. Menuen vises 2. Opkald-ikonet vælges 3. "Seneste"-knappen vælges 4. Trykkes på en af kontakterne på listen 5. Der lægges på 6. Menuen vises igen Alternativt forløb: 4a. Kontakten står ikke på listen, så der gås tilbage til sidste side 5a. Nummeret tastes ind Use case 5 : Sæt alarmen Primært succescenarie: 1. Menuen vises 2. Alarm vælges 3. En allerede oprettet alarm slås til 4. telefonen rystes for at komme tilbage til menuen Alternativt forløb: 3a Ny vælges 4a Tid indtastes 5a Dage for gentagelse vælges 6a Gem trykkes 7a Menuen vises 3b Rediger vælges 4b En gammel alarm vælges 5b Tid redigeres 6b dage for gentagelse vælges 7b Gem trykkes 8b Menuen vises Use case 6 : Tag et billede Primært succescenarie: 1. Menuen vises

142 134 Appendiks C4 Use cases 2. Kamera-ikonet vælges 3. Kameraet starter 4. Menuen vises igen Alternativt forløb: Intet Use case 7 : Se et gammelt billede Primært succescenarie: 1. Menuen vises 2. Fotoalbum-ikon vælges 3. Der vises en oversigt over alle billederne 4. Et af billedere vælges og vises 5. Menuen vises igen Alternativt forløb: 4a. Tilbage til oversigten over billeder 5a. Et nyt billede vælges og vises Use case 8 : Find telefonnummeret til en kontakt (i telefonbogen) Primært succescenarie: 1. Menuen vises 2. Telefonbogen vælges 3. Personen findes og vælges 4. Telefonen rystes for at komme tilbage til menuen 5. Menuen vises Alternativt forløb: Use case 9 : Opret en kontakt i telefonbogen Primært succescenarie: 1. Menuen vises 2. Telefonbogen vises 3. Der vælges "ny kontakt" 4. Informationerne til den ny kontakt skrives ind 5. Informationerne gemmes 6. Menuen vises igen Alternativt forløb: 2a. Ny sms vises - fra person ikke i telefonbog 3a. Ude for sms'en i oversigten findes ikon for telefonbog 4a. Telefonbogen vises 5a. Indtastes informationer og gemmes 6a. Menuen vises 2b. Opkald-ikonet vælges 3b. Sidste opkald vises

143 Appendiks C Tredje iteration 135 4b. Der vises et nyt nummer (ikke inkluderet i telefonbogen) 5b. Link til telefonbogen vælges 6b. Telefonbogen vises 7b. Oplysningerne indtastes og gemmes 8b. Menuen vises igen Use case 10 : Slå et ikon til på menuen Primært succescenarie: 1. Menuen vises 2. Indstillinger vælges 3. Ikon indstillinger vælges 4. Et ikon slås til 5. Telefonen rystes 6. Menuen vises Alternativt forløb: Use case 11 : Skriv en note Primært succescenarie: 1. Menuen vises 2. Note vælges 3. Ny vælges 4. Noten tastes 5. Noten gemmes 6. Menuen vises Alternativt forløb: 5a. Et opkald modtages 6a. Opkaldet afsluttes 7a. Note indtastning vises 8a. Noten gemmes 9a. Menuen vises

144 136 Appendiks C5 skærmbilleder fra prototype APPENDIKS C5 SKÆRMBILLEDER FRA PROTOTYPE

145 Appendiks C Tredje iteration 137

146 138 Appendiks C5 skærmbilleder fra prototype

147 Appendiks D Fjerde iteration Appendiks D Fjerde iteration

148 140 Appendiks D1 Skærmbilleder af prototype APPENDIKS D1 SKÆRMBILLEDER AF PROTOTYPE

149 Appendiks D Fjerde iteration 141 s APPENDIKS D2 - OPGAVER Imens man går: - Skriv en sms til nr Ring op til Start musikken - Opret en en ny kontakt til Ole. Nummeret er Imens man sidder - Gå i telefonbogen ring op til Jens - Gentag 5 gange med forskellige personer - Christian - Martin - Ulla - I - Bettina