Användarcentrerad design av verktyg för att skapa funktionalitet i ett gränssnittsdesignsprogram

(1)

Anv¨

andarcentrerad design av verktyg f¨

or att

skapa funktionalitet i ett

gr¨

anssnittsdesignsprogram

av

Rikard Nordin

LITH-IDA-EX--2008/006--SE 2008-01-31

(2)

(3)

skapa funktionalitet i ett

gr¨

anssnittsdesignsprogram

av Rikard Nordin

LITH-IDA-EX--2008/006--SE

Handledare : Eva L. Ragnemalm

Institutionen f¨or datavetenskap vid Link¨opings universitet

Examinator : Eva L. Ragnemalm

Institutionen f¨or datavetenskap vid Link¨opings universitet

(4)

(5)

Spr˚ak Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats ¨Ovrig rapport

URL f¨or elektronisk version

ISBN

ISRN

Serietitel och serienummer

Title of series, numbering

ISSN Titel Title F¨orfattare Author Sammanfattning Abstract Nyckelord Keywords

Idag finns det en stor mängd program för att underlätta vid design av ett grafiskt användargränssnitt. M˚anga av dessa gör det enkelt att snabbt skapa en prototyp för att exempelvis illustrera en idé kring hur ett gränssnitt kan se ut. Vad som däremot ofta saknas är ett effektivt och intuitivt verktyg för att skapa funktionalitet i prototypen och göra gränssnittet levande utan att behöva kunskaper i programmering.

Den här rapporten studerar hur ett verktyg för att skapa funktionali-tet i prototyper, och som inte kräver n˚agra kunskaper i programmering, skulle kunna fungera. Med hjälp av pappersprototyper och anv¨ andarin-tervjuer vägs fördelar och nackdelar mot varandra, och resultatet blir ett nytt förslag p˚a hur ett intuitivt men samtidigt kraftfullt verktyg skulle kunna se ut och fungera.

Institutionen f¨or datavetenskap 581 83 LINK ¨OPING 2008-01-31 — LITH-IDA-EX--2008/006--SE — http://www.ep.liu.se/exjobb/ida/202008/dd-d/006/

User-centered design of a function creation tool for a graphical user interface design program

Användarcentrerad design av verktyg för att skapa funktionalitet i ett gränssnittsdesignsprogram

Rikard Nordin

Användbarhet – Grafiskt gränssnitt – Programutveckling – Program-meringsverktyg

(6)

(7)

grafiskt användargränssnitt. M˚anga av dessa gör det enkelt att snabbt ska-pa en prototyp för att exempelvis illustrera en idé kring hur ett gränssnitt kan se ut. Vad som däremot ofta saknas är ett effektivt och intuitivt verk-tyg för att skapa funktionalitet i prototypen och göra gränssnittet levande utan att behöva kunskaper i programmering.

Den här rapporten studerar hur ett verktyg för att skapa funktionalitet i prototyper, och som inte kräver n˚agra kunskaper i programmering, skulle kunna fungera. Med hjälp av pappersprototyper och användarintervjuer vägs fördelar och nackdelar mot varandra, och resultatet blir ett nytt förslag p˚a hur ett intuitivt men samtidigt kraftfullt verktyg skulle kunna se ut och fungera.

Nyckelord : Anv¨andbarhet – Graﬁskt gr¨anssnitt – Programutveckling – Programmeringsverktyg

(8)

(9)

Stort tack till Eva L. Ragnemalm och Jonas Lundberg för handledning och inspiration som gjort det här arbetet möjligt.

Mikael Kindborg f¨or inspiration och energi.

Olof Arnell, Joakim Frögren, Joakim Johansson, Nicklas Lindgren, Fredrik Linusson, Joakim Nemback, Mathias Nordvall, Nils Nyman, Erik Pryts och Therese Öberg för att jag fick stjäla en timme av era liv och pl˚aga er med korkade intervjufr˚agor.

Malin Persson och Hanna Norrman för sena kvällar konsumerandes te och klaganden över en rapport som aldrig blir klar.

Ylva som sparkade mig tills jag gjorde klart de sista detaljerna,

och sist, men inte f˚aast1: alla andra vänner och ovänner som stöttat, eggat och pinat mig till den här punkten i mitt liv.

1_{Korrekt b¨}_{ojning enl. Svenska akademins ordbok 1926}

(10)

(11)

1 Inledning 1

1.1 Bakgrund . . . 1

1.2 Anv¨andning av prototyper . . . 2

1.3 Disposition . . . 3

1.4 Deﬁnitioner och f¨ortydliganden . . . 3

2 Teori 7 2.1 Vad ¨ar design? . . . 7

2.2 Designmodeller . . . 8

2.3 Nyttan av sammanh˚allen design . . . 9

2.4 Anv¨andarunders¨okningar . . . 10

2.5 Konceptuella prototyper . . . 13 2.6 Prototyper . . . 13 2.7 Summering av teori . . . 14 3 Metod 17 4 Andra verktyg 19 4.1 Squeak . . . 19 4.2 Macromedia Director MX . . . 21 4.3 Adobe GO Live! . . . 22

4.4 Eclipse Visual Editor . . . 23

4.5 QT Designer . . . 25

4.6 TelePICTIVE . . . 26

(12)

x INNEH˚ALL 4.7 Summering av verktyg . . . 27 5 Programdesign 29 5.1 Scenarion . . . 29 5.1.1 Oppna f¨¨ onster . . . 29 5.1.2 Drag–och–sl¨app-funktion . . . 30 5.2 Designf¨orslag . . . 30

5.2.1 Prototyp 1 – Direkt manipulering . . . 31

5.2.2 Prototyp 2 – Drag funktioner . . . 32

5.2.3 Prototyp 3 – V¨alj funktion med sm˚a menyer . . . . 32

5.2.4 Prototyp 4 – Egenskapsf¨onster . . . 33

5.2.5 ˚Aterkoppling av skapade funktioner . . . 34

6 Anv¨andarunders¨okning 35 6.1 Intervjumallen . . . 35

6.2 Intervjuresultat . . . 38

6.2.1 Intervju med person A . . . 39

6.2.2 Intervju med Person B . . . 39

6.2.3 Intervju med Person C . . . 40

6.2.4 Intervju med person D . . . 41

6.2.5 Intervju med person E . . . 42

6.2.6 Intervju med person F . . . 43

6.2.7 Intervju med person G . . . 45

6.2.8 Intervju med person H . . . 46

6.2.9 Intervju med person I . . . 47

6.2.10 Intervju med person J . . . 48

6.3 Sammanfattning av intervjuerna . . . 49

6.4 Utv¨ardering av metodik . . . 50

7 Diskussion 51 7.1 Klassiﬁcering av intervjuerna . . . 51

7.2 Utv¨ardering av prototyperna . . . 52

7.2.1 Prototyp ett . . . 52

7.2.2 Prototyp tv˚a . . . 53

7.2.3 Prototyp tre . . . 53

(13)

7.2.5 ˚Aterkoppling . . . 54

7.3 Slutligt designf¨orslag . . . 55

7.4 Unikhet i slutprototypen . . . 56

7.5 Att t¨anka p˚a vid fortsatt arbete . . . 56

Figurer 58 Litteraturf¨orteckning 59 Index 61 A Designskisser 63 A.1 Prototyp 1 – Direkt manipulering . . . 63

A.2 Prototyp 2 – Drag funktioner . . . 65

A.3 Prototyp 3 – V¨alj funktion med sm˚a menyer . . . 67

A.4 Prototyp 4 – Egenskapsf¨onster . . . 69

A.5 ˚Aterkoppling av skapade funktioner . . . 71

(14)

(15)

Inledning

1.1 Bakgrund

M˚anga forskare inom designomr˚adet uttrycker hur viktigt det är att under programutvecklingsprocessen p˚a ett enkelt och snabbt sätt kunna prova ut olika designförslag. Det behövs för att produkten ska bli användbar och för att h˚alla nere utvecklingskostnaderna [1]. En mycket stor vikt ligger i just användargränssnittet om programmet ska bli en succé eller inte d˚a detta ¨

ar den del av programmet som användaren kommer i direkt kontakt med [1]. D˚a är det ocks˚a viktigt att enkelt och snabbt kunna skapa en prototyp för att demonstrera ett designförslag för tilltänkta användare [2].

De flesta av dagens verktyg för gränssnittsdesign klarar inte av att repre-sentera funktionalitet, utan är verktyg för ren grafisk design av gränssnitt [3]. De skapar grafiska prototyper eller ibland ett gränssnitt som med hjälp av andra verktyg kan användas för att skapa den slutgiltiga produkten, men de klarar inte av att representera hur gränssnittet ska vara organi-serat i tiden, hur användaren ska kunna utföra sina uppgifter med hjälp av det program prototypen ska illustrera och hur de datastrukturer som bygger upp gränssnittet ska se ut och fungera. Dessa brister inskränker ut-vecklingen d˚a en prototyp ska utvecklas med hjälp av ett s˚adant verktyg. För det första kan det vara sv˚art för en tilltänkt användare att f˚a en k¨

(16)

2 1.2. Anv¨andning av prototyper

la för hur slutprodukten ska se ut genom att undersöka en prototyp. För det andra m˚aste ofta ett nytt gränssnitt skapas utifr˚an prototyperna med hjälp av andra verktyg, exempelvis kraftfullare programspr˚ak [3]. Arbete som redan är gjort m˚aste d˚a göras om, och en risk finns att man missar detaljer i prototypen vid tillverkningen av den slutliga produkten.

Jag har genom min utbildning och hobbyverksamhet inom programme-ring stött p˚a m˚anga verktyg för att grafiskt designa ett gränssnitt. Vissa av dem är anpassade för att användas av programmerare, och andra är an-passade för att passa personer utan n˚agon programmeringsbakgrund. Jag lever i uppfattningen att verktygen som är anpassade för ickeprogrammera-re ofta hävdar att man ska kunna skriva program eller prototyper utan att programmera, men ofta blir programutvecklaren änd˚a tvungen att anv¨ an-da programkod för att lägga till funktionalitet i sitt gränssnitt. Att behöva skriva programkod är n˚agot jag uppfattar som besvärligt och tidskrävande om man snabbt vill skapa n˚agot för att testa en idé, men samtidigt ett kraftfullt verktyg för den som kan hantera det fullt ut.

För att sammanfatta är fr˚agan allts˚a: Hur ska ett verktyg för att skapa funktionalitet i en prototyp se ut om det ska b˚ade vara lättanvänt för n˚agon som inte har erfarehet av programmering, men samtidigt tillräckligt kraftfullt för att ge kontroll och överblick för en mer avancerad användare.

1.2 Anv¨

andning av prototyper

För att finna svar p˚a min fr˚aga har jag valt att utveckla prototyper. I arbetet använder jag mig av prototyper p˚a tv˚a sätt. Dels använder jag dem själv i form av mina designskisser för att enkelt förmedla det gränssnitt som jag vill att subjekten ska ge ˚aterkoppling till under intervjuerna. Dels best˚ar hela mitt arbete i att utveckla ett verktyg för att tillverka nya prototyper. Jag m˚aste därför b˚ade tänka p˚a att f˚a mina designskisser s˚a klara och tydliga som möjligt och att mitt verktyg ska kunna skapa nya prototyper som blir klara och tydliga att visa upp för en slutanvändare.

För att ta reda p˚a mer om vad prototyper egentligen är och vad de kan tillföra mitt arbete har jag valt att göra en djupare litteraturstudie över prototyper som bland annat presenteras i kapitlet teori.

(17)

1.3 Disposition

Först presenteras den teori som denna rapport baseras p˚a. Därefter under-söks n˚agra designverktyg som finns idag för att beskriva tidigare beprövade idéer. Sedan presenteras mina egna prototyper för hur ett verktyg skulle kunna se ut.

För att förankra och förbättra min idé genomfördes en anv¨ andarunder-sökning kring prototyperna, vad subjekten använde idag och vad de tycker om existerande verktyg. Intervjuerna genomfördes med personer ur tv˚a oli-ka användargrupper, datavetenskap och kognitionsvetenskap, för att f˚a med tv˚a olika perspektiv p˚a programdesign.

Intervjuerna analyseras och redovisas, och efter denna analys presenteras ett förbättrat förslag p˚a hur ett verktyg för att skapa funktionalitet i ett gränssnitt kan se ut. Till sist utvärderas arbetet och förslag presenteras ¨

over vad som kan arbetas vidare p˚a. Rapporten ämnar inte att presentera en färdig och fullt fungerande produkt, utan ska ses som en förstudie till fortsatt utveckling.

1.4 Definitioner och f¨

ortydliganden

Detta är ett omr˚ade med m˚anga tekniska begrepp som kan vara sv˚ara att först˚a. Rapportens tilltänkta m˚algrupp är personer som arbetar med eller studerar datorspr˚ak eller gränssnittsdesign, men även här kan begrepp sälla till med problem d˚a de kan betyda olika saker för olika personer eller olika grupper. Därför förtydligas nedan vilken definition arbetet utg˚ar ifr˚an. Användare En person som anv¨ander n˚agot, främst ett program. Mina

användare är de som ska använda designverktyget. De har i sin tur användare, som ibland kallas “slutanvändare” för att förtydliga d˚a det behövs.

Användbar N˚agot användbart är n˚agot som g˚ar att använda, varken mer eller mindre. Ofta används detta ord d˚a det handlar om gradering. Om produkt A är mer användbart än produkt B betyder det att en användare hellre använder A än B om denne f˚ar välja.

(18)

4 1.4. Definitioner och f¨ortydliganden

Arbetsflöde Inom design syftar arbetsfl¨ode till den ordning i vilken en användare använder gränssnittet under sitt arbete. Ett arbetsflöde kan till exempel beskrivas genom de kommandon användaren skri-ver i ett terminalgränssnitt eller som de musrörelser och klick som användaren utför i ett grafiskt gränssnitt.

Bildmanus En sorts pappersprototyp som illustrerar funktionalitet och händelseflöde med hjälp av bildserier.

Datorbaserad prototyp Ett program implementerat p˚a en dator som ska visa funktionalitet och utseende hos en ¨annu ej utvecklad pro-dukt. Den datorbaserade prototypen kan sakna vissa funktioner, sak-na delar av funktioner eller vara implementerad i ett helt ansak-nat spr˚ak ¨

an man t¨ankt implementera slutprodukten i.

Design Med design syftas allt som oftast p˚a en helhetsdesign, vilket mer noggrant beskrivs i kapitel 2.1 p˚a sidan 7.

Designer Egentligen ¨ar detta mer eller mindre synonymt med program-utvecklare, men eftersom rapporten delar upp yrket i tv˚a kategorier s˚a kommer detta vara beteckningen p˚a en programutvecklare med huvudsakligt arbetsomr˚ade i det graﬁska gr¨anssnittet.

Gränssnitt Den del av programmet som interagerar med anv¨andaren. Det kan vara ett grafiskt gränssnitt (GUI), men kan även vara till exem-pel ett röstgränssnitt i en automatisk telefontjänst eller ett terminal-gränssnitt med en kommandoprompt. D˚a ordet “gränssnitt” används syftar det till valfri interaktionsform, och i annat fall specificeras det-ta.

Pappersprototyp Generellt ¨ar detta en grov skiss eller mer exakt ritning p˚a papper. Ibland klipper man ut dessa bilder och flyttar omkring i ett uppritat gränssnitt för att simulera funktionalitet. En pappers-prototyp kan ocks˚a vara av typen bildmanus.

Programmerare Programutvecklare med huvudsyssla att skapa program-kod och/eller designa underliggande datastrukturer och algoritmer.

(19)

Programutvecklare En person som arbetar med att skapa program. Till exempel genom att programmera, grafiskt designa eller genomföra annat förarbete eller kringarbete.

Prototyp N˚agot som beskriver utseende, funktion eller struktur hos en tillt¨ankt produkt. En prototyp kan till exempel vara en papperspro-totyp eller en datorbaserad propapperspro-totyp.

(20)

(21)

Teori

Detta arbete handlar i grund och botten om tre saker: design, prototyper och intervjuteknik. Teorin bakom dessa tre omr˚aden kan uppfattas som luddiga och odefinierade för den oinvigde, men det finns mycket teori som definierar, förklarar och utforskar omr˚adena.

2.1 Vad ¨

ar design?

Begreppet design är ett ganska omtvistat uttryck som jag här ämnar försöka reda ut en smula. Ordet design är ett annat ord för formgivning, det vill säga gestaltning av hantverkligt eller industriellt framställda produkter och miljöer. I dagligt tal avser ordet vanligen en produkts form eller utseende [4].

I sin fulla bemärkelse syftar design allts˚a till formgivning av en produkt, men m˚anga programutvecklare inskränker uttrycket n˚agot, till att endast omfatta formgivningen av den del av programmet som användaren kommer i kontakt med, den grafiska designen, och utesluter d¨armed underliggande datastrukturer och algoritmer. Vissa g˚ar till och med s˚a l˚angt att de an-vänder design för att endast beteckna den grafiska utformningen av ett gränssnitt [5].

D˚a man vill omfatta formgivningen av hela produkten kan man ibland

(22)

8 2.2. Designmodeller

anv¨anda sig av ordet helhetsdesign[4], f¨or att understryka att man inte in-skränker uttrycket p˚a n˚agot sätt. Detta innefattar allts˚a även formgivning-en av funktioner, deras interaktion med gränssnittet och deras interaktion med bakomliggande strukturer.

Interaktionsdesign ¨ar ett uttryck för att beskriva designen av ett förem˚al som är skapat för att interagera med användaren [4]. Det kan till exempel röra sig om en telefon, ett datorspel eller en ringklocka p˚a en dörr. Termen interaktionsdesign är däremot direkt olämplig att applicera p˚a till exempel en gardin, även om man kan tillämpa design p˚a gardiner.

Interaktionsdesignen syftar dessutom ofta till att skapa en anv¨ andarupp-levelse som utökar eller förbättrar sättet p˚a vilket människor arbetar, kom-municerar och interagerar med varandra och med sina verktyg.

2.2 Designmodeller

Designmodeller ¨ar ett uttryck som anv¨ands f¨or att kategorisera olika de-lar av ett program eller en prototyp [6]. Designmodellerna kategoriserar programutvecklingen i fem olika grupper [6]:

Applikationsmodell Den datastruktur som anv¨andargränssnittet beror och bygger p˚a. Här definieras alla data som bygger upp det gränssnitt som användaren kommer i kontakt med.

Abstrakt presentationsmodell Beskriver organisationen av gr¨ anssnit-tet. Hur komponenter är grupperade och vilka tekniker man anv¨ an-der för att presentera informationen för användaren. Modellen skapas oberoende av h˚ardvara och andra faktorer som existerar utanför pro-dukten.

Konkret presentationsmodell Beskriver det s¨att som den abstrakta pre-sentationsmodellen faktiskt presenteras för användaren. Beror p˚a h˚ ard-vara och andra faktorer utanför programmet, eftersom dessa faktorer inverkar p˚a det intryck som användaren f˚ar fr˚an gränssnittet.

Uppgifts-/dialogmodell Detta ¨ar tv˚a modeller som ligger mycket nära varandra. Uppgiftsmodellen är den modell som beskriver hur en an-vändare kan utföra olika uppgifter i programmet och dialogmodellen

(23)

¨

ar den modell som definierar dialogen som användaren skapar med programmet för att utföra uppgiften.

Kontextmodell Kontextmodellen beskriver i vilken kontext gr¨anssnittet används. Med kontext menas den miljö och andra utomst˚aende va-riabler som p˚averkar användandet. Kontextmodellen p˚averkar och p˚averkas av till exempel uppgifts- och dialogmodellen i mycket hög grad d˚a uppgiften och miljön ofta samverkar. Den abstrakta presen-tationsmodellen däremot har inget utbyte alls med kontextmodellen. Att använda sig av en eller flera designmodeller gör att man kan struktu-rera upp sitt designarbete och fokusera p˚a en del av designen i taget bland annat för att undvika att man missar vissa omr˚aden och aspekter av de-signen [7]. Det underlättar ocks˚a designarbete i grupper, d˚a olika delar av gruppen kan ˚ata sig att utforska och utveckla olika delar av designen utan att r˚aka utföra dubbelt arbete.

2.3 Nyttan av sammanh˚

allen design

Varför är det d˚a s˚a viktigt att lägga tid och pengar p˚a att designa dator-program? Dels kan man se p˚a denna fr˚aga i perspektivet varför utvecklare ska lägga tid p˚a förarbete och undersökningar istället för att bara skriva ihop ett program direkt. Dels kan man belysa fr˚agan fr˚an utg˚angspunkten vad de tilltänkta användarna ser för användningsomr˚ade och möjligheter i det program som ska produceras.

Enligt “The importance of Designing Usable Systems”[1] ser m˚anga pro-gramutvecklare funktionaliteten hos en produkt som n˚agot skilt fr˚an gr¨ ans-snittet. En användare ˚a andra sidan ser oftast gränssnittet som hela funk-tionaliteten. Därmed anser ofta användaren att programmet är användbart om gränssnittet är användbart. Detta leder i sin tur till att n˚agon som ut-vecklar ett program m˚aste se till helheten. Man m˚aste designa med tanke p˚a [1]:

• Den graﬁska representationen av programmet.

• De underliggande strukturer och algoritmer som bygger upp

(24)

10 2.4. Anv¨andarunders¨okningar

• De arbetsflöden och arbetssätt som användare använder sig av och

skapar.

• Interaktionen mellan programmets delar och eventuellt interaktionen

med andra program.

Att notera ¨ar att dessa fyra punkter sammanfaller ganska v¨al med de fem designmodeller som listas i kapitel 2.2, men teorierna kring detta kommer fr˚an n˚agot olika angreppspunkter.

Om utvecklaren h˚aller ihop alla dessa delar när programmet designas s˚a kan man finna flera fördelar i slutprodukten; till exempel minskade support-behov, mindre behov av introduktion, högre produktivitet, mindre frustra-tion och högre bel˚atenhet hos användaren. Allt detta kan summeras ihop i högre inkomster i längden för ett företag inom programutveckling [1].

N˚agot som ofta fokuseras p˚a inom användbarhet och design är gr¨ ans-snittets utformning [8]. Det finns m˚anga verktyg som stödjer en gr¨ ans-snittsdesigner, och m˚anga verktyg som stödjer programmeraren, men de är segregerade och samarbetar inte. Därför behövs det ett verktyg som b˚ade kan användas för att designa den rent grafiska delen av gränssnittet, testa detta p˚a användare och samtidigt kunna kopplas till programmerare och funktionsdesigners. Ett arbetssätt som involverar användare, grafiska de-signers, programmerare och övriga medarbetare under hela utvecklingspro-cessen minskar utvecklingskostnaderna och leder till högre produktkvalité och bättre användbarhet [8]. Om splittring istället uppst˚ar mellan arbets-grupperna s˚a leder det ofta till att “den ena handen vet inte vad den andra gör”. Resultatet blir spretigt och produkten blir inte användarvänlig [4].

Med andra ord är det inte bara viktigt att h˚alla bra kvalitet i alla delar av produktens design, utan ocks˚a viktigt att h˚alla ihop alla utvecklargrupper i processen under samma tak s˚a att de kan diskutera förslag och lösningar med varandra och utbyta erfarenheter.

2.4 Anv¨

andarunders¨

okningar

För att kunna undersöka om prototyperna accepteras hos de tilltänkta användarna kan man exempelvis använda sig av intervjuer av en grupp människor som kan tänkas vilja använda den färdiga produkten.

(25)

Enligt rapporten “User involvement in Concept Creation” [9] kan en an-vändarundersökning kring användbarhet delas in i fyra delar, eller works-hops.

1. Anv¨andarna f˚ar diskutera de problem de upplever med deras nuva-rande system.

2. Användarna f˚ar själva komma p˚a förslag till lösningar till sina pro-blem och eventuella framtida propro-blem.

3. Anv¨andarna f˚ar utveckla sina l¨osningar till prototyper.

4. Till sist f˚ar användarna utvärdera andra användares prototyper. Genom denna modell använder man sig av användare p˚a ett optimalt sätt genom att l˚ata användaren definiera svaga punkter i en design. Ofta vet man kanske om att designen har svaga punkter men vill ha detta bekräftat, eller s˚a kan användaren komma p˚a en lösning p˚a problemet. Det kan ocks˚a vara s˚a att användaren hittar svaga punkter som designern inte tänkt p˚a ¨

over huvud taget [9].

N˚agot som är mycket viktigt vid den här typen av intervjuer är att ställa rätt fr˚agor, och att ställa dem p˚a rätt sätt. Artikeln “Generating Good De-sign Questions”[10] beskriver QOC-modellen, som g˚ar ut p˚a att identifiera Questions, Options och Criterion; allts˚a Fr˚agor, Alternativ och Slutkrite-rium. Innan intervjuen ska man skriva ett antal fr˚agor som var och en ska ha ett antal alternativ som resulterar i ett antal slutkriterium. Figur 2.1 illustrerar hur dessa tre element kan vara kopplade till varandra. Varje slut-kriterium är n˚agot som behöver lyftas ut och resultera i en funktion eller en lösning p˚a ett problem [10]. P˚a detta sätt kan man engagera sitt subjekt till att utforska s˚a m˚anga alternativ som möjligt.

¨

Aven om det ska finnas ett antal alternativ och slutkriterier vid inter-vjuens början s˚a betyder det inte att mängden är fixerad under intervjuen. Nya alternativ och slutkriterium skall tillföras ett intervjuformulär om det upptäcks fler under intervjuernas g˚ang, och även nya möjliga fr˚agor bör undersökas och eventuellt tillföras under undersökningens g˚ang. Dessa kan användas vid en senare intervju med ett annat subjekt eller för att stödja ett resultat.

(26)

12 2.4. Anv¨andarunders¨okningar F r å g a F r å g a F r å g a F r å g a S l u t k r i t e r i u m S l u t k r i t e r i u m S l u t k r i t e r i u m S l u t k r i t e r i u m A l t e r n a t i v Figur 2.1: QOC-modellen ¨

Aven artikeln “Design Space Analysis” [11] tar upp QOC-modellen, och tillför möjligheten att poängsätta olika alternativ genom att väga samman fördelar och nackdelar hos de olika alternativen till en lösning. Detta kan till exempel ˚astadkommas med en plus/minus-lista för varje alternativ. Detta leder till att designern kan f˚a bättre överblick och enklare kunna s˚alla ut bra alternativ och positiva slutkriterium fr˚an d˚aliga alternativ och negativa slutkriterium [11].

I artikeln “Design Space Analysis and Use-Representations” [12] utveck-las QOC-modellen vidare. I tidigare artiklar beskrivs en intervju som n˚agot statiskt och diskret, men nu appliceras teorin och beskrivs i praktiska sce-narion. Verklighetens intervjuer kan mycket sällan vara varken statiska eller diskreta utan m˚aste anpassas efter varje subjekts erfarenhet och inställning till ämnet [12].

I artikeln [12] diskuteras ocks˚a olika verktyg och modeller för att utveckla design, vilka verktyg och modeller som är bra vid vilka tillfällen, och hur de olika delarna kan samarbeta för att underlätta arbetet. Sammanfattat kan man säga att artikeln [12] beskriver en helhetssyn p˚a designarbetet baserat p˚a forskargruppens tidigare arbete.

(27)

2.5 Konceptuella prototyper

Artikeln “Conceptual Models”[13] beskriver konceptuella prototyper. Om man använder sig av konceptuella prototyper ska man inte designa med tanken att beskriva hur slutprodukten kommer se ut, utan hur slutproduk-ten kommer att fungera. Med andra ord är det inte gränssnittets utseende som är viktigt, utan vad man kan göra med gränssittet och p˚a vilket sätt gränssnittet beter sig när användaren ska utföra uppgifter. Därför skall man beskriva vägar till funktioner och funktionernas resultat snarare än utseende [13].

Det är ocks˚a lämpligt att inte beskriva samma funktion med hjälp av olika prototyper om de uppför sig p˚a samma sätt. Om man exempelvis kan rita cirklar och rektanglar genom att först välja endera cirkel- eller rektangelverktyget och sedan klicka och dra för att rita figuren är det ingen mening med att skapa prototyper för b˚ada funktionerna, det räcker med att göra en prototyp och sedan förklara att man kan utföra den andra funktionen p˚a samma sätt enligt “Conceptual Models” [13].

Konceptuella prototyper skiljer sig fr˚an designmodeller genom att design-modeller kategoriserar programmets eller prototypens olika delar, medan konceptuella prototyper definierar hur man ska skapa en prototyp s˚a att den blir s˚a effektiv som möjligt i utvecklingsarbetet. Man kan utveckla en konceptuell prototyp genom att inrikta sitt designarbete p˚a en eller flera designmodeller.

2.6 Prototyper

En prototyp kan vara väldigt m˚anga olika saker beroende p˚a vilket yrkes-omr˚ade man rör sig i, men det viktiga med en prototyp är inte vad det är, utan vad den används till att beskriva och p˚a vilket sätt den beskriver [14].

Enligt Houde[14] kan man dela in prototyper i tre olika niv˚aer:

• Role

• Look and feel • Implementation

(28)

14 2.7. Summering av teori

Role-niv˚an innebär att man använder sig av pappersprototyper för att ut-trycka grundläggande placering av saker och funktionaliteten i gränssnittet. Den kan ge en känsla för vad man kan göra och hur man utför detta. Des-sa skisser är ganska billiga att skapa, och därför kan man utveckla m˚anga prototyper och testa p˚a sina tilltänkta användare.

Look and feel inneb¨ar en prototyp som ska ge testpersonen en känsla för hur det kan kännas att använda produkten. Designern m˚aste nu troligtvis ta ett steg upp och implementera prototypen p˚a en dator. Det behöver d¨ ar-emot inte inneh˚alla all funktionalitet som slutprodukten ska inneh˚alla, utan kan till exempel vara en prototyp över en viss funktion eller ett gränssnitt som saknar viss funktionalitet.

En s˚adan prototyp kan tillverkas med ett helt annat verktyg än slutpro-dukten tillverkas med. Det kräver dock mer arbete än den första proto-typen, och oftast har ett designteam inte tillräckligt med resurser för att skapa mer än ett f˚atal s˚adana prototyper. N˚agot som kan göras är dock att skapa flera prototyper som var och en testar n˚agon funktion i gränssnittet utan att de ännu är sammanlänkade med varandra i ett program.

Till sist tillverkas implementationsprototypen. Den tillverkas med samma verktyg som den slutgiltiga produkten och ska bland annat kunna testa hur den slutgiltiga produkten kommer bete sig p˚a olika h˚ardvara och andra detaljer kring effektivitet och resurskrav. Denna prototyp har man normalt bara resurser för att bygga en version av, och helst ska den kunna användas för att bygga den slutgiltiga produkten p˚a, allt enligt Houde [14].

2.7 Summering av teori

Design kan sammanfattas som all den teori som ligger till grund f¨or ett implementationsarbete. Den kan i sin tur delas in i olika underkategorier s˚asom helhetsdesign, interaktionsdesign eller graﬁsk design. Designmodeller ¨

ar en annan dimensionsaxel inom design som ser p˚a designbegreppet fr˚an en annan synvinkel.

Konceptuella prototyper är ett sätt att designa prototyper genom att istället för att skapa prototyper som beskriver utseendet hos produkten, skapa prototyper som beskriver funktioner hos produkten.

(29)

prototy-per kan man f˚a en objektiv bedömning, tips och idéer som p˚a ett kostnads-effektivt sätt kan ge en användbar slutprodukt. Dessa intervjuer behöver struktureras för att ge maximalt med information och täcka upp s˚a m˚anga aspekter som möjligt kring prototypen. Detta kan exempelvis göras med hjälp av QOC-modellen.

(30)

(31)

Metod

Jag har valt att undersöka vilken funktionalitet ett designverktyg behöver för att en programutvecklare ska kunna använda verktyget till att skapa funktionalitet i ett användargränssnitt. Metoden för att skapa funktionali-tet ska vara effektiv och intuitiv, för att passa b˚ade personer med program-meringsbakgrund och personer som saknar den bakgrunden. Det ska vara enkelt att komma ig˚ang att använda verktyget, samtidigt som det ska vara tillräckligt kraftfullt för att fylla behovet hos programutvecklare med olika bakgrund.

De bildmanus jag utvecklat har jag skapat efter att först undersökt vilka verktyg som finns idag och vilken funktionalitet de erbjuder. Det finns en stor mängd olika program med den här typen av verktyg, men m˚anga av dem skapar funktionalitet p˚a ungefär samma sätt. För att inte behöva un-dersöka alla program har jag valt ut ett antal som jag anser representerar och täcker upp branchen idag. Dessa verktyg presenterar jag närmare i ka-pitel 4. Jag presenterar ocks˚a det jag anser vara de olika verktygens fördelar och nackdelar. I kapitel 5 skapar jag sedan egna bildmanus som renodlar de olika positiva funktioner jag funnit i de andra verktyg jag undersökt.

Jag vill undersöka om min prototyp fungerar för mina tilltänkta anv¨ an-dare. Jag vill ocks˚a f˚a hjälp med att utveckla mina initiala idéer till en slutgiltig prototyp. För att göra detta har jag valt att titta p˚a intervjutek-niker för designarbete.

(32)

18

Jag har valt att arbeta med en metod som p˚aminner om QOC-modellen, som beskrivs i kapitel 2.4. QOC-modellen anser jag är ett bra verktyg för att kunna styra en intervju och f˚a konkreta resultat ur ett ämne som annars kan urarta i en lös diskussion utan n˚agra slutsatser. Samtidigt anser jag att den ger tillräckligt mycket flexibilitet för att inte l˚asa in subjekten i fördefinierade svar p˚a fr˚agorna utan till˚ater att man tänker utanför de uppsatta ramarna vid intervjuen. Det tror jag leder till ett mer kreativt och kvalitativt resultat. Det finns naturligtvis fler intervjumetoder som erbjuder samma resultat och kvalité, men jag känner mig nöjd och trygg med QOC.

Eftersom jag tyvärr saknar de resurser som krävs för att genomföra den omfattande undersökning i fyra steg som beskrivs i QOC-modellen, har jag valt att inte l˚ata mina användare helt p˚a egen hand utveckla prototy-per, utan har redan innan intervjuerna utvecklat ett antal prototyper som jag presenterar under intervjuerna. Jag har däremot försökt se till att jag har en grov QOC-modell över fr˚agorna även om inte alla alternativ är väl utforskade p˚a förhand. P˚a detta sätt kan jag använda mig av metoden i komprimerad form. Efter intervjuerna har jag applicerat plus/minus-listor enligt kapitel 2.4 p˚a intervuresultaten för att enklare kunna skaffa mig en uppfattning och överblick över resultatet.

Resultatet av arbetet är ett förslag p˚a hur ett nytt designverktyg kan se ut. Detta förslag kan ligga till grund för nya prototyper, eventuellt pap-persprototyper med högre detaljrikedom eller en datorbaserad prototyp med möjlighet till interaktion.

(33)

Andra verktyg

Det finns idag en mängd verktyg som används vid produktutveckling. Det här kapitlet g˚ar igenom ett urval av dessa. Dessa verktyg har alla olika sätt att skapa funktionalitet i prototypen. Vad jag speciellt undersöker är hur en användare av verktyget kan skapa funktionalitet i sitt gränssnitt och vilka funktioner som gör verktyget speciellt. Jag ger ocks˚a personliga kommentarer p˚a vad jag anser är fördelar och nackdelar med verktygen.

4.1 Squeak

Squeak är en programmeringsmiljö baserad p˚a Smalltalk. Syftet med Sque-ak är att skapa en programmeringsmiljö som är anpassad för barn. Syftet med miljön är att skapa olika former av spel, och verktyget är därför inte anpassat till vanlig fönstergränssnittsprogrammering, men det g˚ar även att tillverka fönstergränssnitt.

För att skapa funktionalitet i Squeak finns det flera olika verktyg att använda. Ett av dem är Etoys [15] där användaren skapar funktionalitet genom att ändra värden direkt p˚a ett objekt (se figur 4.1). Objekten är i det här fallet bilder som endera kan vara färdiga bilder, eller bilder som man ritar själv. I bilden kan man se ett fönster med en knapp i som ritats p˚a arbetsytan. Genom att högerklicka p˚a ett objekt f˚ar man upp de verktyg

(34)

20 4.1. Squeak

man kan använda för att förändra objektet och ge den egenskaper och funktioner. I bilden har knappen “Button 1” precis högerklickats p˚a s˚a att menyn syns omkring.

Figur 4.1: EToys

Ett annat verktyg är MagicWords [16], som baseras p˚a samma bilder, men här skapar användaren istället funktionalitet genom att dra etiketter med text beskrivande funktionen hos etiketten till bildobjekten (se figur 4.2). En etikett kan till exempel vara “Vänster”, som f˚ar objektet att börja röra sig ˚at vänster konstant. P˚a bilden ser vi en kanin i en ballong som representerar ett objekt. Genom att etiketten “up” har dragits till kaninen s˚a rör den sig upp˚at med en grundhastighet.

B˚ada dessa verktyg ser jag som ganska triviala att börja använda. Spe-ciellt MagicWords som känns mycket enkel att använda. Nackdelen med MagicWords kan vara att lyckas beskriva vad varje etikett gör med bara ett ord. Exempelvis etiketten “Studsa” som betyder att objektet ska börja röra sig ˚at motsatt h˚all när det n˚ar fönsterkanten, men det skulle egentligen lika gärna kunna betyda att det ska p˚averkas av en tyngdkraft och studsa precis som en boll.

(35)

Figur 4.2: MagicWords

stor m¨angd ikoner kring varje objekt, och jag tror att det kan vara st¨orande med kryptiska ikoner kring varje objekt.

B˚ada dessa verktyg till Squeak är anpassade för att användas av barn, men jag tror att idén som s˚adan kan vara användbar även för en designer som konstruerar ett “vuxet” gränssnitt.

4.2 Macromedia Director MX

Att bygga ett gränssnitt i Macromedia Director MX baseras inte p˚a fönster i sig, utan användaren har en ganska hög frihet i att helt enkelt rita sitt gränssnitt p˚a frihand. Varje objekt – en linje, cirkel eller en text – kan sedan funktionalitet länkas till. Funktionalitet skapas genom att designern klickar p˚a ett objekt, och f˚ar d˚a möjligheten att skriva skriptkod för objektet [17] (se figur 4.3). P˚a bilden ser man en skärmdump fr˚an Macromedia Director MX. I mitten till höger syns fönstret som inneh˚aller det gränssnitt som ritats upp, i det här fallet kallas det “Window1”. I fönstret strax till vänster syns scriptet för objektet “Button 1”, vilket man f˚ar upp genom att

(36)

22 4.3. Adobe GO Live!

högerklicka p˚a objektet i gränssnittet. Längst till vänster syns slutligen de verktyg man har till förfogande för att rita sitt gränssnitt.

Figur 4.3: Macromedia Director MX

En fördel med Director är att designern är mycket fri i sin kreativitet. Man är inte p˚a förhand bunden till att använda standardknappar och f¨ ons-ter, utan kan rita s˚adana saker precis som man vill att de ska se ut.

Nackdelar jag ser är att scriptspr˚aket kan vara sv˚art att använda för en person som inte är van vid programmering, och scriptspr˚aket har dessutom stora begränsningar i sina datastrukturer vilket gör att n˚agon som är insatt i programmering kan känna sig begränsad i spr˚aket.

4.3 Adobe GO Live!

GO Live används för att skapa interaktiva textsidor. Till exempel kan man med programmet skapa hemsidor, PDF:er och liknande sidor som till ex-empel ska inneh˚alla ett formulär [18].

Själva den grafiska designprocessen g˚ar till p˚a ungefär samma sätt som i Macromedia Director MX. Skillnaden är dock att istället för att skriva

(37)

scriptkod p˚a varje funktion s˚a f˚ar användaren istället möjlighet att med hjälp av direktmanipulation konstruera funktionalitet för ett objekt (se figur 4.4).

Figur 4.4: Adobe GO Live!

Jag anser att detta ger ett mycket verklighetsnära implementationssätt. Eftersom man utför funktionen för att skapa funktionen s˚a f˚ar designern direkt en liten feedback p˚a hur funktionen kommer att kännas för anv¨ an-daren. En nackdel är att verktyget inneh˚aller en begränsad mängd funktio-ner, och det g˚ar inte att kombinera dessa med varandra för att skapa nya funktioner. ˚A andra sidan har GO Live inte uttryckt n˚agra ambitioner till att vara ett verktyg för avancerad programutveckling, ett verktyg som gör s˚adana anspr˚ak kanske kan ha en annorlunda och bredare funktionsupp-sättning.

4.4 Eclipse Visual Editor

Eclipse är en programmeringsmiljö ursprungligen utvecklad för javapro-gram, men kan idag användas till andra programspr˚ak. Fr˚an början

(38)

in-24 4.4. Eclipse Visual Editor

nehöll den enbart en editor med kringverktyg för att programmera, och först senare blev editorn utökad med ett tilläggsverktyg som p˚a grafisk väg till˚ater programutvecklaren att rita upp gränssnitt.

Figur 4.5: Eclipse Visual Editor

I figur 4.5 ser vi ett fönster kallat “Team Members” som ritats upp i ap-plikationen. Nedanför ritytan ser man källkoden för fönstret, och det är allts˚a denna källkod man editerar för att skapa funktionalitet i prototypen. Till vänster syns en verktygsrad, “Palette”, och till höger syns inst¨ allning-ar s˚asom storlek, färger, teckensnitt och andra inställningar för de olika grafikkomponenterna.

Jag anser att det här är ett typiskt verktyg skapat av och för programme-rare. En detalj man märker det p˚a är att programmet startar upp i editor-läge, och programutvecklaren f˚ar sedan leta reda p˚a det grafiska verktyget. En annan detalj är att det enbart är den rent grafiska layouten som skapas i det grafiska verktyget, all funktionalitet f˚ar man sedan lägga till i det kodskelett som det grafiska verktyget genererar.

Eftersom verktyget är väldigt starkt anpassat till det programspr˚ak man utvecklar i s˚a är det iallafall för mig ett smidigt verktyg att använda vid programmering. Att använda det som ett grafiskt designverktyg däremot

(39)

känns inte helt trivialt d˚a det bara inneh˚aller de standardobjekt som finns i programspr˚akets bibliotek. Den artistiska friheten känns begränsad, och ingen funktionalitet g˚ar att skapa utan att man blir ganska väl bekant med hur spr˚aket ifr˚aga fungerar och är uppbyggt.

4.5 QT Designer

QT Designer är ett verktyg för att skapa C++-program kopplade till QT-biblioteket, som är ett grafikbibliotek utvecklat för C++-spr˚aket med tan-ken att det ska vara plattformsoberoende [19].

Figur 4.6: QT Designer

Till en början uppfattar jag verktyget som ganska klassiskt för ett GUI-verktyg skapat av och för programmerare, men jag märker ganska snabbt att det finns en skillnad. För att skapa funktionalitet s˚a behöver nämligen inte användaren skriva kod, utan man väljer helt enkelt ett objekt i en lista (vilket syns i figur 4.6), vilken händelse som ska utlösa funktionen samt vilken funktion hos vilket objekt som ska köras. I figuren bör man framförallt lägga märke till de tv˚a fönstren i mitten. Det nedre av dem

(40)

26 4.6. TelePICTIVE

inneh˚aller det uppritade gränssnittet, och det övre fönstret inneh˚aller listan med funktioner som finns i gränssnittet, för nuvarande tv˚a stycken som b˚ada är kopplade till knapparna okButton och cancelButton.

I det övre fönstret som kallas “Signal/Slot editor” ˚aterfinns allts˚a alla funktioner. Det gör att användaren kan f˚a en snabb överblick över alla funktioner som skapats i gränssnittet. Fr˚agan är bara hur l˚ang listan blir, och om det kanske blir sv˚art att överblicka den efter ett tag.

QT Designer är ocks˚a starkt bundet till QT-biblioteket vilket betyder att en designer är ganska begränsad till de knappar och andra objekt som redan finns fördefinierade, och därmed till˚ater inte verktyget n˚agon större artistisk frihet.

4.6 TelePICTIVE

TelePICTIVE är ett exprimentiellt program som utvecklats av bland an-nat David S. Miller p˚a Bellcore [8] just för att sammanfoga olika grupper av utvecklare under ett och samma program. Flera utvecklargrupper ska kunna använda samma verktyg till alla delar av programdesign och pro-gamutveckling. Här kan man samla skisser, rita prototypgränssnitt, skri-va programkod, skriskri-va kravspecifikationer och utföra användarintervjuer i samma program med inbyggd versionshantering och access p˚a distans. [8]

Projektet verkar dock inte ha presenterat n˚agot sedan 1992, och de pro-totyper som finns visar p˚a ett för˚aldrat gränssnitt som jag inte tror skulle fungera till modern programutveckling. Vad som änd˚a gör programmet värt att notera är att det integrerar alla delar i programutvecklingen under ett och samma tak. Tekniken är enligt mig med andra ord för˚aldrad, men te-orierna och resultaten som kom fram under utvecklingen av TelePICTIVE om att man kan samla olika utvecklare med olika bakgrund och m˚al under samma tak och f˚a dem att samarbeta i samma program [8] anser jag h˚alla ¨

(41)

4.7 Summering av verktyg

De verktyg jag nu g˚att igenom anser jag ha sina styrkor och svagheter. Problemet, som jag ser det, är att svagheterna överväger styrkorna. Sque-ak har kreativ feedback, men verktygen kanske inte är tillräckligt kraftfulla för att täcka upp en professionell programutvecklares krav. Macromedia Director MX har ungefär samma problem d˚a det är enkelt att skapa enk-la funktioner men saknar enligt min uppfattning ett tillräckligt kraftfullt scriptspr˚ak för mer avancerade funktioner samtidigt som det kräver att man änd˚a lär sig behärska ett scriptspr˚ak. GO Live är enbart utvecklat med hemsidor och PDF-formulär i ˚atanke och saknar därmed funktioner för att skapa generella programgränssnitt. Eclipse är utvecklat för och av programmerare vilket mer eller mindre kräver att man lär sig programmera innan man kan använda verktyget, precis som QT Designer. TelePICTIVE inneh˚aller ett intressant koncept där man försökt sammanfoga alla delar av programutvecklingen i ett program, men d˚a det är skapat med utg˚ angs-punkt i de primitiva grafiska gränssnitt som byggdes för över 15 ˚ar sedan s˚a ¨

ar det sv˚art att se hur just TelePICTIVE skulle kunna anv¨andas i modern gr¨anssnittsutveckling.

Sammanfattningsvis kan man säga att verktygen kan kategoriseras in i tv˚a grupper. Endera är de enkla att använda, men även enkla i de funk-tioner man kan skapa och lämpar sig därmed d˚aligt för mer avancerad programutveckling. Alternativt har de kraftfulla funktioner, men nästan uteslutande m˚aste man d˚a lära sig att programmera, vilket inte är ett helt trivialt steg för den som inte gjort det förut.

(42)

(43)

Programdesign

Jag väljer att presentera mina fyra prototyper i tv˚a olika scenarion, för att lättare kunna visa p˚a för- och nackdelar i de olika prototyperna under min användarundersökning. Att beskriva samma funktion i flera olika de-signförslag har jag baserat p˚a kapitel 2.5 kring teorierna om konceptuella prototyper.

M˚alet här är, som beskrivs i kapitel 3, att renodla de funktioner jag funnit d˚a jag undersökt olika existerande verktyg.

5.1 Scenarion

Här beskrivs de tv˚a scenarion jag sedan applicerar mina prototyper p˚a för att enkare genom exempel kunna förklara funktionen hos mina prototyper.

5.1.1 Oppna f¨

¨

onster

Förutsättningarna för detta scenario är att programutvecklaren har skapat tv˚a stycken fönster, “window1” och “window2”. I fönstret “window1” finns det en knapp. Funktionaliteten som ska skapas är att d˚a slutanvändaren klickar p˚a knappen i “window1” ska fönstret “window2” öppnas.

(44)

30 5.2. Designf¨orslag

Figur 5.1: ¨oppna f¨onster

5.1.2 Drag–och–sl¨

app-funktion

Förutsättningarna för det andra scenariot är att programutvecklaren har skapat ett fönster med tv˚a listor i. Listorna kan vara tomma eller inneh˚alla ett eller flera objekt. De skulle till exempel kunna vara tv˚a kataloger som inneh˚aller filer med en fil per rad representerade som filnamnet. Funktio-naliteten som ska skapas är att slutanvändaren ska kunna med hjälp av en drag–och–släpp-funktion kunna kopiera objekt fr˚an den ena listan till den andra.

5.2 Designf¨

orslag

Nedan presenteras de fyra olika prototyper jag arbetat fram, applicerat p˚a de tv˚a scenarion som beskrivits i kapitel 5.1.

(45)

Figur 5.2: drag–och–sl¨app-funktion

5.2.1 Prototyp 1 – Direkt manipulering

Syftet med prototypen är att designern ska skapa funktionalitet genom att utföra precis den funktion man vill skapa. Om exempelvis en knapp ska stänga ett fönster s˚a markeras först knappen, och därefter “stänger” man fönstret genom att klicka p˚a kryssrutan i fönstrets övre högra hörn.

Exemplet i figur A.1 illustrerar hur designern först klickar p˚a knappen, och sedan p˚a det andra fönstret – objektet som ska öppnas. Eftersom det finns en osäkerhet i vad designern vill göra med det andra fönstret kommer det nu upp en ruta, där designern kan välja om det andra fönstret ska ¨

oppnas eller fokuseras d˚a knappen trycks ned.

Här kan man se ett problem med prototypen, d˚a det kan kännas okon-sekvent för designern om en liten ruta kommer upp när det finns flera alternativ för ett objekt.

I nästa scenario (Figur A.2) vill designern skapa tv˚a listor, där det ska g˚a att dra objekt fr˚an den första listan till den andra. Designern tar d˚a och drar ett fördefinierat dummyobjekt, som f˚ar symbolisera alla objekt som kan ligga i listan, och drar över det till den andra listan, precis som

(46)

slutanvändaren ska kunna göra. Här krävs ocks˚a tv˚a alternativ som syns i en ruta d˚a dummyobjektet släpps ned, eftersom designverktyget inte kan veta om slutanvändaren ska kunna dra objekt eller kopiera objekt mellan listorna.

5.2.2 Prototyp 2 – Drag funktioner

Prototyp nummer tv˚a använder sig av en etikettmodell som jag har l˚anat fr˚an MagicWords. Min idé är att undersöka om ett koncept som är tänkt ska användas för barn ocks˚a kan användas för vuxna människor i professionella miljöer.

Designern väljer en funktion i listan över funktioner, som sedan dras till det objekt som ska ha funktionen. Om funktionen sedan p˚averkar ett annat objekt s˚a dras ett “snöre” ut fr˚an etiketten som “fästs” vid objektet som p˚averkas.

I scenariot där ett fönster ska öppnas genom att användaren klickar p˚a en öppna-knapp (Figur A.3), s˚a dras allts˚a funktionen “open” till knappen som ska utföra funktionen, och “snöret” dras sedan iväg och placeras p˚a valfri plats i det fönster som ska öppnas.

En fördel med den här prototypen jämfört med det första prototypen är att det inte finns n˚agon osäkerhet kring vilken funktion som ska utföras. Funktionens namn finns ju redan p˚a etiketten, och om designern istället vill att en knapp ska fokusera ett fönster s˚a väljer man helt enkelt “focus” istället för “open” fr˚an början.

För att skapa tv˚a listor fr˚an vilka slutanvändaren ska kunna dra objekt fr˚an den ena till den andra, s˚a väljs funktionen “copy” fr˚an listan över funktioner, placeras p˚a den första listan och sedan markeras att det är den andra listan slutanvändaren ska kunna dra objekt till (Figur A.4).

5.2.3 Prototyp 3 – V¨

alj funktion med sm˚

a menyer

Denna prototyp baserar sig p˚a att designern ska fr˚an en meny i varje objekt välja en händelse som ska utlösa en funktion. Funktionen väljs sedan i det objekt som ska p˚averkas av funktionen.

Precis som i den första prototypen s˚a är ˚aterkoppling av vilken funktion som utförts bortplockad ur sammanhanget, d˚a jag anser att vilken som

(47)

helst av de fyra alternativen i ﬁgur A.9 kan anv¨andas.

I figur A.5 väljer designern att när händelsen “n˚agon klickar p˚a knappen” inträffar, s˚a ska funktionen “öppna fönster nummer tv˚a” utföras. Det görs genom att designern först väljer “onklick” i menyn för knappen, och sedan väljer funktionen “open” fr˚an det andra fönstret.

I figur A.6 illustreras hur designern skapar möjlighet att dra objekt fr˚an en lista till en annan. I den första listan väljs funktionen “att kunna dra”, och den andra listan markeras för att visa var objekt ska kunna dras. Ef-tersom funktionen inte har n˚agra alternativ att välja p˚a efter att man valt dragfunktionen, s˚a behövs ingen meny där designern ska välja funktion.

En möjlig feedback p˚a detta är att ändra musmarkören s˚a att den ˚ ater-speglar vad designverktyget förväntar sig för input fr˚an användaren. Här finns ocks˚a utrymme för att användaren ska kunna välja flera listor som objekten fr˚an den första listan ska kunna dras till.

5.2.4 Prototyp 4 – Egenskapsf¨

onster

Den sista prototypen är inspirerat av till exempel Adobe Go Live! och andra program där varje objekt har en egenskapsruta där diverse inställningar kan göras som till exempel färg, namn och annat utseende. Tanken är att längst ned i en s˚adan egenskapsruta presentera de funktioner som finns i objektet. Funktioner läggs till genom att designern väljer knappen “add”, och sedan väljer vilken funktion som ska läggas till.

I det första scenariot – att öppna ett fönster (Se figur A.7), s˚a väljer först designern knappen, om det inte redan är gjort, för att f˚a upp egenskaperna för objektet. Sedan klickar designern p˚a knappen “add” för att lägga till en ny funktion till knappen. Sedan klickar man p˚a det fönster som ska öppnas, varp˚a en meny kommer upp där designern väljer alternativet “open”.

Valet av vilken funktion som ska utföras kan kännas igen fr˚an prototyp ett och tv˚a. Skillanden ligger i hur användaren väljer vilket objekt som ska utlösa funktionen.

Om man istället applicerar prototypen p˚a scenariot “drag objekt” (Fi-gur A.8) s˚a väljer desingern den lista fr˚an vilken man ska kunna dra objekt, väljer att lägga till en funktion, och sedan vilken funktion som ska läggas till, allts˚a möjligheten att dra objekt till lista 2.

(48)

5.2.5 ˚

Aterkoppling av skapade funktioner

För att användaren ska veta vad som är gjort, och för att kunna ha m¨ oj-ligheten att ändra eller ta bort skapade funktioner, s˚a m˚aste det p˚a n˚agot sätt g˚a att ta reda p˚a vilka funktioner som är skapade. Därför behövs en ˚aterkoppling som tydligt talar om för användaren vilka funktioner som är skapade och vad de betyder. Jag har utformat fyra olika alternativ (Se figur A.9) för att ge ˚aterkoppling till vad programutvecklaren hittils har skapat.

Det första av de fyra alternativen best˚ar av en lista som inneh˚aller de funktioner som skapats. Den ing˚ar redan i prototyp fyra (Figur A.7 och A.8), men skulle ocks˚a kunna visa alla funktioner för alla objekt i den här proto-typen. Syftet är att varje rad representerar en funktion. Genom att skapa en ny funktion skapas ocks˚a en ny rad, och genom att markera en rad kan man komma ˚at olika alternativ s˚asom att förändra funktionen eller ta bort den.

De övriga tre alternativen är olika former p˚a ˚aterkoppling som baserar sig p˚a etiketter, som p˚a lite olika sätt visar vad funktionen i fr˚aga p˚averkar. D˚a man skapar en ny funktion s˚a skapas en etikett, och genom att markera etiketten kan man p˚a olika sätt komma ˚at alternativ för den funktionen. I Alternativ 2 och 4b visar ˚aterkopplingen visuellt vilken form av händelse som utlöser funktionen, i de övriga f˚ar användaren själv anta detta utifr˚an sammanhanget. Dessa tre alternativ finns med i prototyp nummer tv˚a (Fi-gur A.3 och A.4) där etiketten används direkt i prototypen när funktionen skapas.

(49)

Anv¨

andarunders¨

okning

Användarundersökningen är genomförd med en intervjumall som beskrivs i kapitel 6.1. Varje intervju har sedan sammanfattats i kapitel 6.2.

6.1 Intervjumallen

Syftet med att göra en intervju är dels att f˚a en utvärdering av de proto-typer jag skapat, och dels att utgöra en grund för det slutgiltiga förslaget p˚a hur ett verktyg skulle kunna fungera. Intervjuernas fokus kommer att ligga p˚a utvärdering och jämförelse av fördelar och nackdelar hos de oli-ka modellerna, men jag vill dessutom f˚a höra andra idéer och förslag fr˚an subjekten. Därför har jag valt den kvalitativa QOC-modellen framför en kvantitativ metod, som hade kunnat fungera om jag bara ville rangordna prototyperna.

P˚a en punkt skiljer jag mig fr˚an QOC-modellen. Jag har valt att h˚alla en ganska öppen diskussion kring de olika designförslagen samtidigt som jag har färdiga prototyper att bygga diskussionerna p˚a. Detta gör att jag förvandlar QOC-modellen fr˚an en strukturerad intervjuteknik till n˚agot man skulle kunna kalla semistrukturerad. Man kan se detta som att mina fr˚agor leder till en oändlig mängd svarsalternativ istället för en diskret ¨

andlig mängd, men mitt syfte är ändock att de ska leda fram till samma

(50)

36 6.1. Intervjumallen

slutkriterium och positiva/negativa utv¨arderingar kring resultaten.

Nedan presenteras de intervjufr˚agor jag har valt, med kommentarer och motiveringar till varf¨or jag valt fr˚agan samt vad jag hoppas f˚a ut f¨or resultat av fr˚agan under intervjuen.

1. Vad är ett gränssnittsverktyg/vad är en funktion

I detta avsnitt syftar diskussionen till att dels ta reda p˚a vad anv¨ anda-re använder idag, samt att ta reda p˚a vilken niv˚a användaren ligger p˚a. Det är ocks˚a viktigt att vi b˚ada är överens om vad begreppen gränssnittsverktyg och funktion har för mening.

(a) Har du tidigare använt ett grafiskt verktyg för att bygga gränssnitt?

Denna fr˚aga är till för att ge mig en snabb check p˚a hur mycket bakgrundskunskap personen i fr˚aga har. Det ger mig möjlighet att anpassa spr˚aket efter person.

(b) Is˚afall: Vilket verktyg anv¨ander du? ¨

Aven detta är en intressant fr˚aga eftersom användare ofta ut-g˚ar ifr˚an en känd värld. Om jag kan definiera mina funktioner utifr˚an en redan känd miljö s˚a kommer det att underlätta kom-munikationen. Jag är ocks˚a intresserad av att f˚a reda p˚a fler möjliga verktyg att titta p˚a för att f˚a inspiration.

(c) Is˚afall: Hur skapar man funktionalitet med det verkty-get?

Fr˚agan bör ställas p˚a ett annorlunda vis för att anpassa till per-son och vilket verktyg perper-sonen i fr˚aga är van vid. Fr˚agan är mest en kontroll p˚a att personen uppfattat vad jag menar med att skapa funktionalitet, men kan ocks˚a vara intressant om an-vändaren är van med ett verktyg som jag inte är bekant med. 2. Presentera funktionen “öppna fönster”

Här kommer jag att presentera fyra olika sätt att skapa funktionalitet p˚a, i ett scenario där användaren vill f˚a en knapp att öppna ett nytt fönster.

(51)

(a) Vilken anser du är den bästa av de här 4 lösningarna? Fr˚agan har den naturliga följdfr˚agan “varför?”, och är menad att leda fram till en diskussion kring vad som is˚afall är d˚aligt med de ¨

ovriga modellerna och vad som är bra med den bästa modellen. (b) Vad ser du för problem i dem?

Förhoppningen är att problem kommer att tas upp i diskussio-nen tidigare. Diskussiodiskussio-nen syftar till att lyfta fram b˚ade bra och d˚aliga delar av varje funktionsmodell. Kan vara användbar om användaren är för positivt inställd och inte vill vara tillräckligt kritisk.

(c) Vad kan man förbättra för att undvika problemen? Det här är en ganska öppen fr˚aga där personen f˚ar komma med egna förslag och idéer p˚a vad man skulle kunna ändra eller f¨ or-bättra. Den finns för att skapa utrymme för s˚adan feedback fr˚an personen. Kanske kan besvaras med ett exempel p˚a hur det görs i ett annat program om användaren anser att det sättet är enkla-re.

3. Presentera ˚aterkopplingsalternativ

Jag presenterar här fyra olika sätt att f˚a ˚aterkoppling p˚a vad man som användare har gjort och inte har gjort.

(a) Vilken anser du är den bästa av de här fyra lösningarna? Fr˚agan syftar till diskussion kring vad som är bra och vad som ¨

ar mindre bra med de olika modellerna. (b) Vad ser du f¨or problem i dem?

Precis som i det tidigare scenariot en fr˚aga f¨or att f˚a fram b˚ade bra och d˚aliga sidor av modellerna.

(c) Vad kan man förbättra för att undvika problemen? ¨

Aven detta en fr˚aga med samma syfte som i tidigare diskussion. (d) Kan man kombinera flera olika ˚aterkopplingsalternativ

för att f˚a en bättre miljö?

Här h˚alls en liten diskussion kring att kombinera tv˚a eller flera olika alternativ. +/- kommer att uppföras kring att kombinera

(52)

38 6.2. Intervjuresultat

saker i sig, men diskussionen kan bli ganska kort om vi redan kommer in p˚a omr˚adet tidigare. Syftet med fr˚agan ¨ar att jag har en misstanke om att viss ˚aterkoppling fungerar bra i vissa fall, medan en annan ˚aterkoppling passar b¨attre i andra fall.

4. Presentera funktionen “skapa drag n’ drop”

Detta scenario är till för att sätta funktionsmodellerna i det tidigare scenariot p˚a prov. Scenariot finns även till som en hjälp om personen i fr˚aga skulle ha sv˚art att sätta sig in i det andra scenariot, lite som en backup.

(a) Med bakgrund i scenariot “öppna fönster”: Ser du n˚agra nya problem funktionsmodellen som var bäst där? Fr˚agan ställs för att se om personen funnit n˚agra problem med en tidigare modell när den utsätts för ett nytt scenario.

(b) Skulle en annan funktionsmodell vara b¨attre f¨or att ska-pa drag n’ drop?

Denna fr˚aga hänger ihop med den föreg˚aende fr˚agan, och hand-lar ocks˚a den om att försöka f˚anga upp funna problem. Den leder ocks˚a in p˚a nästa fr˚aga.

(c) Kommer du p˚a n˚agot annat tillf¨alle n¨ar en funktions-modell kanske inte fungerar?

Detta är en öppen fr˚aga som egentligen inte är s˚a viktig att f˚a svar p˚a, men den är en resurs för att f˚anga upp idéer fr˚an personen ifr˚aga. En diskussion kan ocks˚a svara p˚a om tv˚a eller flera olika modeller kan kombineras för ett bättre resultat.

6.2 Intervjuresultat

Intervjuerna blev lyckade, och jag känner efter˚at att jag f˚att fram myc-ket bra information som jag kan använda i fortsatt arbete. Varje intervju tog mellan en halv och en timme, och utfördes i en lugn och avskärmad miljö. Jag förde anteckningar under intervjuerna, och nedan redovisas n˚ a-got längre och mer allmänt tillgängliga sammanfattningar fr˚an intervjuerna

(53)

baserade p˚a de anteckningar och minnen jag har fr˚an intervjuerna. Varje sammanfattning skrevs ned senast dagen efter varje intervju, och de skrevs ocks˚a innan jag p˚ab¨orjade n˚agon ny intervju.

6.2.1 Intervju med person A

Person A studerar kognitionsvetenskap och har tidigare inte anv¨ant n˚agot liknande verktyg inom omr˚adet och har lite programmeringserfarenhet fr˚an universitetskurser.

Person A tycker att prototyp ett känns naturligt. Osäkerhet r˚ader dock kring fr˚agan om man ska använda sig av en meny ifall flera alternativ finns. A tycker att det kan kännas ostrukturerat om menyn bara dyker upp när flera alternativ finns, men det är ocks˚a onödigt att ha en meny om det bara finns ett alternativ. Reflektion över om man vill utföra handlingen först och sedan f˚a alternativ uppkommer ocks˚a.

Prototyp tv˚a känner A sig osäker till, och tror inte riktigt det blir bra. A menar att listor nästan alltid blir oöverblickbara och att tid g˚ar ˚at till att leta efter rätt funktion. Prototyp tre kommenteras med att det känns likt första prototypen.

Person A känner att prototyp fyra till sist kan vara sv˚art att använda p˚a grund av att det känns som det saknas en direkt visuell ˚aterkoppling till vilket objekt man egentligen arbetar med.

För ˚aterkoppling tycker person A att etiketter är bäst, och om A m˚aste välja en av dem s˚a känns alternativ 4a bäst. A kommenterar ocks˚a al-ternativ 3 med att det kan vara sv˚art att veta vilket objekt som utlöser funktionen och vilket objekt som p˚averkas.

Sammanfattningsvis tycker person A att prototyp ett k¨anns trevligast att anv¨anda.

6.2.2 Intervju med Person B

Person B studerar kognitionsvetenskap och har tidigare anv¨ant Squeek i utbildningssyfte samt har lite programmeringserfarenhet fr˚an universitets-kurser.

B tycker att prototyp ett verkar enkelt att använda sig av. Eventuellt skulle man vid vissa tillfällen vilja f˚a upp alternativ innan man utför

(54)

hand-40 6.2. Intervjuresultat

lingen, men det beror p˚a när det passar till handlingen. Det kan ocks˚a kännas inkonsistent om menyer inte kommer p˚a samma sätt p˚a alla objekt. Prototyp tv˚a kommenterar person B med att listan troligtvis kommer att bli för l˚ang för att vektyget ska bli användbart i realiteten. När jag föresl˚ar en flerniv˚alista säger B att det kan bli praktiskt möjligt, men att det fortfarande kan bli sv˚art att hitta och arbeta med den.

Prototyp tre tycker B känns klassiskt och tror inte det är n˚agra problem att använda sig av, även om det inte känns som n˚agon nyhet.

Prototyp fyra slutligen finner B ett problem i att det inte finns n˚agon direkt visuell koppling till vilket objekt som alternativfönstret visar alter-nativ för, utan användaren m˚aste själv veta vilket objekt som är markerat. För ˚aterkoppling tycker B att en direkt feedback i form av etiketter är bäst, och alternativ 4a ligger högst i topp för b˚ada.

Slutligen tycker person B att prototyp ett k¨anns som det mest naturliga att anv¨anda.

6.2.3 Intervju med Person C

Person C studerar datavetenskap och har tidigare programmerat litegrann, och d˚a använt verktygen Eclipse, Visual Basic och Adobe Go Live. I de första tv˚a verktygen skapas funktionalitet genom att man skriver program-kod. Det sista verktyget skapar funktionalitet p˚a ett sätt som p˚aminner om prototyp fyra i skisserna. C har programmeringserfarenhet fr˚an univer-sitetskurser och har även programmerat n˚agra mindre projekt hemma.

Person C kommenterar de verktyg där man skriver kod som att de är trevliga att använda, även om det kan bli mycket kodskrivande ibland. Adobe Go Live däremot tycker C inte alls om d˚a C tycker sig tappa kon-trollen över funktionaliteten och inte längre kan precisera exakt vad som ska hända.

Prototyp ett och tre tycker C är helt okej, och uppfattar som att de kan vara bra i olika situationer. Att ha menyer p˚a olika ställen beroende p˚a om det krävs eller inte ser C inte som ett problem utan faller sig troligtvis ganska naturligt när man f˚att vänja sig vid programmet.

Prototyp tv˚a anser person C kommer skapa en alldeles för l˚ang lista med funktioner, och det kan vara sv˚art att veta vilken funktion som faktiskt utför det man vill utföra. Är det enkelt att ge relevanta namn till alla

(55)

funktioner?

Prototyp fyra känner C igen fr˚an Adobe Go Live, och tror det blir sv˚art att använda effektivt även om C ser en viss fördel gentemot Go Live ef-tersom det lämnar n˚agot mer kontroll till användaren.

Kring ˚aterkoppling tror C mest p˚a en lista precis som i alternativ 1, men kan ocks˚a tänka sig att kombinera tillsammans med n˚agot av de andra förslagen. P˚a fr˚aga om vilket av de övriga tre etikettmodellerna som känns bäst är C osäker och ser b˚ade fördelar och nackdelar p˚a samtliga förslag.

¨

Aven i slutet av intervjuen tror C fortfarande att prototyp ett eller tre skulle vara det b¨asta av de h¨ar prototyperna. En kombination av de b˚ada tror C kan bli riktigt bra.

6.2.4 Intervju med person D

Person D studerar datavetenskap och är mycket väl bevandrad inom pro-grammering och har använt verktygen Glade, Visual C++ och Visual Basic. I samtliga verktyg skapar D funktionalitet genom att skriva programkod, och verktygen används endast för att visuellt rita upp fönster.

Prototyp ett uppfattar D som ganska begränsat och har sv˚art att se hur man skulle kunna generalisera det till att fungera för alla typer av funktionsskapande. D tror ocks˚a att det kan vara sv˚art att veta vad man ska klicka p˚a för att skapa funktionaliteten. Är det naturligt att man klickar p˚a fönstret man ska öppna efter att man klickat p˚a knappen? Är fönstret det naturliga objekt som öppnar sig?

Prototyp tv˚a är D tveksam till om det är överblickbart. Listan kan bli för l˚ang för att man p˚a ett enkelt sätt ska kunna hitta i den. Om listan däremot kan h˚allas kort s˚a tror D att det kan vara ett mycket användbart och lättförst˚aligt alternativ.

Prototyp tre tycker D har en förväntad effekt, med en meny i varje ände, men precis som i prototyp ett s˚a kan det vara sv˚art att hitta vilket objekt man ska hitta avsedd funktionalitet i.

Prototyp fyra tycker person D är den bästa prototypen av de fyra. Det har en vettig balans mellan direktmanipulering och effektivitet för en van användare.

I fr˚aga om ˚aterkoppling tycker D att alternativ 2 behöver n˚agon form av markering för att visa ˚at vilket h˚all effekten är. alternativ 3 uppfattas som