2002-04-17 09:13 Människa-Datorinteraktion DVC002 HCI text Anders Carlsson pt00aca@student.bth.se Per Salomonsson pt00psa@student.bth.se Grupp: D
Innehållsförteckning 1. Inledning... 3 2. Design och produktutveckling... 4 2.1 Vad är design?... 4 2.2 Varför behövs design?... 5 2.3 Vem designar?... 6 2.4 Vad skall designas?... 7 3. Metaforer... 8 4. Hur man kommer fram till bra användargränssnitt... 12 4.1 Prototyper... 12 4.1.1 Low-fidelity prototyper... 12 4.1.2 High-fidelity prototyper... 13 5. Designmönster... 14 5.1 Form... 14 5.2 Supplementary Window... 15 5.3 Selection... 16 5.4 Ephemeral Feedback... 17 5.5 Direct Manipulation... 17 6. Personliga reflektioner... 19 6.1 Anders Carlsson... 19 6.2 Per Salomonsson... 20 7. Källförteckning... 21 Sida 2 av 21.
1. Inledning HCI (Human Computer Interaction) är ett stort och ganska brett område. I den här texten diskuterar vi en del av de saker som vi tycker är viktiga inom området. Vi kommer även att ta fram vad vi har lärt oss genom att gå kursen och göra laborationerna. Sida 3 av 21.
2. Design och produktutveckling 2.1 Vad är design? Design är att få en produkt användbar. Det räcker idag inte med att ha en bra teknisk lösning på ett problem. För att lösningen skall bli användbar krävs även en god design. En bra design kompletterar en teknisk lösning så att användaren känner sig hemma med den. God design är inte bara utseendet hos en produkt. Det kan även vara att få produkten att passa in i en produktionscykel. Eller varför inte att få produkten att passa in en miljöpolicy och göra den miljövänlig. Design kan vara så mycket mer än vad man kanske tänker på vid första anblick. Hur designen sedan utformas beror på produktens syfte. Designen för exempelvis ett underhållningsprogram för barn blir högst sannolikt väsentligt skild från designen för en teknisk applikation utvecklad för att övervaka prestanda hos databaser. I det första fallet ser vi antagligen ett färgglatt gränssnitt med stora knappar och bilder. I det senare fallet är det mycket troligt att vi ser en lösning som i mycket högre grad är baserad på textuella beskrivningar som förutsätter stora domänspecifika kunskaper hos användaren. I båda fallen är dock designen helt avgörande för om den tänkta användaren skall trivas med och därmed använda produkten. Om vi tänker oss den omvända situationen så står vi inför flera problem. Den kanske inte ens läskunniga användaren ur målgruppen för underhållsapplikationen finner sin applikation tråkig och kanske helt obegriplig. Databasövervakaren å andra sidan finner antagligen sin applikation svår att jobba med. Sida 4 av 21.
Han begriper säkerligen applikationen men retar sig troligtvis på det överflödigt grafiska gränssnittet. Detta enkla exempel visar hur viktigt det är med en väl definierad målgrupp och en genomtänkt design som passar målgruppen. 2.2 Varför behövs design? Design behövs således för att anpassa en bra teknisk produkt till en specifik målgrupp och ge en applikation ett gränssnitt som passar användaren i fråga. Det är heller inte omöjligt att samma produkt utvecklas med olika gränssnitt och designer som riktar sig till olika användargrupper. Anledningen att vi vill ha en god design är alltså att vi vill anpassa en produkt till en specifik målgrupp med specifika intressen, kunskaper och mål. Detta ställer då mycket höga krav på designern eftersom han/hon måste tänka i helt andra banor än den traditionella applikationsutvecklaren. I stället för att fokusera på den tekniska lösningen måste designern i stället fokusera på den tilltänkte användaren och sätta sig in i hennes sätt att se på tillvaron. Vad vill användaren göra med applikationen? Vad vill användaren göra själv och vad vill hon att applikationen skall göra. På vilket vis vill hon ha information presenterad? Vilken domänkunskap har användaren? Dessa är bara några av de frågor som designern måste ställa sig själv, eller ännu hellre ställa till den tilltänkte användaren. Sida 5 av 21.
2.3 Vem designar? Inom programvaruutveckling så kan man hävda att tidigare har det inte varit någon alls som har designat. De gånger som design faktiskt har förekommit så har det många gånger inte varit på grunder som en design egentligen skall genomföras på, utan snarare på grunder som kommer från utvecklaren själv, inte den tilltänkte användaren. Problemet inom programvaruutveckling är att det krävs en specifik kunskap för att skapa snabba, bra och robusta programvarutekniska lösningar. Denna kunskap skiljer sig många gånger helt och hållet från den kunskap som behövs för att göra en bra design. De kunskaper som behövs då är mer av psykologisk och konstnärlig karaktär. Därför måste det i programvaruutvecklingen involveras flera personer från flera, inom programvaruutvecklingen nya, vetenskapsdiscipliner såsom psykologi, beteendevetenskap och etik. Dessutom finns det ofta idag en konstnärlig aspekt på det hela. Användaren vill inte bara ha ett bra och lättanvänt program utan även ett snyggt program. Det skall, i den mån det går, vara roligt att arbeta med ett program. För att uppnå detta mål räcker det inte med att programmet gör vad användaren vill och på det sätt användaren vill det. Dessutom måste applikationen se trevlig ut. Vem skulle vilja jobba med exempelvis ett Windows som bara presenterades i gråskaliga färger? Antagligen skulle det inte vara särskilt många som tyckte om det. Istället så vill användaren ha något som är trevlig att titta på. Däremot får det inte gå till överdrift. Den konstnärliga aspekten på designen får inte gömma den tekniska kunskapen hos applikationen. Det får inte bli för flashigt och krimskramsigt. Då tycker antagligen den mer vane användaren att programmet är jobbigt och i längden oanvändbart. Vem är det då som skall utföra denna design? Ja därom tvistar de lärda som man brukar säga. Klart är dock att det inte är den traditionella programvaruingenjören. Karl-Ola Sida 6 av 21.
Warnhammar, rektor vid Högskolan för design och konsthantverk vid Göteborgs Universitet skriver i en artikel i Ny Teknik nr 2002:5 som svar på frågan vart dessa designingenjörer skall utbildas: Framtiden ställer sådana krav på vår förmåga till kreativitet att svaret otvetydigt måste bli vid en konstnärlig fakultet, men en som breddat sin utbildningsbas att omfatta mer teknik, ekonomi, etik och samhällsorientering. Den träning som en konstnär får i kreativitet, utvecklar ytterligare en dimension i förmågan att lösa problem. Vi kan inte lösa nya problem med gamla metoder. Därför måste också de som ska lösa uppgifterna tränas i gränsöverskridande och samverkan. Med detta resonemang i bakhuvudet kan vi se den nya typen av ingenjörer framför oss. En ingenjör med kunskaper inom en rad vitt skilda vetenskapsdiscipliner såsom psykologi, konst, etik och programvaruteknik. Dock är det nog så att den höga tekniska kunskap som dagens programvaruingenjörer har kommer att behövas även i framtiden. Den behöver dock kompletteras med de nya ingenjörernas kunskaper. 2.4 Vad skall designas? Egentligen är det så att allt som vi använder har designas på ett eller annat sätt. Någon har på något vis bestämt hur en sak skall se ut. Sen är det en annan sak att utseendet kan vara mer eller mindre lyckat. Dessutom är det så att det kan vara av olika stor vikt om utseendet är lyckat eller ej. En applikation som används ofta har naturligtvis större krav på sig att ha en lyckad design. Å andra sidan kan man tänka att en produkt som inte används särskilt ofta måste ha en god design så att användaren inte måste lära om varje gång hon skall använda produkten. Användaren lär sig troligtvis en produkt som används dagligen, trots en bristfällig design. Men designen får inte vara så bristfällig att användaren tröttnar och väljer en annan produkt. Sida 7 av 21.
Vad som skall designas är således en avvägning mellan hur ofta en produkt skall användas, vem som skall använda den och till vad den skall användas. Naturligtvis kan man tycka att alla produkter borde vara optimalt designade. Men med detta synsätt ställs man inför två problem. För det första finns det nog knappast något sådant som en optimal design, såvida man inte utvecklar en produkt för en enda specifik användare. Men om man då ändå strävar efter att få en så god design som möjligt då? Ja naturligtvis är det ett bra mål men då ställs man inför det andra problemet: designprocessen tar tid och kostar därmed pengar. Därför kanske det inte är värt att exempelvis lägga ett år av studier på hur ett skohorn används för att hitta en bra design. Däremot så kanske det är värt det när man skall designa en videobandspelare eller en diskmaskin. Utifrån detta kan vi då dra slutsatsen att design är en kreativ process som gör en produkt användbar i ett visst sammanhang. Hur detta går till kan skilja sig oerhört mycket beroende på produkten, användaren och användningsområdet. Det vi kan säga generellt är dock att för att skapa en god design så krävs en väldig kunskap inom områden som dagens programvaruingenjörer tyvärr ofta inte har. Här ser vi då det nya behovet, en teknisk ingenjör som har en massa mjuka kunskaper om hur en människa fungerar och tänker, hur samhället fungerar och hur man på ett enkelt, smidigt och snyggt sätt integrerar de tekniska applikationerna i denna miljö. 3. Metaforer Metaforer hjälper oss att förstå och förklara saker. Att få oss att tänka på saker på ett visst sätt. Sida 8 av 21.
Det finns två olika slags metaforer: Funktionell metafor Visuell metafor För att underlätta navigering och förståelsen av strukturen och funktionaliteten bör man vara noga med vilken metafor för användargränssnittet som man väljer. I datorsystem är den funktionella metaforen viktigast. Den visuella metaforen används för att förstärka den funktionella metaforen. Även om det grafiska gränssnittet ser likadant ut kan man ha olika funktionella metaforer. Den funktionella metaforen är något som gör att användaren uppfattar funktionaliteten och strukturen i ett program på ett visst sätt. Det är viktigt att välja en metafor som passar bra med den funktion som finns. När man väl gjort det så är det mycket viktigt att uppfylla de förväntningar som metaforen ger och absolut inte bryta mot den. Man ska t.ex. inte välja en bok som metafor om man med metaforen kan sortera sidor i olika ordning. Däremot kan man utöka metaforen med funktioner som vanligtvis inte skulle finnas där; t.ex. en sökfunktion. Metaforen ska alltså hjälpa användaren att snabbare och enklare förstå hur systemet fungerar och hur det är strukturerat. Det är då viktigt att välja en metafor anpassad till målgruppen. Det måste alltså vara någon "miljö" som användaren känner till tidigare. Man måste också tänka på att metaforen kan ge olika associationer hos olika målgrupper. Sida 9 av 21.
En metafor består också av flera olika delar som symboliserar olika funktioner. I ett operativsystem (MacOS och Windows) har man t.ex. skrivbord som metafor för bildskärmen där allting ligger, mappar för att förvara dokument, papperskorg för att slänga dokument, menyer för att välja diverse olika kommandon. En vanlig metafor är att se datorn (eller andra tekniska lösningar) som ett verktyg (eller snarare en hel verktygslåda) där användaren lär sig använda en del verktyg för att uppnå ett visst resultat. När man designar gränssnitt till program är det viktigt att sätta målgruppens användare i fokus. Genom att dra paralleller mellan verkligheten och de olika verktygen som finns i en ofta komplex dator, kan användandet förenklas genom att användaren kan gå mer på känsla för att lära sig använda verktyget. Ett sätt att minska komplexiteten på datorn kan vara att flytta ut verktygen från den idag vanliga datorn till nya fysiskt olika maskiner för olika ändamål. Komplexiteten att lära sig använda ett verktyg minskar då. Man pratar om genomskinlighet i tekniska lösningar. Med genomskinlighet menar man hur mycket av systemets interna struktur som ses av användaren. Är systemet helt dolt för användaren kallas det för en black-box. Detta är ett ständigt dilemma för designers, hur mycket som ska visas för användaren för att systemet ska fungera bra, och användaren ska vara nöjd. Hur man än vrider och vänder på det så är det så att metaforer sätter gränser för hur vi tänker. Detta kan vara både positivt och negativt. Positivt med tanke på att det blir lättare att greppa, men det kan också sätta stopp för en del tankar som kanske hade utvecklats till en bra och fungerande ide. Sida 10 av 21.
I datorvärlden finns det massor av termer och begrepp som kan vara svåra att förstå pga. av komplexiteten för den som inte är utvecklare/designer/programmerare mm. Därför används metaforer frekvent för att förklara och få den vanlige användaren/kunden/åskådaren att förstå. Hur alla som utvecklar/använder ett system kommunicerar för att förstå varandra på ett så korrekt och bra sätt som möjligt diskuteras i kommande kapitel. Sida 11 av 21.
4. Hur man kommer fram till bra användargränssnitt För att få fram en så bra produkt som möjligt räcker det inte att bara försöka prata om hur man vill att en viss produkt ska se ut och fungera. Det är viktigt att man testar på den specifika målgruppen. Även om man själv som utvecklare tycker att en viss lösning är den bästa så kanske det inte alls stämmer överens med vad målgruppen tycker. 4.1 Prototyper Ofta är det så att en användare inte har specifika önskemål på hur han/hon tycker att vissa funktioner ska fungerar och visas. Tar man då fram en prototyp så är det mycket lättare att få bra feedback. För att det ska bli bra måste man ta fram flera versioner och plocka det bästa från respektive. Det finns flera olika sorters prototyper. Allt från en karvad träbit till ett ritat dummie- GUI i Visual Studio (utvecklingsmiljö för mjukvaruutvecklare) kan kallas för prototyp. Budgeten för ett projekt kan sätta stopp för att man utvecklar allt för många och avancerade prototyper. 4.1.1 Low-fidelity prototyper Tidigt i utvecklingsskedet av en produkt så kan det vara bra att inte vara bunden till en dator för att kunna på ett enkelt sätt visa hur ens tankebanor går när det gäller användargränssnittet. En mockup kan vara en väldigt enkel skiss på ett papper likaså kan det vara mer ordentliga pappmodeller. En viktig fördel med att göra så här är att även den inte så datorkunnige kan visa upp en lösning utan att behöva krångla med en dator. Sida 12 av 21.
Att testa en mockup på användare kan vara svårt att göra. Det är lättare senare i utvecklingen av en produkt att testa på en användare. Anledningen att det kan vara lättare att testa senare är att det börjar likna slutprodukten mer och att man eventuellt har produkten i datorn så att det går lättare att spåra hur testpersonen använder programmet. En mockup är en så kallad low-fidelity prototyp. Det betyder att den inte är så mycket i närheten av vad slutprodukten kommer att vara. Den kan t.ex. vara i ett helt annat material. 4.1.2 High-fidelity prototyper När man börjar få grepp om hur användargränssnittet kan komma att se ut kan man börja rita upp det i datorn istället, och då använda något verktyg som snabbt ritar upp ett dummie-gui. För att kunna testa ett sådant program mot användaren behöver ingen logik i programmet vara skriven, utan det kan vara fejkad statisk feedback, men man får ändå en uppfattning om hur användaren reagerar. Härifrån testas och förnyas prototyperna iterativt tills det passar målgruppens behov. Sida 13 av 21.
5. Designmönster Ett designmönster är en beskrivning av hur interaktionen mellan användare och programvara går till. Några tänkvärda rader från boken Interaction Design Beyond Human Computer Interaction: The idea of patterns was first proposed by Christopher Alexander, a British architect who described patterns in architecture. His hope was to capture quality without a name that is recognizable in something when you know it s good. Designmönster används för att få ett enhetligt utseende och beteende på en applikation. Det kan vara en god ide att studera olika designmönster innan man börjar designa en applikation. Vem är användaren och hur vill hon använda produkten? Beroende på detta kan vi använda oss av olika designmönster för att få hjälp med att implementera en god design. Vi har här valt ut ett antal designmönster och tagit upp dem för diskussion. 5.1 Form Detta designmönster ger användaren möjlighet att mata in information genom textrutor och dylikt. Detta ger användaren mycket stor frihet, men ställer samtidigt höga krav på programvaruutvecklaren att ta hand om all information på ett korrekt sätt. En av de största fördelarna med att använda detta designmönster är att man kan samla in en väldig mängd varierande data från användaren. Det man dock måste tänka på är att inte överösa användaren med textrutor och andra former av ifyllnadsval. Då kan hon lätt tappa intresset för applikationen. Ett alternativ är att ange en delmängd av fälten som måste fyllas i för att gå vidare i applikationen. Sida 14 av 21.
5.2 Supplementary Window Supplementary window kan även kallas för Dialog. Idén med designmönstret är att man ska samla information genom olika småfönster. Fördelen med denna design av GUI är att man inte har alla inställningar i huvudfönstret. Detta gör huvudfönstret lättare att förstå och mer överskådligt. Användaren bestämmer själv vilka inställningar och eller valmöjligheter som hon vill se och/eller påverka. En nackdel kan vara att det kan vara svårt att hitta alla inställningar och valmöjligheter för en oerfaren användare. Det kan också bli en väldig massa klickande för att öppna och stänga olika dialoger. Detta designmönster lämpar sig ur detta synsätt oftast för något mer avancerade applikationer där det ställs lite större krav på användarens kunskaper inom området applikationen berör. Detta för att hon skall kunna följa logiken i vart hon hittar val och inställningar. Detta ställer naturligtvis även krav på att designern av applikationen är insatt i och följer denna logik. I vissa fall kan detta designmönster trots ovan förda resonemang lämpa sig för nybörjaranvändare. Detta för att man kan gömma en del funktionalitet som annars skulle förvirra den ovane användaren. Under tiden som användaren sedan bygger upp sin kunskap inom området så kan hon välja att plocka fram den tidigare dolda funktionaliteten. Sida 15 av 21.
5.3 Selection Huvudtanken i detta designmönster är att samla information från användaren genom att ge henne ett antal olika valmöjligheter. Dessa valmöjligheter är fördefinierade i applikationen. Detta behöver dock inte betyda att de är statiska, de kan mycket väl hämtas in från exempelvis en databas. Detta att användaren får ett antal val presenterade för sig för med sig två stora fördelar. För det första så vet användaren hela tiden vilka valmöjligheter hon har. För det andra så underlättar detta i stor utsträckning felhanteringen i programvaran bakom GUI:t, eftersom utvecklaren i väldigt stor utsträckning kan förutsäga de indata användaren kan tänkas ge. Nackdelen i detta är en annan sida av samma egenskap. Användaren är låst till de valmöjligheter som ges i programmet och kan exempelvis inte skriva in löptext vid ett val där hon inte tycker något av de givna alternativen passar henne. Det gäller alltså för utvecklaren att förutsäga och inkludera de alternativ som användaren kan tänkas vilja ha, så att hon inte saknar något. Detta kan göras i studier av befintliga system och interjuer med de blivande användarna. Sida 16 av 21.
5.4 Ephemeral Feedback Tanken bakom detta designmönster är att inte störa användaren med information som hon inte nödvändigtvis är intresserad av. Varje gång användaren utför ett kommando fås direkt feedback i ett fönster. Detta fönster påverkar inte alls applikationen. Man kan i många implementationer välja att ha det synligt eller inte. Även om man har det synligt så behöver man inte bry sig i det, annat än om man är intresserad av informationen som presenteras där. En fördel med detta är att man kan ge användaren en massa information utan att störa henne. Användaren väljer själv om hon vill ta del av informationen eller inte. Implementerar man detta designmönster bör man göra det möjligt för användaren att gömma feedbackfönstret. Om det inte är möjligt kan användaren uppleva det som irriterande att en massa information, som hon inte är intresserad av, presenteras i ett fönster som tar plats på skärmen. 5.5 Direct Manipulation Användaren jobbar direkt mot det objekt som ska manipuleras istället för att gå via en controller. Ett bra upplägg gör detta till en snabbanvänd teknik. Resultatet av manipulationen syns direkt för användaren (exempelvis knappen ändrar utseende). Det kan vara lite mer komplext att implementera mjukvara med direct manipulation än att låta andra controllers kontrollera objekten. Detta är dock något att i många fall sträva efter i så stor utsträckning som möjligt eftersom det ger en så snabb respons till användaren på inmatade kommandon. Applikationen kan upplevas betydligt mer dynamisk och medgörlig om användaren enkelt kan utföra kommandon som hon direkt ser resultatet av, istället för att få gå igenom en serie val innan ändringen slår igenom. Exempelvis vill vi på en radioapparat inte välja i tre menyer innan vi hittar funktionen Sida 17 av 21.
för att höja respektive sänka volymen. Den vill vi komma åt på en gång och få en direkt respons på. Sida 18 av 21.
6. Personliga reflektioner 6.1 Anders Carlsson Jag tycker att kursen Människa Dator Interaktion är en kurs som behövs i den programvarutekniska utbildningen. Den ger en annan aspekt på programvaruutveckling och introducerar begrepp som Usability Goals, Experience Goals och Användbarhetstest. Dessa begrepp återspeglar en annan syn på programvaruutveckling än den klassiskt utbredda. Istället för att helt inrikta sig på att göra snabba och eleganta program så inriktar vi oss i denna kurs på att göra program som faktiskt går att använda, vilket ändå måste vara målet med all programvaruutveckling. I laboration två genomförde vi användartester med avsikt att testa vår design, inte som tidigare att verifiera funktionaliteten i programmet. Detta är en ny vinkling som jag tycker är en nyttig erfarenhet. Det enda jag tycker är lite synd med kursen är att den går samtidigt med vårt tiopoängs programvaruprojekt. Projektet tenderar att ta mycket tid och denna kursen blir då lidande. Jag tror att om kursen hade gått parallellt med en mindre intensiv kurs så han man haft mer tid att verkligen sätta sig in i detta för oss på PT helt nya tankesätt. Anders Carlsson Sida 19 av 21.
6.2 Per Salomonsson I och med den här kursen har jag börjat fundera i lite andra banor när det gäller att ta fram användargränssnitt. Användbarhetstester har visat sig vara mycket viktiga, det visade sig när vi gjorde laboration 2 och testade programmet med ett antal personer. Problem som man inte ens tänkt på dök då upp. Att gå Programvaruteknik och läsa en sådan här kurs tror jag är mycket nyttigt. Det är lätt att man glömmer bort att ett användargränssnitt inte bara ska vara snyggt och passa en själv (läs utvecklaren). HCI har blivit allt viktigare och jag tror att i framtiden kommer ännu större tyngd läggas vid det. Det märks redan nu hur viktigt det är att t.ex. en handdator ser bra ut, och jag tror att det kommer att bli mer av det. Per Salomonsson Sida 20 av 21.
7. Källförteckning Interaction Design Beyond Human Computer Interaction Av: Preece, Rogers, Sharp Ny Teknik nr 5 2002 Av: Karl-Ola Warnhammar, rektor vid Högskolan för design och konsthantverk, Göteborgs Universitet. Föreläsningar DVC002 vid BTH vt 2002 Av: Hans Kyhlbäck, Elin Heinstedt, Kari Rönkkö och representanter från Symbian Laborationer DVC002 vid BTH vt 2002 Sida 21 av 21.