PenlessApplication En webbläsare för handdator

Transkript

1 MDI/Interaktionsdesign PROJEKTRAPPORT PenlessApplication En webbläsare för handdator Projektuppgift 1 Interaktionsdesignseminarium I Interaktionsanalys: Infovis 1 Handledare: Studerande: Staffan Björk Magnus Johansson Magnus Nilsson Linda Sjödin Christina Wisser

2 Sammanfattning På senare år har handdatorer slagit igenom som ett praktiskt sätt att ta med sig information på. Det har visat sig vara problem med att använda webbsidor på en handdator eftersom sidorna oftast är utformade för att passa en stor skärm med bra upplösning. När man använder samma sida på en liten skärm med sämre upplösning försvinner lätt överblicken av ett dokument. Detta projekt har därför bestått av att ta fram en prototyp för en webbläsare för Pocket PC som klarar av enklare webbsidor. Vi har studerat tidigare visualiseringstekniker och därefter tagit fram en tillämpning av focus/context visualiseringsteknik som förenklar användandet av webbsidor på en handdator. Tekniken, PenlessApplication, ger också användaren det stöd som behövs för att lättare kunna navigera bland informationen. Vi har valt att all hantering ska kunna ske med en hand. Detta gör att användaren kan använda den fria handen till annat såsom att hålla i en telefon. Genom enhandsgreppet kan även de med vissa handfunktionshandikapp använda browsern. Resultatet blev en teknik som använder sig av focus /context visualisering. Det vill säga att användaren får både detalj och översikt över dokumentet. Webbläsaren ger användaren en möjlighet att läsa webbsida för webbsida i ett fokusfönster samtidigt som två mindre fönster hjälper användaren med översikt. Ett av översiktsfönstren speglar den text användaren ser i fokusfönstret i sitt sammanhang men i ett mycket litet format. Det andra översiktsfönstret visar de länkar som finns på webbsidan i en lista. Det är möjligt för användaren att bläddra bland länkarna och välja för att gå vidare. Resultatet av vårt arbete har mynnat ut en fungerande webbläsare för ipaq. Webbläsaren ger användaren möjlighet att se båda detaljer och översikt. Navigering sker med hjälp av navigeringsknappen på ipaq en. Genom att vi valt att inte använda ett pekdon har möjligheterna att skriva in text uteslutits i denna version. Tekniken skulle kunna kompletteras med t ex ljudinmatning för att skriva in webb adresser i senare versioner. 2

3 Innehållsförteckning 1 Inledning Syfte och problemformulering Krav på funktionalitet och visualiseringsteknik Relaterat arbete Metod Resultat Utveckling av designen Slutgiltig design Beskrivning av visualiseringstekniken Diskussion Slutsatser och framtida arbete Referenser

4 1 Inledning Under de senaste åren har användningen av handdatorer ökat kraftigt. Detta har inneburit att flitigt använda datorapplikationer såsom ordbehandlare, mediaspelare och webbrowsers överförts och anpassas till ett mindre format. Sysslor som tidigare utförts på datorn i hemmet och på kontoret kan idag, tack vare handdatorns mobilitet, utföras i nästan vilken miljö som helst. Detta har även inneburit att kraven för utformning av applikationer har förändrats. De som skapar programmen måste både utgå från de begränsningarna handdatorn faktiskt innebär (mindre skärm, mindre minne, inget tangentbord osv.) men även från att den slutgiltiga produkten kommer att användas i de mest oförutsägbara situationerna. I detta arbete har vi fått uppgiften att skapa en webbrowser åt en ipaq handdator. Det är en uppgift som presenterat flera utmaningar. För det första är handdatorns skärm betydligt mindre än de flesta monitorerna för stationära datorer. Detta är ett problem då webbsidor på nätet är anpassade till att visas på större skärmar. Vidare begränsas webbrowserns utformande ytterligare då vi i uppgiften förbjudits att använda scroll bars, en vanligt förekommande navigeringsfunktion som återfinns i de flesta program där stora mängder information visualiseras. Som om dessa begränsningar inte räckte tyckte vi i gruppen att det vore intressant om användaren inte behövde använda sig av en stylus, det vill säga det pekdon som ersätter de stationära datorernas mus. Tanken var att man enbart med en hand skulle kunna läsa text, navigera i sidan samt att lätt komma åt sidans länkar. Detta kan vara mycket användbart i situationer då det krävs att en hand är fri för andra sysslor, exempelvis med att skriva, hålla en telefonlur eller hålla i en busstropp med. Vi menar att en sådan webbrowser i hög grad är anpassningsbar till olika arbetssituationer. 1. På/av- och ljusknapp 7. Kalenderknapp 2. Skärm 8. Röstinspelningsknapp 3. Snabbstartsknapp 9. Mikrofon 4. Snabbmeny 10. Ljusomgivningskänslig sensor 5. Högtalare samt 5-vägs navigationsknapp 11. Alarm/laddningsindikatorlampa 6. Kontaktlisteknapp Figur 1. Snabbspecifikation över ipaq 4

5 2 Syfte och problemformulering Syftet med detta arbete är dels att utefter givna begränsningar utforma en webbrowser för en ipaq handdator samt att implementera en prototyp av den i Java. Vi har i utformandet av denna rapport arbetat utefter följande frågeställningar: - Hur kan man utifrån tidigare utarbetade teorier och tekniker skapa en webbrowser för handdator (eller små skärmar)? - Hur gick vi till väga då vi utformade browsern? - Vad blev resultatet, fördelar/nackdelar? 2.1 Krav på funktionalitet och visualiseringsteknik Användaren ska kunna o läsa webbsidor o följa länkar o navigera bland text, bild och länkar utan stylus o få en överblick över helhet och detalj o använda handdatorn med en hand Visualiseringstekniken ska o Klara av att presentera webbsidor med de begränsade resurser som finns på en handdator o kunna presentera enklare webbsidor med ny eller tidigare tillämpad teknik o göra navigeringen enkel o skall inte använda scroll bars. 3 Relaterat arbete I detta kapitel presenteras de teorier och undersökningar vi utgått från under designprocessen. Vi stödjer våra resultat dels på forskning inom visualiseringsteknik men även inom andra typer av interaktionsdesign. För att visualisera text på små skärmar finns det en mängd olika tekniker. I stort rör det sig om tre inriktningar textreducering, zooming samt focus+context. Textreducering handlar att genom semantiska metoder och beräkningar reducera textmängden så att endast den väsentligaste informationen visas för användaren (Holmberg 1999). Tekniken är särskilt intressant då informationsmängden är så stor att det försvårar navigeringen. Exempel på tillämpningar som faller inom ramen för textreducering är bland annat dynamic queries (användaren reducerar själv textmängden genom självvalda filter) samt software agents (programmet reducerar viss information automatiskt). 5

6 Att zooma handlar helt enkelt om att förstora och förminska en text. Då man är intresserad av ett stycke i texten zoomar man in och läser. Då man vill navigera i texten zoomar man ut så att man får en helhetsbild av textens struktur. Denna teknik används exempelvis av pad++ -tekniken (Benderson & Hollan 1994). Focus+context handlar om att integrera en detalj med överblick så att användaren både kan navigera och se detaljer på samma output. Till denna teknikfamilj tillhör exempelvis fisheye (Furnas 1986). I denna fokuseras en specifik del av en text samtidigt som de de andra delarna förminskas mer och mer ju längre ifrån de kommer fokusen. En annan teknik som tillhör focus+context är Flip-zooming (Holmquist 1999). Här delas texten upp i objekt, exempelvis i sidor, där den sida som skall läsas visa i normalstorlek och de övriga minskas ner. Strukturen över i vilken ordning sidorna kommer behålls. Man väljer den sida man vill läsa varpå det finns möjlighet att zooma in ännu närmre. Robertson och Mackinlay (1993) beskriver i en artikel som behandlar deras teknik, The Document Lens, svårigheterna med att skapa ett visualiseringssystem då textens storlek och struktur är okänd. Problemet ligger i att textdokumentets, eller i vårt fall webbsidan, inte kan visas i sin helhet då den riskerar att bli så förminskad att den blir oläsbar. Om man däremot endast styckar texten i delar tappar läsaren översikten vilket försvårar navigeringen i texten. En sådan uppdelning blir problematisk eftersom det är omöjligt att förutse huruvida texten är linjär eller uppdelad i kapitel. Textens kontinuitet kan försvinna. Därför är det viktigt att skapa ett verktyg som både kan återge texten i ett läsbart format men som ger läsaren en känsla av den globala strukturen. Björk m fl. beskriver i artikeln Powerview (2000) svårigheterna med att utforma applikationer till handdatorer. Designern måste ta hänsyn till att användaren inte nödvändigtvis befinner sig i en kontrollerad kontorsmiljö. Med handdatorns mobilitet kommer oförutsägbara användarmiljöer där arbetssituationen kan medföra obekväma ställningar för användaren, dåligt belysta bullriga platser osv. Ofta förutsätts att användaren har båda händerna fria så denne kan styra programmet med en stylus. Vidare tar traditionella grafiska interfacekomponenter såsom scroll bars, knappar och menyer tar upp en märkbart stor del av handdatorns skärm. Greeking är en teknik för att visualisera text på en skärm. Tanken är att ge en generell bild av hur texten är strukturerad i ett dokument. Därför behöver texten i sig inte visas, utan kan representeras av exempelvis linjer, så att användaren får en uppfattning om hur dispositionen ser ut. Denna metod används bland annat av preview-funktioner i ordbehandlingsprogram [ 4 Metod Arbetssättet kan grovt delas upp i faserna idégenerering, analys, utvärdering och resultat. Liknande arbetssätt använder Nigel Cross i boken Engineering Design Methods (1994). Arbetet har dock varit en iterativ process och faserna har överlappat varandra och kommit igen mer än en gång. 6

7 Idégenerering Analys Utvärdering Resultat Figur 2. Processöversikt I idégenereringsfasen alstrades idéer genom brainstorming, skisser och diskussioner. Här försökte vi även hitta kärnan till de problem som vår teknik skulle lösa. Detta hjälpte oss att ta fram de krav som ställdes på tekniken. Fasen mynnade ut i en del skisser (se bilaga 1) och en kravspecifikation som gav gruppen något att diskutera kring. I analysfasen analyserades de idéer och förslag som tagits fram i idégenereringsfasen. Vi gjorde en nulägesstudie där vi studerade artiklar som behandlade liknande visualiseringstekniker. Detta följdes av mer diskussioner och fler lösningsförslag. Teknikbeskrivningar med skisser har kontinuerligt växt fram och värderats. I utvärderingsfasen jämförde vi våra lösningsförslag mot de krav som ställdes på tekniken. Vi diskuterade för- och nackdelar. Lösningsförslagen som togs fram granskades och värderades. Många var bra men dessvärre inte genomförbara med den teknik som vi hade tillhanda. En del lösningsförslag fick omarbetas och många gånger var det skärmens storlek som satte begränsningar. I resultatfasen bestämdes det hur den slutgiltiga tekniken skulle se ut. Den kom att vara en blandning av de olika tekniker som vi diskuterat oss fram till. Detaljer i applikationens formgivning såsom färger, typsnitt var det sista som behandlades innan vi fokuserade på implementationen. Arbetssättet som projektet delades upp i och som vi valde att arbeta efter hjälpte oss att inte utelämna någon viktig information. Arbetsfördelningen i gruppen gav sig ganska naturligt eftersom alla representerade olika kunskaper. 5 Resultat 5.1 Utveckling av designen Utformningen av Penless har växt fram under projektets gång. Tekniska problem som dök upp efter hand har påverkat designen. Några idéer fick tidigt överges eftersom vi inte trodde att vi skulle hinna genomföra dem. Samtidigt innebar detta att vi fick tänka 7

8 om och kunde skapa nya och mer anpassningsbara lösningar. Till en början diskuterades huruvida man kunde använda ipaq en liggandes och därigenom få en bättre läsbarhet eftersom texten presenteras på en större yta. Ett eventuellt problem som detta skulle medföra var hur navigationsknapparna skulle kunna användas av både höger- och vänsterhänta. Vi beslutade att inte följa upp idén eftersom vi saknade både programmeringskunskaper och tid att utföra den. Figur 3. Liggande läsyta Ett krav vi tidigt specificerade var att användaren skulle kunna läsa text, söka på och samtidigt ha en god översikt av sidan. Detta kan man lösa antingen genom att visa webbsidan över hela fönstret, där några begränsade rader förstoras upp till läsbar text varpå den övriga informationen bara visas som tecken symboler (genom greeking eller semantisk zooming). En slags variant på fisheytekniken helt enkelt. Detta läsfönster skulle kunna växlas mot ett översiktsfönster där ett hierarkiskt träd visade sidans struktur och storlek. För att kunna växla mellan de två sidorna skulle man en ha klickbar ikon. Ett annat alternativ vore att ha flikar vid någon av sidans kanter vilket skulle ge en indikation att man kan byta läge. Denna prototyp övergavs eftersom användaren inte skulle behöva byta lägen mellan att navigera och läsa. Utan ha båda funktionerna närvarande samtidigt. Figur 4. Skisser med olika funktioner Ett annat tidigt förslag var att det alltid visas läsbar text i ett stort fönster. Nedanför detta skulle det finnas tre valbara rutor: en ruta för att skriva in sökväg, en som visade en översikt av webbsidan samt en för att navigera i länkarna. En ruta var alltid aktiv vilket indikerades med en markeringsfärg. De övriga inaktiva rutorna skulle markeras i grått. Då man valde en ruta man var intresserad av visades information om denna under läsfönstret. Valde man sök så kom ett fält upp där man kunde skriva in en 8

9 adress, valde man översikt kom ett förenklat strukturträd upp som visade var i hierarkin man befann sig. Valde man slutligen navigation visades en bokmetafor med markerad text för att visa var i dokumentet man befann sig. Det var utifrån denna prototyp vi utvecklade den slutgiltiga designen. Bristerna i tekniken var att rutorna måste markeras, det vill säga göras aktiva, vilket kändes lite för avancerat. Det gick att förenkla. Vidare blir det svårare för användaren att växla mellan de olika lägena utan stylus. För att göra browsern användbar var vi tvungna att överge tanken om olika lägen för olika uppgifter. Figur 5. Skisser med valbara fält Vi har genom hela projektet velat ha en dokumentöversikt i form av en ikon. Från början var ikonen tänkt att vara en metafor för en bok som ligger uppslagen på så sätt skulle användaren kunna se om han är långt fram eller bak i dokumentet med hjälp av bokens tjocklek. Vi ville även att bokikonen skulle visa text på en sida och en länköversikt på den andra sidan. I stället för bokmetaforen funderade vi också på att använda ett block, en pergamentrulle eller en kikare. Figur 6. Översiktsikoner Bokmetaforen som textöversikt utvecklades till att representeras av ett vanligt papper, ett A4-ark, såsom i dokumentöversikten i Word. Detta eftersom metaforen kändes onödigt krånglig, vi kunde inte motivera dess existens. För att få en indikation på var i sidan läsfönstret befann sig skulle den aktuella texten i översiktsfönstret ramas in av en färgad ruta. En idé var att rutan skulle kunna vara navigeringsbar och att man genom den skulle kunna styra vad som visades i det läsfönstret, en idé som övergavs eftersom vi inte använder en stylus som man kan styra med. Rutan blev snarare en avspegling synkron med läsfönstret. Ett av de större problemen som kom att påverka designen var att definiera vad en sida i textöversikten var. Vi bestämde tillslut att en A4-sida i översiktsrutan representerade hela den aktuella webbsidan (html-filen). Detta innebar ett nytt stort problem. Hur skulle en stor sida kunna representeras på ett A4-ark? Till en början tänkte vi använda oss av greeking, men då uppstår problemet hur vi skulle representera ikoner, bilder och länkar. Webbsidor är ju inte enbart fylld med text. Därför beslutades att hela sidan skulle förminskas vilket skulle ge ungefär samma effekt som greeking. Texten skulle vara oläsbar, men man får en känsla av sidans struktur och form. 9

10 En ytterligare aspekt var hur länkar skulle representeras. I den förminskade översikten skulle dessa vara svåra att hitta och följa. I läsfönstret visas endast begränsad information. Det skulle bli besvärligt för användaren att i en stor sida bläddra upp och ner för att hitta en specifiklänk. Vi valde att införa ytterligare ett fönster, länköversikten, där alla sidans länkar radades upp och det var möjligt att välja någon av dessa. Något som vi bestämde oss för tidigt i projektet var att använda färger för att synliggöra olika saker som till exempel länkar, i blått, och var man befann sig på sidan, i rött på översiktsikonen. Andra förslag som diskuterats och som kanske skulle kunna användas i framtida varianter är att ge feedback genom ljus och ljud och att användaren själv ska kunna bestämma storlek på texten. Alla idéer som vi kommit fram till och som diskuterats under projektets gång har på något sätt påverkat resultatet. De har gett inspiration och fört oss in på olika tankebanor även om de inte direkt finns med i slutresultatet. 5.2 Slutgiltig design Skärmen är uppdelad i tre fönster, ett större som visar den läsbara texten, ett mindre som ger en sidöversikt och ett tredje som ger en länköversikt. Detta medför att användaren har möjlighet att läsa sin text i det stora fönstret och samtidigt få en överblick över var just denna text hör hemma på webbsidan i den mindre ikonen för sidöversikt. De länkar som är presenterade på sidan visas i länklistan. Ikonen som visar sidöversikten ger också användaren information om hur sidan är utformad, hur stor den är, om det finns några bilder och var på sidan man befinner sig. I länklistan presenteras information om de länkar som förekommer i texten och detta ger användaren en uppfattning om vilken information som visas på sidan och om det man söker finns representerat där. De två mindre fönstrena är synkroniserade med läsfönstret. I länklistan navigerar man med höger och vänster knapparna. För att detta ska kännas logiskt trots att man bläddrar upp och ner i länklistan har länkarna kopplats till en punktlista som ändras från höger till vänster, se figur 8. En av länkarna som visas i länklistan är en så kallad fusklänk som man kan välja för att backa i dokumentet. Denna länk är alltid synlig i listan. Skärmens uppdelning motsvarar den skala som går under benämningen gyllene snittet. Skalan används med fördel vid formatkonstruktioner (Hallberg, 1984). Enligt definition är gyllene snittet en relation mellan en mindre och en större del av en helhet, där den mindre delen står i samma proportion till den större som den större till helheten och tvärtom. Förhållandet mellan längden och bredden är 5 till 8. Det hävdas att vi människor uppfattar gyllene snittet som harmoniskt. Formeln för gyllene snittet är b/a = a/a+b, vilket för vår applikation motsvarar 198/ /320 (pixlar). 10

11 Figur 7.Gyllene snittet Fönsterna är placerade såsom vi tror känns mest logiskt för användaren. Det stora läsfönstret är viktigast och det fångar användarens uppmärksamhet först. Därför valde vi att placera det överst och de två mindre fönstren under. Vi placerade översiktsfönstret till vänster och länkfönstret till höger, för att vi upplevde att det kändes mer naturligt. Den grafiska utformningen innebar val av färger till länkar, val av typsnitt och storlekar på bokstäver samt färg till kvadraten som markerar positionen i översiktsfönstret. Länkfärgen valdes efter färgen som förekommer i andra webbrowsers, nämligen blå. Användarna är vana vid den färgen och det fanns ingen anledning för oss att byta den. Då det gäller typsnitt valde vi att rubrikerna skrevs ut med ett sans serif-typsnitt och brödtexten med ett serif-typsnitt. Detta är en vedertagen form av layout, som förekommer både i dagspress och i böcker. Den anses vara vilsam för ögat. Resultatet av alla diskussioner kring designen av Penless Application kom att se ut som i bilden nedan. Figur 8. ipaq med vår webbrowser 11

12 Efter att ha gjort vissa avvägningar mellan det önskvärda resultatet och tekniken så kom resultatet att se ut som i bilden nedan. Figur 9. Slutgiltigt utformningsresultat 5.3 Beskrivning av visualiseringstekniken I detta stycke beskrivs den visualiseringsteknik vi utarbetat. Den bygger på focus+context-tekniken där användaren får en överblick av webbsidan samtidigt med en detaljerad bild. Handdatorns display har delats upp i tre fönster, ett större och två mindre. Det större fönstret, läsfönstret, ger en detaljerad vy. Här skall användaren läsa text, se bilder och länkar. I det mindre fönstret som är placerat i vänster underkant, sidöversiktsfönstret, visas hela sidan (med andra ord hela html-filen) kraftigt förminskad. Det är i detta fönster som användaren får en överblick av hur sidan är strukturerad. En röd rektangel visar vart på sidan läsfönstret är fokuserat. Därigenom blir det lättare för användaren att navigera. I nedre högra hörnet visas ett fönster med en översikt av sidans länkar, länkfönstret. Därigenom behöver användaren inte gå igenom hela sidan för att aktivera en speciell länk. Visualiseringsteknikens unicitet är också att användaren inte ska behöva använda penna utan ska klara att använda handdatorn med en hand. ipaq använder sig av en navigationstangent för navigation och val. Tangenten har fem funktioner, dessa är: upp, ner, höger, vänster som väljs genom att trycka på motsvarande sida av tangenten. Genom att trycka på centrum av tangenten får användaren funktionen välj/bekräfta. Ett tryck på navigationstangentens övre eller nedre del förflyttar läsaren en sida upp respektive ner i texten. 12

13 Figur 10. ipaq s navigationsknapp. Genom att trycka på höger sida av navigationstangenten är det möjligt att bläddra bland länkar. Visualiseringstekniken ska hjälpa användaren att snabbt och enkelt läsa information i detalj men samtidigt få en översikt. Tekniken medger att användaren kan använda ett enhandsgrepp för att genomföra uppgiften. Genom det kan användaren utföra andra uppgifter med den andra handen. 6 Diskussion Det finns mycket att arbete kvar att utföra för att Penless Application skall bli en bra och genomtänkt produkt. Vi kommer i detta kapitel diskutera de svagheter som vi idag känner till och som vi, under andra förutsättningar, hade kunnat utveckla. Det är viktigt att poängtera att det antagligen finns fler brister som vi, på grund av vår inblandning i projektet, har svårt att se. Därför skulle det nästa steget i ett fortsatt arbete vara att utföra en användarstudie. En sådan skulle förmodligen ge en bättre bild av var problemen med vår teknik ligger. Eftersom vi arbetat på en teoretisk nivå skulle det vara givande att faktiskt möta de praktiska problemen. Ett påtagligt problem med vår webbläsare är att vi i sidöversiktsfönstret förminskar hela sidan. Med en större sida, eller en större fil, blir det sannolikt svårare att se delmängder av helheten i vårt kontextfönster. Man tappar textens struktur. Det är till och med troligt att det är omöjligt att använda tekniken som den är om filerna är mycket stora Här hade det varit kanske varit lämpligare att exempelvis implementera en semantisk zoom. Bilder och text hade kunnat visualiseras/representeras av ikoner. På så vis hade stora sidor kunnat visas utan att strukturen förvanskas. Men vi tror ändå att minikopian av hela dokumentet hjälper användaren att orientera sig i de flesta hemsidor. Ett annat problem är att länklistan i sig inte ger tillräcklig information om vad länken är kopplad till. Länktexten på hemsidor är inte alltid beskrivande. Exempelvis är länkar med ledtexter som klicka här, tryck på välj inte särskilt informativa i vår 13

14 länkruta. I en potentiell utveckling av prototypen skulle det ur våra länkar gå att välja ut något eller några ord som ger viss vägledning i länklistan. Som det ser ut idag förutsätter vår teknik att länkarna har bra benämningar för att de skall ge vägledning i länklistan. Att inte använda ett pekdon har både sina för- och nackdelar. Fördelar som nämnts är att de i specifika arbetssituationer möjliggör för användaren att överhuvudtaget kunna hämta information på nätet. Det är inte ovanligt att en hand är upptagen och då krävs ett enhandsgrepp. Det kan också tänkas att funktionshandikappade som enbart kan bruka en av sina händer skulle uppskatta att det gick att navigera med hjälp av en hand. Själva utformningen av dosan skulle kanske behöva omarbetas något för att passa bättre i handen. En stor nackdel är att det i vår nuvarande version av prototypen inte går att direkt skriva in en URL eftersom pennan inte används. Detta hade kunnat lösas genom hjälp av navigeringsknapparna som styr en markör i en lista med bokstäver och tecken. Genom att trycka in navigeringsknappen då markören vilar på en specifik bokstav skulle denna skrivas. Vanliga förkortningar som www, com och se skulle finnas i listan så att inskrivningen gick snabbare. Vi har som vi tidigare nämnt två lägen för knapparna som navigerar i texten. Användaren kan gå ner rad för rad, eller sida för sida. I den senare handlingen måste användaren hålla nere knappen en stund. Det kan vara problematiskt att implementera sådana funktioner då alla användare har olika uppfattningar om hur lång en stund egentligen är. Genom att låta ipacen generera ett ljud, exempelvis ett kort pip, då den hoppar fram en sida, får användaren omedelbar feedback för vilken funktion applikation utför. Förutom möjligheten att generera ljud innehar ipacen fyra extra knappar som vi inte använt. Främst därför att deras funktion inte är åtkomlig genom Java. Däremot hade det varit möjligt att nå dom om vi programmerade applikationen i C++. Möjligtvis hade vårt koncept fallit då det kan vara svårt att med ett enhandsgrepp nå alla fyra knapparna. Hade det dock i en användarstudie framkommit att vi saknar någon fundamental funktion är det bra att ha i åtanke att vi har fyra extra knappar. Uppgiften har på sätt och vis varit svår för att en stor del av arbetet har legat på programmeringssidan samtidigt som det inte är den del av uppgiften som lyfts fram. Uppgiften i sig har också varit komplex med att sätta sig in i olika visualiseringstekniker på kort tid och se deras möjligheter och begränsningar samt att försöka komma på bra förslag till nya lösningar. Vi har trots detta fått bra kvalitet på resultatet med de förutsättningar vi haft. Vi har inte nått ända fram, men de beror också på de avgränsningar som vi gjort i projektet. De metoder vi valt har fungerat väl. Troligtvis hade det kunnat fungera ännu bättre om vi gått igenom några mer strukturerade metoder innan för att ha alternativ att välja på. 14

15 7 Slutsatser och framtida arbete I detta kapitel kommer vi att knyta igen säcken som varit projekt InfoVis 1, som för oss resulterade i Penless Application. I kapitel 2 ställde vi oss tre frågor som vi skall återknyta till här. Den första frågeställningen är det som hela denna rapport försöker förklara. Den största bristen har för oss varit dels anknytningen till teorier och relaterade arbeten samt bristen på vår erfarenhet av design. Det finns inte många teorier och tidigare arbeten vi kan luta oss tillbaka mot. Vissa funktioner vi tillfört har vi haft svårigheter att motivera. Vi känner att det är rätt eller fel att använda en viss färg eller en viss placering på ett fönster, men vi kan inte riktigt motivera varför. Vi har varken den teoretiska kunskap av vad användare generellt föredrar, eller den fingerspetskunskap en yrkesverksam interaktionsdesigner har. Däremot har vi erfarenheter som dator- och programanvändare och det är mycket av den tysta kunskapen vi använt oss utav för att uppnå våra mål. Den andra frågeställningen kan knytas an till det som står här ovanför. Med den tysta kunskapen, samt ett urval av tidigare visualiseringstekniker, resonerade vi oss fram till ett resultat. Vad som också är viktigt att poängtera är att våra begränsade kunskaper i programmering styrde hur designen slutligen kom att se ut. Tanken om en styluslös design uppstod först när vi insåg hur svårt det var att mappa touchfönstret i programkoden. Detta resulterade att vi fick omarbeta designen ännu en gång och idéer fick kastas. I efterhand känns det rätt skönt att bli av med några dessa. Därigenom har vi i arbetet insett att olika typer av begränsningar kan resultera att designen blir bättre. Man skall inte vara för rädd för att kasta bort idéer. I den sista frågeställningen frågar vi oss vad som är fördelarna respektive nackdelarna med vår design. Många av nackdelarna tar vi upp i diskussionskapitlet. Det finns säkerligen flera vi ännu inte känner till. Några fördelar som vi vill understryka ännu än gång är att användaren kan navigera med en knapp, vi sparar mycket läsyta på att inte använda traditionella interfacekomponenter som scroll bar och menyer. Användaren kan lätt navigera i var på sidan han/hon befinner sig, vilken del som är fokuserad och läsbar. Det är lätt att hitta länkar och nyttja dom för att fortsätta resan på informationsmotorvägen. 15

16 8 Referenser Bederson, Benjamin B, Hollan, James D: Pad++ A Zooming Graphical Interface fo Exploring Alternate Interface Physics, UIST 1994 Björk, Staffan, Redström, Johan, Ljungstrand, Peter, Holmquist, Lars-Erik: PowerView: Using information links and inforamtion views to navigate and visualize information on small displays, sid Artikel, Björk, Staffan., Bretan, Ivan,.Danielsson, Rolf,. Karlgren, Jussi,. Franzén, Kristoffer,. WEST: A Web Browser for Small Terminals, CHI Letters vol 1,1, Ashevill, NC, 1999 Cross, Nigel: Engineering Design Methods, The Open University, 1984 Milton Keynes, UK Furnas, G.W. Generalized Fisheye Views. Human Factors in Computing Systems, sid 16-23, CHI 1986 Conference Proceedings Hallberg, Å: Klart för tryck, Bokförlaget Spektra, Berlings Grafiska AB, Arlöv, 1985 Holmquist, Lars Erik: Flip Zooming: Focus+Context Visualization of Linearly Ordered Discrete Visual Structures, sid 29 31, För PLAY Robertson, George G., Mackinlay, Jock D The Document Lens, s , 1993 Xerox Palo Alto Research Center 16