m o b i l e touch interfaces

Transkript

1 O p timizing the performance of m o b i l e touch interfaces Bria n Høj J ako bs e n Konge n s Lyng by IMM- B.E ng

2 Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone , Fax IMM-B.Eng

3 Summary This report aimed to find correlation between parameters, to clarify possible options for optimizing the user experience on touch mobile phones. Especially the relationship between parameters that a programmer can t control, and parameters which a programmer can fix, was in focus. The correlations were found through user testing and statistical analysis of data. I found indications of coherence between the user's ability to learn and phone screen type, which showed a faster learning when using a capacitive screen, it was, as a starting point, also faster to use than the resistive screen. Furthermore, I found a correlation between the number of objects and user interface presentation of data, where a grid, due to the good use of the screen, turned out to be significantly faster, between 18 and 25 objects. In addition, I became aware of a connection between the user's interaction with lists and numbers of objects in the list. I also found an indication that the optimal text size depends on the number of objects in a list. Results showed that there are opportunities for better user experience by optimizing the parameters under different conditions, due to other parameters.

4 ii

5 Resumé Denne rapport havde til formål at finde sammenhæng mellem parametre, for at klarlægge en eventuel mulighed for optimering af brugeroplevelsen på touch mobiler. Specielt sammenhængen mellem parametre, som en programmør ikke kan styre, samt parametre som programmør kan rette på, var i fokus. Denne sammenhæng blev konstateret ved hjælp af brugertest, og statistisk analyse af data. Jeg fandt indikationer på sammenhæng mellem brugerens indlæringsevne og mobilens skærmtype, som viste en hurtigere indlæring ved brugen af den capacitive skærm, desuden var den som udgangspunkt også hurtigere at bruge end den resistive skærm. Endvidere fandt jeg en sammenhæng mellem antallet af objekter og brugergrænsefladens præsentation af data, hvor et grid, grundet den gode udnyttelse af skærmen, viste sig at være signifikant hurtigere, ved 18 til 25 objekter. I øvrigt blev jeg opmærksom på en sammenhæng mellem brugerens interaktion med lister og antallet af objekter i listen. Jeg fandt også en indikation på, at den optimale tekststørrelse afhænger af antallet af objekter i en liste. Resultaterne viste, at der er mulighed for bedre brugeroplevelse ved at optimere på parametre under forskellige vilkår, grundet andre parametre.

6 iv

7 Preface This thesis was prepared at Informatics Mathematical Modeling, the technical University of Denmark as partial fulfillment of the requirements for acquiring the B.End degree in Information Technology. The thesis aims to explore opportunities to optimize performance for users of touch phones, for further development of mobile interfaces that dynamically changes its appearance based on external parameters The work on this thesis was done from October 18st, 2010 to January 31th, The workload corresponded to 20 ECTS points. The thesis supervisor was Jakob Eg Larsen, Department of Informatics and Mathematical Modelling, Technical University of Denmark. Konge n s Lyng by, ja n ua ry Bria n Høj J ako bs e n

8 vi Summary...i Resumé... iii Preface... v Indledning... 1 Analyse Mulige optimerings område valg af optimerings område Test Setup Test Deltagere Valg af værktøjer værktøjer Nokia Qt SDK Implementation Kinetic scroll GUI Bruger test TestData Efterfølgende forarbejdning af test data udfordringer under udviklingen Forsøgsgennemgang Resultater og diskussion Gruppering af test data Indlæring under testen Signifikante Resultater Andre resultater Konklusion Perspektivering Skærmtyper Scroll-test... 26

9 8.3 Grid-List test Mekanismer i state machine Statistiske påviselige resultater Litteraturhenvisninger Bilag Bilag 1: Gruppe A Alle 9 erfarne brugere med touch mobil Bilag 2: Gruppe B Alle 6 brugere uden touch mobil Bilag 3: Gruppe AB - Alle 15 testbrugere Bilag 4: Udfylde testbruger skemaer Bilag 5: Main.cpp Bilag 6: kineticscroll.cpp Bilag 7: kineticscroll.h Bilag 8: Program til forarbejdning af data Bilag 9: Forarbejdet resultat data Bilag 10: Bilag 11: Bilag 12:... 54

10 viii

11 KAPITEL1 Indledning Denne rapport vil se på hvilke optimeringer i brugergrænsefladen, der kan laves til touch mobiler, og hvilken forskel der er på forskellige touch typer. I takt med at mobiltelefonerne bliver mere avancerede, vokser muligheden for i mere eller mindre grad at bruge dem, som erstatning for computere. Specielt touch skærmens udbredelse har gjort meget for brugerens interaktion med mobilen, samt gjort det muligt at udstyre mobiler med større skærme. Det har i større grad muliggjort at flytte funktionalitet til mobiltelefonen. For software udviklerne har touch funktionaliteten, samt de små skærme i forhold til computere, været en relativ ny udfordring. Dette har resulteret i brugergrænseflader med store begrænsninger. Specielt udvikling til Nokia s60 er en stor udfordring med hensyn til kompatibelt med flere forskellige touch teknologier samt mobiler uden touch funktionalitet som fx T9 keyboards. Der vil i rapporten blive udført test, der har til formål at finde sammenhæng mellem parametre, for at give mulighed for optimering af brugeroplevelsen. Specielt sammenhængen mellem parametre, som en programmør ikke kan styre, som fx antallet af kontakter i en kontakt liste, sammenlignes med parametre som programmør kan rette på, som fx tekstens punkt størrelse. Resultaterne vil blive visualiseret i form af grafer, og dataen vil blive analyseret ud fra relevante statistiske modeller. Rapporten har ikke til formål at komme til nogle specifikke indstillinger, men nogle resultater som vil vise, om der er noget at arbejde videre med, og eventuelt hvilke indstillinger, der kan resultere i forbedringer for brugerne.

12 KAPITEL 2 Analyse Der er mange områder på mobiler, der kan optimeres, men det er vigtigt for mit valg af optimeringsområde, at det skal være noget generelt for at give resultaterne relevans. Det skal også være noget, som der ikke er alt for mange forskellige implementationer af, da det ellers vil resultere i et stort antal test, bare for at dække forskellen på eksisterende ting. Så for at finde noget meget generelt at teste på, vil jeg se nærmere på alle de gamle UI elementer i en mobiltelefon, da de minder meget om hinanden på forskellige mobiltelefoner. Yderligere er de også områder, som har haft lang tid til at udvikle sig på, før touch mobiler kom, og muligvis ikke har fuldt med udviklingen efterfølgende. Menu struktur 2.1 Mulige optimerings område Dybde af menusystemer, samt fordeling og visualisering af menupunkter kan betyde meget for hastigheden af menuernes navigering. Den nok største faktor er, at opdelingerne er lavet naturligt, så de er til at finde rundt i, men når det er sagt, er optimering også muligt ud fra viden om navigeringshastigheden i lister med vilkårlige antal menupunkter. Dette område er interessant, efter som navigering i lister med mange punkter formentlig er blevet væsentlig hurtigere med touch mobiler. Men en optimering vil først kræve en optimering af visualiseringen af menu interfacet, da det vil ændre i navigeringshastigheden. Menu interface Visualiseringen af menu interface har stor indflydelse på navigeringen på mobiltelefoner. Det er primært objektstørrelse og måden de visualiseres på, der har indflydelse på brugeroplevelsen. Desuden er der mange eksterne parametre, der kan have indflydelse på, hvad der virker optimalt, deriblandt skærmstørrelse og skærmtype.

13 3 Kontaktpersoner Kontaktpersoner er typisk en liste af navne eventuelt med tilhørende billede. Men ofte er der yderligere mulighed for gruppering af folk samt søgefunktion. Listen af kontaktpersoner kan optimeres ud fra de samme kriterier som mobilens menu interface, mens de yderligere navigeringsmuligheder baserer sig på, at det er en liste, som brugeren har oprettet, og derfor selv kender og kan sortere i den efter eget ønske. På samme måde som ved menu struktur er dette område interessant, da navigering i lister med mange punkter formentlig er blevet væsentlig hurtigere med touch mobiler. Det vil derfor også først kræve en optimering af visualiseringen af menu interfacet, da det vil ændre i navigeringshastigheden for kontaktpersoner. Fx er der i nogle nye programmer valgt at erstatte navnelister med et grid med billeder af folk. Mail og besked ind- og udbakke Alle beskedformer var oprindeligt opdelt i individuelle mappestrukturer, sorteret efter oprindelsestidspunkt. Senere er der virkelig sket meget på området, ikke mindst efter touch mobiler er kommet på markedet. Nu kan beskeder være opdelt efter personer, og det er derfor effektivt at se flere beskeder på skærmen på samme tid, af både indgående og udgående. Eftersom det er noget, som har udviklet sig meget, inden for de seneste år og virker forskelligt på forskellige telefoner, vil det være et område, som kræver meget brugertestning for at finde indikationer på, hvilke af de eksisterende implementationer, der virker optimalt og eventuelt sammenknytter eksterne parametre til deres funktionalitet. Musikafspiller Musikafspillere på forskellige mobiltelefoner har meget forskellige opbygninger, hvor musikken kan sorteres på mange forskellige måder og selve interfacet til at styre musikken også varierer meget. Det skyldes formentligt, at der også bliver solgt mange dedikerede musikafspillere, som der også er brugt meget tid på at udvikle efter brugernes bedste befindende. Efter som der også er solgt dedikere musikafspillere, som benytter touch interface, er det også et felt, som musikafspillere på mobiltelefoner er meget godt med på. Andre muligheder Der er helt sikkert andre områder på mobiltelefoner, som der kan optimeres på, men jeg vil mene, at jeg har været inde på nogle meget vigtige område for mobiltelefonerne, og mener, at det er blandt dem, at mit endelig optimerings område skal findes.

14 4 Kapitel 2 - Analyse 2.2 valg af optimerings område Jeg kan se muligheder i at optimere på alle de ovenstående områder, men det er ikke dem alle, hvor jeg har forudsætningerne for at komme hele vejen fra implementation af test setup til en løsning, hvor interne parametre kan optimeres i forhold til eksterne parametre, som resultat af en brugertest. Musikafspiller, mail og besked ind- og udbakke Det er to områder der, på forskellige mobiltelefoner har mange forskellige implementationer, gør, at der vil være meget arbejde i at udvikle de forskellige løsninger. Det vil også ende op i virkelig mange test, da det er relativt stort område, som formentligt er ensbetydende med mange interne og eksterne parametre at teste på. Uden erfaring med programmering til mobiltelefoner og kun lidt erfaring med lavere niveau af programmeringssprog som c og c++, er jeg ikke sikker på, hvor meget jeg har tid til at udvikle, og ønsker derfor ikke at lægge mig fast på, at programmere alt for meget fra start. Jeg ser det derfor ikke, som et smart valg at starte på at udvikle flere test systemer til nogle af mobilens største og mest kompliceret systemer. Menu struktur og kontaktpersoner Det er to meget forskellige områder i mobilen og begge meget interessante. Det er også områder, som jeg vil vurdere, at jeg rent implementeringsmæssigt har tid til. Til gengæld mener jeg, at de mest vitale dele er afhængig af et allerede optimeret interface. Så hvis testdelen ikke skal blive meget stor, som resultat af at jeg prøver at dække fx både menu struktur og menu interface, vil jeg være tvunget til at tage udgangspunkt i et specifikt interface. Det kan fejlagtigt resultere i en masse testdata, som ikke kan sige mig meget om sammenhængen mellem eksterne og interne parametre, hvilket vil give nogle statiske resultater, hvilket ikke er, hvad jeg søger. Menu interface Et godt optimeret menu interface er noget, som kan genbruges mange steder i mobilen og formentlig det, som giver mig de største muligheder for at teste interne variable som fx tekststørrelse mod eksterne variable som fx skærmtypen. Det er et lille og afgrænset område, hvor der er veldefinerede ting at teste på, hvilket forhåbentlig vil kunne ende op med nogle retningslinjer for, hvordan et interface kan optimeres, når de eksterne parametre ændres. Da jeg ser menu interfacedelen, som det jeg kan få mest ud af, ønsker jeg at se nærmere på, hvilke parametre der har størst potentiale for at give interessante og brugbar resultater. Efterfølgende vil jeg se på, hvorledes jeg kan lave et testsetup, som kan teste det, uden at kræve alt for meget arbejde af testbrugerne.

15 5 2.3 Test Setup Formålet med mine forsøg er at finde sammenhæng mellem parametre, hvor specielt sammenhængen mellem interne og eksterne parametre vil have stor interesse. Med eksterne parametre mener jeg, forhold som en programmør ikke kan styre, som fx antallet af kontakter i en kontakt liste, eller mobiltypen som programmet bliver kørt på. Når jeg nævner interne parametre, er det derimod forhold, som en programmør kan rette på for at give den bedste brugeroplevelse. Derfor skal der udarbejdes nogle forsøg, der kan vise, hvad eksterne eller interne parametre kan betyde for brugerens interaktion med mobilen. Og hvis muligt, skal der findes sammenhæng mellem en eller flere eksterne og interne parametre, for at gøre det muligt at justere på de interne parametre i forhold til de eksterne. [4, gsmarena.com, mobil Jeg har to mobiltelefoner til rådighed fra DTU, en Nokia X6 (X6) specifikationer] og en Nokia 5800 XpressMusic (5800) [5, gsmarena.com, mobil specifikationer]. De to mobiler benytter samme CPU, arbejder ved samme hastighed og har samme mængde RAM. Skærmene på mobilen er desuden af samme størrelse (360 x 640 pixels, 3.2, ca. 54mm * 40mm), men X6 benytter en capacitive skærm og 5800 benytter en resistive skærm. Operativsystemet på begge mobiler er s60, men de forskellige modeller har ikke mulighed for at benytte samme firmware, hvilket har resulteret i at X6 benytter version , mens 5800 benytter c Interessante eksterne parametre Skærmstørrelse Selv om de fleste touch mobiler kommer med relativ store skærme, vil en variation i skærmstørrelse nemt kunne få indflydelse på brugeroplevelsen. Skærmtype Efter som jeg har to skærmtyper til rådighed, vil det være et oplagt parameter at teste på. Capacitive touch skærme er nu de mest udbredte blandt forbrugerelektronik, og kan fremstilles på flere forskellige måder, som bl.a. afhænger af, om det skal være en multi-touch skærm. Capacitive touch skærme benytter fingerens evne som elektrisk kondensator. Fingerens berøring vil øjeblikkelig resultere i en målbar forstyrrelse i det elektriske felt, og virker derfor meget responsive, men også meget følsomme over for [6, books.google.com, en bog om capacitive touch teknologi] væsker eller andre ledende ting. Resistive touch skærme er mere holdbare og virker under sværere vilkår som kontakt med væsker, eller hvis brugeren benytter handsker eller et tilfældigt objekt af fx plastik til at trykke med. Det er muligt, fordi den benytter sig af to flader, som brugeren skal trykke sammen for at lave en kortslutning. Det er derfor ikke vigtigt, hvad der bliver trykket med, men kun et krav, at der ikke bliver trykket ned på skærmen over en alt for

16 6 Kapitel 2 - Analyse stor flade. Den største udfordring ved brugen af en Resistive touch skærm kan derfor nemt være store fingre, hvilket også er grunden til, at der normalt medfølger en stylus, [7, resistivetouchscreen.org, om resistive touch teknologi] der altså er en lille pegepen til skærmen Antal objekter Antallet af objekter i en given liste kan betyde meget for, hvor hurtig en bruger kan finde et specifikt objekt. Bevægelse Hvis mobilen og brugeren er i bevægelse, kan det resultere i, at det bliver meget svært at læse tekst og trykke meget præcist på mobilen. Et meget spændende område, men [8, Investigating Selection and Reading Performance on a Mobile Phone while Walking]. er allerede veldokumenteret Interessante interne parametre Visualisering Hvorledes det påvirker brugerens interaktion med mobilen, om ting bliver vist som en liste eller i en gitterstruktur. Punkt størrelse Større tekst kan både hjælpe med læsbarheden og gøre det nemmere at ramme det rigtige felt, men det resulterer også i, at der ikke kan visualiseres så mange objekter på skærmen. Men mindre interessant, da jeg allerede er i besiddelse af en rapport på [8, Investigating Selection and Reading Performance on a Mobile Phone while Walking] området. Auto scroll Muligheden for auto scroll i en liste har indflydelse på, hvor meget brugeren skal arbejde for at bevæge sig rundt i en liste. Det bliver ofte omtalt som kinetisk scroll, og er mobilens egenskab til at fortsætter med at scrolle listen automatisk, efter at brugeren har løftet sin finger, effekten aftager indtil, den til sidst er helt stoppet. Navnet er en metafor for brugerens mulighed for at tilføje listen en bevægelsesenergi. Scrolling hastighed Max hastigheden auto scroll kan scrolle i en liste, og hvor hurtigt at scrolling hastigheden nedjusteres med, kan betyde meget for brugeren, både for læsebarheden af data, men også for hvor hurtigt man kan komme igennem en liste.

17 7 Fejlparametre I forbindelse med min test skal der tages hensyn til eventuelle fejlparametre, som kan få stor indflydelse på de samlede resultater, og risikere at give store misvisninger, når der sammenlignes på tværs af testpersoner. Erfaring med touch skærme Det kommer til at betyde meget for resultaterne, om testpersonerne normalt benytter sig af en touch mobil, det vil derfor blive noteret hvilke brugere, der normalt benytter en touch mobil, og hvilken mobil type der er tale om, så jeg kan holde styr på fordeling af skærmtyper. Det vil formentligt have betydning for deres indlæring under testen. Antal hænder Alle test vil blive udført ved brug af den ene hånd, det vil formentlig betyde noget, hvis enkelte brugere normalt benytter sig af to hænder, hvilket også vil blive noteret. Learning curve Alle brugere vil i mere eller mindre grad blive bedre til at udføre opgaverne, hvor specielt folk uden erfaring med touch mobiler må forventes at blive bedre under udførslen af opgaverne. For at prøve at forhindre det i at ødelægge mine resultater, vil brugerne skiftevis blive sat til at starte med X6 og Det samme gælder for de enkelte opgaver på mobilen, der på samme måde burde blive skiftet rundt, så de kommer i en tilfældig rækkefølge, men eftersom det vil kræve meget arbejde både i implementation, udførsel og analyse, er det ikke noget, jeg har i sinde at gøre. Logning af klik på forskellige skærmtyper Capacitive skærme er kendt, som værende meget følsomme og kræver meget lidt berøring, mens Resistive skærme slet ikke reagerer på let berøring. Det vil betyde, at en bruger kan trykke mange gange på den Resistive skærm uden, at det vil blive logget, og vil derfor kunne resultere i misvisninger i statistikken. Det kan løses på flere måder bl.a. ved at filme og lave manuel optælling, men den nemmeste løsning er primært at se på den tid, som brugeren har brugt på de enkelte opgaver, og ikke hvor mange klik den er løst med. Test setup De test, der skal køres, skal til dels vise betydningen af de enkelte parametre, men yderligere er det vigtigt, at de givende test vil vise sammenhæng mellem eksterne og interne parametre. Da det vil kræve mange test for at kunne vise virkningen af de enkelte parametre samt sammenhængen mellem flere parametre, er det vigtigt, at jeg begrænser det til nogle enkelte parametre. Jeg vil derfor fokusere på tre vigtige parametre skærmtype, antal objekter og visualisering. Jeg har valgt dem ud fra, at jeg

18 8 Kapitel 2 - Analyse minimum ønsker et internt og et eksternt parameter og ud fra, at jeg ikke må ende op med flere test, end hvad jeg kan forvente en testdeltager vil bruge tid på. Antal objekter og visualisering giver en god kombination mellem interne og eksterne parametre. Skærmtype er god som tredje parameter, da der kun er to skærmtyper, og derfor ikke resulterer i alt for mange test, selv om det i testen kombineres med de to andre variabler. Skærmtype For at teste skærmtype har jeg to mobiltelefoner til rådighed. Alle testpersoner kan derfor lave de samme test på begge mobiltelefoner, som vil gøre det nemmere at sammenligne resultater for de to skærmtyper. Jeg håber her at kunne påvise nogle stærke og svage punkter ved de to skærmtyper. Visualisering Antallet af objekter og måden de visualiseres på er et internt og et eksternt parameter, som relativt nemt kan testes i forhold til hinanden. Jeg vil teste et grid og en liste med forskellige antal objekter op mod hinanden. Formålet er at eftervise brugerens navigationshastighed, når der arbejdes med en liste eller et grid af billeder. Jeg har taget udgangspunkt i Nokias s60 menu, som kan sættes op i et grid, hvor der under normale indstillinger vises tre kolonner af næsten kvadratiske billeder. Samme menutype er normal under Android og ios, men skærmstørrelsen og antallet af kolonner er anderledes. For at gøre udviklingen nemmere benytter jeg mig af enkelte bogstaver frem for billeder. Jeg har valgt tekststørrelse 22, som passer med de 3 kolonner og resulterer i at 6 rækker er det maksimale antal, uden at skulle scrolle. Der testes med 6, 18 og 25 bogstaver, hvor de to første er det maximale antal, der kan vises på skærmen for henholdsvis liste og grid, hvilket betyder, at der kan trykkes på dem uden at skulle bruge scroll, mens de 25 kræver, at der scrolles på begge visningstyper. De to ovenstående billeder viser resultatet af den endelige implemetation, hvor det venstre viser et grid med 18 bogstaver og det højre viser en iste med 6 bogstaver

19 9 Tekststørrelse Grid eller List Grid 3x6 List 6 Antal bogstaver 6 6 Antal bogstaver Antal bogstaver Jeg vil I resten af rapporten henvise til denne test som Grid-List test, og de enkelte test vil jeg navngive G6, G18, G25, L6, L18 og L25. Objekter Antallet af objekter er et eksternt parameter, som nemt kan testes. Det bliver delvis testet i Grid-List testen, men for at få resultater under mere normale forudsætninger, sætter jeg en specifik test op for at dække objekter. Denne test skal efterligne en kontakt liste, og er derfor fyldt med unikke navne Jeg har valgt en punktstørrelse 12, som på skærmene giver et felt på 5-6mm at trykke på, alt efter mellemrummet mellem linjerne. Det er efter min vurdering meget lignende, hvad Nokia har som standardindstilling for lister, og derfor som udgangspunkt en udmærket indstilling. Men er i kontrast til størrelsen i Grid-List testen meget mindre. Det vil forhåbentlig give en mulighed for at lave sammenligninger mellem de to test og få en indikation af betydningen på tekststørrelse. Der testes med 10 navne, som bliver det maksimale antal linjer uden scroll. Der testes også med 25 linjer, som giver mulighed for at sammenligne med G25 og L25 fra Grid- List testen. Yderligere testes der med 50 og 100 linjer, som må formodes at være det maksimale en bruger manuelt vil gennemsøge, for at se hvordan tidsforbruget vokser som resultat af antallet af objekter på de to mobiltyper. Ovenstående billede viser den endelige implementation af listen.

20 10 Kapitel 2 - Analyse Tekststørrelse 12 Antal navne 10 Antal navne 25 Antal navne 50 Antal navne 100 Jeg vil I resten af rapporten henvise til denne test som Scroll testen og de enkelte test som l10, l25, l25, l50 og l Test Deltagere Det er svært på forhånd at skulle vurdere, hvor mange testdeltagere der skal til for at gøre resultaterne signifikante, da resultaternes spredning har rigtig meget at sige. En artikel [8, Investigating Selection and Reading Performance on a Mobile Phone while Walking] har lavet nogle andre forsøg på mobiltelefoner, som minder meget om mine forsøg. Deres resultater er gode og er lavet på baggrund af 16 deltagere, hvilket som udgangspunkt gerne skulle give mig en mulighed for tilsvarende gode resultater med ca. 16 deltagere.

21 KAPITEL 3 Valg af værktøjer For at udføre alle mine test, så de simulerer funktionaliteten der er på markedet nu, vil jeg implementere en meget fleksibel kinetic scroll list, som giver mulighed for at vise data i en vertikal liste eller grid. For både list og grid skal der kunne scrolles vertikalt for at tilgå data, som ikke kan være på skærmen. Ved at trykke på et specifikt objekt skal der være mulighed for at skifte listen ud med en anden liste med andre parametre. Alle brugerinput skal løbene gemmes i hukommelsen, og når testen er færdig, skal der oprettes en fil, hvor alt data gemmes. 3.1 værktøjer For at vælge hvilket værktøj jeg ønsker at bruge til udvikling af mit testsystem, vil jeg primært se på, hvad Nokia giver af muligheder. Til Nokia mobiler er der mulighed for brug af flere forskellige udviklingsværktøjer, hvor jeg primært har set på deres Qt og Jave SDK. Deres ældre Java SDK vil for mig formentlig være det nemmeste at udvikle i, da jeg har en del erfaring med Java, men det er primært tiltænkt S40 [1, nokia.com, om Java til Nokia]. Deres nyere udviklingsværktøj Nokia Qt SDK henvender sig direkte til smartphones [2, nokia.com, om QT til Nokia] og lover bedre performance, men benytter sig af C++, som jeg har mindre erfaring med. Da det er vigtigt for mine test, at jeg ikke ender med at have performanceproblemer, som kan resultere i mere tilfældige resultater, vil jeg benytte mig af Nokia Qt SDK. Det er et stort SDK der formentlig vil kræve noget indlærings tid, men så vil jeg forhåbentlig også ende op med et godt resultat. 3.2 Nokia Qt SDK Qt framework benytter standard C++, men der er gjort et omfattende arbejde for at forbedre sproget, hvor der specielt er stort potentiale i de mange medfølgende klasser. Eftersom jeg har arbejdet meget med.net C#, som er et stort framework, har jeg været taknemlig for det omfattende sæt af klasser, der trods anderledes funktionalitet har kunne spare mig tid.

22 KAPITEL 4 Implementation Jeg har udviklet et program til at udfører test på mobiltelefonerne, som er det, jeg primært vil forklare om i dette kapitel. Men til sidst vil jeg også nævne et program, som jeg har lavet til at gennemgå logfiler fra mit mobiltelefonprogram. Jeg vil forsøge at gennemgå udviklingen, så det kan læses uden at læse i koden, og jeg vil derfor heller ikke gå i alt for mange detaljer. 4.1 Kinetic scroll Mine test omhandler scroll i list og grid, og skal simulere virkelighedens operativsystemer, hvor både S60, ios og Android benytter sig af kinetic scroll. Derfor ønsker jeg også at implementere denne funktionalitet for at give den bedste sammenligningsmulighed. Til implementeringen af min kinetic scroll liste har jeg taget [3, picasaweb.google.com, Den oprendelig udgangspunkt i en eksisterende og velkendt state machine state machine]. Implementeringen bygger på en enum (State), der altid holder styr på, hvilken state du befinder dig i. De tre forskellige inputs typer (Press event, Move event og Release event) vil så have forskellige virkninger på systemet i forskellige states.

23 13 Først vil jeg forklare de vigtigste variabler og foruddefinerede tal. Foruddefinerede tal [Bilag 6, Kode, side 41] De foruddefinerede tal kan findes i vedlagte bilag. HASTIGHED_MAX 50 Det maksimale antal pixels, indholdet på skærmen, skal flytte sig på et TIME_TICK. Det må ikke være et alt for stort tal, da det vil resultere i, at man ikke kan nå at læse teksten, eller at det ikke bevæger sig flydende afhængig af størrelsen på TIME_TICK. TIME_TICK 20 Det antal millisekunder der skal gå mellem AutoScroll/AlarmClock opdateringerne. Et for lille tal vil resultere i stor belastning af CPU, mens et for stort tal vil resultere i en hakkende bevægelse. SNAPSHOT_INTERVAL 25 Tiden mellem en ny hastighed udregnes ud fra brugerens bevægelse. Et lille interval vil resultere i en mindre hastighed, mens et stort interval resulterer i større hastighed. Det er vigtigst, at værdien vælges, så den udregnede hastighed sammen med TIME_TICK give en bevægelse, der minder om den, som brugeren lavede lige før fingeren blev løftet. MARGIN 10 Det antal pixels brugeren kan flytte fingeren uden, at der skiftes fra state Pressed til Manual Scroll. En stor værdi vil give en manglende respons, når brugeren begynder at scrolle, men en lille værdi vil betyde, at et uforsigtigt klik kan give problemer med, at programmet skifter til state manual Scroll, og derfor ikke giver det forventede resultat. Vigtige variable Forskydning Det antal pixel som der er scrollet ned i listen. Afstand Indeholder forskellen mellem det sted, hvor fingeren er trykket ned og fingerens nuværende placering. Bruges til udregning af hastighed. TimeStamp Bruges sammen med snapshot_interval til at finde det næste tidspunkt, hvor der skal udregnes en hastighed, i state ManualScroll hastighed

24 14 Kapitel 4 - Implementation Det antal pixels, der ved Auto Scroll automatisk lægges til forskydning. State machine Nedenfor ses forklaring til de individuelle states, og koden kan findes i vedlagte bilag. [Bilag 6, Kode, side 41] Steady Default værdien er Steady, men ved et tryk på skærmen vil staten ændres til Pressed og registrere, hvor på skærmen der er trykket, samt GUI laget registrerer, hvilken knap der er trykket på. Pressed I denne state er der mulighed for at stoppe med at trykke på skærmen, som resulterer i, at staten går tilbage til Steady, og GUI laget vil sætte den allerede registrerede knap til selected. Der er også mulighed for at flytte fingeren rundt på skærmen, hvor en ændring på positionen i forhold til den oprindelige position på mere end en fastlagt margin vil resultere i, at der skiftes til state Manual Scroll. Ved et skift vil der blive gemt et timestamp og afstand blive nulstillet, for at der ikke kommer problemer i Manual Scroll. Manual Scroll Når der flyttes på fingeren i denne state, vil afstand konstant blive opdateret, og GUI laget vil blive informeret om den nye forskydning og retter listen, så scroll passer. Når der er gået et kort tidsinterval snapshot_interval efter det sidste timestamp, vil der blive udregnet en hastighed på baggrund af Afstand. Efterfølgende vil der blive sat et nyt timestamp, så der efter et kort tidsinterval igen kan udregnes en ny hastighed ud fra afstand. Hvis fingeren løftes fra skærmen og Hastighed er nul, bliver state sat til Stop. Ellers bliver state sat til Auto Scroll og programmets AlarmClock (yderligere forklaring følger) vil blive startet. Auto Scroll I denne state vil programmets alarmclock (yderligere forklaring følger) automatisk scrolle i noget tid, og derefter gå til staten Stop. Men hvis der undervejs trykkes på skærmen, vil der straks skiftes til state Stop, Hastighed

25 15 sættes til nul, og der registreres, hvor på skærmen der er trykket, og programmets alarmclock stoppes. Stop AlarmClock Hvis der flyttes på fingeren i denne state, vil resultatet blive det samme som i state Pressed, men hvis fingeren løftes, vil state uden videre blive sat til Steady. Programmets AlarmClock benytter sig af en timeevent, så den, uden brugerens indvirkning, løbene kan lave opdateringer. Når state er sat til AutoScroll, vil AlarmClock med et fast interval TIME_TICK sænke hastighed, lægge hastighed til den eksisterende forskydning, og opdatere GUI delen, så den passer til den nye forskydning. Hvis hastigheden falder til nul, sættes state til steady og AlarmClock stoppes. Dette vil resultere i, at mobilen automatisk scroller, mens brugeren er i stand til at skimme teksten, og undervejs falder hastigheden indtil den til sidst stopper. 4.2 GUI Jeg har tegnet den grafiske brugerflade med brug af QPainter, som er en medfølgende klasse, der indeholder en lang række funktioner til at tegne og skrive. For at regne ud hvilken del af listen der skal tegnes, benyttes forskydning og information fra den pågældende tests opsætning vedrørende punktstørrelse og opsætningen af grid/list. Koden til den grafiske brugerflade kan findes i vedlagte bilag. [Bilag 5, Kode, side 35]

26 16 Kapitel 4 - Implementation 4.3 Bruger test Jeg har lavet en test klasse, hvor jeg opretter de ti test. I test klassen er der nogle lister til at indeholde de relevante informationer, nogle funktioner til at få information om den aktuelle test, samt funktionen testcreater der bruges til at oprette de ti test. En test oprettes med følgende oplysninger Hvor mange objekter der skal være i testen Hvilke objekter der skal vælges for at afslutte testen Hvilken størrelse tekst der skal benyttes Om testdataen skal være navne eller bogstaver Hvor mange kolonner der skal være på linjerne Funktionerne namegenerator alfabet bruges så til at generere den ønskede mængde objekter. Koden til brugertesten kan findes i de vedlagte bilag. [Bilag 5, Kode, side 35] 4.4 TestData Til at gemme alt det genererede testdata har jeg lavet klassen TestData. Den indeholder nogle lister, der indeholder alt testdata, indtil alle test er udført og testdataen bliver gemt i en fil. For at gemme testdataen i de nævnte lister, benyttes funktionen savedata, der gemmer følgende data. Nummer på testen Størrelsen på forskydning Event type Event position x Event position y Tidspunkt Efter udførslen af alle test benyttes funktionen storedata til at gemme alt data med semikolonseparering mellem alle variabler og newline efter de enkelte events. For at finde et sted at gemme tekstfilen, bruges funktionen getfilename. Den finder et fortløbende og ubenyttet nummer # på en sådan måde, at informationen kan gemmes under "E:\data\test#.txt". Koden til implementationen af TestData kan findes i de vedlagte bilag. [Bilag 5, Kode, side 35]

27 Efterfølgende forarbejdning af test data De 15 testbrugeres test af de to mobiltelefoner har til sammen genereret 30 filer med testdata, der sammenlagt svarer til flere hundrede sider. Det ville resultere i et stort manuelt arbejde at finde ud af, hvor lang tid brugerne har brugt på de enkelte test, og hvor mange klik de har benyttet sig af. Jeg har derfor valgt at lave et program til at gennemgå alt data, og opstille det, så det kan importeres til et statistikprogram. Programmet har jeg valgt at skrive i C#, som er det, jeg har den største kendskab til. Det består af en funktion til at gennemgå alle datafilerne, hvor der optælles klik og udregnes brugt tid, for alle test. Denne data gemmes i dertil oprettede objekter, og efterfølgende opstiller funktionen alt data, så det er klar til indlæsning i et statistikprogram. Koden til dette program kan ses i vedlagte bilag. [Bilag 8, Kode, side 46] 4.6 udfordringer under udviklingen I starten af mit udviklingsforløb brugte jeg en del tid på at omstille mig til at udvikle i Nokia QT SDK. Men efter nogen tids eksperimentering og udvikling var jeg klar med min første liste, som fungerede i den medfølgende mobilsimulator, og fremskaffede derfor eksemplarer af Nokia 5800 og Nokia X6 mobiltelefonerne. Efter kort tids test på mobiltelefonerne erfarede jeg hurtigt, at programkravene ikke er det samme for brugen af en touch skærm og en mus. Jeg havde simpelthen udviklet et program, som var nærmest umuligt at benytte, uden brugen af en stylus. Dette resulterede i en større ombygning af koden og tilføjelse af bl.a. margin. Af dette kan jeg konkludere, at det kan betale sig at teste kode så tidligt som muligt.

28 KAPITEL 5 Forsøgsgennemgang De enkelte forsøgspersoner modtager mobilen, uden programmet er startet op. Deres første opgave er, under min vejledning, at finde og starte programmet. Det har til formål at give folk uden erfaring med touchmobiler en smugle erfaring, før forsøget starter. Det første, som brugeren får at vide, er, at selve testen består af 10 små opgaver, der hver i sær vil blive præsenteret med et skærmbillede, der viser, hvilket navn eller bogstav, brugeren har til opgave at trykke på. For at starte den enkelte test, skal brugeren trykke på det fremviste objekt, når han er klar. Herefter vises mange objekter, hvor brugeren så skal finde det tidligere vist objekt. Hvis det ønskede objekt ikke fremtræder på skærmen, skal der scrolles ned, indtil det fremkommer, og der trykkes på objektet. Derefter tilgås næste opgave med samme procedure. For at sikre at det ikke kommer som en overraskelse, bliver alle testbrugere informeret om, at alt data er i alfabetisk orden. Når alle 10 opgaver er løst på den ene telefon, bedes brugeren om at gentage det samme på den anden telefon. For ikke at give den ene telefon en fordel i forhold til indlæring, skal de enkelte brugere starte skiftevis med den ene og den anden telefon. Efter fuldførelsen af testen blev deltageren bedt om at oplyse relevant data for testen, så som erfaring med mobiler. De oplyste data er noteret på dertil oprettet [Bilag 4, side 32] skemaer.

29 KAPITEL 6 Resultater og diskussion Efter at have benyttet mit dertil udviklede C# program til at udvinde de vigtigste informationer fra de 30 store og uoverskuelige logfiler, er jeg endt op med 600 tal, [bilag 9, data, side 50] der beskriver den enkelte testbrugers brugte tid (målt i sekunder) og registrerede klik for de enkelte test. Den data har jeg indlæst i statistikprogrammet JMP for at give et bedre overblik over, hvordan de enkelte personer er placeret, og hvilke personer der falder uden for det normale. 6.1 Gruppering af test data Det første jeg arbejde med var at finde sammenhæng mellem deres oplyste informationer, som alder eller vaner for brug af telefoner. Jeg var i stand til at finde en meget tydelig sammenhæng, nemlig mellem testresultaterne, og om testbrugerne var ejere af en touch mobil eller ej. Personer med en touch mobil brugte i snit 4,2 sekund på en test, mens en bruger uden en touch mobil i snit brugte 6 sekunder. Det er ikke unaturligt, at brugere med mindre erfaring er langsommere, men middelafvigelsen var også over dobbelt så stor, hvilket resulterer i statistisk meget usikkert data. Da jeg fremadrettet ofte vil differentiere mellem brugere med og uden erfaring med touch mobiler, vil jeg give de to brugergrupper navne. Gruppe A Alle 9 erfarne brugere med touch mobil. Gruppe B Alle 6 brugere uden touch mobil. Gruppe AB - Alle 15 testbrugere (Foreningsmængden mellem A og B). A [Bilag 1, graf, side 29], B [Bilag 2, graf, side 30] og AB [Bilag 3, graf, side 31] viser søjlediagrammer, for alle test og begge mobiltyper. Søjlerne indikerer gennemsnittet og fejllinjerne viser middelafvisningen. På samme måde vil de efterfølgende grafer også tegnes. Da jeg godt er klar over, at en mindre gruppe vil resultere i mere usikkert data, vil jeg primært arbejde med gruppe A og AB, eftersom B både er en lille gruppe og en gruppe med meget stor middelafvigelsen, som begge medvirker til meget usikkert data. Det er vær at nævne, at samtlige deltagere i gruppe A var i besiddelse af en telefon med capacitive skærmteknologi.

30 20 Kapitel 6 Resultater og diskussion 6.2 Indlæring under testen Efterfølgende har jeg set på brugernes indlæring under testen. Det kan have stor betydning for troværdigheden af sammenligninger mellem forskellige test, og er derfor en vigtig faktor for den senere analyse af resultaterne. Da jeg formoder, at der her er en forskel mellem gruppe A og B, har jeg set på dem individuelt. Det er også en interessant måde at se forskellen på, mellem de to skærmtyper. Gruppe A Den første illustration viser gruppe A, og resultaterne af alle 10 test på begge mobiltelefoner. Yderligere har jeg med lineær regression tegnet bedste rette linje. Da hældningen bestemmes ud fra, hvor lang tid der bliver brugt på opgaverne, kan den enkelte linje ikke sige noget, men en forskel på hældningen mellem de to vil indikere, at der er sket en større indlæring under den test, som giver den mest vandrette linje. Her er de to linjer relativt parallelle og eftersom brugerne i gruppe A har erfaring med den capacitive skærmtype (X6), og jeg derfor ikke forventer en videre indlæring under forsøget, vil paralleliteten betyde, at jeg også vil se bort fra indlæring i forsøg med 5800 med gruppe A. Gruppe B Denne illustration viser to ikke parallelle linjer, og tyder på at gruppen har haft en større/hurtigere indlæring under forsøgene med X6.

31 21 Vigtigt er det at bemærke, at ved sammenligning af alle fire linjer, ligger hældningen på gruppe A mellem, hvad hældningen er for de to linjer for gruppe B, hvilket gør resultaterne lidt mindre betydningsfuldt. Det kan betyde, at det skyldes tilfældigheder, eller at gruppe B er blevet mere utålmodige med 5800, og derved ikke koncentreret sig så meget. 6.3 Signifikante Resultater Grundet de relativt få forsøgspersoner og en stor spredning, specielt på 5800, har jeg ikke mulighed for at finde mange statistisk signifikante resultater. Grid-List 18 Som forventet har jeg været i stand til at påvise en signifikant forskel mellem hastigheden på et grid og en liste, når altså antallet af objekter ikke kan vises på listen, men stadig kan vises i et grid

32 22 Kapitel 6 Resultater og diskussion På illustrationen til venstre ses den markante fordel ved et grid. På illustrationen til højre ses en t test lavet i JMP ud fra gruppe A mobil Samme testtype har vist, at gruppe A mobil X6 og gruppe AB mobil 5800 også har en signifikant forskel på grid og [Bilag 10, side 51] list. De resterende test kan ses i vedlagte bilag. Grid-List 25 Ved Grid-List test med 18 objekter var det meget hurtigere med et Grid, som resultat af der ikke skulle bruges scroll. På den nedenstående Illustration til venstre, viser resultatet af Grid-List test med 25 objekter, samt scroll test med 25 objekter. Ved 25 objekter ses også en lille fordel ved Grid, som altså viser, at det er en virkelig god måde at repræsentere data på, hvis det altså er muligt. Eftersom jeg ikke har testet med over 25 objekter, har jeg ikke mulighed for at kommentere yderligere på denne tendens. Både forskellen mellem G25 og L25 samt G25 og l25 er signifikante, illustrationen til højre viser en t test af G25 mod l25 med data fra gruppe A mobil X6. De resterende [Bilag 11, side 53] test kan ses i vedlagte bilag.

33 23 Forskel på skærmtyper [Bilag 1, graf, side 29] Som det kan ses, ikke kun på gruppe A men også B [Bilag 2, graf, side 30], så er der en stor forskel på, hvor hurtigt at brugerne kan gennemføre test på henholdsvis 5800 og X6. Det er en forskel, der er mere markant, end jeg havde forventet. Om det skyldes at klik, scroll eller begge dele er svært at udføre på 5800, er umiddelbart ikke så tydeligt har en meget stor middelafvigelsen, og ved nærmere analyse i JMP kan det også ses, at det er forskellige personer, som har problemer i de forskellige test. Det er to ting, der indikerer, at brugerne har haft store vanskeligheder med brugen af mobilen. Ved t test viser flere test, at 5800 er signifikant langsom i forhold til X6, og på illustrationen til højre ses gruppe AB test G1 som et eksempel. De [Bilag 12, side 54] resterende test kan ses i vedlagte bilag. 6.4 Andre resultater Der kan læses mange ting ud fra de mange indhentede data, både ting som jeg oprindelig ønskede at finde, men også andet. Det meste er ikke andet end indicier, men muligvis noget en ny og større test vil kunne undersøge. Størrelse Tekststørrelsen er et område, der allerede er [8, Investigating Selection and Reading arbejdet med i Performance on a Mobile Phone while Walking], men jeg mener, at jeg har fået noget rimelig interessant frem i min test. Denne illustration viser test af liste med punkt størrelse 12 og 22 både med det maksimale antal objekter, der kan være på skærmen og med 25 objekter. De er ikke direkte sammenlignelige, da test L6 og L25 kun viser bogstaver og der i l10 og l 25 vises navn. Hvis der ses på de to test, hvor opgaven kun er at trykke uden at bruge scroll (L6 og l10), kan det ses, at der bliver brugt dobbelt så lang tid i den test med små navne (l10), end den med store bogstaver (L6). Denne tidsfaktor kan både skyldes, at testbrugerne bruger mere tid på at genkende/læse navne end enkelte bogstaver, eller fordi testbrugeren har svært ved at trykke på det lille navn.

34 24 Kapitel 6 Resultater og diskussion Det der er interessant ved denne graf er, at den viser indikationer på, at den omtalte tidsfaktor, allerede ved 25 objekter, er blevet opvejet af, at der skal bruges mindre tid på scroll. Altså en tydelig indikation på, at en lille tekststørrelse yder bedre, når der er mange objekter. Scroll længde og hastighed Nedenstående illustration viser X6 data fra min scroll test Det kan ses af den venstre illustration, at der ved en fordobling af objekter langt fra sker en fordobling i den totale brugte tid. Men hvis l10 antages som værende den tid, man bruger på at klikke, og derfor fratrækker den tid fra de andre test, for at finde den tid der bruges på scroll, giver det illustration til højre. Her ses det, at en fordobling i objekter næsten resulterer i en fordobling i tid. Det er muligt, at den brugte tid kan reduceres i de lange lister, hvis brugeren kender indholdet (som ofte er tilfældet i fx en kontaktliste), efter som det formentlig vil resultere i, at brugeren benytter kinetic scroll mere aggressivt for at komme til ca. det ønskede sted. Men selv med de målte tider, skal listen være relativ lang før, det kan betale sig at bruge en eventuel søgefunktion.

35 KAPITEL7 Konklusion Jeg har i denne rapport set på muligheden for at optimere touch mobilers brugergrænseflade, og undersøgt forskellen mellem forskellige touch teknologier. Jeg har opsat test, som har været i stand til at vise en betydelig sammenhæng mellem forskellige parametre. Jeg har fundet indikationer på sammenhæng mellem brugerens indlæringsevne og mobilens skærmtype, som viste en hurtigere indlæring ved brugen af den capacitive skærm, desuden var den som udgangspunkt også hurtigere at bruge end den resistive skærm. Endvidere har jeg fundet en sammenhæng mellem antallet af objekter og brugergrænsefladens præsentation af data, hvor et grid, grundet den gode udnyttelse af skærmen, viste sig at være signifikant hurtigere, ved 18 til 25 objekter. Yderligere har jeg kunnet finde en sammenhæng mellem brugerens interaktion med lister og antallet af objekter i listen. Jeg har i øvrigt fundet en indikation på, at den optimale tekststørrelse afhænger af antallet af objekter i en liste. Mine resultater er visualiseret i form af grafer og er statistisk dokumenteret. Resultaterne er ikke specifikke indstillinger, som udviklere direkte vil kunne bruge til at optimere deres system. Men de viser nogle parametre, der ved videreundersøgelse kan give nogle retningslinjer for optimale justeringer af parametre under forskellige vilkår, grundet andre parametre.

36 KAPITEL8 Perspektivering 8.1 Skærmtyper At mine resultater viser, at X6 med en capacitive skærm, som udgangspunkt er hurtigere at benytte, og at den også har en tendens til en hurtigere indlæring end 5800, må formodes at have stor indflydelse på forbrugernes førstehåndsindtryk. Det kunne være interessant at undersøge brugen af en stylus til 5800 eller om lang tids erfaring med skærmtypen vil resultere i, at 5800 bliver lige så hurtig som X6, og om den dårlige ydelse er specifik for 5800, eller om det er generelt for resistive skærme. 8.2 Scroll-test Mine resultater fra scroll-testen vil formentlig ikke kunne bruges til noget alene, efter som jeg ikke har sammenknyttet eksterne og interne parametre på området. Jeg har vist en indikation af, hvordan antallet af objekter i en liste, påvirker tidsforbruget, men hvis det ikke sammenknyttes med et internt parameter, som fx skriftstørrelse, vil det ikke give mulighed for at optimere listen til de specifikke parametre. Udover at det fremadrettet kunne være interessant at teste på flere forskellige skriftstørrelser, kunne det også være interessant at teste søgning i lister, hvor brugerne på forhånd er bekendt med indholdet af listen. Dette kunne have betydning på brugbarheden af resultaterne, eftersom mobilbrugere ofte er bekendt med indholdet i diverse lister, som fx deres kontaktliste. 8.3 Grid-List test Min test har vist stort potentiale i brugen af Grid, men eftersom min test kun går op til 25 objekter, kunne det være interessant at se, hvordan det skalerer op. På nuværende tidspunkt bliver Grid primært brugt til at vise ikoner til opstart af menuer eller programmer. Yderligere test ville også kunne belyse, om det ville være fordelagtigt at bruge Grid til fx billeder af kontaktpersoner.

37 Mekanismer i state machine Da jeg ved den indledende analyse og test design ikke havde nogen erfaring med programmering til mobiltelefoner, kendte jeg ikke til problematikken i de meget upræcise klik. Ved implementering benyttede jeg mig af et eksisterende state machine design, som brugte en margin, der bestemmer hvor meget bevægelse, der skal til for at bestemme, om en handling skal tolkes som scroll eller et klik. Denne margin er klart et tal, der generelt kan optimeres, men også et tal, der kan optimeres til den enkelte skærmtype eller interface, og muligvis også til den enkelte bruger. 8.5 Statistiske påviselige resultater En generel tendens i mine resultater er, at de ikke er signifikante grundet stor spredning og et relativt lavt antal testdeltagere. Fremtidige test vil formentlig indeholde flere testdeltagere, men det vil også være smart at designe nye test, så testdeltagerne kan gennemgå forskellige test, der giver data inden for samme område. På de to måder vil det være muligt at få flere testdata. Ved eventuelt at indsnævre testgruppen til fx ikke at indeholde folk uden kendskab til touch mobiler, ville det også kunne ende med en mindre spredning, som igen vil hjælpe til at give mere signifikant data.

38 KAPITEL9 Litteraturhenvisninger [1] [2] [3] [4] [5] [6] as_brr=3&as_pt=alltypes&ei=smoaseonjihmyatkllwzcw [7] [8] "Investigating Selection and Reading Performance on a Mobile Phone while Walking" by Bastian Schildbach and Enrico Rukzio (september 2010)

39 KAPITEL10 Bilag Bilag 1: Gruppe A Alle 9 erfarne brugere med touch mobil.

40 30 Kapitel 10 Bilag Bilag 2: Gruppe B Alle 6 brugere uden touch mobil.

41 31 Bilag 3: Gruppe AB - Alle 15 testbrugere

42 32 Kapitel 10 Bilag Bilag 4: Udfylde testbruger skemaer

43 33

44 34 Kapitel 10 Bilag

45 35 Bilag 5: Main.cpp #include <QtCore> #include <QtGui> #include <iostream> #include <fstream> #include <sstream> #include <ctime> #include <QString> #include <sys/stat.h> #include "kineticscroll.h" // Test ////////////////////////////////////////////////// static QStringList namegenerator(int length) QStringList names; names << "Brian" << "Lasse" << "Lise" << "Andre" << "Anne" << "Camilla" << "Christian" << "Daniel" << "Gustav" << "Jonas" << "Kasper" << "Lars" << "Mikkel" << "Simon" << "Svante" << "Thomas"; QStringList surnames; surnames << "Jakobsen" << "Nielsen" << "Larsen" << "Olesen" << "Jørgensen" << "Andersen" << "Christensen" << "Jensen" << "Sørensen" << "Rasmussen" << "Jørgensen" << "Petersen" << "Madsen" << "Kristensen" << "Olsen" << "Thomsen" << "Christiansen" << "Poulsen" << "Johansen" << "Knudsen"; // combine name and surname QStringList combinednames; int namecount = names.count(); int surnamescount = surnames.count(); for (int j = 0; j < surnamescount; ++j) for (int i = 0; i < namecount; ++i) combinednames << QString("%1 %2").arg(names[i]).arg(surnames[j]); if(combinednames.count() == length) combinednames.sort(); return combinednames; surnames.move(0,surnamescount-1); combinednames.sort(); return combinednames; static QStringList alfabet(int length) QStringList letters; letters << " A" << " B" << " C" << " D" << " E" << " F" << " G" << " H" << " I" << " J" << " K" << " L" << " M" << " N" << " O" << " P" << " Q" << " R" << " S" << " T" << " U" << " V" << " W" << " X" << " Y" << " Z"; QStringList returnletters; for (int i = 0; i < letters.count() &&!(i == length) ; i++) returnletters << letters[i]; return returnletters;

46 36 Kapitel 10 Bilag class Test public: Test() testcreater(6, 3, 22, 2, 3); testcreater(6, 5, 22, 2, 1); testcreater(18, 8, 22, 2, 3); testcreater(18, 12, 22, 2, 1); testcreater(25, 20, 22, 2, 3); testcreater(25, 21, 22, 2, 1); testcreater(10, 4, 12, 1, 1); // testcreater(25, 18, 12, 1, 1); // testcreater(50, 40, 12, 1, 1); // testcreater(100, 87, 12, 1, 1); // testnumber = -1; nexttest(); QString name(int i) if (testexist && i < amountofnamesintest) return testnamelist[test()][i]; return ""; int wantedpersonnumber() if (testexist) return testpersonlist[test()]; return -1; QString wantedpersonstr() if (testexist) return testnamelist[test()][testpersonlist[test()]]; return ""; int fontsize() if (testexist) return fontsizelist[test()]; return -1; int columns() if (testexist) return columnlist[test()]; int test() return testnumber; bool nexttest() testnumber++; if(test() < testnamelist.count()) amountofnamesintest = testnamelist[test()].count(); return true;

47 37 testexist = false; return false; int amountofnames() return amountofnamesintest; private: int testnumber; QList<QStringList> testnamelist; QList<int> testpersonlist; QList<int> fontsizelist; QList<int> columnlist; bool testexist; int amountofnamesintest; void testcreater(int length, int person, int fontsize, int testcontent, int columns) QStringList names; if(testcontent == 1) names = namegenerator(length); else names = alfabet(length); QStringList personname; personname << names[person]; testnamelist << personname; testpersonlist << 0; fontsizelist << fontsize; columnlist << columns; testnamelist << names; testpersonlist << person; fontsizelist << fontsize; columnlist << columns; ; // TestData ////////////////////////////////////////////////// class TestData public: bool savedata; void adddata(int testnumber, int mouseeven, int posx, int posy, int forskydning) if (savedata) testnumberlist << testnumber; mouseevenlist << mouseeven; posxlist << posx; posylist << posy; forskydninglist << forskydning; time_t rawtime; struct tm * timeinfo; char buffer [10]; time ( &rawtime ); timeinfo = localtime ( &rawtime ); strftime (buffer,10,"%x",timeinfo); timelist << buffer;

48 38 Kapitel 10 Bilag void storedata(testdata& testdata) if(savedata) std::string filename = getfilename(); std::ofstream myfile; myfile.open (filename.c_str()); for (int i = 0; i < testdata.testnumberlist.count(); i++) myfile << testdata.testnumberlist[i]; myfile << ";"; myfile << testdata.mouseevenlist[i]; myfile << ";"; myfile << testdata.posxlist[i]; myfile << ";"; myfile << testdata.posylist[i]; myfile << ";"; myfile << testdata.forskydninglist[i]; myfile << ";"; myfile << testdata.timelist[i]; myfile << ";\n"; myfile.close(); qwarning() << "gemt som " << filename.c_str() << " " << testdata.testnumberlist.count(); savedata = false; private: QList<int> testnumberlist; QList<int> mouseevenlist; QList<int> posxlist; QList<int> posylist; QList<int> forskydninglist; QList<std::string> timelist; std::string getfilename() std::string tempname; struct stat stfileinfo; int intstat = 0; int i = 0; while(intstat == 0) i++; std::stringstream ss; ss << i; tempname = "E:\\data\\test"; tempname.append(ss.str()); tempname.append(".txt"); intstat = stat(tempname.c_str(),&stfileinfo); return tempname; ; // NameList ////////////////////////////////////////////////////////////////////// ///// class NameList : public QWidget, public KineticScroll

49 39 Q_OBJECT public: NameList(QWidget *parent = 0) : QWidget(parent) _forskydning = 0; tagged = -1; selected = -1; setattribute(qt::wa_opaquepaintevent, true); setattribute(qt::wa_nosystembackground, true); setmousetracking(true); KineticScroll::setAcceptMouseClick(this); simulation = false; testdata.savedata =!simulation; protected: virtual QPoint scrollforskydning() const return QPoint(0, _forskydning); virtual void setscrollforskydning(const QPoint &forskydning) int yy = forskydning.y(); if (yy!= _forskydning) _forskydning = qbound(0, yy, _height * test.amountofnames() / test.columns() - height()); update(); protected: // GUI ///////////////////////////////////// void paintevent(qpaintevent *event) //hvis der er trykket på den rigtige person skal den gå til næste test if (selected == test.wantedpersonnumber()) if(!test.nexttest()) testdata.storedata(testdata); selected = -1; tagged = -1; setwindowtitle(test.wantedpersonstr()); QPainter p(this); p.setfont(qfont("arial", test.fontsize())); _height = QFontMetrics(p.font()).height(); p.fillrect(event->rect(), Qt::white); int start = _forskydning / _height; /// int y = start * _height - _forskydning; if (_forskydning <= 0) start = 0; y = -_forskydning; start = start * test.columns(); int end = start + height() / _height * test.columns() + 1; if (end > test.amountofnames() - 1) end = test.amountofnames() - 1; for (int i = start; i <= end; y += _height) int x = 0; while(i <= end && x < width()) p.setbrush(qt::nobrush);

50 40 Kapitel 10 Bilag p.setpen(qt::black); if (i == selected) p.fillrect(x, y, width()/test.columns(), _height, QColor(0, 128, 240)); p.setpen(qt::white); p.drawtext(x, y, width()/test.columns(), _height, Qt::AlignVCenter, test.name(i)); x += width()/test.columns(); i++; p.end(); // Event press move release /////////// void mousepressevent(qmouseevent *event) testdata.adddata(test.test(), 1, event->pos().x(), event- >pos().y(), _forskydning); KineticScroll::handleMousePress(event); if (event->isaccepted()) return; if (event->button() == Qt::LeftButton) int y = event->pos().y() + _forskydning; int i = y / _height * test.columns(); int x = width()/test.columns(); while(x < event->pos().x()) i++; x += width()/test.columns(); if (i!= tagged) tagged = i; selected = -1; update(); event->accept(); void mousemoveevent(qmouseevent *event) testdata.adddata(test.test(), 2, event->pos().x(), event- >pos().y(), _forskydning); KineticScroll::handleMouseMove(event); void mousereleaseevent(qmouseevent *event) testdata.adddata(test.test(), 3, event->pos().x(), event- >pos().y(), _forskydning); KineticScroll::handleMouseRelease(event); if (event->isaccepted()) return; if (event->button() == Qt::LeftButton) selected = tagged; event->accept(); update();

51 41 // variable ////// private: int _forskydning; int _height; int tagged; int selected; bool simulation; Test test; TestData testdata; ; // Main ////////////////////////////////////////////////////////////////////// #include "main.moc" int main(int argc, char *argv[]) QApplication app(argc, argv); NameList list; list.setwindowtitle(""); #ifdef Q_OS_SYMBIAN list.showmaximized(); #else list.resize(360, 640); list.show(); #endif return app.exec(); #include "kineticscroll.h" #include <QtCore> #include <QtGui> #define HASTIGHED_MAX 50 #define TIME_TICK 20 #define SNAPSHOT_INTERVAL 25 #define MARGIN 15 class KineticScrollAlarmClock: QObject public: KineticScrollAlarmClock(KineticScroll *scroller) this->scroller = scroller; void start(int interval) if (!timer.isactive()) timer.start(interval, this); void stop() timer.stop(); protected: void timerevent(qtimerevent *event) Q_UNUSED(event); scroller->alarm(); private: KineticScroll *scroller; QBasicTimer timer; ; Bilag 6: kineticscroll.cpp

52 42 Kapitel 10 Bilag class KineticScrollPrivate public: typedef enum Steady, Pressed, ManualScroll, AutoScroll, Stop State; State state; int margin; //hvor meget der må flyttes før der skiftes til Manual Scroll QPoint presspos; QPoint forskydning; //hvor meget der er Scrollet QPoint Afstand; QPoint hastighed; KineticScrollAlarmClock *alarmclock; QTime timestamp; QWidget *target; QList<QEvent*> ignorelist; ; KineticScroll::KineticScroll() var = new KineticScrollPrivate; var->state = KineticScrollPrivate::Steady; var->margin = MARGIN; var->alarmclock = new KineticScrollAlarmClock(this); var->timestamp = QTime::currentTime(); var->target = 0; KineticScroll::~KineticScroll() delete var; void KineticScroll::setMargin(int margin) if (margin >= 0) var->margin = margin; int KineticScroll::margin() const return var->margin; void KineticScroll::setAcceptMouseClick(QWidget *target) var->target = target; static QPoint deaccelerate(const QPoint &hastighed, int a = 1, int max = HASTIGHED_MAX) int x = qbound(-max, hastighed.x(), max); int y = qbound(-max, hastighed.y(), max); if (x > 0) x -= a; else if (x < 0) x += a; if(y > 0) y -= a;

53 43 else if (y < 0) y += a; return QPoint(x, y); void KineticScroll::handleMousePress(QMouseEvent *event) event->ignore(); if (event->button()!= Qt::LeftButton) return; if (var->ignorelist.removeall(event)) return; switch (var->state) case KineticScrollPrivate::Steady: event->accept(); var->state = KineticScrollPrivate::Pressed; var->presspos = event->pos(); break; case KineticScrollPrivate::AutoScroll: event->accept(); var->state = KineticScrollPrivate::Stop; var->hastighed = QPoint(0, 0); var->presspos = event->pos(); var->forskydning = scrollforskydning(); var->alarmclock->stop(); break; default: break; void KineticScroll::handleMouseRelease(QMouseEvent *event) event->ignore(); if (event->button()!= Qt::LeftButton) return; if (var->ignorelist.removeall(event)) return; QPoint Afstand; switch (var->state) case KineticScrollPrivate::Pressed: event->accept(); var->state = KineticScrollPrivate::Steady; if (var->target) QMouseEvent *event1 = new QMouseEvent(QEvent::MouseButtonPress, var->presspos, Qt::LeftButton, Qt::LeftButton, Qt::NoModifier); QMouseEvent *event2 = new QMouseEvent(*event); var->ignorelist << event1; var->ignorelist << event2; //aktivere mousepressevent() i main QApplication::postEvent(var->target, event1); //aktivere mousereleaseevent() i main QApplication::postEvent(var->target, event2); break; case KineticScrollPrivate::ManualScroll: event->accept(); Afstand = event->pos() - var->presspos; var->forskydning = scrollforskydning(); var->presspos = event->pos();

54 44 Kapitel 10 Bilag if (var->hastighed == QPoint(0, 0)) var->state = KineticScrollPrivate::Steady; else var->state = KineticScrollPrivate::AutoScroll; var->alarmclock->start(time_tick); break; case KineticScrollPrivate::Stop: event->accept(); var->state = KineticScrollPrivate::Steady; var->forskydning = scrollforskydning(); break; default: break; void KineticScroll::handleMouseMove(QMouseEvent *event) event->ignore(); if (!(event->buttons() & Qt::LeftButton)) return; if (var->ignorelist.removeall(event)) return; QPoint Afstand; switch (var->state) case KineticScrollPrivate::Pressed: case KineticScrollPrivate::Stop: Afstand = event->pos() - var->presspos; if (Afstand.x() > var->margin Afstand.x() < -var->margin Afstand.y() > var->margin Afstand.y() < -var- >margin) var->timestamp = QTime::currentTime(); var->state = KineticScrollPrivate::ManualScroll; var->afstand = QPoint(0, 0); var->presspos = event->pos(); event->accept(); break; case KineticScrollPrivate::ManualScroll: event->accept(); Afstand = event->pos() - var->presspos; setscrollforskydning(var->forskydning - Afstand); if (var->timestamp.elapsed() > SNAPSHOT_INTERVAL) var->timestamp = QTime::currentTime(); var->hastighed = Afstand - var->afstand; var->afstand = Afstand; break; default: break; void KineticScroll::alarm() if (var->state == KineticScrollPrivate::AutoScroll) var->hastighed = deaccelerate(var->hastighed); setscrollforskydning(var->forskydning - var->hastighed); var->forskydning = scrollforskydning(); if (var->hastighed == QPoint(0, 0))

55 45 var->state = KineticScrollPrivate::Steady; var->alarmclock->stop(); else var->alarmclock->stop(); Bilag 7: kineticscroll.h #ifndef KINETICSCROLL_H #define KINETICSCROLL_H class QMouseEvent; class QPoint; class QWidget; class KineticScrollAlarmClock; class KineticScrollPrivate; class KineticScroll public: KineticScroll(); virtual ~KineticScroll(); void setmargin(int margin); int margin() const; void setacceptmouseclick(qwidget *target); void handlemousepress(qmouseevent *event); void handlemousemove(qmouseevent *event); void handlemouserelease(qmouseevent *event); protected: virtual QPoint scrollforskydning() const = 0; virtual void setscrollforskydning(const QPoint &forskydning) = 0; private: void alarm(); KineticScrollPrivate *var; friend class KineticScrollAlarmClock; ; #endif // KINETICSCROLL_H

56 46 Kapitel 10 Bilag using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.IO; namespace Statistik class Program static void Main(string[] args) Bilag 8: Program til forarbejdning af data List<int> testpersonlist = new List<int>(); List<Test> testlist = new List<Test>(); string mobil = string.empty; string path0 = string.empty; string path1 = ":\\data\\test"; string path2 = ".txt"; int testperson = 0; try try Console.WriteLine("Mobil:"); mobil = Console.ReadLine(); if (mobil == "x6" mobil == "5800") path1 = "c:\\users\\brian\\desktop\\imm-b.eng \\" + mobil + "\\test"; ///////////////////////////// else Console.WriteLine("drev:"); path0 = Console.ReadLine(); Console.WriteLine("skriv de ønskede numre"); while (true) testpersonlist.add(convert.toint32(console.readline())); catch if (testpersonlist.count() == 0) Console.WriteLine("test 1-15"); testpersonlist.clear(); testpersonlist.add(1); testpersonlist.add(2); testpersonlist.add(3); testpersonlist.add(4); testpersonlist.add(5); testpersonlist.add(6); testpersonlist.add(7); testpersonlist.add(8); testpersonlist.add(9);

57 47 testpersonlist.add(10); testpersonlist.add(11); testpersonlist.add(12); testpersonlist.add(13); testpersonlist.add(14); testpersonlist.add(15); while (testperson < testpersonlist.count()) String tekst; using (StreamReader sr = new StreamReader(path0 + path1 + testpersonlist[testperson].tostring() + path2)) Test test = new Test(1, testpersonlist[testperson]); while (sr.peek() >= 0) tekst = sr.readline(); string[] felter = tekst.split(';'); if (felter.count() >= 6 &&!(Convert.ToInt32(felter[0]) % 2 == 0)) if (felter[1] == "1") test.klik++; test.addsluttid(felter[5]); else if (felter.count() >= 6 && (Convert.ToInt32(felter[0]) % 2 == 0)) if ((Convert.ToInt32(felter[0])) >= test.testnr) testlist.add(test); test = new Test(Convert.ToInt32(felter[0]) + 1, testpersonlist[testperson]); else test.addstarttid(felter[5]); testlist.add(test); testperson++; Console.WriteLine("::::::::::::::::::::"); for (int i = 1; i < 20; i++, i++) testperson = 0; int klikmin = 1000; int klik = 0; int klikmax = 0; int sekmin = 1000; int sek = 0; int sekmax = 0; testlist.foreach(delegate(test test)

58 48 Kapitel 10 Bilag test.testnr == i) if (testperson < testpersonlist.count() && if (test.klik > klikmax) klikmax = test.klik; klik += test.klik; if (test.klik < klikmin) klikmin = test.klik; if (test.sek > sekmax) sekmax = test.sek; sek += test.sek; if (test.sek < sekmin) sekmin = test.sek; testperson++; ); Console.WriteLine("klikMin == " + klikmin + " sekmin == " + sekmin + " klik == " + klik / testpersonlist.count() + " sek == " + sek / testpersonlist.count() + " klikmax == " + klikmax + " sekmax == " + sekmax); Console.WriteLine("::::::::::::::::::::"); testperson = 0; while (testperson < testpersonlist.count()) int klik = 0; int sek = 0; testlist.foreach(delegate(test test) if (test.testperson == testpersonlist[testperson]) klik += test.klik; sek += test.sek; ); Console.WriteLine(" klik == " + klik + " sek == " + sek); testperson++; Console.WriteLine("::::::::::::::::::::"); StreamWriter sw = new StreamWriter("c:\\Users\\Brian\\Desktop\\IMM-B.Eng \\test" + mobil + ".txt"); testperson = 0; string str = string.empty; testlist.foreach(delegate(test test) if (test.testperson == testpersonlist[testperson]) str += "SekTest " + test.testnr + " Mobil " + mobil + ";" + "kliktest " + test.testnr + " Mobil " + mobil + ";"; ); Console.WriteLine(str); sw.writeline(str);

59 49 while (testperson < testpersonlist.count()) str = string.empty; testlist.foreach(delegate(test test) if (test.testperson == testpersonlist[testperson]) str += test.sek + ";" + test.klik + ";"; ); Console.WriteLine(str); sw.writeline(str); testperson++; sw.close(); catch (Exception e) Console.WriteLine("The process failed: 0", e.tostring()); Console.WriteLine(testList.Count+"::::::::::::::::::::"); foreach (Test test in testlist) Console.WriteLine(test.testPerson + " " + test.testnr + " " + test.klik + " " + test.sek); Console.ReadLine(); class Test public Test(int testnr, int testperson) this.testnr = testnr; this.testperson = testperson; public int testperson; public int testnr; public int klik = 0; public int sek; private int starttid; public void addstarttid(string tid) string[] felter = tid.split(':'); starttid = 3600 * Convert.ToInt32(felter[0]); starttid += 60 * Convert.ToInt32(felter[1]); starttid += Convert.ToInt32(felter[2]); public void addsluttid(string tid) string[] felter = tid.split(':'); sek = 3600 * Convert.ToInt32(felter[0]); sek += 60 * Convert.ToInt32(felter[1]); sek += Convert.ToInt32(felter[2]); sek -= starttid;

60 50 Kapitel 10 Bilag Bilag 9: Forarbejdet resultat data SekTest 1 Mobil x6;kliktest 1 Mobil x6;sektest 3 Mobil x6;kliktest 3 Mobil x6;sektest 5 Mobil x6;kliktest 5 Mobil x6;sektest 7 Mobil x6;kliktest 7 Mobil x6;sektest 9 Mobil x6;kliktest 9 Mobil x6;sektest 11 Mobil x6;kliktest 11 Mobil x6;sektest 13 Mobil x6;kliktest 13 Mobil x6;sektest 15 Mobil x6;kliktest 15 Mobil x6;sektest 17 Mobil x6;kliktest 17 Mobil x6;sektest 19 Mobil x6;kliktest 19 Mobil x6;sektest 1 Mobil 5800;klikTest 1 Mobil 5800;SekTest 3 Mobil 5800;klikTest 3 Mobil 5800;SekTest 5 Mobil 5800;klikTest 5 Mobil 5800;SekTest 7 Mobil 5800;klikTest 7 Mobil 5800;SekTest 9 Mobil 5800;klikTest 9 Mobil 5800;SekTest 11 Mobil 5800;klikTest 11 Mobil 5800;SekTest 13 Mobil 5800;klikTest 13 Mobil 5800;SekTest 15 Mobil 5800;klikTest 15 Mobil 5800;SekTest 17 Mobil 5800;klikTest 17 Mobil 5800;SekTest 19 Mobil 5800;klikTest 19 Mobil 5800; 3;6;3;6;2;5;2;4;3;6;5;7;1;2;4;3;6;6;8;6;3;4;1;2;5;6;5;6;11;13;10;20;2;3;11;8;7;9;14;15; 1;2;3;4;2;4;5;5;5;4;7;5;2;2;6;4;9;9;9;8;1;2;1;2;2;2;5;6;2;3;4;5;3;2;9;9;6;5;30;18; 1;2;2;2;1;2;5;3;5;5;4;7;2;2;3;3;9;8;10;5;3;4;2;2;2;2;3;3;6;9;5;4;3;4;6;3;7;6;11;11; 3;5;2;2;1;2;7;7;13;7;10;15;5;5;4;5;7;8;14;15;2;3;1;2;19;25;11;11;19;30;4;7;3;5;6;5;13;1 5;18;16; 1;2;1;2;1;2;3;6;8;5;5;7;2;3;4;4;6;6;9;10;1;2;18;16;8;9;6;8;8;10;6;6;1;2;6;5;8;10;11;9; 1;2;1;2;1;2;3;4;2;3;5;5;3;4;5;4;5;5;10;7;4;4;7;5;3;2;10;9;10;7;9;10;3;3;18;13;13;12;14;1 2; 1;2;1;2;2;2;3;4;4;4;6;8;3;2;5;3;9;10;10;7;1;2;1;2;2;2;5;8;2;3;7;9;3;2;5;4;9;11;11;18; 6;6;2;2;0;2;3;5;3;3;3;4;3;4;2;3;7;6;9;14;9;9;2;2;2;4;6;4;7;8;6;6;3;2;3;3;5;3;10;8; 2;2;1;2;3;3;4;4;3;3;4;5;5;6;5;4;4;5;10;9;7;3;3;2;3;2;4;5;4;4;6;7;1;2;6;8;8;9;9;12; 1;2;2;2;1;2;2;4;3;5;4;4;2;2;4;4;6;9;8;5;3;3;2;2;5;6;4;4;4;3;4;4;3;4;4;6;9;8;11;9; 1;2;1;2;1;2;5;6;2;4;4;5;2;4;5;4;7;7;8;6;2;3;1;2;4;4;3;3;4;4;4;5;1;2;5;8;6;6;11;9; 1;2;1;2;2;2;4;4;4;4;4;8;1;2;3;4;5;6;8;7;1;2;1;2;1;2;3;4;3;3;5;5;2;2;5;4;6;6;10;8; 1;2;1;2;1;2;3;5;4;4;3;3;1;2;4;6;4;5;9;7;0;2;1;2;2;2;5;6;3;3;3;3;2;2;6;6;8;7;7;7; 0;2;1;2;1;2;3;4;2;4;4;5;1;2;3;4;4;7;12;8;1;2;1;2;1;2;3;3;3;3;5;6;2;2;4;4;6;7;6;5; 2;2;6;3;2;2;5;5;4;3;6;8;5;3;9;4;10;8;7;7;3;3;3;2;2;2;4;3;6;4;10;11;4;2;15;9;13;14;21;12;

61 51 Bilag 10:

62 52 Kapitel 10 Bilag

63 53 Bilag 11:

64 54 Kapitel 10 Bilag Bilag 12:

65 55

66 56 Kapitel 10 Bilag

67 57