61
Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete Stockholm, Sverige 2006

Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

  • Upload
    donhan

  • View
    224

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Propellerhead Reason för nybörjare

Användarcentrerad utvärdering och designprocess

A N D E R S L J U N G

Examensarbete Stockholm, Sverige 2006

Page 2: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Propellerhead Reason för nybörjare

Användarcentrerad utvärdering och designprocess

A N D E R S L J U N G

Examensarbete i människa-datorinteraktion om 20 poäng vid Programmet för medieteknik Kungliga Tekniska Högskolan år 2006 Handledare på CSC var Henrik Artman Examinator var Yngve Sundblad TRITA-CSC-E 2006:118 ISRN-KTH/CSC/E--06/118--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.csc.kth.se

Page 3: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Propellerhead Reason för nybörjare

Sammanfattning

Denna rapport beskriver ett examensarbete som utförts inom människa- datorinteraktion påKTH för Propellerhead Software AB. Syftet med arbetet var att med hjälp av användartesteridentifiera de funktioner och objekt i musikprogrammet Reason som är svårast att förstå för ennybörjare. Propellerheads ville dessutom få förslag på förändringar som skulle kunna minimeradessa svårigheter, utan att de skulle vara i vägen för mer avancerade användare.

Tio explorativa och kvalitativa användartester utfördes och resultaten i form avanvändbarhetsproblem grupperades, rankades och analyserades. De tre störstaproblemområdena gällde

• att skapa överblick och konceptuell förståelse• att få en enhet att låta• att spela in

Resultaten från användartesterna låg till grund för fyra designförslag som i form avpappersprototyper utvärderades i samarbete med användarna. Designförslagen består av entutorial, ett projektgalleri, en ny preset-baserad enhet samt ett ”Easy Mode”, det vill säga ettspeciellt läge för nybörjare i programmet.

Propellerhead Reason for novices

Abstract

This report describes a Master’s project performed at KTH’s department for Human-ComputerInteraction for Propellerhead Software AB. The goal for the project was to identify the functionsand objects in the music software Reason that are the hardest for beginners to understand.Propellerheads also were interested in design solutions that would minimize these difficultieswithout annoying more experienced users.

Ten explorative and qualitative user tests were performed, and the results in the form ofusability problems were grouped, ranked and analyzed. The three most critical problem areaswere

• getting overview and conceptual understanding• getting a device to sound• recording

Four design proposals based on the user tests were produced and in the form of paper prototypesevaluated in cooperation with the users. The design proposals consist of a tutorial, a projectgallery, a new preset based device and an ”Easy Mode”.

Page 4: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

InnehållsförteckningBakgrund..............................................................................................................................................1

Datormusikbranschen idag..............................................................................................................1

Datormusikens historia....................................................................................................................1

Propellerhead Reason......................................................................................................................3

Syfte och problemdefinition............................................................................................................3

Avgränsningar .................................................................................................................................4

Teori .....................................................................................................................................................5

Människa- datorinteraktion .............................................................................................................5

Formge för nybörjare eller experter? ..............................................................................................9

MDI och musik..............................................................................................................................10

Metod .................................................................................................................................................13

Fas 1: Explorativa användartester.................................................................................................13

Fas 2: Utveckla designförslag .......................................................................................................18

Fas 3: Utvärdera designförslag .....................................................................................................18

Resultat...............................................................................................................................................19

Rekrytering ....................................................................................................................................19

Användartester...............................................................................................................................19

Sammanfattning och analys av resultat ........................................................................................32

Intervju med Propellerheads support ............................................................................................34

Utvärdering av designförslag ........................................................................................................34

Designförslag.................................................................................................................................35

Diskussion..........................................................................................................................................40

Sammanfattande slutsatser ............................................................................................................40

Framtida studier.............................................................................................................................41

Referenser ..........................................................................................................................................43

Tryckta källor ................................................................................................................................43

Internetkällor .................................................................................................................................44

Bilagor................................................................................................................................................45

Bilaga A: användarkontrakt ..........................................................................................................45

Bilaga B: bakgrundsenkät .............................................................................................................47

Bilaga C: Instruktioner till testpersonerna....................................................................................50

Bilaga D: Kritiskt index ................................................................................................................51

Bilaga E: Allvarlighetsrankning per testperson............................................................................54

Page 5: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bakgrund

1

BakgrundI detta kapitel ges en kort bakgrund till området datormusik, samt en motivering varför

examensarbetet har utförts.

Datormusikbranschen idagÅr 2003 omsatte musikinstrument- och ljudteknikbranschen ca 170 miljarder kronor (The MusicTrades 2004). Musikskapande är idag en i hög grad datoriserad verksamhet, där tekniken öppnarfantastiska möjligheter för den som lyckas bemästra den. Många artister och musiker är idagoberoende av de stora inspelningsstudior som i princip haft monopol på inspelningsteknikensedan det blev möjligt att spela in ljud. Med Internet har dessutom en helt ny kanal attdistribuera musik öppnats, framför allt genom filformatet mp3. Sammantaget har datoriseringenomformat hela musikbranschen: studior läggs ner, skivbolagen går dåligt och publiken lyssnarpå nedladdade mp3:or i sina iPods. Samtidigt har möjligheterna för musiker att realisera sinaidéer dramatiskt ökat.

Datormusik har också blivit ett konkurrensmedel mellan datortillverkarna. Apple levererar idagsina datorer med musikprogrammet Garageband, som trots sitt fokus på enkelt musikskapandeför nybörjare är ett mycket kraftfullt verktyg om man jämfört med de kassettbandspelare somdominerade hobbymarknaden för 15 år sedan. Dessutom köpte Apple år 2002 Emagic, varsmusikprogram Logic är ett av de större på marknaden.

Datormusikens historiaMusik skapad på elektronisk väg har funnits sedan slutet av 1800-talet, då Thaddeus Cahill fickpatent på sitt så kallade Telharmonium (Manning 2004). Apparaten var 20 m bred, vägde ca 200ton och alstrade ljud via olika mekaniskt växlade elektriska dynamos. Syftet bakom dennagigantiska musikmaskin var att förse stora städer med direktsända konserter via telenätet, enslags tidig form av streaming. Tyvärr störde Telharmonin, som tjänsten kallades, den vanligatelefonin alltför mycket. I kombination med det astronomiska priset på tvåhundratusen dollargjorde detta att Cahills företag New England Electric Music Company gick i konkurs 1914.

Förutom Thereminen, som spelas genom att positionera händerna framför två antenner, användede följande decenniernas elektroniska musikinstrument i första hand pianotangenter för attkontrollera ljudalstringen. Skälen till detta var främst praktiska: pianotangenter är lätta attomsätta till elektriska kontakter och är (till skillnad från till exempel en fiolsträng) diskretuppdelade i olika tonhöjder. Av periodens fantasifullt namngivna instrument (Sphärofon 1927,Dynaphone 1928, Ondes Martenot 1928, Trautonium 1930) lever Hammondorgeln (1935)fortfarande kvar som ett standardinstrument för det mer traditionella rockbandet.

Under och efter andra världskriget dominerades utvecklingen av elektronisk musik av tvåinriktningar. I Paris fanns Pierre Schaeffer som propagerade för musique concrète, det vill sägamusik skapad genom manipulation av inspelade ljud, främst genom kreativ användning av ettflertal bandspelare. I Köln fanns å andra sidan en grupp forskare och tonsättare, bland andraKarl-Heinz Stockhausen, som ville skapa syntetiska ljud på elektronisk väg.

Det stora uppsvinget för elektronisk musik kom med lanseringen av portabla och överkomligtprissatta analoga synthesizers i mitten av sextiotalet. En synthesizer är ett elektronisktinstrument, ofta med pianotangenter, som kan generera i princip vilket ljud som helst. Tidigarehade det bara funnits ett fåtal dyra och avancerade synthesizers främst inom den akademiskavärlden, till exempel Columbia Universitys RCA-synthesizer. Ungefär samtidigt, år 1966, kombåde Robert Moog och Donald Buchla ut med kommersiella system, baserade på subtraktiv

Page 6: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bakgrund

2

s"ntes. Av dessa namn är det Moog som kanske ärmest känt, mycket tack vare syntklassikernMinimoog :se bild 1=.

>nder s?uttiotalet användes alltmer syntar inomkonst@ och populärmusiken. Dessutom kom vissaartister, till exempel tyska KraftGerk, att uteslutandeanvända syntar. I slutet av s?uttiotalet fanns ettflertal tillverkare av analoga syntar, trummaskiner

och enkla se,uencers. Dessa kunde kopplas ihopoch synkroniseras med .ontrol 2oltage :IJ=.Tyvärr hade var?e tillverkare sin egen IJ@standard,så det var inte säkert att en Buchla@keyboard fungerade med en Moog@synt. För att lösa dettaproblem samlades de stora musikelektroniktillverkarna 1O83 bakom en ny digital standard förkommunikation mellan musikmaskinerR Musical 5nstrument Digital 5nterface :MIDI=.

Digital teknik och mikroprocessorer mö?ligg?ordeäven nya syntesmetoder, till exempel FM9s"ntes

och sampling. 1O83 presenterade Samaha sinförsta helt digitala FM@synt DT7 som tack varesina nya l?udmö?ligheter och MIDI blev en enormförsäl?ningsframgång :se bild 2=. Den ärfortfarande världens mest sålda synthesiVer. Tillskillnad från analoga syntar, som av tekniska skälhade en kontroll för var?e syntesparameter,introducerade de digitala syntarna en interaktion via WID@displayer, menyer ochfunktionstangenter.

Den första kommersiella samplingssynten, eller samplern, hette Fairlight och lanserades 1O7O.FairlightRen var riktad mot professionella musiker och hade ett grafiskt gränssnitt däranvändaren kunde redigera samplade vågformer med en l?uspenna på en skärm. Den något merhumant prissatta Emulatorn från E@mu Systems kom två år senare, vilket g?ordesamplingstekniken mer överkomlig för gemene man. De första samplingssyntarnas l?udkvalitetoch minneskapacitet var med dagens mått mätt relativt begränsade. >tvecklingen gick docksnabbt och redan 1O88 fanns till exempel Akai S1ZZZ som kunde sampla i ID@kvalitet och hade32 Mb minne.

Med MIDI fanns helt plötsligt en enkel mö?lighetatt koppla ihop syntar med dåtidens hemdatorer.>nder andra hälften av åttiotalet utvecklades ettflertal notskrifts@ och se[uencerprogram, tillexempel Steinbergs Pro9<= för Atari ST ochIommodore Amiga, samt I@Wabs Notator för AtariST :se bild 3=. Dessa program spelade endast inMIDI@data för att styra syntar, och synkroniseradesofta med analoga bandspelare som kunde spela inl?ud. Tidigare hade det funnits hårdvarubaseradese[uencers, men datorernas grafiska gränssnitt ochderas överlägsna användbarhet g?orde snart dessaöverflödiga.

>nder OZ@talet fick persondatorerna allt högre prestanda vad gäller processorkraft, minne ochhårddiskstorlek. Kombinerat med att det även blev vanligare med l?udkort i persondatorernablev det snart praktiskt mö?ligt även för hobbymusiker att använda datorn som digitalbandspelare. En ny famil? av kombinerade MIDI@ och l?udinspelningsprogram lanserades.>tvecklingen skedde parallellt från två hållR dels MIDI@program som utökades med

Bild A: Minimoog

CwwwEhollowsunEcomG

Bild <: Hamaha DIJ

CwwwEvintages"nthEcomG

Bild L: .9Lab Notator

CwwwEtweakheadOEcomG

Page 7: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bakgrund

3

ljudinspelning (till exempel Logic Audio), och dels ljudprogram som fick stöd för MIDI (tillexempel Digidesign ProTools).

Den sista pusselbiten bestod i att få in även syntar, samplers och trummaskiner i programmen,så kallade mjukvarusyntar. Det första spadtaget togs av Steinberg med programmet Cubase VST(Virtual Studio Technology). Genom att skapa ett öppet så kallat plug-in-format öppnade manupp programmet för tredjepartstillverkare att utveckla både effekter och mjukvarusyntar. Idagfinns ett flertal musikprogram som fungerar som kompletta mjukvarustudios, till exempelSteinbergs Cubase SX3, Apples Logic 7 och Digidesigns ProTools 7. Dessa kallas på grund avsin karaktär av schweizisk armékniv ofta för Digital Audio Workstations eller DAW:s, och är dedominerande verktygen för inspelning av musik. Det finns även loopbaserade musikprogramdär interaktionen liknar mer ”klipp och klistra” i färdiga ljud och loopar än om att spela ettinstrument. Exempel på dessa är Fruity Loops, Ableton Live med flera.

Propellerhead ReasonPropellerhead Software AB är ett mjukvaruföretag iStockholm med ca 30 anställda. Företaget utvecklar sedan1999 musikprogrammet Reason, som detta examensarbetebaseras kring. Propellerheads första produkt var Recycle,ett program för att hantera loopar. Reason föregicks ävenav ReBirth från 1997 (Rebirth Museum 2006), en virtuellmodellering av synttillverkaren Rolands klassiskatrummaskin TR-808 och bassynt TB-303 från det tidigaåttiotalet. ReBirth blev en stor framgång tack vareelectromusikens ökade popularitet, de fysiskaförebildernas höga andrahandsvärde samt att man tidigtutnyttjade Internet för att marknadsföra produkten.

Reason kan ses som en utveckling av ReBirth, och skiljersig på ett antal sätt från mer traditionella DAW:s som Cubase, Logic och ProTools. Den störstaskillnaden är att Reason saknar möjlighet att direkt spela in ljud. Istället riktade sig programmetfrån början främst till användare som vill skapa renodlad instrumental elektronisk musik, ochdärigenom klarar sig utan denna funktionalitet. Dock finns möjlighet att koppla ihop ochsynkronisera Reason med de flesta DAW:s genom Propellerheads egna protokoll ReWire, ochpå det sättet använda Reason som mjukvarusynt och DAW:n för inspelning av ljud. Ett annatsärdrag som skiljer Reason från traditionella DAW:s är programmets grafiskaanvändargränssnitt som bygger på en stark metafor till fysisk musikutrustning. Programmetfungerar som ett virtuellt rack, vilket användaren fyller med valfria moduler av olika slag:syntar, samplers, trummaskiner och effekter. Den enda begränsningen på hur många modulersom kan användas samtidigt är datorns prestanda.

Syfte och problemdefinitionReasons primära målgrupp är inte nybörjare, utan snarare redan syntintresserade hobby- ochprofessionella musiker. Den grundläggande designen gjordes så tidigt som 1998 och vissaförutsättningar har sedan dess förändrats:

• den nya generationen användare har mindre erfarenhet av hårdvaran som gränssnittetbaseras på

• allt fler användare med mindre musikalisk och teknisk erfarenhet, det vill säganybörjare, vill använda datorn som ett musikaliskt verktyg

• Propellerheads är idag mer erfarna utvecklare än man var 1998, och vissa designbeslutsom togs då skulle man idag göra annorlunda

Bild 4: Reason

Page 8: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bakgrund

4

För att möta dessa nya krav hos marknaden arbetar Propellerheads därför kontinuerligt medutveckling av Reason. Syftet med detta examensarbete är att genom användartester mednybörjare identifiera vilka områden i programmet som är mest problematiska, samt att ta framdesignförslag för hur problemen kan minimeras. Eftersom Propellerheads tidigare inte arbetatmed användarcentrerade metoder eller användartester finns det också ett intresse att lära sig merom vad dessa kan ge för resultat.

De frågeställningar jag ska försöka besvara är:

• Vilka objekt eller funktioner är vid första mötet med applikationen svårast förnybörjaren att förstå?

• Hur kan Reasons gränssnitt förändras för att underlätta för nybörjare, utan attförändringarna stör mer erfarna användare?

AvgränsningarPropellerheads arbetar idag med personas (se Användarcentrerade metoder sid 7). Jag kommer idetta arbete endast att använda dessa personas för att kategorisera testpersonerna. Att ta framnya eller förfina de existerande personas ligger utanför denna rapport.

Musikprogram bör stödja användare med mycket skiftande musikalisk erfarenhet och datorvana(Hunt 2000, sid 178), vilket innebär att designförslag riktade mot nybörjare inte får hindra ellerstöra mer avancerade användare. Tillagd funktionalitet och stöd för nybörjare måste därför varalätta att välja bort för. Det gäller att ”inte sätta stödhjul på programmet” (Cooper & Reimann2003).

Förutom att ta hänsyn till mer erfarna användare har jag i mina designförslag även tagit hänsyntill Reasons speciella karaktär och kärnvärden. Propellerheads är intresserade av inkrementellaförändringar av gränssnittet, inte förslag på ett nytt musikprogram för nybörjare.

Arbetet kommer inte att resultera i en färdig applikation, utan kommer att presenteras i form avdenna rapport samt designskisser.

Page 9: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Teori

5

TeoriI denna del redogörs för teoribildning och begrepp inom ämnet människa-

datorinteraktion, med speciellt fokus på musikapplikationer.

Människa- datorinteraktionDetta examensarbete är skrivet inom ämnet människa- datorinteraktion (MDI, på engelskaHuman Computer Interaction – HCI). Inom ämnet studerar man hur människor och datorerinteragerar, och hur interaktionen på olika sätt kan förbättras. Interaktionen mellan människaoch dator skapas i mjukvarans gränssnitt. I takt med att datorer blivit allt vanligare i samhällethar andelen användare utan teknisk bakgrund ökat, och användarnas bakgrund är dessutom mervarierad. Inom mjukvaruindustrin har därför alltmer fokus och resurser lagts på gränssnittetmellan människa och dator. Detta speglas till exempel i att gränssnittet idag utgör ca 50% avkoden och minst 29% av budgeten i ett mjukvaruprojekt (Ferreira et al 2005). Ämnet ärtvärvetenskapligt och innefattar discipliner som psykologi, datalogi, design, ergonomi, etnografimed mera.

Användbarhet

För att ett system ska fungera bra ska det ha rätt funktionalitet (”utility”) och vara användbartför en användare (”usability”). Användbarhetär ett centralt begrepp inom MDI, även om termengår att applicera på i princip vilken teknisk artefakt som helst. Till exempel har MDI-forskarenDonald Norman skrivit en inspirerande bok om hur vardagens bruksföremål är designade(Norman 2002). Användbarhet är ett mångfacetterat begrepp som forskare och yrkesverksammahar svårt att enas om vad det egentligen innebär. Denna ambivalens genomsyrar även hantverketmed att ta fram ett väl fungerande gränssnitt, vilket gör att gränssnittsdesign fortfarande ligger igränslandet mellan konstnärlig och vetenskaplig verksamhet (Ferreira et al 2005). Det existerardock olika förslag på definitioner av användbarhet. Enligt den internationella standardenISO9241-11:1998 är användbarhet:

…den utsträckning till vilken en specificerad användare kan använda en produkt för

att uppnå specifika mål, med ändamålsenlighet, effektivitet och tillfredsställelse, i ett

givet användningssammanhang. (Gulliksen & Göransson 2002)

Detta låter ju onekligen önskvärt, men säger egentligen inte så mycket om hur en mjukvara skavara utformad för att uppnå dessa mål. Jakob Nielsen ger lite mer kött på benen i en lista medkvalitetsattribut som användbar mjukvara bör uppfylla i så hög grad som möjligt (Nielsen1993):

• Lätt att lära – hur lätt är det för användaren att utföra enkla arbetsuppgifter förstagången de använder systemet?

• Effektivt – när användaren lärt sig systemet, hur snabbt kan de utföraarbetsuppgifterna?

• Lätt att komma ihåg – hur snabbt går det att sätta sig in i systemet efter en tidsfrånvaro?

• Få fel – hur många fel gör användaren, hur allvarliga är dessa och hur lätt kananvändaren återhämta sig från felen?

• Tilltalande utformning – hur tilltalande är det att använda systemet?

I folkmun pratar man ofta att program ska vara användarvänliga, men denna term är alltförallmän för att säga någonting om ett system. För det första behöver användaren enligt Nielseninte ett system som är ”vänligt”, utan ett system som hjälper henna att utföra sitt arbete. Olikasystem har olika användare, och vad som är ”vänligt” för en person behöver inte nödvändigtvis

Page 10: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Teori

6

vara det för en annan. Cooper & Reimann (2003), som har en mindre akademisk och merpraktisk inställning till mjukvarudesign, hävdar dock att mjukvara ofta är oförskämd (”rude”)mot användaren. Formuleringar i felmeddelanden kan få användaren att tro att hon gjort fel, ochnedlåtande frågor som ”Är du säker?” när användaren vill utföra en destruktiv dataoperation kange användaren en känsla av att bli bedömd av systemet. Enligt Cooper & Reimann är en av deviktigaste aspekterna hos interaktiva produkter överhuvudtaget att inte få användaren att kännasig dum, vilket kanske skulle kunna kopplas tillbaka på begreppet användarvänlighet.

Interaktiva system kan vara allt ifrån banksystem till datorspel. Användbarhetsstudier hartraditionellt varit mer fokuserade på professionella användare och funktionella aspekter påsystemen (Jordan et al 1996). Kraven som ställs på system som används i arbetet respektive somhobby är dock något olika. Jämför till exempel kraven som ställs på ett kalkylprogram och ettdatorspel. Förutom ”ren” användbarhet finns det en dimension kring användarens upplevelse avsystemet, nämligen hur tillfredställande, kul, belönande eller liknande användaren tycker(Preece et al 2002). Reason och andra musikprogram används både som professionella verktyg imusikstudios, med höga krav på användbarhet, men måste också leverera en underhållande ochkreativt stimulerande upplevelse för hobbymusikern.

Användarcentrerad systemutveckling

Utgångspunkten för användarcentrerade metoder är att användarens behov, mål och egenskaperska diktera hur tekniska system tas fram och designas. Detta i motsats till att låta ingenjörersidéer eller tekniken i sig, till exempel ett speciellt sätt att programmera, utgöra målet förteknikutvecklingen. Utvecklarnas mentala modell av systemet influeras ofta undermedvetet avtekniska hänsyn, och stämmer kanske dåligt överens med slutanvändarnas mål och mentalamodell. Ett klassiskt exempel där utvecklarna inte reflekterat över användarnas mål varfilhanteraren i Windows 3.x, där ledigt hårddiskutrymme presenterades i antal kilobyte. Tillexempel kunde det stå:

C: 231,728KB free, 1,047,248KB total

En vanlig användare var knappast intresserad av att veta exakt hur många lediga kilobyte somfanns, utan ville snarare veta om hårddisken höll på att bli full. En jämförelse mellan dettillgängliga och totala utrymmet, uttryckt i procent, hade varit mer användarcentrerat (Cooper &Reimann 2003).

Begreppet användarcentrerad systemutveckling myntades av Donald Norman (1986) som skrev:

”[…] user-centered design emphasizes that the purpose of the system is to serve the

user, not to use a specific technology, not to be an elegant piece of programming.

The needs of the users should dominate the design of the interface, and the needs of

the interface should dominate the design of the rest of the system.”

Precis som med begreppet användbarhet råder det även olika uppfattningar om vadanvändarcentrerad systemutveckling egentligen är. Olika författare kallar disciplinen UsabilityEngineering (Nielsen), Human-Centered Design (ISO 13407), Goal-Directed Design (Cooper),Contextual Design (Beyer & Holtzblatt) och så vidare. Gulliksen et al (2003) har av dessa olikatolkningar sammanställt tolv principer som är utmärkande för ett användarcentrerat synsätt påsystemutveckling:

1. Användarfokus – aktivitetens mål, arbetets domän eller kontext, användarens mål,uppgifter och behov ska tidigt styra utvecklingen

2. Aktivt användardeltagande – representativa användare ska aktivt delta, från startgenom hela utvecklingsprocessen och systemets livslängd

3. Evolutionär systemutveckling – systemutvecklingen ska vara både iterativ ochinkrementell

4. Enkla designrepresentationer – designen måste representeras på ett sådant sätt att denkan förstås av användare och alla intressenter

Page 11: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Teori

7

5. Prototyper – prototyper ska tidigt och kontinuerligt användas för att visualisera ochutvärdera idéer och designlösningar i samarbete med användarna

6. Utvärdera användandet i sitt sammanhang – användbarhetsmål och designkriterierska styra utvecklingen

7. Explicita och medvetna designaktiviteter – utvecklingsprocessen ska innehållaspeciella designaktiviteter

8. Professionell attityd – utvecklingsprocessen ska utföras av effektiva tvärvetenskapligaprojektgrupper

9. Användbarhetsexpertis – användbarhetsexperter ska vara involverade tidigt ochgenom hela utvecklingsprocessen

10. Holistisk design – alla aspekter som påverkar det framtida användandet av systemetska utvecklas parallellt

11. Processanpassning – en användarcentrerad process måste specialiseras, anpassasoch/eller implementeras lokalt för varje situation

12. En användarcentrerad inställning ska alltid etableras

För mindre projekt kan en delmängd av dessa principer vara realistiska att använda sig av.Tvärvetenskapliga projektgrupper med användbarhetsexperter förutsätter ofta större projekt.

Användarcentrerade metoder

Vilka metoder står då till ens förfogande som användarcentrerad systemutvecklare? Enskiljelinje går mellan kvalitativa och kvantitativa metoder. De senare syftar till att få frammätbara värden på interaktionen, till exempel hur lång tid det tar att utföra en uppgift i ettgränssnitt jämfört med ett annat. Kvantitativa metoder innebär ofta användbarhetstestning(”usability testing”) och har sin grund i klassisk positivistisk vetenskapstradition. Fokus liggertill stor del på användarens uppgifter (”tasks”) och i litteraturen hämtas oftare exempel frånstora IT-projekt snarare än från konsumentvaror eller underhållning. För att minimera störandefaktorer som kan påverka testresultatet utförs testerna företrädesvis i laboratoriemiljö, ochresultaten behandlas med statistiska metoder för att garantera tillförlitlighet och validitet.Variabler som kan testas är bland annat tiden det tar att utföra en viss uppgift, förhållandetmellan lyckade interaktioner och fel, antal funktioner som användes eller inte användes, hurmycket dödtid som uppstod med mera (Nielsen 1993). Kritik som riktats mot kvantitativametoder är att de besvarar frågor som ”hur länge?” eller ”hur ofta?” men inte säger någontingom ”hur?” eller ”varför?”. När man beskriver mänskligt beteende med metoder som utvecklatsinom främst fysiken är risken stor att man förlorar viktiga nyanser som kan vara avgörande föratt förstå användarna och deras mål. Det finns ett flertal kvalitativa undersökningsmetoder somutvecklats inom antropologi och etnografi. Cooper & Reiman (2003) lyfter fram de metoder deanser är de mest fruktsamma i de designprojekt där de varit konsulter:

• Intressentintervjuer – intervjuer med uppdragsgivaren och andra intressenter iföretaget för att förstå deras vision av produkten, tekniska och ekonomiska hänsyn förprojektet samt företagets bild av användaren.

• Domänexpertintervjuer – domänexperterna kan vara uppdragsgivarna eller anställdainom företaget. De är experter men inte designers, så deras lösningsförslag är oftastmest intressanta som förtydliganden av problemen.

• Kund- och användarintervjuer – utanför konsumentbranschen är kunden (inköparen)ofta någon annan än slutanvändaren. Intervjuer med kunden är viktiga för att förstådennes mål med införskaffandet av produkten, medan användarens mål, arbetsflöde ochkontext är det centrala för designarbetet.

• Användarobservation – att prata om hur man använder en produkt är inte samma saksom att använda produkten. Ofta har användaren så kallad tyst kunskap som intekommer fram vid intervjuer eftersom den ofta är på gränsen till undermedveten. Cooper& Reimann framhåller en blandning av observation och intervju som det kanske mesteffektiva sättet att samla in kvalitativa data (se Metod sid 13).

Page 12: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Teori

8

• Litteraturstudier – designteamet bör läsa allt tillgängligt material i form avmarknadsplaner, manualer, specifikationer och liknande för att generera frågor att ställaintressenter och domänexperter.

• Produkt- och konkurrentstudier – parallellt med intervjuerna kan det vara värdefulltatt studera och utvärdera prototyper, tidigare versioner eller konkurrerande system föratt bilda sig en uppfattning om standards och vad som ligger i framkanten avutvecklingen.

En vanligt förekommande metod inom marknadsföring är fokusgrupper, där ett antalrepresentativa användare samlas i ett rum och utfrågas och diskuterar tillsammans. Som verktygför designprojekt är fokusgrupper dock mindre effektiva eftersom de är frikopplade från självaanvändandet av produkten, och den sociala situationen gör att deltagarna söker konsensus. Inomen gren av användarcentrerad systemutveckling kallad Participatory Design vill man attanvändarna tillsammans med utvecklarna designar systemen (Preece et al 2002). Inom dennagren ordnar man ofta workshops, det vill säga strukturerade designsessioner där användare ochutvecklare tillsammans tar fram och utvärderar prototyper.

Det finns även användarcentrerade metoder som inte direkt befattar sig med användarna. I enheuristisk utvärdering utgår man från checklistor baserade på användarens kognitivaegenskaper och sunt förnuft. Heuristiska regler som gränssnitt bör följa är (Nielsen 1993):

• Enkel och naturlig dialog – logiskt ordnad och relevant information• Tala användarens språk – använd för användaren välkända begrepp och termer• Minimera användarens minnesbelastning – användaren ska inte behöva komma ihåg

information, den ska vara synlig när den behövs• Konsistent utformning – användaren ska inte behöva fundera på om olika begrepp

eller funktioner betyder samma sak• Återkoppling – systemet ska alltid visa sin status och vad som händer• Tydliga ”utgångar” – användaren ska alltid enkelt kunna avbryta eller ångra en

funktion• Kortkommandon – kortkommandon hjälper experanvändaren att jobba mer effektivt• Konstruktiva felmeddelanden – felmeddelanden ska i vanlig text, utan felkoder,

beskriva problemet och föreslå en lösning• Förhindra fel – systemet ska i första hand dock minimera antalet fel• Hjälp och dokumentation – även om det är bättre ifall systemet fungerar utan hjälp

och dokumentation är den ibland nödvändig. Den ska då vara lätt sökbar, fokusera påanvändarens uppgifter, lista konkreta åtgärder och inte vara alltför omfattande.

Heuristiska utvärderingar utförs av användbarhetsexperter. För att upptäcka så många fel sommöjligt låter man ofta flera experter utvärdera samma system.

En annan metod är att skapa personas. Personas är fiktiva men detaljerade arketypiskaanvändare och är ett bra verktyg för att inom projektet kommunicera vem man designar för(Cooper & Reimann 2003, Gulliksen et al 2003). Personas baseras på intervjuer ochobservationer av riktiga användare. De är inga medelvärden, utan representerar olikaanvändargrupper med distinkta beteenden och mål. Eftersom man till exempel inte kan designaen bil som tilltalar alla bilförares behov väljer man ut en primär persona att designa för. NärDodge testade sin Ram-pickup i en fokusgrupp var det 80% som ogillade den. Företaget gickvidare ändå eftersom 20% älskade modellen, och bilen blev en försäljningssuccé (Cooper 1999).För en diskussion kring hur Propellerheads arbetar med personas se Definition och rekryteringav nybörjare på sid 14.

Page 13: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Teori

9

Formge för nybörjare eller experter?De flesta interaktiva system måste stödja alltifrån nybörjare till expertanvändare. Ta till exempelMicrosoft Word, som används både av kontorspersonal för avancerad formatering avexempelvis rapporter, och samtidigt av den mindre datorkunnige hemanvändaren som någongång vill göra en inbjudan till ett födelsedagskalas. Programmet måste samtidigt stödja bådadessa typer av användare. Undantag finns, kanske främst inom så kallade walk-up-and-use-system (informationskiosker, biljettautomater med mera), där inlärningstiden i princip måstevara noll eftersom användaren oftast bara kommer att använda systemet vid ett enda tillfälle.

I Nielsens definition av användbarhet (seAnvändbarhet sid 5) är ”Lätt att lära” den förstaoch kanske viktigaste delen, eftersom allaanvändare någon gång är nybörjare. Nielsenverkar se inlärningskurvan från nybörjare tillexpert som endast en funktion av tiden, och attmålet för alla användare är att i slutändan blisupereffektiva expertanvändare. Han höjer ocksåett varningens finger för att ett alltför stort fokuspå nybörjaranvändarna i och för sig kan gekortsiktiga vinster vad gäller inlärningen, menockså kan hämma expertanvändaren i det långaloppet genom lägre effektivitet (se figur 1).Cooper & Reimann (2003) har å sin sida en enligtförfattaren mer nyanserad bild av hur en populationanvändare ser ut och för vem man ska designaprogrammet. De delar in användarna i nybörjare,medelanvändare (intermediates) ochexpertanvändare. Nybörjaranvändare är man bara ettkort tag, för ingen vill ju vara nybörjare ochinlärningstiden är oftast kort i förhållande till heladen tid man kommer att använda programmet.Expertanvändarna är också ganska få, för få personeranvänder program så ofta och mycket att de blirriktiga experter. Experterna är heller inte experter pålivstid. Ofta använder man ett program mycket underen viss tidsperiod, och blir rätt duktig på det. Men är man borta ett tag glömmer man oftatypiska expertbeteenden som kortkommandon och olika knep. Kvar finns alltså en stor gruppmedelanvändare, och det är denna grupp som Cooper & Reimann menar att man ska designa för(se figur 2). De gör en jämförelse till ett skidområde: ja, det finns en nybörjarbacke, och ja, detfinns några svarta pister, men mest finns det mellansvåra pister som tilltalar majoriteten avskidåkarna.

Vilken typ av funktioner passar då för de olika grupperna? Nybörjaren behöver ofta hjälp att fåen konceptuell förståelse och överblick över programmet. Denna hjälp behövs bara precis ibörjan, och ligger sedan antagligen i vägen för mer avancerade användare. Därför får dennahjälp inte vara en fast del i programmet, utan gå att ta bort eller stänga av. De vanligastehjälpsystemen är referensmaterial och fungerar som uppslagsböcker. Dessa förmedlar oftastingen översikt och passar därför bättre för medel- eller expertanvändare. Cooper & Reimannföreslår en guide i ett separat fönster, som berättar om programmets olika delar och verktyg. Förmedelanvändaren, som förstår programmets omfång och olika delar, är tooltips den perfektahjälpen. De är inte i vägen eller förklarar sånt användaren redan vet, utan ger bara en kortfattadbeskrivning av den aktuella funktionen. Medelanvändaren vill ha sina vanligast användaverktyg synliga och lätt åtkomliga, och vill samtidigt veta att det finns mer avancerade

Figur 2: Användare (Cooper &

Reimann 2003 sid 38)

Användarnas nivå

An

tal

Nybörjare Medel Experter

Figur 1: Inlärningskurvor

(Nielsen 1993 sid 28)

Tid

Användare

ns k

unskap

oc

h e

ffe

kti

vit

et

Nybö

rjarfo

kus

Expertfokus

Page 14: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Teori

10

funktioner om hon behöver dem. Expertanvändaren å sin sida använder ofta programmet fleratimmar om dagen och vill ha snabb åtkomst till de flesta delar i programmet. Därför ärkortkommandon och stöd för egendesignade makron typiska stöd för expertanvändarna.

MDI och musikUtveckling och design av musikrelaterade produkter, både hårdvaru- och mjukvarubaserade, harfått relativt lite uppmärksamhet i MDI-litteraturen (Fernandes & Holmes 2002, Seago, Holland& Mulholland 2004). Detta är i författarens ögon en smula paradoxalt, eftersom domäneninnefattar många modaliteter och är rik på interaktionsmöjligheter. Förutom den vanligainteraktionen med mus, skärm och tangentbord kräver musikdomänen för det första output iform av ljud, och olika inputenheter som MIDI-klaviaturer och -kontroller, trumpads och olikahaptiska gränssnitt är vanligt förekommande.

Ställs det då några speciella krav på musikrelaterade interaktiva system? I en studie från 1995kring Computer Music Systems (CMS) analyserade Polfreman & Sapsford-Francis hurkompositörer arbetade med mjukvara (Seago, Holland & Mulholland 2004). De identifierade ettantal arbetssätt och drog slutsatserna att designers av musikrelaterad mjukvara måste ta hänsyntill stora skillnader mellan de olika kompositörernas arbetssätt. De rekommenderade också attmusikprogram måste stödja användare med olika musikalisk bakgrund och skolning genom att

• erbjuda mer än en typ av interaktion• ”gömma” oönskad komplexitet• tillhandahålla ett hjälpsystem

Andy Hunt (2000) tittar i sin avhandling närmare på olika gränssnitt för realtidskontroll avmusik. Han identifierar fem olika interaktionsmetaforer för musikaliska applikationer, därReason hamnar i kategorin ”Graphic Sound and Score Designer”. Vidare kritiserar han ävenMDI-forskningens fokus på ”ease-of-use” till exempel Ted Nelsons 10-minutersregel som sägeratt ett system som inte går att lära ut på tio minuter är för komplicerat. Han påpekar att musikerägnar åratal av träning åt att bemästra svåra gränssnitt som till exempel klarinetten. Risken medett alltför stort fokus på ”ease-of-use” vad gäller realtidskontroll av elektroniskamusikinstrument är enligt honom att man undervärderar människans förmåga att lära ochanpassa sig, samt de möjligheter ett svåranvänt gränssnitt kan ha för den som bemästrar det. Enslutsats av hans användartest var att komplexa uppgifter kräver komplexa (multiparametriska)gränssnitt, eftersom användarna presterade bättre på svåra uppgifter än på lätta när de användekomplexa gränssnitt. En liknande argumentation står Nigel Derrett för, då han något skämtsamtanalyserar fagottens gränssnitt utifrån heuristiska användbarhetskriterier (2004). Han formuleraräven en ”Heckels’s lag” (döpt efter den moderna fagottens uppfinnare) som säger attgränssnittets roll i huruvida användare tar till sig ett system eller inte är omvänt proportionelltmot systemets upplevda värde.

Fernandes och Holmes (2002) utför en heuristisk utvärdering samt användartester på en gitarr-preamp, men studien tar inte upp några unika aspekter från musikdomänen och hade lika gärnakunna handlat om en fjärrkontroll. Biddle och Noble (2001A, 2001B) har analyserat huranvändare konstruerar program (eller ”patcher”, se avsnitt Reason grafiska gränssnitt nedan) förden virtuella modulsynten Nord Modular (Clavia 2006). Nord Modulars gränssnitt har storalikheter med Reasons, med atomära ljudmoduler som kopplas ihop med virtuella sladdar. Biddleoch Noble betraktar denna typ av interaktion som ett visuellt programmeringsspråk, ochanvänder olika visualiseringstekniker för att illustrera olika drag och tendenser i användarnasprogrammeringsstil, och analyserar vidare hur dessa påverkar till exempel ”debugging” av enpatch. De har också, tillsammans med Matthew Duignan med flera (Duignan et al 2004), gjorten jämförande studie av hur Reason och ett annat musikprogram, Ableton Live (Ableton 2006)använder sig av metaforer. I sin analys tittar de på vilka metaforer som finns i de respektivegränssnitten och hur de uppfyller av författarna framtagna heuristiska krav. Till exempel låsermetaforen ”Reason är ett rack” användaren till att ordna sina enheter i en endimensionell lista.

Page 15: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Teori

11

De ställer sig samma fråga som Propellerheads: hur många av framtidens musiker kommer attha erfarenhet av hårdvara, och därigenom bli hjälpta av Reasons metaforer?

Reasons grafiska användargränssnitt

Reasons grafiska användargränssnitt bygger på en stark och konsekvent metafor (eller analogi)till fysiska hårdvaruenheter samlade i ett virtuellt 19-tumsrack (bild 1 sid 4). Till skillnad frånPropellerheads tidigare program ReBirth är dock Reasons enheter inte exakta kloner avexisterande hårdvara, även om de i vissa fall lånar drag och egenskaper av dem. Till exempellånar Reasons mixer (längst upp i bild 1 sid 4) sin färgsättning och layout från företagetMackies hårdvarumixers (Mackie 2006).

Att designa mjukvara med hjälp av metaforer till fysiska motsvarigheter är mycket vanligt och imånga fall framgångsrikt. Ett klassiskt exempel är papperskorgen som finns i ett flertaloperativsystem. Fördelarna med denna metod är att användaren kan lära sig och utföra en nyhandling (”radera en fil från hårddisken”) genom att utnyttja kunskap de redan har från denfysiska världen (”slänga något i papperskorgen”) (IBM 2006, Nielsen 1993, Preece et al 2002).Metoden är dock inte helt oproblematisk. Ofta gör översättningen från den fysiska till dendigitala världen att det uppstår logiska eller kulturella motsättningar. I skrivbords- ochpapperskorgsfallet så står ju papperskorgen oftast under och inte på skrivbordet. Ettmotargument mott detta är dock att det inte spelar någon roll så länge användaren förstår varförpapperskorgen på skärmen måste stå på skrivbordet och inte under. Metaforer kan också varabegränsande. Skrivbordsmetaforen kan göra det svårt att lokalisera en speciell fil på ett överfylltskrivbord, där textsökning kanske hade gått snabbare. Som tur är går ju metaforer att utöka, såatt de drar fördel av att vara digitala och inte bara blir elektroniska representationer av fysiskaobjekt. I Reason kan till exempel alla enheter fällas ihop till en tunn list för att spara plats iracket och därigenom minimera scrollning (se bild 4 sid 3 samt bild 5). Detta är ett beteendesom ett vanligt 19”-rack naturligtvis inte klarar av och bryter därför på ett sätt mot metaforen,men en vedertagen sanning inom gränssnittsdesign är att man aldrig bör sätta begränsningar påmjukvarans funktioner på grund av den valda metaforen (IBM 2006, Cooper & Reimann 2003).

Användaren skapar de enheter han vill arbeta med genomatt välja dem i en meny. Enheterna kopplas automatiskt intill en kanal på mixern eller inom en signalkedja beroendepå vilken enhet som var markerad när den nya enhetenskapades, så kallad auto-routing. Denna auto-routingfungerar för de vanligaste kopplingarna, men genom atttrycka på TAB-tangenten kan användaren ”vända” på racketoch själv koppla ihop de olika enheterna med virtuellasladdar på enheternas baksida (se bild 5). Förutom ljud kanenheterna även kopplas ihop med CV-sladdar för att styraen mängd olika parametrar mellan enheterna.

Alla instrumentenheter och vissa effektenheter kan laddasmed färdiga ljud, så kallade patcher. Patcherna finns iljudbanker kallade Refills. Reason levereras med två Refills,Reason Factory Sound Bank och Orkester [sic] Sound Bank,men både Propellerheads och olika tredjepartstillverkareskapar och säljer ytterligare Refills. Patcherna i Refills ärhierarkiskt ordnade i ett mappsystem och laddas med hjälpav en browser, ett modalt fönster liknande WindowsUtforskaren (se bild 6). Browsern har vissa hjälpfunktionersom är tänkta att underlätta ljudväljandet: entextsökfunktion, Autoplay för att provlyssna på samples ochloopar, ett filter som filtrerar bort patcher som inte passarden aktuella enheten samt ett system för att skapa

Bild 5: Rackets baksida

Bild 6: Browsern

Page 16: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Teori

12

favoritlistor. Förutom att leta och välja instrumentpatcher används browsern även till att laddasånger, effektpatcher, och enskilda samples.

Ifall en enhet laddas med en patch som inte passar, tillexempel ett Redrum-trumset laddas i en Subtractor, kommerSubtractorn att bytas ut mot en Redrum. Denna teknik kallascrossbrowsing.

Förutom racket med dess olika ljudenheter har Reason ensequencer där MIDI-data kan spelas in och redigeras (bild7). Sequencern har två huvudlägen eller modes: Arrangeoch Edit Mode. I Arrange Mode presenteras alla spår i enlista till vänster, samt en översikt över vad varje spårinnehåller i form av note on-meddelanden (hädanefterkallade toner) och automation. Innehållet kan grupperas,flyttas, kopieras och raderas, vilket gör Arrange Modelämpligt för att överblicka och ändra strukturen i musiken.

I Edit Mode (bild 8) tittar man däremot på innehållet i ettindividuellt spår i taget. Innehållet kan presenteras på olikasätt genom att man väljer att visa olika lanes: Key Lane föratt se toner utifrån ett vertikalt pianotangentbord, VelocityLane för att se tonernas anslagsstyrka, Pattern Lane för attse automatisering av rytmbyten etc. Här finns möjligheteratt in i minsta detalj redigera det musikaliska innehållet.

Två av instrumentenheterna, trummaskinen Redrum ochstegsequencern Matrix har förmågan att inuti själva enhetenhantera musikaliskt material i form av små (0-ca 4 takterlånga) patterns (hädanefter kallade mönster) som upprepas.Materialet skapas i enheten och kan sedan exporteras tillenhetens sequencerspår för att lättare kunna redigeras, ellerså låter användaren sequencern styra enhetens uppspelningav mönstren.

Bild 7: Arrange Mode

Bild 8: Edit Mode med Key

Lane, Velocity Lane samt

två Controller Lanes

Page 17: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Metod

13

MetodDetta avsnitt behandlar vilka metoder som använts i examensarbetet, varför de valts

samt hur de påverkat resultatet.

Arbetet har utförts i tre faser. I den första fasen utfördes en serie användartester för att skapaförståelse för hur nybörjare går tillväga för att lära sig Reason, samt för att identifieraproblemområden i programmets gränssnitt. I den andra fasen utvecklades ett antaldesignförslag, baserade på kunskaperna från första fasen. I arbetets tredje och sista fasutvärderades och modifierades designförslagen i samarbete med användare.

Fas 1: Explorativa användartesterEtt önskemål från Propellerheads och därmed en grundförutsättning för projektet, var att viskulle utföra någon typ an användartester. I denna fas av examensarbetet samarbetade jag medinteraktionsdesignern Björn Johansson, som sedan tidigare var engagerad som konsult avPropellerheads. Syftet med användartesterna var att få en bild av hur nybörjaranvändare gårtillväga för att lära sig Reason, samt att identifiera de största problemområdena i gränssnittet fördenna typ av användare.

Den metod som verkade passa våra syften och resurser bäst var någon form av kvalitativdeltagande intervju, även kallad Contextual Inquiry (Beyer & Holtzblatt 1998). Nielsen (1993)beskriver den närliggande Think Aloud-metoden som att den ”may be the single most valuableusabilty engineering method”. Contextual Inquiry bygger på ett mästare/lärling-förhållandemellan testpersonen och intervjuaren, där testpersonen är den kunnige hantverkaren ochintervjuaren den frågvisa nybörjaren. Metoden bygger på fyra principer:

• Kontext: Istället för att observera användaren i något sterilt användbarhetslaboratoriumska intervjuerna eller observationerna genomföras i användarens normala arbetsmiljö,eller den miljö som är aktuell för produkten. Att intervjua användaren i dennes naturligamiljö och kontext kan skapa ökad förståelse för hur användandet verkligen ser ut.Svarar testpersonen i telefon mitt i ett arbetsmoment? Antecknar testpersonen på papperför att komma ihåg? I vår studie utfördes intervjuerna i användarnas hem, och i ett fallpå användarens arbetsplats.

• Partnerskap: Intervjun/observationen bör utformas som en kollaborativ utforskning avanvändarens arbete, och växla mellan observation och utfrågning. Andra former avrelationer som intervjuare/intervjuad, expert/nybörjare eller gäst/värd bör undvikas. Ivårt fall, då vi studerade nybörjare, innebar detta att vi som observatörer fick försökalåtsas att vi inte heller hade prövat Reason. Varje felaktig tolkning som användarengjorde följdes upp och analyserades som om den varit korrekt.

• Tolkning: En stor del av arbetet går ut på att sammanställa observationer, kontext ochvad användarna säger, och ur detta material göra tolkningar som kan ligga till grund fördesignförändringar. Man får dock vara försiktig och inte gå endast på lösa antaganden,utan korrelera dessa med användarna.

• Fokus: Istället för att ha ett färdigt frågeformulär eller låta användaren jobba på heltfritt bör observatören fokusera arbetet på det som kan vara viktigt för studien. I Reasonär ett roligt moment att testa alla tusentals ljud som finns i ljudbankerna. Om enanvändare verkade fastna i detta kunde vi till exempel föreslå att vi skulle gå vidare ochspela in ljudet.

Page 18: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Metod

14

Denna form av Contextual Inquiry är främst framtagen för stora projekt inom näringslivet, tillexempel bank- eller affärssystem. Cooper & Reimann (2003) föreslår ytterligare några punkterför att förfina metoden och anpassa den till mindre och mer konsumentinriktade produkter:

• Kortare intervjuer: Contextual Inquiry förutsätter dagslånga intervjuer medanvändarna. Cooper & Reimann hävdar att ungefär timslånga intervjuer ger tillräckligadata, förutsatt att man gör ungefär 4-6 tester för varje egenskap (se Definition ochrekrytering av nybörjare nedan). Det är lättare och mer effektivt att hitta användare somär villiga att ställa upp för en timmes intervju än för en hel dag, och dessutom får manstörre demografisk spridning.

• Mindre designteam: Contextual Inquiry bygger på att ett stort designteam utförparallella intervjuer och sedan redovisar dessa för varandra. Cooper & Reimann föreslåristället att ett mindre designteam på 2-3 personer utför testerna sekventiellt, så att allafår uppleva alla och samma tester.

• Identifiera målen först: Istället för att fokusera på användarens arbetsuppgifter börman istället fokusera på användarens mål med arbetet, som arbetsuppgifterna sedan skaförverkliga.

• Se bortom affärsvärlden: Etnografiska studier som Contextual Inquiry kan varavärdefulla även för konsumentprodukter. Dock är det viss skillnad vad gäller fokus påfrågeställningarna. En viktig aspekt för Reason är till exempel att det ska vara roligt attanvända och stimulera kreativitet, vilket kanske inte gäller ett banksystem.

Definition och rekrytering av nybörjare

För att kunna utföra användartesterna behövde vi identifiera och rekrytera ett antal personer sompå ett ungefär motsvarade potentiella Reasonanvändare. Deras gemensamma drag skulle vara attde var intresserade av att skapa egen musik, samt att de aldrig använt Reason. Förutom detta vardet önskvärt med en relativt stor spridning vad gäller musikalisk erfarenhet och preferenser,datorvana, ålder och kön med mera.

På Propellerheads arbetar man idag utifrån fyra hypotetiska personas som tagits fram genominterna diskussioner. Dessa är inte baserade på den relativt rigorösa metodik som föreslås avCooper & Reimann (2003), utan har mer karaktären av kundsegmentering av existerande ochpotentiella användare. I korthet kan de beskrivas som:

1. Reasonanvändaren Reasonman är en medel- eller expertanvändare2. Switcher äger annan musikteknik men har blivit rekommenderad Reason3. musikern Muso kan datorer men har aldrig gjort musik med datorprogram4. Mia som är DJ vet vad som låter bra, men är i övrigt musikalisk novis

Propellerheads önskan var att testa personer med Musos eller Mias bakgrund, men eftersomderas personas inte tagits fram baserat på användarstudier, och därmed kanske inte representerarnybörjaranvändare fullt ut, valde vi att gå en annan väg. För att definiera den något vaga termen”nybörjare” och hitta lämpliga testpersoner delade vi istället upp potentiella testpersoner efterderas domänspecifika och tekniska expertis (Cooper & Reimann 2003 sid 47, Nielsen 1993 sid44). Domänexpertisen består av musikaliska kunskaper som till exempel att kunna spela ettinstrument, musikteori, kunskap om taktarter, harmonilära, terminologi med mera. Tekniskexpertis består dels av allmän datorvana (ordbehandling, e-postprogram etc.) och dels averfarenhet av andra musikprogram. Personer utan datorvana var mindre intressanta för studien,eftersom dessa troligtvis inte är potentiella Reasonanvändare.

Page 19: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Metod

15

Denna uppdelning resulterade i en matris med fyra celler (tabell 1) i vilka Propellerheadspersonas går att placera ut på ett ungefär. Personan Mia motsvaras av två olika kategorier, vilketgör att den får delas upp i Mia typ 1 respektive typ 2.

Allmäntdatorvan

Använt andramusikprogram

Musikalisktkunnig

! Muso ! Switcher min 5 st.

Musikalisknovis

! Mia (1) ! Mia (2) min 5 st.

min 5 st. min 5 st.

Tabell 1: Olika kategorier av nybörjare

Hur många testpersoner behövde vi då rekrytera? I MDI-kretsar är det en vedertagen sanning attdet vanligtvis räcker med att testa med ungefär 5 personer, och att man efter dessa fem testerinte upptäcker så många nya fel eller problem (Nielsen 1993). Eftersom vi hade fyra olikagrupper att testa skulle detta innebära sammanlagt 20 testpersoner. Cooper & Reimann hävdardock att det räcker om man utför 4-6 tester per egenskap (Cooper & Reimann 2003).Egenskaper motsvaras i detta fall av de fyra kategorierna

• Musikalisk novis• Musikaliskt kunnig• Allmänt datorvan• Använt andra musikprogram

Detta innebar att varje rad och kolumn i matrisen ska totalt innehålla minst fem st. testpersoneroch att det minsta antalet användartester därför kom att bli tio stycken.

Bakgrundsenkät

För att verifiera testpersonernas domän- och tekniska expertis fick de vid testtillfället besvara enmindre enkät med frågor kring deras datorvana, musikkunskap och attityd till Reason (se bilagaB). Enkäten utformades i enlighet med riktlinjer för enkätkonstruktion (Rubin 1994, Preece et al2002). Vi bestämde att det första testet delvis skulle fungera som pilotstudie. Om pilottestetresulterade i stora förändringar av testmetoden skulle resultaten bortses ifrån. Detta inträffadedock inte.

Ersättning

För att få testpersoner att ställa upp erbjöd Propellerheads dem ersättning i form av en Not ForResale-licens (NFR) på Reason. Denna licens är ett fullt funktionerande Reason medinstallationskivor, registreringskort, manualer och allt som ett vanligt Reason innehåller. Denenda skillnaden är att programmet inte går att uppdatera om/när Propellerheads släpper en nyversion. Värdet uppskattas till ungefär 4000 kr, vilket skulle vara en mycket bra betalning för ettpar timmars arbete. Därför kände jag att det fanns utrymme att knyta upp testpersonerna förytterligare aktiviteter inom ramen för mitt examensarbete. Detta inklusive vissa forskningsetiskahänsyn reglerades i ett användaravtal (se bilaga A) som testpersonerna fick läsa igenom ochskriva under innan testet började.

Rekrytering

Rekryteringen utfördes genom att projektets intressenter (Ernst Nathorst-Böös, Björn Johanssonoch författaren) gick igenom sina respektive bekantskapskretsar efter personer som motsvaradede kriterier vi ställt upp. Vi funderade ett tag på att rekrytera genom en webbenkät, men gjordebedömningen att det antagligen inte skulle vara värt besväret. Nackdelen med detta informella

Page 20: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Metod

16

sätt att rekrytera är att den demografiska spridningen kan bli för liten. Detta bedömdes docksom mindre relevant för vår studie så länge testpersonernas domän- och tekniska expertisstämde. E-postinbjudningar skickades ut inom Propellerheads samt på Medietekniks e-postlistapå KTH. För att undvika att användare av icke licensierade kopior av Reason skulle ställa upp itestet bara för att få en laglig licens nämnde vi inte ersättningens storlek i dessa utskick.

Genomförande

Metoden innebar att en testledare satt med användaren när hon använde Reason, och enobservatör förde anteckningar över vad som hände. Björn Johansson och jag växlade mellandessa roller. Eftersom Propellerheads var intresserade av användartesterna i sig deltog personalfrån företaget som observatörer vid tre tillfällen. Två av testerna utförde jag själv utanobservatör. För dokumentation användes även en videokamera som spelade in skärmbilden ochdialogen mellan testperson och testledare. Vi funderade på att använda ett video capture-program typ Snapz Pro X (Ambrosia Software 2006) som spelar in skärmbilden till en fil direkti datorn, men fick rådet av Propellerheads att detta ibland var svårt att köra samtidigt somReason.

Testerna utfördes i användarnas hem, och i ett fall på användarens arbetsplats (se Explorativaanvändartester sid 13). I möjligaste mån utförde vi testerna på testpersonernas egna datorer. I defall detta visade sig omöjligt på grund av datorns prestanda eller placering i lägenheten, tog vimed egna bärbara datorer. Förutom dator försåg vi även användarna med ett MIDI-klaviaturifall de inte hade ett. Testpersonerna hade naturligtvis tillgång till Reasons Getting Started-manual, utförlig dokumentation i pdf-format samt Internet (i alla fall utom två).

Testerna tog ca 1,5 till 2 timmar effektiv tid. På grund av bandbyte i videokameran blev det oftaen välbehövlig paus efter en timme. Testpersonerna instruerades först om testet och fick skrivapå ett avtal som reglerade videoupptagningen samt hantering av personuppgifter (se bilaga Aoch C). Sedan gavs de uppdraget att försöka skapa ett 10-20 s långt musikstycke i valfri stil ochfick starta programmet. Vi lät testpersonerna i möjligaste mån arbeta helt fritt och utan att vihjälpte dem. Syftet med studien var ju ändå att förstå hur användaren går tillväga för att lära sigprogrammet. Trots detta ville vi fokusera arbetet så att användarna hann testa så många delar iprogrammet som möjligt: skapa enheter och testa ljud, spela in, arrangera och mixa. Så om enanvändare körde fast på ett problem eller moment i mer än cirka femton minuter, eller verkadeså frustrerad att hon var på väg att avbryta testet, hjälpte vi henne vidare i programmet. På dettasätt belyste vi fler delar i programmet, men tappade viss information om hur allvarligtproblemet egentligen var. Vissa problem hade kanske tagit dagar för testpersonen att lösa. Föratt få testpersonerna att testa till exempel mixning gav vi dem ibland små uppdrag som ”Hurskulle du göra för att lägga ett eko på trummorna?”.

Efter testerna genomfördes en kortare intervju med testpersonerna kring hur de upplevt testet,samt vad som varit svårast respektive roligast.

Page 21: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Metod

17

Analys av materialet

För varje test genomfördes en analyssession, då vi tittade igenom videomaterialet och deproblem som testpersonerna råkat ut för sammanställdes till en lista. Fastän användaretesternautfördes explorativt och kvalitativt behövde vi något sätt att rangordna de olika problem somuppstått inom studien. Dessa kvantitativa värden används bara internt och säger ingenting omhur Reason fungerar i förhållande till något annat program. Vi anpassade severity ranking-metoder presenterade av Rubin (1994) och Nielsen (1993) till att passa vår studie. För varjeproblem enades vi om ett värde på hur detta problem enligt vår tolkning påverkat respektivetestperson. Av dessa individuella värden bildade vi sedan ett medelvärde. Skalan som användesvar enligt tabell 2:

Allvarlighet Beskrivning Exempel

4 Oanvändbart Användaren kan eller vill inte använda en del avprogrammet baserat på hur det är designat.

3 Allvarligt Användaren kan använda programmet, men inteutan allvarliga begränsningar eller motstånd.

2 Medel Användaren kan använda programmet i de flestafall, men inte utan en viss ansträngning.

1 Irriterande Problemet är relativt lätt att gå runt eller är ett rentkosmetiskt problem, till exempel stavfel.

0 Inget problem Det som inträffade är inget använbarhetsproblem.

Tabell 2: Allvarlighetsrankning

För varje problem beräknades även ett mått på frekvensen, det vill säga hur många av de tiotestpersonerna som råkat ut för problemet. Skalan som användes här var enligt tabell 3:

Frekvens Andel

4 90-100%

3 51-89%

2 11-50%

1 0-10%

Tabell 3: Frekvensrankning

Här skiljer sig vår metod något från Rubins, eftersom vi inte tar hänsyn till hur ofta varjetestperson råkat ut för varje problem. Till exempel fallet ”var femte person råkade ut förproblemet varannan gång” skulle med Rubins metod få

0,2 ! 0,5 = 0,1 " frekvens = 1

medan vår metod ger

0,2 " frekvens = 2

Detta berodde på att vi inte hade tillräcklig noggrannhet i analysen av videomaterialet. Eftersommålet med rankningen endast var att rangordna problemen internt gav metoden enligt vårbedömning ändå ett användbart resultat.

Page 22: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Metod

18

Allvarlighet och frekvens summerades till ett värde som på engelska kallas criticality och somjag har valt att översätta till kritiskt index.

kritiskt index = allvarlighet + frekvens

För att sammanfatta är kritiskt index ett mått på både problemets påverkan på testpersonernasamt hur stor andel av testpersonerna som råkat ut för problemet. Indexet kan anta värdenmellan 0 och 8, där 0 inte är ett problem över huvud taget, och 8 är ett mycket allvarligtproblem. Förutom att rangordna de enskilda problemen efter hur allvarliga de var grupperade viproblemen efter vilka användarmål de påverkade. Eftersom problemen ofta är relaterade tillvarandra, även i olika nivåer, införde vi en struktur med huvudmål som i sin tur kan delas upp idelmål. Till exempel består huvudmålet ”Få en enhet att låta” av bland annat delmålet ”Förståvad en patch är”. Problem som på något sätt hörde ihop, till exempel uppstod i samma enhet,grupperades i en kategori. Huvudmålen och deras undermål sorterades även kronologiskt eftervar de oftast uppstått i arbetsflödet.

Intervju med Propellerheads supportavdelning

För att korrelera våra resultat och se om vi missat något genomförde jag en intervju medPropellerheads supportansvarige, Loui Westin.

Fas 2: Utveckla designförslagAnvändartesterna och de efterföljande analyserna och diskussionerna kring dessa genererade enmängd designförlag kring olika separata problem för nybörjare i gränssnittet (se Resultat avanvändartester sid 19). För att lösa en del mer generella problem togs ett antal övergripandedesignförslag fram parallellt. För att få fram så effektiva designförslag som möjligt fokuseradejag på att lösa problem på så hög nivå som möjligt (Rubin 1994).

Fas 3: Utvärdera designförslagDe övergripande designförslagen utvärderades tillsammans med tre av användarna frånanvändartesterna. Dessa testpersoner motsvarade tre olika användarkategorier vad gäller domän-och teknisk expertis, och tre olika personas: Mia, Muso och Switcher (se Definition ochrekrytering av nybörjare sid 14). Designförslagen representerades med enkla pappersprototyper(Snyder 2003, Preece et al 2002, Beyer & Holtzblatt 1998).

Page 23: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

19

ResultatHär presenteras de viktigaste resultaten från användartesterna, designarbetet och

utvärderingen.

RekryteringEfter viss ansträngning lyckades vi hitta tio testpersoner som stämde in på våra kriterier (seDefinition och rekrytering av nybörjare sid 14). Den svåraste typen av användare att hitta var desom inte hade någon traditionell musikalisk erfarenhet eller kunskap, men ändå hade erfarenhetav andra musikprogram. I övrigt spände testpersonernas bakgrund från musikintresseradenoviser till musikhögskolestuderande och erfarna Logic-användare. Av de tio testpersonerna varendast en kvinna, vilket antagligen också speglar målgruppen (Electronic Musician 2006).Åldern varierade från 17 till 48 år, och medelåldern var 33 år.

AnvändartesterÖverlag fungerade det praktiska vad gäller testerna bra. Ingen användare avbröt testet, och allalyckades på 1,5 till 2 timmar prestera en liten snutt musik, låt vara med varierande grad av hjälp.Vi märkte en del av den problematik som nämnts i litteraturen om att testpersonerna gärnatystnar och behöver tillfrågas (Nielsen 1993, Seago 2004) men vi upplevde det inte som någotstörre problem. Sammanlagt identifierades 182 användbarhetsproblem (för en komplett lista sebilaga D och E). Av dessa inträffade 119 stycken (65%) endast för en testperson. Ett problem,att få MIDI Input till rätt spår, inträffade för nio av de tio testpersonerna.

Problemen grupperades i områden efter vilket av användarens huvudmål det påverkade, samtvilken kronologisk del i arbetsflödet de uppstod. För varje huvudmål, delmål och kategoriberäknades problemens sammanlagda kritiska index, samt hur stor andel delmålen ochkategorierna utgjorde av huvudmålet (se Analys av materialet sid 17).

Nedan följer en lista på huvud- och delmålen sorterade efter i vilken kronologisk ordning deoftast uppkom. Målen som handlar om hjälpsystemen inträffade lite var som helst och därför harjag lagt dem sist. Huvudmålen kallas H1, H2 och så vidare, och D2:3 är delmål nr tre tillhuvudmål nr två. För varje problemområde presenteras i enlighet med Jordan (1996) ettsummerat kritiskt index för området, den procentuella andelen av det sammanlagda kritiskaindexet, en beskrivning av problemen samt möjliga lösningar. Precis som problemen de löser ärdessa lösningsförslag atomära och tar inte hänsyn till helheten. Detta innebär att de kan fåimplikationer på andra delar i programmet. Till exempel får lösningen att mappa Redrumskanaler över hela klaviaturen (se H6 Att få en enhet att låta, sid 22) följden att låtar skapade iReason 3.0 inte kommer att fungera på samma sätt i en eventuell ny version. Lösningen skaparpå så sätt ett nytt problem som också måste hanteras. Därför bör de lösningsförslagen iresultatdelen i vissa fall mer ses som en ytterligare förklaring av problemet än som slutgiltigadesignförslag.

H1 Vill få överblick och konceptuell förståelse

• Summerat kritiskt index: 109• Del av totalt kritiskt index: 16%

Beskrivning

De flesta testpersonerna hade vid testets början ingen eller en väldigt vag uppfattning om vadReason kan och hur det fungerar. När Reason startas första gången laddas automatiskt en

Page 24: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

20

demolåt. Alla testpersoner utom en genomgick en fas där de tittade igenom demolåtens rack ochsequencer, och försökte skapa sig en bild av hur programmet fungerar. Den tionde personenstängde direkt ner demolåten och skapade en ny tom sång för hon tyckte demolåten var förplottrig och gjorde henne nervös. Överlag kommenterade ungefär hälften av testpersonerna attdet fanns många enheter och knappar eller att de vid första anblicken tyckte programmetverkade komplicerat (kritiskt index 5,5). Vissa blev osäkra om demolåten var en demolåt, enstandarduppsättning enheter eller om det var ett tomt dokument som man till exempel får närman startar Microsoft Word. Det sistnämnda förstärktes av att två testpersoner lade märke till attdemolåtens dokumentfönster heter ”Untitled” (Mac) eller ”Document” (Windows).Testpersonerna gick ofta systematiskt igenom enheterna och menyerna för att försöka få enuppfattning om vilka möjligheter som stod till buds, vilket är en vanlig metod (Cooper &Reimann 2003 sid 36). Att få igång demolåten var inget problem, transportknapparnas symboler(play, stop etc.) var mycket effektiva. Många tyckte att de tekniska termer som förekommer påenheterna (”Filter”, ”Mod Envelope” osv.) inte sade dem någonting (kritiskt index 5,3). Denenhet som väckte mest huvudbry var Combinator:n, som till skillnad från till exempel Mixereller Redrum har en anonym frontpanel och ett namn som inte ger en klar bild över vad enhetenegentligen gör (kritiskt index 4,7). En testperson ville dra i reglarna och lyssna efterförändringar i demolåtens sound, men drog antingen i inaktiva reglage eller hörde inte resultatetpå grund av att demolåten har ganska många olika instrument. Demolåten använder dessutomen hel del automation av reglage, och har vissaförvirrande egenskaper. Till exempel är trummaskinensbastrumma mute:ad, vilket gjorde att en testperson somklickade på audition-knappen intill inte fick hörabastrumman. På kanalen intill är mute:en dessutomautomatiserad och har därför en grön markering. Förnågon som kanske inte ens förstår begreppet mute blirdetta ganska svårt att tyda (se bild 9).

Sammanfattningsvis kan man säga att Reason skulle kunna göra ett bättre jobb på att ta hand omnybörjare precis i början. Demolåten dyker upp utan förklaring om vad den är, och fokus verkarmer vara att imponera på avancerade användare snarare än att utbilda nybörjare.

Möjliga designförslag

Ersätt demolåten med en tutorial. För nybörjaren är en tutorial eller guide ett bra sätt att skapaöverblick och konceptuell förståelse (Cooper & Reimann 2003). Se Designförslag sid 34.

H2 Problem att skapa och arbeta med en ny sång

• Summerat kritiskt index: 23• Del av totalt kritiskt index: 3,4 %

Beskrivning

Detta problemområde är litet men allvarligt. När fyra av tio testpersoner skapade ett nyttdokument var sequencerdelen minimerad. Detta skedde på fyra olika datorer och både iWindows och OSX, så det berodde inte på testutrustningen. Att sequencern inte syns är en bug,och det finns därför inget stöd i hjälpen för att klara sig ur det. Buggen beror antagligen på attsequencern har en minimihöjd på ca 30 pixlar, och ifall denna underskrids minimerassequencern. Alla testdatorer kördes med en vertikal upplösning på 768 pixlar. Den endaindikationen på att sequencern finns men inte syns är att markören ändrar utseende när manplacerar den över kanten mellan transportpanelen och racket. Första gången felet uppstod bleväven vi testare lika förbryllade. I ett av de fyra fallen valde jag att direkt visa hur man får framsequencern, eftersom testpersonen redan var ganska modstulen. Buggen blir dessutom merallvarlig av att användaren inte får någon visuell feedback på att hon har ”fått tag i” sequencernförrän minimihöjdens 30 pixlar är uppnådd. Detta fick användarna att avbryta rörelsen i tron attdet inte fungerade.

Bild 9: Tre olika status på

mute-knappen i demolåten

Page 25: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

21

Möjliga designförslag

Buggen måste åtgärdas, och det ska ges visuell feedback även de första 30 pixlarna.

H3 Vet inte var man ska börja

• Summerat kritiskt index: 34• Del av totalt kritiskt index: 5,1 %

Beskrivning

När användarna skapat ett nytt tomt dokument hamnade en de i problem främst för att de inteförstått att enheterna är en förutsättning för att få Reason att låta. Användarna prövade en radolika tekniker för att på något sätt få ljud i programmet. De som hade erfarenhet av andrasequencerprogram (främst Logic) valde att först skapa ett sequencerspår, och sedan koppla dettill mixern (som finns automatiskt när man skapar ett nytt dokument). En som hade erfarenhetav ett DJ-program ville dra in ljudfiler i Arrange-vyn.

En avancerad detalj fick två av testpersonerna att tolka om mixerns funktion. När mixern harMIDI Input (det vill säga att MIDI-klaviaturens data skickas till mixerns sequencerspår)aktiverar tangenttryckningar på klaviaturen mixerkanalernas mute-funktion. Detta är en detaljtänkt för livebruk, då man enkelt vill kunna mute:a olika ljudkällor i ett arrangemang utan attanvända musen. Eftersom mute-indikatorerna blinkade när användarna tryckte på tangenternatolkade de detta som att ljud gick in i mixern men inte hördes. Eftersom ljudet gick in på flerakanaler omtolkade de sin mentala modell av mixern från att ha varit en ”vanlig mixer” till avvara någon slags frekvensuppdelad mixer (liknande en grafisk equalizer). Detta gjordeåtminstone en av användarna osäker senare i processen, när han upptäckte att mixern fungeradeprecis som en vanlig. Flera användare lade också mycket tid på att experimentera medsequencerspårens Out-meny, vilket var resultatlöst.

Möjliga designförslag

Användarnas problem i detta stadium berodde till stor del på att systemet inte utbildat dem attenheterna är det centrala i Reason. Skapar man en enhet får man automatiskt ett nyttsequencerspår och MIDI Input sätts till detta spår. Denna kunskap borde förmedlas i en tutorial.

H4 Problem att skapa en enhet

• Summerat kritiskt index: 29• Del av totalt kritiskt index: 4,3 %

Beskrivning

Enheter skapas genom att välja dem från Create-menyn (se bild10). Denna lista innehåller alla enheter som finns i Reason:instrument, effekter och övriga enheter, totalt 30 olika. Menynär därför lång, och det tog ibland lång tid för användarna atthitta den enhet de letade efter. Listan innehåller endast text(inga ikoner) och namnen är i många fall obegripliga föranvändaren, vars mål oftast är ”jag vill ha ett basljud” ellerliknande. Reason har en funktion i Create-menyn för att leta ljudoch inte enheter (”Create Device by Browsing Patches”), meningen av testpersonerna uppmärksammade denna. För att förståskillnaden och kunna välja mellan en ”Subtractor AnalogSynthesizer” och en ”Malström Graintable Synthesizer”behöver man dessutom veta något om skillnaden mellansubtraktiv och granulär syntes, vilket inte var vanlig kunskapbland våra testpersoner. Alla enheter har samma typsnittsgrad,

Bild 10: Create-menyn

Page 26: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

22

så den vanligare Subtractor-synten framstår inte som viktigare än den mer ovanliga splitboxenSpider, förutom att den senare är placerad längre ner i listan.

Möjliga designförslag

Ett första steg skulle kunna vara att förbättra Create-menyn som den ser ut idag. Menyn skullekunna vara nästlad med rubrikerna ”Instruments”, ”Effects” och ”Other” och ha ikoner för deolika enheterna. Ett annat sätt vore att göra mer reklam för ”Create Device by BrowsingPatches”-funktionen, som bättre överensstämmer med nybörjarnas mål. De vanligaste enheternaskulle också kunna finnas som ikoner i en palett bredvid eller ovanför racket. Så har man löstdet i till exempel Max/MSP som också är baserat på att skapa och koppla ihop ljudenheter(Cycling ’74 2006). Denna lösning skulle även passa medelanvändarna som vill ha snabbtillgång till sina verktyg, och för expertanvändarna skulle det finnas kortkommandon (Cooper &Reimann 2003).

H5 Problem att ta bort en enhet

• Summerat kritiskt index: 12• Del av totalt kritiskt index: 1,8 %

Beskrivning

Detta område består av tre ganska olika problem: en testperson tog av misstag bort mixernvilket gjorde att ljudet försvann, en person tog bort fel av två likadana enheter och en personförstod inte hur man tar bort enheter ([backspace], [delete] eller menykommando) och användeundo-funktionen istället (en så kallad workaround).

Möjliga designförslag

Målet med att ta bort enheter är att man inte vill ha en massa oanvända enheter som tar plats iracket och gör det svårt att överblicka. En funktion för att ta bort oanvända enheter skulle varaanvändbar även för mer avancerade användare. Till exempel innehåller Andreas Tilliandersdemolåt tre oanvända RV7000 reverb-enheter. En oanvänd enhet skulle i så fall vara eninstrumentenhet som inte har något inspelat på sitt spår eller har några CV-kopplingar. Föreffektenheter skulle kravet vara att de ej är inkopplade, eller att ingen signal skickas till dem.

H6 Få en enhet att låta

• Summerat kritiskt index: 126• Del av totalt kritiskt index: 20%

Beskrivning

Detta var det mål som användarna hade mest problem med.Användarna hade vid detta lag lyckats skapa en enhet, menefter det fanns det flera hinder som gjorde att den inte lät.Det största problemet, och det allvarligaste enskildaproblemet i hela studien, var att testpersonerna oftast intelyckades få MIDI Input till rätt spår, och därmed till rättenhet (kritiskt index 7,3). MIDI Input sätts till ett visst spårgenom att placera en klaviaturikon framför spåret ispårlistan (se bild 11). Som vi ser i bilden finns det treparametrar som kontrollerar inspelning och manipulering avspåren: klaviaturikonen, Rec-indikatorn och markeringen. I bilden ser man att flera spår kan haaktiv Rec-indikator samtidigt, att spåret med MIDI Input alltid har aktiv Rec-indikator och attdet markerade spåret inte nödvändigtvis behöver vara spåret med MIDI Input. Att det finns såmånga valmöjligheter beror på att man vill kunna skicka flera olika spår till samma enhet samtatt avancerade användare samtidigt vill kunna spela in MIDI-kontrolldata till ett annat spår än

Bild 11: Spårlistan

Page 27: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

23

det som har MIDI Input. Tyvärr blir detta system väldigt svårt för nybörjaren att förstå.Klaviaturikonen är egentligen den viktigaste parametern här, men de flesta användare verkadeinte se den eller verkade bedöma den som mindre viktig jämfört med markeringen. När manklickar på spårets namn blir spåret markerat och racket autoscrollar till motsvarande enhet, menMIDI Input sätts inte till spåret. Problem med MIDI Input på fel ställe uppstod på flera olika sättoch minst en gång för nio av tio testpersoner. För tre av testpersonerna var problemetkatastrofalt, och vi var tvungna att hjälpa dem vidare.

Ett annat hinder mot att få en enhet att låta var att vissainstrumentenheter (alla utom de två syntarna) saknar ettgrundljud när de skapas. Användarna valde oftast att skapaen Redrum trummaskin som första enhet. När de fått denförväntade de sig ofta att den skulle kunna låta direkt, ochprövade att trycka på olika knappar och spela på MIDI-klaviaturen. Men som programmet fungerar nu måste manförst ladda den med en uppsättning trummor (ett kit) ellerenskilda samplingar innan den kan låta. Enheten markeraratt den är ”tom” endast genom att textboxarna därtrumljudens namn ska stå är tomma (se bild 12) och att det står ”Init Patch” i patch-textboxen(se delmålen nedan). För en nybörjare är denna passiva feedback alltför svag.

Ett annat problem med just Redrum är att knapparna för att provlyssna på ljuden är små (se bild12, knapparna längst upp till höger) och att de tio trumkanalerna enligt gammal MIDI-konvention är mappade till den lägsta oktaven på klaviaturen. I testerna hade vi oftast en litentvåoktavers klaviatur, vilket gjorde att om testpersonen lyckats ladda ljud och prövade att spelapå klaviaturen så hördes det ändå ingenting.

Möjliga designförslag

För nybörjare är det systemet med klaviaturikonen för MIDI Input alltför avancerat och blir ettmycket stort hinder för att snabbt komma igång och göra musik. För deras behov räcker det medatt när ett spår är markerat har det spåret automatiskt MIDI Input, och varje enhet har bara ettspår. Detta innebär att när man markerar en enhet kan enhetens spår automatiskt få MIDI Input.Huruvida klaviaturikonen och multipla spår per enhet finns eller inte skulle kunna vara enpreferensinställning. Markeras flera spår sätts MIDI Input till det senast markerade spåret. Allainstrumentenheter bör också skapas med ett grundljud, så att användaren snabbare kan fåakustisk feedback på att systemet fungerar. Detta skulle heller inte vara ett hinder för medel-eller expertanvändare, eftersom det är lika omständligt att byta från en tom uppsättning som frånett grundljud. Trumljuden i Redrum bör dessutom mappas ut över hela klaviaturen genom attden lägsta oktaven kopieras till de övriga. Eftersom Redrum (precis som Mixern, se huvudmålH3 sid 21) använder vissa tangenter till att mute:a kanaler kan dessa flyttas till den högstaoktaven på klaviaturen där expertanvändarna kan använda dem.

D6:1 Förstå vad en patch är

• Summerat kritiskt index: 19• Del av totalt kritiskt index: 2,8 %

Beskrivning

Flera enheter, både instrument och effekter, går att laddamed olika inställningar. Dessa inställningar kan bestå avbåde rena parametervärden till enhetens reglage (som iSubtractor:n eller RV7000-reverbet), eller parametervärdenplus samplingar (som i samplers och Redrum). För att varakonsekvent har man valt att benämna alla dessa olika typerav inställningar ”patcher”, vilket kommer från de kablar som

Bild 12: Skillnaden mellan en

laddad och tom Redrumkanal.

Bild 13: Patchval

Page 28: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

24

kopplade ihop tidiga modulära analogsyntar. Tyvärr är begreppet patch ganska okänt förde flesta nybörjare. Många har en förståelse för att det går att ladda ”ljud”, men kopplarinte detta till det kryptiska ”Init Patch” på enheternas frontpanel (se bild 13, sid 23). Ifallet Redrum kallas också en uppsättning trummor för ”Kit”, vilket skapar ytterligareförvirring. Vissa tolkade ”Kits” som både en uppsättning ljud och en rytm, ungefär somen loop.

Möjliga designförslag

Byt ”Init Patch” mot ”Load Sound” respektive ”Load Effect” i patchvalsmodulen påenheternas frontpanel.

D6:2 Ladda en patch

• Summerat kritiskt index: 89• Del av totalt kritiskt index: 13%

Beskrivning

Testpersonerna upplevde en del problem med att ladda en patch. Till exempel fungeradeikonerna på patchvalsknapparna (se bild 10) mindre bra än till exempeltransportknapparnas. Många hade svårt att hitta patchvalsmodulen på de olika enheternaeftersom de är ganska små och inkonsekvent placerade på de olika enheterna. När manklickar på knappen med en stiliserad mapp öppnas browsern (se avsnitt Reasons grafiskagränssnitt sid 11). Browsern upplevdes överlag som lite svår. Den har flera olika vyer ochtextfält, tar upp ganska mycket skärmyta och döljer racket. Ingen hittade eller använde tillexempel den fritextsökfunktion som finns i browserns överkant, en funktion som annarspassar bra för användarnas mål. Patcherna är organiserade som filer i ett hierarkisktmappsystem. Det största problemet med browsern för en nybörjare är att den automatisktfiltrerar bort patcher som inte passar den aktuella enheten (detta går att ställa om), mendäremot inte filtrerar bort mappar som inte innehåller några passande patcher. Dettainnebär att de flesta mappar i ljudbankerna ser ut att vara tomma. Ingen förklaring ges tilldetta. Testpersonerna kunde oftast inte hitta någon bra förklaring förutom ”jag måste hagjort något fel”. En person trodde att det kanske var mappar för ljud man kunde köpasenare, och en person kallade dem ”skrytmappar”.

Möjliga designförslag

Patchvalsmodulen är viktig och borde vara större, tydligare uppmärkt och konsekventplacerad på enheternas frontpanel. Browserns gränssnitt borde utvärderas noggrant, vilketskulle kunna utgöra en separat studie. Att ha patcherna organiserade i ett hierarkisktmappsystem är mer programmerings- än användarcentrerat och skulle kunna ersättas meden sökbar databas med flera attribut: enhetstyp, namn, instrumenttyp, musikalisk karaktäretc. Sådana system finns i till exempel Garageband (Apple 2006) och Kore (NativeInstruments 2006). I alla fall borde användaren få ett snällt formulerat felmeddelande ifallen tom mapp visas, eller så skulle de bortfiltrerade patcherna kunna visas ”utgråade”.

H7 Problem att spela en patch

• Summerat kritiskt index: 8,0• Del av totalt kritiskt index: 1,2 %

Beskrivning

Detta problemområde består av tre mindre problem upplevda av tre olika testpersoner. Detallvarligaste är (i mitt tycke) att DrRex:s Preview-knapp inte är lika stor och inbjudande somRedrums Run-knapp.

Page 29: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

25

Möjliga designförslag

Gör DrRex och Redrum mer konsekventa genom att ha samma storlek och stil på Preview-respektive Run-knapparna.

H8 Vet inte var man ska börja med att spela in

• Summerat kritiskt index: 12• Del av totalt kritiskt index: 1,8 %

Beskrivning

Testpersonerna hade i många fall en vag eller felaktig mental modell över hur MIDI egentligenfungerar, vilket gjorde dem osäkra på hur inspelning i Reason egentligen går till. De flesta hadeingen erfarenhet av MIDI-klaviaturer. En användare ansåg att MIDI är ”enklare ljud”, kanskemed anledning av att de enklare ringsignalerna i dagens mobiltelefoner är sparade i MIDI-formatet. Vissa användare ville spela in själva ljudet från enheterna, vilket MIDI inte gör.

Möjliga designförslag

En viss kunskap om MIDI, till exempel att det är tangentnedtryckningarna och inte ljudet manspelar in, är antagligen en förutsättning för att kunna använda musikprogram. Hjälp- ochkunskapssystemen bör ge nybörjarna dessa grundläggande kunskaper.

H9 Problem att ändra en patch

• Summerat kritiskt index: 3• Del av totalt kritiskt index: 0,4 %

Beskrivning

Detta problemområde består av endast ett fel som inträffade för en av testperonerna. Personenfick i Getting Started-manualen förslaget att ändra Subtractorns filterinställning (vilket oftaresulterar i en stor förändring av ljudet), men lyckades inte hitta filtrets reglage på frontpanelen.

Möjliga designförslag

Instrumentenheternas frontpaneler är relativt plottriga ochofta och sällan använda reglage ser likadana ut. Det blirdärför svårt att lokalisera specifika reglage. Ett undantagär Malströmens filter, som har fått ett större och merinbjudande reglage än Subtractorns (se bild 14). Attfrekvensen är ”överordnad” resonansen indikeras genomreglagens storlek. Denna teknik att särskilja viktigafunktioner på frontpanelerna borde utnyttjas mer.

H10 Problem att programmera stegsequencers

• Summerat kritiskt index: 31• Del av totalt kritiskt index: 4,6 %

Beskrivning

Stegsequencers finns i både Redrum och Matrix, men eftersom endast en person testadeMatrix:en relaterar de flesta problemen till Redrum. Överlag lyckades testpersonerna ganska bramed stegprogrammeringen. Att ha en rullande loop som lätt går att påverka genom att baraklicka i och ur taktdelar verkar fungera bra för målgruppen. Problemområdet består av enganska spretig samling problem, men de går att gruppera kring tre teman. Dels förståelse kringatt det musikaliska materialet finns lagrat i själva enheten, dels kombinationen av att det finns

Bild 14: Subtractorns respektive

Malströms filterreglage

Page 30: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

26

flera trumljud men bara en rad med ”steg”, och dels vissa detaljer i Redrums grafiska gränssnitt.När två av testpersonerna gjort ett mönster de var nöjda med ville de spara det. En annantolkade mönsterbankerna som ljudbanker. En testperson ville rensa ett mönster i demolåten menfick det aldrig helt tyst därför att han bara rensat en av tio trumkanaler. Två personer hadetidigare klickat runt lite på måfå och råkat ställa in enheten på att visa steg 17-32 som inte varaktiva eftersom mönstret bara hade 16 steg. Deras förändringar av mönstret hade därför ingeneffekt. En testperson märkte inte att Redrum startade när han tryckte på [Run] eftersom hansfärgblindhet hindrade honom från att se den lilla lysdioden som visar vilket steg som spelas.

Möjliga designförslag

Att det musikaliska materialet finns i enheten och inte i sequencern kan vara svårt att lära sig,men har stora fördelar i normalt arbete och bör därför inte förändras. Vilken trumkanal som äraktiv visas idag bara med en mindre [Select]-knapp och skulle kunna indikeras starkare. Vilkasteg som är aktiva skulle kunna visas med annan färg på lysdioden. I så fall skulle alla 16lysdioder slockna ifall användaren ändrade vyn till steg 17-32 eller högre, förutsatt att mönstretfortfarande var 16 steg eller kortare. För att underlätta för användare med färgblindhet skulleman kunna öka kontrasten i färgerna.

H11 Problem att spela in

• Summerat kritiskt index: 102• Del av totalt kritiskt index: 15%

Beskrivning

Att spela in är det tredje största problemområdet. Med att”spela in” räknar vi både att spela in i realtid med MIDI-klaviaturen samt att rita in toner i Edit Mode. Vidinspelning med klaviaturen rörde de största problemenhur själva inspelningen sätts igång. För det första var detproblematiskt att få kombinationen av MIDI Input ochRec-indikatorn på rätt kanal. Trots att det inte varit någotproblem att förstå och använda de övrigatransportknapparna fungerade inspelningsknappen inte likabra. Flera tryckte på den röda inspelningsknappen, somdirekt började lysa (se bild 15) och spelade på klaviaturenutan att något spelas in. Reason har implementerat sammaskyddsmekanism som finns på bandspelare: man måstetrycka på både [Rec] och [Play] för att inspelning ska ske.Eftersom datorn bara har en mus måste man dock trycka påknapparna efter varandra. När man väl fått igång inspelningblev en del testpersoner ändå tveksamma, vilket verkadebero på att det inte ges så mycket visuell feedback på attnågot spelas in. Testpersonerna hade också en del problemmed att förstå Loop-funktionen och dess indikatorer. Deflesta verkade ha en mental bild av Reasons sequencer somen bandspelare med ett oändligt långt band. Att Loop är aktiverat som default när man skapar ettnytt dokument gjorde att programmet inte betedde sig som förväntat. Två personer som valde attrita in toner ville att tangentnedtryckningar på MIDI-klaviaturen skulle visas på klaviaturen iEdit Mode:s Key Lane (se bild 16). De ville välja ton genom att spela på klaviaturen och direktse den i Key Lanes klaviatur så att de kunde rita in den med pennan.

Bild 15: Transportknapparna

Bild 16: Key Lane

Page 31: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

27

Möjliga designförslag

Det bör räcka med att trycka på [Rec] för att sätta igång inspelning. Till skillnad från entraditionell bandspelare har Reason en undo-funktion, vilket gör skyddsfunktionen att trycka[Rec] och [Play] onödig. Detta borde även gynna mer erfarna användare. Programmet bordeockså ge starkare visuell feedback på att inspelning sker, till exempel genom en rödmarkeringsram kring sequencern och/eller en växande rektangel i sequencerspåret som visar varman spelat in. Loop-funktionen bör vara inaktiv som default när man skapar en ny låt.Tangentnedtryckningar på MIDI-klaviaturen bör visas i klaviaturen i Key Lane.

D11:1 problem att spela in mönsterbyten

• Summerat kritiskt index: 26• Del av totalt kritiskt index: 3,9 %

Beskrivning

Ofta lyckades testpersonerna programmera ett trummönsteri Redrum utan alltför stora problem, och verkade dessutomtycka det var roligt. Ganska snart uppstod önskan attmönstret skulle förändras en bit in i låten, och här körde endel fast. Problemen bottnar dels i skillnaden mellanstegsequencers och den vanliga sequencern (se avsnitt H10Problem att programmera stegsequencers, sid 25), och delsi vissa snårigheter i enheternas gränssnitt. Testpersonernahade ofta som mål att ”få in trummorna i sequencern”, detvill säga att exportera mönstret till Redrums spår för attdär kunna arrangera det. Hur detta skulle gå till var dockinte lätt att förstå. Funktionen finns i Edit-menyn ochheter ”Copy Pattern To Track”, men den var svår att hitta.Några testpersoner förstod att det också går attautomatisera mönsterbyten och testade den tekniken. Enav dessa kopplade inte Redrums mönsterbanker (bank A,mönster 1 osv.) till representationen A1, A2… i PatternLane, där automatiseringen ska spelas in (se bild 17 och 18).

Möjliga designförslag

Kopplingen mellan stegsequencerna och deras sequencerspår skulle kunna görastydligare. En av testpersonerna föreslog under utvärderingen (se avsnitt Utvärdering avdesignförslag sid 34) att man skulle kunna ha ett ett-till-ett-förhållande mellan mönstrenoch spåret. Så när Redrum skapas och bara har ett enda taktlångt tomt mönster så visasdetta i sequencerspåret. Ifall användaren tar bort några takter av mönstret så inaktiverasmönsterfunktionen vid uppspelning, eller ifall användaren placerar markören över en tomtakt. En mindre förändring skulle vara att lägga till en knapp för funktionen ”CopyPattern To Track” till Redrums frontpanel. En sådan finns redan i loopspelaren DrRex,vilket gör funktionerna inkonsekventa. Representationen av mönsterbankerna i Redrumoch i Pattern Lane borde vara mer lika, till exempel genom att ha en miniatyr av Redrumsmönsterbank i Pattern Lane. En mycket enkel förändring skulle vara att byta ordning påmönster och banker på Redrums frontpanel, så att mönstren utläses A1 och inte 1A osv.

Bild 17: Mönsterbanker

Bild 18: Mönsterautomation

Page 32: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

28

H12 Problem att förstå uppspelning

• Summerat kritiskt index: 17• Del av totalt kritiskt index: 2,6 %

Beskrivning

När man spelar in MIDI representeras de inspelade tonerna iArrange View av små röda streck (se bild 19). Dessa går sedan attgruppera genom att dra pennan över dem eller genom ettmenykommando. Hälften av testpersonerna var inte nöjda med desmå röda strecken, utan ville att det inspelade materialet skulle seut som i demolåten (grupper). Representationen, som till exempelinte visar tonernas längd i tidsled (duration), fungerade med andraord dåligt som kvitto på att man spelat in. En användare mederfarenhet av Logic trodde att de röda strecken representeradenågon form av MIDI-kontroll, till exempel aftertouch. Ett annat problem med förståelsen avuppspelning var när en testperson exporterat ett Redrum-mönster till sequencern så triggadestrumljuden både från sequencerspåret och från Redrums interna stegsequencer. Resultatet blevett hörbart fasfel i ljudet. Detta problem uppstod även för en annan testperson, men dennemärkte inte fasfelet.

Möjliga designförslag

Tonerna bör grupperas automatiskt när inspelningen är klar. Representationen av toner iArrange View är liten och kryptisk, och följer inte standarder som etablerats i andra program.En tydligare och mer standardiserad representation med notlängder skulle ge en bättre bild avmaterialet. När en användare exporterat ett mönster till sequencern med ”Copy Pattern ToTrack” bör ”Pattern Off” automatiskt aktiveras i Redrum. Funktionen måste dock förändras såatt det fortfarande är möjligt att spela upp mönster i Redrum genom att trycka [Run].

H13 Problem att arbeta med låtstrukturen

• Summerat kritiskt index: 27• Del av totalt kritiskt index: 4,0 %

Beskrivning

Detta är en samling problem rörande Arrange View, där målet är att skapa och förändra strukturi låten. Även här blir representationen av toner ett problem. De röda små strecken ger inte likabra översikt över låtens struktur som grupper gör, så testpersonerna ville ofta få det att se ut somdet gjort i demolåten. När testpersonerna försökte markera och flytta toner var detta svårt,antingen på grund av att de enskilda tonerna bara är en pixel breda och därmed svåra att träffa,eller på grund av att sequencerns ”Snap to Grid”-inställning gjorde att man inte kunde markeraendast de toner man ville utan fick några på köpet. För en testperson som testade funktionen”Insert Bars Between Locators” (som adderar tomma takter mellan vänster och högerlooppunkt) i demolåten blev detta ett allvarligt problem, eftersom låten då började loop:a kringdetta nya tysta parti. En testperson hade spelat in både mönster i Redrum samt lagt till extratrumslag i sequencerspåret. När han sedan använde mute-funktionen i tracklistan blev hanförvånad över att denna tystade hela enheten och inte bara den MIDI-data som fanns isequencerspåret.

Möjliga designförslag

Även här skulle automatisk gruppering av inspelade toner underlätta för användarna att enkelt fåmer överblick över låtens struktur. Funktioner som påverkar innehållet, till exempel ”Insert BarsBetween Locators”, skulle kunna animeras för att öka förståelsen för vad de utför.

Bild 19: Toner vs grupp

Page 33: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

29

H14 Problem att manipulera MIDI-händelser

• Summerat kritiskt index: 47• Del av totalt kritiskt index: 7,1 %

Beskrivning

Dessa problem rör Edit Mode och detaljmanipulering av enskilda spår och toner. Edit Mode harmånga olika vyer och verktyg för att se MIDI-datan (se D14:1 nedan), och problemen är mestsmå detaljer kring hur dessa fungerar. Till exempel prövade många testpersoner att användahandverktyget för att dra i toner, men detta används i Reason som i till exempel Adobe Acrobatför att ta tag i och scrolla dokumentet (Adobe 2006). En användare upplevde samma problemmed både pennverktyget och när han ville ändra längden på en ton: detta går inte att göra åtvänster förbi tonens startposition. Vissa testpersoner hade problem att markera toner för de varför små. En tesperson trodde han hade kvantiserat de synliga tonerna men egentligen var bara enmarkerad och därmed kvantiserad.

Möjliga designförslag

Problemen är utspridda över flera funktioner samt verktyg och därmed svåra att lösa medgenreella designförändringar.

D14:1 Problem att läsa representationer i Edit Mode

• Summerat kritiskt index: 16• Del av totalt kritiskt index: 2,3 %

Beskrivning

Dessa problem handlar om förståelse för olika representationer i Edit Mode. Till exempelhade en del testpersoner svårt att avgöra vad staplarna i Velocity Lane representerade.

Möjliga designförslag

Velocity-värdena för tonerna skulle kunna representeras i Key Lane ifall denna gjordestredimensionell med dimensionerna tid, tonhöjd och velocity.

H15 Problem att ändra mixerkanal

• Summerat kritiskt index: 4,0• Del av totalt kritiskt index: 0,6 %

Beskrivning

Detta mål består av bara ett problem som två av testpersonerna råkade utför. De testade EQ:n på mixern, och manipulerade Treble- och Bass-reglagen utan att lägga märke till att EQ:n behöver slås på genom atttrycka in den lilla EQ-knappen uppe till vänster i modulen (se bild 20).EQ-knappen kan lätt uppfattas som en indikator och inte en knapp. En avtestpersonerna tyckte att ljudet förändrades, medan den andre var merosäker.

Möjliga designförslag

EQ:n bör automatiskt slås på första gången Treble eller Bass förändras. Detta skulle kunna varaett problem vid livebruk, då man kanske vill göra en inställning på känn och sedan aktivera den.Därför borde vilket sätt EQ:n fungerar på gå att ställa in i preferenserna.

Bild 20: EQ

Page 34: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

30

H16 Problem att använda effekter

• Summerat kritiskt index: 17• Del av totalt kritiskt index: 2,5 %

Beskrivning

Överlag hade testpersonerna liten eller ingen erfarenhet av mixerbordoch var därför inte speciellt insatta i skillnaden mellan insert- (serielltkopplade) och sendeffekter (parallellkopplade). En testperson mederfarenhet av Logic tolkade sendeffekternas namnlappar på mixern somfack där man kunde skapa effekter. En person ville ha eko bara påvirveln och inte hela trumsetet i Redrum. Det finns en funktion för detta,nämligen två effekttappningar i själva Redrum, men funktionen ärkryptiskt uppmärkt med namnen S1 och S2 (se bild 21). Personenhittade heller ingen passande hjälp (se avsnitt H19 Problem att användahjälpen sid 31).

Möjliga designförslag

Effekthanteringen skulle kunna göras enklare, men antagligen inte utan att bryta mot metaforentill hårdvara. Till exempel skulle man kunna ha fack för effekter i mixern och i Redrum.

H17 Problem att koppla ihop enheter

• Summerat kritiskt index: 11• Del av totalt kritiskt index: 1,6 %

Beskrivning

Överlag var testpersonerna inte så medvetna om vilken enhet som var markerad och att dettaavgör var nästa enhet skapas. Ofta fungerade detta ändå bra: enheten de jobbade med och villelägga en effekt på var markerad och autoinkopplingen skötte allt på rackets baksida när deskapade effektenheten. Ibland bad vi testpersonerna lägga en effekt på en annan enhet, och ifallde då inte markerade denna enhet hamnade effekten på fel ställe. Ganska få testpersonerupptäckte av sig själva att man kan vända på racket och göra manuella kopplingar mellanenheterna där. En testperson ville göra en otillåten koppling, till exempel koppla en ingång tillen ingång.

Möjliga designförslag

Att den aktuella markeringen avgör var nya enheter skapas skulle kunna etableras mer tydligt ien tutorial. För just effekter skulle enheterna kunna ha en [Add Effect]-knapp nere till högersom öppnar browsern med effektfiltret aktiverat, och skapar en inserteffekt under denmarkerade enheten.

H18 Problem att använda Getting Started

• Summerat kritiskt index: 23• Del av totalt kritiskt index: 3,4 %

Beskrivning

Ungefär hälften av testpersonerna använde någon gång Getting Started-manualen för att få hjälpoch vägledning. Två personer använde den mycket. Att ha en separat bok att titta i fick iblandtestpersonen att vara mindre uppmärksam på vad som hände på skärmen, och var också svår atthantera rent praktiskt (lägga ifrån sig, ha plats för etc.). En testperson tolkade texterna väldigtbokstavligt. Stod det ”Skapa en mixer” gjorde han detta även om han redan hade en mixer. Efteratt framgångsrikt ha laddat en patch i en Subtractor uppmanades han att ”gör på samma sätt med

Bild 21: Redrums

effekttappningar

Page 35: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

31

Redrum”, vilket fick honom att öppna browsern i Subtractorn igen, i tron att detta skulle bytaljud på Redrum:en.

Möjliga designförslag

En tutorial på skärmen skulle lösa både de praktiska problemen med pappersvarianten samtbättre visa exakt vad som ska göras med hjälp av video. Den skulle också kunna använda länkartill förklaringar av begrepp med mera.

H19 Problem att använda hjälpen

• Summerat kritiskt index: 4,5• Del av totalt kritiskt index: 0,7 %

Beskrivning

Två testpersoner kunde inte hitta den hjälp de behövde, utan var tvungna att hjälpas eller gickvidare. En av personerna hade Windows, men använde inte hjälpfunktionen. Däremot hittadehan viss hjälp via Google.

Möjliga designförslag

Även här skulle en tutorial antagligen ha hjälpt bättre än Getting Started. En av personernaefterfrågade rubriker av typen ”How to [play/record/mix]…” etc.

Page 36: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

32

Sammanfattning och analys av resultatHur fungerar då Reason för nybörjare? Trots att alla testpersoner tyckte det var roligt att testaReason, och de flesta lyckades prestera en snutt musik, så finns det många förbättringar att görai sättet som Reason tar hand om nybörjare. Många av de problem användarna råkat ut för berorpå små enskilda detaljer i gränssnittet, till exempel den knepiga MIDI Input-ikonen ellerfrånvaron av återkoppling när användaren hamnar i en ”tom mapp” i browsern. Även om mångaav de problem som testpersonerna råkade ut för vart och ett för sig inte var så allvarligt, såuppstod de ofta i kombination med varandra och skapade tillsammans mer svårforceradefelkluster. Till exempel uppstod ofta fel med MIDI Input-ikonen i kombination med attanvändaren inte kunde hitta några patcher i browsern, vilket gjorde att de av testpersonernauppfattades som ett enda fel.

STARTSummerat

kritiskt index% av totalt

kritiskt index

H1 Vill få överblick och konceptuell förståelse 108,9 16,3

H2 Problem att skapa och arbeta med en ny sång 19,0 2,8

FÅ REASON ATT LÅTA

H3 Vet inte var man ska börja 33,9 5,1

H4 Problem att skapa en enhet 28,9 4,3

H5 Problem att ta bort en enhet 12,0 1,8

H6 Få en enhet att låta 125,6 18,8

D6:1 Förstå vad en patch är 18,8 2,8

D6:2 Ladda en patch 89,3 13,4

H7 Problem att spela en patch 8,0 1,2

H8 Problem att ändra en patch 3,0 0,4

INSPELNING

H9 Vet inte var man ska börja med att spela in 11,8 1,8

H10 Problem att programmera en stegsequencer 31,0 4,6

H11 Problem att spela in 102,4 15,3

D11:1 Problem att spela in patternbyten 25,8 3,9

H12 Problem att förstå uppspelning 17,3 2,6

ARRANGERING

H13 Problem att arbeta med låtstrukturen 31,0 4,6

H14 Problem att manipulera MIDI events 47,1 7,1

D14:1 Problem att läsa representationer i Edit Mode 15,5 2,3

MIXNING

H15 Problem att ändra mixerkanal 4,0 0,6

H16 Problem att använda effekter 17,0 2,5

H17 Problem att koppla ihop enheter 11,0 1,6

HJÄLP / MANUAL

H18 Problem med "Getting Started" 23,0 3,4

H19 Problem att använda hjälpen 4,5 0,7

Tabell 4: Användarmål i kronologisk ordning.

Som vi kan se i tabell 4 finns det tre mål som har markant högre summerat kritiskt index än deandra målen:

Page 37: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

33

• H1 Vill få överblick och konceptuell förståelse• H6 Få en enhet att låta• H11 problem att spela in

Dessa tre inträffar dessutom relativt tidigt i den genomsnittliga arbetsprocessen (se figur 3):

Figur 3: Huvudmålens kritiska index i kronologisk ordning

Nybörjarens största hinder mot att skaffa sig överblick och konceptuell förståelse är enligt mintolkning att demolåten inte är ett lämpligt sätt att göra detta på. Oftast hade nybörjarna med sinabegränsade förkunskaper ingen möjlighet att effektivt kunna ta till sig den tekniska terminologinoch dra nytta av hårdvarumetaforen. Att demolåten dök upp oombedd, och dessutom heter”Untitled” eller ”Document”, fick användarna att tveka om huruvida den var en demolåt eller etttomt dokument. Sammantaget fungerade den endast bra för en av testpersonerna, som hadeerfarenhet av både hårdvaruenheter och Logic. Demolåtens passiva roll som utbildare gjorde attmånga av testpersonerna snabbt övergick till en trial-and-error-metodik och planlöst klickaderunt, eller övergick till att läsa i Getting Started-manualen. Trial-and-error-metoden var ofta intespeciellt lönsam. Chansen att av misstag ändra en viktig inställning, till exempel visa steg 17-32i Redrum, var stor och kunde få ödesdigra konsekvenser senare. Förutom att demolåten ärpassiv och lämpar över ansvaret för kunskapsöverföringen på användaren så är den förnybörjaren alldeles för omfattande och komplicerad. Flera av testpersonerna blev överväldigadeav den upplevda komplexiteten.

När användaren känner sig redo att försöka göra en egen låt är det första delmålet att få ljud iprogrammet. Ofta hade testpersonerna en spontan idé om vilket instrument eller ljud de villebörja med, till exempel ”jag vill göra trummor” eller ”jag vill ha ett basljud”. Som Reason ärutformat idag är den naturliga arbetsgången att först skapa en enhet, och sedan ladda den meden patch. För medel- och expertanvändare fungerar detta arbetssätt bra, men för nybörjarnaliknar det närmast en hinderbana. Förutom att Create-listan är överfull med kryptiskt namngivnaapparater som kräver förståelse om olika syntesmetoder så laddas vissa enheter utan ettgrundljud. Funktionerna ”Create Device by Browsing Patches” i kombination med browsernsfritextsökfunktion skulle kunna reducera antalet steg i kedjan, men tyvärr är de undangömdaoch förutsätter att användaren vet vad en patch är. Att få ljud i en enhet och kunna börja testaljud är den första ”belöningen” användaren får, och därför är det viktigt att minska tiden det taratt nå dit.

108,9

19,0

33,928,9

12,0

125,6

8,03,0

11,8

31,0

102,4

17,3

31,0

47,1

4,0

17,011,0

23,0

4,5

0,0

20,0

40,0

60,0

80,0

100,0

120,0

140,0

H1 H2 H3 H4 H5 H6 H7 H8 H9 H10 H11 H12 H13 H14 H15 H16 H17 H18 H19

Huvudmål

Su

mm

era

t k

riti

sk

t in

de

x

Page 38: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

34

Vad gäller att spela in är det främst att förstå skillnaden mellan stegsequencers och den vanligasequencern som försvårar för nybörjaren. Att programmera trummor i Redrum fungerade oftastmycket bra, men så fort testpersonen skapat ett mönster uppstod frågan hur man får mönstret attbytas. Här fungerade demolåten som förebild, eftersom testpersonerna oftast förstod att de pånågot sätt kunde exportera mönstret som en grupp till sequencern.

Sammanfattningsvis borde designarbetet fokusera på att ge nybörjarna överblick precis i början,snabbare ta nybörjarna till en nivå då de kan börja testa ljud samt dölja onödiga funktioner.

Intervju med Propellerheads supportI intervjun med Propellerheads supportansvarige Loui Westin framkom det att de vanligastefrågorna som ställs rör hårdvarurelaterade problem, drivrutiner för hårdvara och Rewire-applikationer. För många användare verkar att vända sig till supporten vara det sista steget, ochföregås av till exempel rådfrågning av hjälpsystemen, Propellerheads hemsidas FAQ och forum,bekantskapskretsen eller Google. Därför är det antagligen bara de allvarligare felen som nårPropellerheads support, och frågor kring användandet av Reason kommer ganska sällan. Av deproblem vi identifierat i användartesterna var problemen med att Redrums ljud endast ärmappade till lägsta oktaven samt hur man exporterar ett mönster till sequensern vanligast.Frågor om MIDI Input förekommer mycket sällan, liksom frågor kring tomma mappar ibrowsern. I användartesterna råkade fyra av tio testpersoner ut för problemet med attsequencern var minimerad när man skapade ett nytt dokument. Denna höga andel verkar integälla för alla Reasonanvändare, för även om buggen var känd är det ganska få som hör av sigom den. En vanlig fråga var ”Hur använder man Reason utan MIDI-klaviatur?”. De flesta somladdar ner demoversionen av Reason saknar MIDI-klaviatur, vilket starkt begränsar hur du kananvända programmet.

Utvärdering av designförslagEtt antal konceptuella designförslag togs fram ochutvärderades tillsammans med tre av testpersonerna.Förslagen var

• Tutorial – en möjlighet att följa tutorials i ettseparat fönster bredvid racket

• Project Gallery – ett galleri som presenterar olikavalmöjligheter för användaren när programmetstartar

• Remake – en ny metaenhet för att lättare kunnavälja ljud

• Easy Mode – en förenklad variant av programmet

Enkla pappersprototyper skapades på plats för attkommunicera designförslagen (se bild 22). Testpersonernafick pröva att utföra olika uppgifter i pappersprototypernaoch designförslagen för- och nackdelar diskuterades. AvRemake och Easy Mode, som är delvis komplementära,föredrog alla Remake, även om ingen tyckte direkt illa omEasy Mode. Utvärderingen genererade även ett antalytterligare designförslag genom att testpersonerna bidrog med idéer. Till exempel föreslog entestperson att projektgalleriet skulle kunna uppdateras dynamiskt med nya demolåtar ochtutorials, och en annan hade funderat ut en egen lösning på problemet hur mönster istegsequencers ska kopplas till den vanliga sequencern. Utvärderingen ledde dock inte till någrastörre förändringar av designförslagen (se Diskussion sid 40).

Bild 22: Pappersprototyp

av Easy Mode

Page 39: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

35

DesignförslagNedan följer en beskrivning av de olika designförslag som tagits fram. Förslagen är på enkonceptuell nivå, och detaljerna är inte till hundra procent utarbetade.

Tutorial

The Mixer

Close

Getting Started 3 (12)

orem ipsum dolor sit amet, consectetuer

adipiscing elit. Morbi eu eros. Pellentesque ac

quam quis mi tempor consectetuer. Vivamus

justo. Aliquam urna turpis, congue vel, ornare

sit amet, consectetuer eu, lectus. Curabitur

auctor, nisi in elementum dictum, pede enim

lacinia turpis, a imperdiet nisi ante ut turpis.Pellentesque odio quam, porta a, accumsan

scelerisque, mattis a, quam. Pellentesque a

pede. Suspendisse metus sapien, venenatis

sit amet, dictum nec, blandit non, massa.

Vivamus eget tellus. Ut velit nisi, auctor sed,

elementum lacinia, vulputate ut, tortor. Cras

neque orci, elementum ut, tristique non,

convallis ac, nisi.

Bild 23: Tutorial-fönstret

Ett bra sätt att ge nybörjarna överblick är, som redan sagts tidigare i resultatdelen, tutorials(Cooper & Reimann 2003). En väl utformad tutorial skulle lösa många av de problem somuppstår när användarna själva måste utforska och lära sig Reason. Speciella drag hosprogrammet, som till exempel att man måste skapa en enhet innan man kan få ljud, skulle kunnaetableras tidigt. Även om det ur ett strikt användbarhetsperspektiv är tveksamt om metaforen tillenheter skapar något mervärde för nybörjarna är den ändå ett av Reasons kärnvärden och börinte ruckas på (se Avgränsningar sid 4). Eftersom Reasons rack har en fast bredd finns detskärmyta till höger och vänster om dokumentfönstret att ha ett separat tutorial-fönster i. Entutorial bör vara uppdelad kring olika ämnen och svårighetsgrader, där ”Getting Started” ellerliknande är viktigast för nybörjaren. ”Getting Started” förklarar vilka olika delar som finns iReason och hur de hänger ihop. Väljer man att följa denna får man ett tomt rack och tutorial-fönstret. Innehållet i tutorial-fönstret består av HTML-text och eventuellt videos. Tutorial:en äruppdelad i ett antal små lektioner om en sida var, och innehållet är anpassat till fönstrets storlekså att användaren inte behöver scrolla. Användaren bläddrar mellan lektionerna med pilar nertillpå sidan. Varje sida förklarar stegvis ett begrepp eller teknik och ger användaren ett uppdrag, tillexempel ”Såhär skapar du en enhet” / ”Skapa nu en enhet själv”.

För medel- och expertanvändare bör det finnas tutorials kring mer avancerade ämnen ochtekniker. Ett exempel kan vara en genomgång av vad som är nytt i den aktuella versionenjämfört med den förra.

Page 40: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

36

Project Gallery

Show this at startup Close

Project Gallery

GettingStarted

Tutorials

What’s new? Learn CV Advancedsampling

Feedback

Empty rack

Songs

Demo Song My rack

Favorites

Techno Rock

Bild 24: Projektgalleriet

Var ska man då välja om och vilken tutorial man vill följa? Förutom att vara åtkomliga från”Help”-menyn bör de presenteras på ett tydligt sätt direkt då programmet startas. Mångaprogram (Microsoft Office, Adobe CS med flera) har ett så kallat projektgalleri som är detförsta som syns när man startar programmet. I ett projektgalleri presenteras en rad möjligheterför användaren: skapa ett tomt dokument, följa en tutorial, se nyheter i uppdateringen och såvidare. Flera av testpersonerna blev osäkra på vad demolåten egentligen var eftersom den dökupp utan att de bad om den. Genom projektgalleriet blir det som presenteras ett aktivt val, ochdärmed förhoppningsvis mindre förvirrande. För att vara användbart även för medel- ochexpertanvändare innehåller projektgalleriet en möjlighet att visa användarens favoritlåtar.Reason har redan idag stöd för att ordna patcher och låtar i favoritlistor, och genom att ta indenna funktionalitet i projektgalleriet kan användaren skapa malldokument och enkelt komma åtdessa. Som redan nämnts föreslog en av testpersonerna att tutorials och demolåtar skulle kunnavara dynamiska och uppdateras via Internet. Genom en tydlig kryssruta kan användaren göra såatt projektgalleriet inte visas från och med nästa programstart.

Page 41: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

37

Remake

Bild 25: Remake Preset Player

Remake är en ”Preset Player” som fungerar som en fjärrkontroll till någon av de vanligaenheterna. Ett preset är ett förinställt ljud, och syntar brukar ha en uppsättning presets och enannan uppsättning användarskapade ljud. Målet är att låta användaren snabbt välja mellan enbegränsad uppsättning presets, dölja oönskad komplexitet i enheternas frontpanel och dessutomförse den som inte äger en MIDI-klaviatur med en klickbar variant på skärmen. En Remakeskapas precis som någon av de andra enheterna, men samtidigt skapas även en dotterenhet iracket med Remake:n svävande framför. Dotterenheten är ”utgråad” och inaktiverad, men gåratt spela på via Remake-enhetens tangentbord (och via ett MIDI-klaviatur om ett sådant ärinkopplat). På Remake:s frontpanel finns ett antal knappar med instrumentkategorier, och fyravariationer för varje kategori. När användaren klickar på knapparna laddas direkt en ny patch idotterenheten. Ifall preset-patchen kräver en annan enhetstyp än dotterenheten så bytsdotterenheten ut. Detta är samma koncept som crossbrowsing, som redan finns i Reason (seavsnitt Reasons grafiska användargränssnitt sid 11). Remake har en lätt naivistisk design för attkommunicera att den är en förenkling. Eftersom de mer avancerade enheterna syns bakom dengrå ridån får användaren ändå bilden av att Reason är ett proffsprogram och att man inte betalat4000 kr för en leksakssynt. Ifall användaren vill ändra en inställning på dotterenheten finns deten Edit-knapp som låser upp dotterenheten temporärt. Remake:n försvinner åt sidan så attanvändaren kommer åt dotterenhetens frontpanel. Nu är istället resten av racket utgråat ochinaktivt. Användaren gör sina inställningar och trycker sedan [Return] eller på en grafisk knappför att få tillbaka Remake:n och stänga dotterenhetens redigeringsläge. Användaren kan göraalla ändringar som är möjliga i de vanliga enheterna, till exempel ladda en ny patch, meninställningarna finns inte kvar nästa gång han skapar en ny Remake. Ifall användaren vill görasig av med Remake-enheten permanent och endast ha kvar dotterenheten finns det ettkommando för detta i Edit-menyn.

Page 42: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

38

Easy Mode

Load Sound

Pop Rock Metal Country

House Techno Synth Electro

Rock 1 Rock 2 Shuffle Halfbeat

Funky Toto RHCP Levon

Rhythm Category

Rhyhtm

RED HOT CHILI

Add

Effect

VOLUME

Load Sound

Leads Pads Strings Brass

Bass Piano Mallet Effects

Nice Nice 2 Hollow Buzzy

Sad Ambient Sweep Bubbly

Sound Category

Sound

Waveform

SWEEP PAD

Filter Envelope

Add

Effect

VOLUME

Upgrade

Upgrade

LEVEL LEVEL LEVEL LEVEL LEVEL LEVEL

PAN PAN PAN PAN PAN PAN

RUN TO TRACK 4/4 3/4 Drummer

Synth A

+1- +

OCTAVE

Attack DecaySustainRelease

Bild 26: Mixer, Subtractor och Redrum i Easy Mode

Easy Mode är ett extra läge (”mode”) i Reason, men skulle också kunna vara en friståendebilligare variant av hela programmet. När användaren installerar Reason tillfrågas han om hanvill köra programmet i Standard eller Easy Mode. Detta kan i efterhand ändras ipreferensinställningarna. Målet med Easy Mode är att dölja många avancerade inställningar påenheternas frontpanel samt att underlätta patchval. I Easy Mode finns nerstrippade ochförenklade varianter av de vanliga enheterna. Vissa avancerade enheter, som Combinator,Matrix, NN-XT och RV7000, saknas. Enheterna heter heller inte som sina fullvärdiga versioner,utan namnen är mer allmänna och syftar på enheternas funktion.

Gemensamt för alla instrumentpaneler är att de har en konsekvent utformad patchvalsmodul tillvänster på frontpanelen (se bild 26). Istället för ”patch” kallas ljuden för ”sounds” för att bättreöverensstämma med användarnas terminologi. Patchvalsmodulen består av åtta kategorier som isin tur innehåller åtta ljud. Texten på patchknapparna uppdateras när användaren byter bank,och patchens namn visas i textrutan längst upp i patchvalsmodulen. Användarna kan dessutomladda andra patcher från ljudbankerna via den vanliga browsern.

För användare som saknar MIDI-klaviatur finns en virtuell klickbar klaviatur som automatiskthamnar under den markerade instrumentenheten. Markeringsramen går runt enheten samtklaviaturen, vilket förtydligar markeringen och till vilken enhet klaviaturen är kopplad. Dettaförutsätter att markering av en enhet automatiskt sätter MIDI Input till motsvarande spår, och attdet bara finns ett spår för varje enhet.

Enheterna innehåller en ”Upgrade”-knapp som förvandlar Easy Mode-enheten till motsvarandevanlig enhet, samt en knapp för att lägga till en insert-effekt. Att ha en speciell knapp för att

Page 43: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Resultat

39

lägga till en effekt gör att användaren slipper tänka på att ha rätt enhet markerad när hon skapareffektenheten. Färgsättningen mellan Easy Mode-enheterna och deras förebilder är identisk föratt etablera deras karaktär inför övergången till Standard Mode. Nedan följer en beskrivning avnågra av Easy Mode-enheterna.

Mixer

Mixern har tappat sin Aux- och EQ-sektion och har nu endast nivå, panorering, mute och solo.För många nybörjare är skillnaden mellan insert- och sendeffekter okänd, och därför har deingen nytta av mixerns Aux-sektion. Även EQ:n är för många överflödig och går att ersätta meden insert-effekt. Resultatet blir att mixer ser mindre plottrig och skrämmande ut.

Synth A

Synth A, som är Subtractorn i bantad version, har behållit några av de viktigare och roligastereglagen som till exempel filtret, medan resten gömts undan. Detta gör att alla reglage som synspå frontpanelen verkligen påverkar ljudet. Namnet ger information om att den är en synt menberättar inget överflödigt om vilken typ av syntes den använder sig av. Malströmens bantadevariant kallas Synth B.

Drummer

Redrum var i testerna ofta den enhet man skapade först, och dess interaktion medstegprogrammering fungerade ofta mycket bra för nybörjare. Därför är det viktigt att röja undannågra av de hinder som trots allt finns. Redrums förenklade variant heter Drummer och har färreantal trumkanaler (sex eller åtta mot tio) än sin förebild, vilket ger enheten ett något mindreplottrigt utseende. Drummer laddas alltid med ett grundljud och grundmönster, nämligen detsom ligger först i patchvalsmodulen. Varje Användaren kan ändra i alla mönster precis som iden vanliga Redrum, men om man skapar en ny Drummer är mönsterna återställda till default-mönsterna. Trumkanalerna är förenklade och har bara reglage för nivå och panorering. De iRedrum små och separata provlyssnings- och kanalvalsknapparna är i Drummer hopslagna tillen enda stor inbjudande knapp eller ”pad”. Detta innebär att varje gång man väljer en kanal förprogrammering får man höra ljudet, vilket fungerar som en akustisk återkoppling på kanalvalet.Den markerade kanalen indikeras med en röd ram runt pad:en, och när en trumkanal triggas frånstegsequencern blinkar en gul ram till. I stegsequencern har de flesta avancerade inställningarnatagits bort, och en ”To Track”-knapp liknande den i DrRex har lagts till. Lysdioderna ovanförstegknapparna lyser nu gula för att indikera hur långt mönstret är. I Drummer kan användarenbara välja mellan 4/4- och 3/4-takt, det vill säga 16 eller tolv sextondelar.

Page 44: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Diskussion

40

DiskussionDetta avsnitt ger återkoppling till arbetets frågeställningar och genomförande.

Sammanfattande slutsatser

Arbetets genomförande

Metoden vi valde för användartesterna fungerade i mitt tycke bra och genererade mycket data.Stämningen vid testerna var ofta lättsam och testpersonerna tyckte det var roligt att delta. Ettproblem för examensarbetet var dock att genomförandet och analysen av användartesterna toglängre tid än planerat, vilket lämnade mindre tid över till utvecklingen av designförslag.Användartesterna blev relativt omfattande både vad gäller antal testpersoner samt analysen avmaterialet. I efterhand kan man ifrågasätta ifall det behövt göras tio tester. De viktigasteidentifierade problemen var ungefär lika utmärkande efter fyra till fem tester som i detslutgiltiga materialet. Att spela in testerna med video blev också något av ett tveeggat svärd.Fördelarna var naturligtvis att testerna i efterhand kunde detaljstuderas för att hitta problem vimissat vid själva testtillfällena, samt att de var ett stöd för att bekräfta eller vederlägga olikatolkningar av materialet. Video har också visat sig mycket effektivt för att kommuniceraresultaten ut till Propellerheads anställda. Nackdelen är dock att det lätt blir onödigt stort fokuspå videoinspelningarna och att det tar tid att gå igenom och klippa materialet. Det visade sig attdet i arbetstid verkligen tar tre till tio gånger materialets längd att bearbeta videoinspelningar(Nielsen 1993).

Ett ”problem” som uppstod var att jag och Björn Johansson mot slutet av användartesterna lärtoss mer om hur nybörjare lär sig Reason och även identifierat flera vanliga användarproblem.Vi var helt enkelt bättre observatörer i slutet i studien än i början. Detta kan ha inneburit att vimissat att registrera problem i de första användartesterna, eftersom vi ännu inte blivituppmärksammade på dem. Det är ju lättare att hitta något när man vet vad man letar efter. Trotsallt tror jag inte att detta påverkat resultatet alltför mycket. Under videoredigeringen gick jagigenom allt material ett flertal gånger, och kompletterade problemlistan allt eftersom.

Att använda kritiskt index som intern rankning av problem fungerade oftast bra, men gav i vissafall resultat som var kontraintuitiva. Felet ”Förstår inte MIDI” fick till exempel 4,8 i kritisktindex, vilket spontant känns lågt om man jämför det med ”Fel Step View (17-32) i Redrum”som fick 5,0. Att användaren inte förstår hur MIDI fungerar känns spontant som ett mycketstörre problem än att en omkopplare hamnat i fel läge. De få konstiga resultaten verkar främstbottna i frekvensskalans relativt grova steg i kombination med hur vi definierat och registreratproblemet. Kanske var det fler testpersoner som inte heller förstod MIDI, men aldrig hamnade ien sådan situation där detta var så tydligt att det var just bristen på förståelse av MIDI som varproblemet. Överlag måste jag dock säga att analysmetoden varit ett mycket bra verktyg för att fåordning och värdera de olika problemen.

Analysarbetet har inneburit en hel del tolkning av resultaten, och denna tolkning hade kunnatgöras på många olika sätt. Grupperingen av användarproblem i huvud- och delmål är ju främstbaserad på vår tolkning av vilket mål testpersonerna för tillfället ville uppfylla, vilket i sin turbaserades på diskussionen under testet och analys av videomaterialet. Huruvida programmeringav en stegsequencer räknas som att spela in eller inte är också en typ av fråga vi var tvungna attta ställning till. Detta har vi gjort baserat på vår kunskap om programmet och domänen. Huromfattande de olika huvud- och delmålen görs påverkar också direkt deras summerade kritiskaindex. En möjlig (men inte så informativ) uppdelning hade ju kunnat vara att bara ha etthuvudmål, nämligen ”Göra en låt i Reason”, och sedan samla alla användarproblem under det.Den uppdelning som nu presenteras är resultatet av många diskussioner och omtolkningar.

Page 45: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Diskussion

41

Något annat vi märkte under analysen av problemen som uppstått i användartesterna var att detibland var svårt att skilja på vad som var ett problem och vad som var en orsak. Är till exempel”Patchfiltret [i browsern] är aktiverat som default” ett problem i sig, eller bara en orsak tillhuvudproblemet ”Användaren får tomma mappar”? Detta hade betydelse för hur vi kom attstrukturera problemen i olika nivåer och grupper. Diskussionerna kring dessa frågor gav om intetydligare svar så i alla fall fördjupad kunskap om problematiken.

Eftersom användartesterna och analysen av dessa tog längre tid än planerat hann jag inteutvärdera designförslagen mer än en gång. Tyvärr gav heller inte utvärderingarna specielltmycket ny information, och relativt få förändringar av förslagen gjordes. Anledningar till dettakan ha varit att designförlagen fortfarande var på en alltför konceptuell nivå för att fungera somriktiga prototyper. Det var svårt att engagera testpersonerna i scenarion och diskussionerna blevav mer allmän karaktär. En annan orsak kan ha varit att ingen av testpersonerna hade använtReason under tiden mellan användartesterna och utvärderingen, vilket gjort att de glömt en delav hur programmet fungerade, vilket gjorde det svårare att göra jämförelser.

Hårdvarumetaforen

Även om det inte ingick i studien tycker jag det har varit intressant att fundera kring hurmetaforen till fysisk hårdvara påverkat eller hjälp nybörjaranvändarna. Sammantaget kan mansäga att testpersonerna inte blev speciellt hjälpta av hårdvarumetaforen. En del användare hadeförst svårt att förstå att man måste ha en enhet för att skapa ljud och man kommenteradeenheterna som ”ljudfunktioner”. Förvirringen som uppstod kring till exempel hur internastegsequencers fungerar i kombination med den vanliga sequencern bottnar egentligen ihårdvarumetaforen. Hade Reason inte varit baserat med hårdvara som förebild hadestegsequencerns funktion antagligen funnits i den vanliga sequencern, och därmed inte skapatlika mycket problem. Med vetskap om att allt färre användare har erfarenhet av hårdvara bordePropellerheads fundera på i vilken utsträckning Reason eller framtida produkter bör använda sigav metaforer som designlösning.

Testpersonernas upplevelse

Som vi sett i resultatdelen uppstår det en hel del problem då nybörjare ska lära sig Reason. Trotsmotgångarna tyckte dock alla testpersoner efteråt att det varit roligt att testa programmet.Belöningen i form av att kunna skapa sin egen musik uppvägde den frustration de kände när dekörde fast. Detta förlåtande beteende var även tydligt på detaljnivå, när de ofta glatt fortsatte såfort de övervunnit ett allvarligt problem. Användare verkar vana vid att det är relativt smärtsamtatt lära sig ett nytt program, och är förberedda på det värsta. Att testa olika ljud i ljudbankernasamt programmera trummönster i Redrum var de tydligaste glädjeområdena, och det var härsom testpersonerna oftast fick sin första ”belöning” för sitt hårda arbete. Att minimera tiden dettar att nå hit, och även antalet moment som krävs, är antagligen det viktigaste målet för hurReason ska bli mer framgångsrikt hos nybörjare. Till skillnad från kontorsprogram eller andraIT-system används ju Reason främst för hobby- och kreativ verksamhet, vilket gör attanvändarna ofta har en helt annan drivkraft att lära sig programmet. Detta bör utnyttjas.

Framtida studierSom vi har sett kan användartester ge mycket input till designarbetet. Denna studie har haftkaraktären av en nollpunktsmätning, och har delvis därför och delvis på grund av de akademiskakraven för ett examensarbete varit ganska omfattande. Ifall Propellerheads i framtiden skullevilja arbeta mer med användartester skulle det vara mer effektivt att göra fler, mindreomfattande och mindre formella tester. Jämförande utvärderingar av parallellt framtagnaprototyper av enskilda funktioner eller delar i programmet skulle kunna generera mycketkunskap och förslag till förändringar. Även tester av tidiga versioner av hela programmet skulle

Page 46: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Diskussion

42

kunna identifiera viktiga problemområden i gränssnittet. Det viktiga är bara att det finns tid attimplementera eventuella förändringar.

Materialet från användartesterna skulle kunna utgöra grunden för ett mer strukturerat arbetekring att ta fram personas. De personas som finns idag är kanske inte tillräckligt underbyggdamed empiriska data för att vara riktigt användbara. Reason har nu uppdaterats ett flertal gånger,och i varje uppdatering har ny funktionalitet, främst i form av nya enheter, lagts till. Kanskefinns det en risk att man blir alltför funktionsinriktad och bygger ut programmet tills det har såmycket funktionalitet att det egentligen inte är speciellt anpassat för någon. Detta kan man sägahar hänt med Microsoft Word, vars kraftfulla formatteringsalternativ antagligen inte används aven typisk användare. Med hjälp av personas skulle designbesluten hela tiden kunna kopplas tillen primär persona, och en förhoppningsvis smart uppdelning av Reason i olika varianter skullekunna göras. Adobes bildredigeringsprogram Photoshop finns till exempel i en enklare versionkallad Photoshop Elements, där vissa funktioner är annorlunda mot den fullstora versionen. Tillexempel väljs automatiskt ”rätt” lager ifall användaren markerar ett antal pixlar i ett tomt lager.En expertanvändare skulle säkert bli galen på denna funktionalitet, men för en nybörjare ellermedelanvändare fungerar den antagligen mycket bra. Parallellen till Reasons problematik kringhuruvida markering av ett sequencerspår innebär att MIDI Input sätts till spåret (se H6 Få enenhet att låta sid 22 samt Easy Mode sid 38) är i författarens ögon slående.

Page 47: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Referenser

43

Referenser

Tryckta källorBEYER H. OCH HOLTZBLATT K. 1998. Contextual Design. Morgan Kaufmann.ISBN 1-55860-411-1.

COOPER J. 1999. The Inmates Are Running The Asylum. Sams Publishing. ISBN 0-672-31649-8

COOPER J. OCH REIMANN R. 2003. About Face 2.0. Wiley Publishing. ISBN 0-7645-26413

DERRETT, N. 2004. Heckel’s Law: Concusions From The user Interface Design of a musical

appliance – the Bassoon. Pers Ubiquit Comput (2004) 8: 208-212

DUIGNAN, M., NOBLE J., BARR P. & BIDDLE R. 2004. Metaphors for Electronic Music

Production in Reason and Live. APCCHI04: Asia-Pacific Computer and Human Interaction.

FERNANDES G. OCH HOLMES C. 2002. Applying HCI to Music-Related Hardware. CHI ’02Extended Abstracts On Human Factors In Computing Systems, sid. 870-871.ISBN 1-58113-454-1

FERREIRA J, BARR P. & NOBLE J. 2005. The Semiotics of User Interface Redesign. i M..Billinghurst & A. Cockburn, (red), CRPIT: Proceedings of the 6th Australian User Interface

Conference, Vol. 40, Australian Computer Society, Inc., Newcastle, Australia, sid. 47—53

GULLIKSEN, J. & GÖRANSSON B. 2002. Användarcentrerad systemdesign. Studentlitteratur.ISBN 91-44-02029-5

GULLIKSEN, J., GÖRANSSON B., BOIVIE I, BLOMKVIST S., PERSSON J. & CAJANDER Å. 2003.Key Principles for User-Centered Systems Design. Behaviour & Information Technology, nov-dec 2003, vol. 22, nr. 6, 397–409

HUNT ANDY 2000. Radical User Interfaces for Real-Time Musical Control. PhD Thesis,University of York

JORDAN P. W. (red) 1996. Usability Evaluation in Industry. Taylor & Francis. ISBN 0-7484-0460-0

MANNING PETER 2004. Electronic and Computer Music. Oxford University Press.ISBN 0-19-517085-7

THE MUSIC TRADES, The Global 225, vol 152, nr 11, ISSN 0027-4488.

NIELSEN JAKOB 1993. Usability Engineering. Academic Press. ISBN 0-12-518405-0

NOBLE J. & BIDDLE R. 2001A. Program Visualisation for Visual Programs. Third AustralasianUser Interface Conference AUIC2002, Conferences in Research and Practise in InformationTechnology, vol 7, Grundy J. & Calder P. (red)

NOBLE J. & BIDDLE R. 2001B. Visualising 1,051 Visual Programs. Australian Symposium onInformation Visualisation, Conferences in Research and Practise in Information Technology,vol 9, Eades P. & Pattison T. (red)

NORMAN, D. A & DRAPER, S.W. (red) 1986. User Centered System Design. Lawrence ErlbaumAssociates. ISBN 0-89859-872-9

NORMAN, DONALD 2002. The Design Of Everyday Things. Basic Books. ISBN 0-465-06710-7

PENNYMAN, B. W. 1985. Computer-Music Interfaces: A Survey. Computing Surveys, Vol. 17,nr. 2, juni 1985

Page 48: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Referenser

44

RUBIN JEFFREY. 1994. Handbook of Usability Testing. John Wiley & Sons.ISBN 0-471-59403-2

SEAGO ALLAN. 2004. Analysis of the Synthesizer User Interface: Cognitive Walkthrough and

User Tests. Technical Report No: 2004/15, http://computing.open.ac.uk

SEAGO A., HOLLAND S. OCH MULHOLLAND P. 2004. Synthesizer User Interface Design –

Lessons Learned from a Heuristic Review. Technical Report No: 2004/20,http://computing.open.ac.uk

SNYDER, CAROLYN. 2003. Paper Prototyping. Morgan Kaufmann Publishers.ISBN 978-1-55860-870-2

InternetkällorABLETON, http://www.ableton.com. Besökt 2006-05-15

ADOBE, www.adobe.com/products/acrobat/pdfs/acrruserguide.pdf. Besökt 2006-05-14

AMBROSIA SOFTWARE, http://www.ambrosiasw.com/utilities/snapzprox. Besökt 2006-05-09

APPLE, http://www.apple.com/ilife/garageband. Besökt 2006-05-13

BARR P., BIDDLE R. & NOBLE J. 2002. A Taxonomy Of User-Interface Metaphors. TechnicalReport, Victoria University of Wellington, http://www.mcs.vuw.ac.nz/comp/Publications/CS-TR-02-11.abs.html. Besökt 2006-05-15

CLAVIA, http://www.clavia.se/products/discontinued/nordmodular. Besökt 2006-05-15

CYCLING ’74, http://www.cycling74.com/products/maxmsp. Besökt 2006-05-12

ELECTRONIC MUSICIAN, http://advertisers.emusician.com/market. Besökt 2006-05-12

IBM Real Things Design Guide http://www-3.ibm.com/ibm/easy/eou_ext.nsf/publish/581.Besökt 2006-05-01

MACKIE 1402-VLZ Pro Mixer http://www.mackie.com/products/1402vlzpro/index.html.Besökt 2006-05-01

NATIVE INSTRUMENTS http://www.native-instruments.com/index.php?id=koresound_us. Besökt2006-05-13

PROPELLERHEAD SOFTWARE AB www.propellerheads.se. Besökt 2006-05-01

REBIRTH MUSEUM www.rebirthmuseum.com. Besökt 2006-05-01

Page 49: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

45

Bilagor

Bilaga A: användarkontrakt

Villkor för medverkan i användarstudie av Reason

Undertecknad har tagit del av nedanstående villkor för medverkan i användarstudie avmusikprogrammet Reason.

Användarstudien av Reason är en del av ett examensarbete på Kungliga Tekniska Högskolanutfört av teknologen Anders Ljung på uppdrag av Propellerhead Software AB.

Syftet med användarstudien är att underlätta för nybörjare av att snabbt och enkelt komma igångmed Reason. Studien kommer att presenteras i en rapport och kommer att finnas tillgänglig förnedladdning på Internet.

Användarstudien består av

• ett ca 2 timmar långt användartest (så kallad Contextual Inquiry)• en skriftlig enkät om tidigare musikerfarenhet och datorvana• maximalt tre ytterligare användartest/workshops (3 x 2 timmar)

Alla resultat baserade på användartester (enkäter, fokusgrupper, intervjuer med mera) kommeratt behandlas anonymt och konfidentiellt. Resultaten kommer att redovisas i en avpersonifieradrapport i form av grafer, tabeller och citat. Inga enskilda resultat eller annan data kommer attdistribueras till andra personer eller organisationer.

Användartesten kommer att dokumenteras med video. Videoinspelningarna kommer endast attanvändas i utvärderingssyfte internt inom Propellerhead Software AB och videxjobbsredovisningen.

Att delta i användarstudien är frivilligt, och deltagaren kan när som helst avbryta sinmedverkan. Som ersättning får varje deltagare en (icke uppgraderingsbar) licens på Reason(värde 3995kr). Om deltagaren av någon anledning inte kan eller vill slutföra studien kommerersättning motsvarande 150kr/timme för nedlagd tid att utbetalas.

Stockholm / 2006

_________________________________ _________________________________

Namnteckning testperson Anders Ljung

_________________________________

Namnförtydligande

Page 50: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

46

Samtycke till behandling av personuppgifter

Porpellerheads Software ABs (bolagets) behandling av vissa personuppgifter kräver enligtpersonuppgiftslagen att deltagaren i användarstudien (försökspersonen) lämnar sitt samtycke.Dessutom krävs att Bolaget givit försökspersonen information om ändamålet med behandlingen.Denna bilaga avser att ge försökspersonen nämnda information och att försökspersonen gerBolaget nödvändigt samtycke enligt följande:

Bolaget kan komma att behandla uppgifter om försökspersonen inklusive försökspersonenpersonnummer, vilka försökspersonen inom ramen för sin medverkan i studien kan komma attlämna till Bolaget. Uppgifterna används för att bolaget skall kunna uppfylla sina skyldigheterenligt användarstudien gentemot försökspersonen. Det kan gälla skyldigheter gentemotmyndigheter till exempel skattemyndigheten.

Uppgifter kan också komma att överföras till andra företag inom Bolagets koncern och därmedgöras tillgängliga i datornätverk inom och utom EU.

Försökspersonen har rätt att i enlighet med personuppgiftslagen från Bolaget få information ombehandlingen av de personuppgifter som berör försökspersonen och Bolaget kommer påförsökspersonen begäran rätta felaktiga personuppgifter (Bolaget kommer naturligtvis även rättafelaktiga personuppgifter som upptäcks utan att försökspersonen påtalar det) samt respekteraförsökspersonen rätt att återkalla lämnat samtycke.

Genom undertecknandet av detta dokument samtycker försökspersonen till Bolagets behandlingav försökspersonen personuppgifter enligt ovan.

Stockholm den ____________________

_________________________________

Namnteckning testperson

_________________________________

Namnförtydligande

Page 51: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

47

Bilaga B: bakgrundsenkät

Användarstudie av Propellerheads ReasonSvaren från enkäten är anonyma och kommer att behandlas konfidentiellt.

Allmän datorvana

1. Hur ofta använder du en dator?

� Flera gånger per dag

� Någon gång per dag

� Någon gång per vecka

� Mer sällan

� Aldrig

� Vet ej

2. Vilka typer av program använder du regelbundet?

� E-postprogram � Ordbehandling � Webbläsare

� Grafikprogram � Videoredigering � Animationsprogram

� Mediaspelare � Musikprogram � Datorspel

� Annat:

Musikerfarenhet

3. Spelar du något instrument?

� Nej inget

� Piano/keyboard

� Stränginstrument

� Blåsinstrument

� Slagverk

� Annat:

4. Sjunger du?

� Ja

� Nej

5. Spelar du, eller har du spelat i band?

� Nej

� Ja ! I hur många år? _____ år

Page 52: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

48

6. Har du någon typ av musikutbildning?

� Nej ingen

� Gymnasium

� Kommunala musikskolan

� Musikhögskola

� Musikvetenskap

� Privatundervisning

� Annan:

7. Har du använt MIDI-instrument?

� Har använt regelbundet i flera år

� Har använt sporadiskt

� Har aldrig använt

� Vet ej

Musikprogram

8. Hur ofta använder du musikprogram för att skapa musik?

� Flera gånger per dag

� Någon gång per dag

� Någon gång per vecka

� Någon gång per månad

� Mer sällan

� Aldrig

� Vet ej

9. Vilket/vilka program använder du då?

� Cubase � Acid

� Logic � Ableton Live

� ProTools � Reason

� Cakewalk � Garageband

� Annat:

10. Vilka musikstilar gör du/vill du göra musik i?

� Pop/rock � Hip Hop � Schlager � Filmmusik

� Techno � Jazz � R’nB � Klassiskt

� House � Synt � Annan:

11. Vilka av följande musikbegrepp känner du till och kan förklara?

� Tempo � Metronom � Klick � Shuffle

� Oktav � Ackord � Tonart � Sequencer

� MIDI � Reverb � Sampler � CV

Page 53: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

49

Reason

12. Vad vet du om Reason?

Bakgrundsvariabler

13. Hur gammal är du? ______ år

Page 54: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

50

Bilaga C: Instruktioner till testpersonernaReason är ett program för att skapa musik. Det finns ljudmoduler för att skapa ljud, styra ljudoch modulera ljud. Det finns också mixers för att blanda ljudkällorna och en sequencer (digital”bandspelare”, eller egentligen en digital ”pianorulle”) som kan spela in musiken på flerakanaler.

Du har i uppdrag att med hjälp av programmet skapa ett stycke musik, ca 10 – 20 sekunderlångt. Vi vill på det sättet se hur programmets utformning hjälper dig eller försvårar för dig attskapa musiken. Det är INTE du som testas, det är programmet!

När du använder programmet under testet ber vi dig ”tänka högt”, d.v.s. försöka förklara hur dutänker när du gör olika moment. Om du får problem vill vi att du försöker förklara vadproblemet är och hur du tänker försöka hantera situationen. Du får använda tillgängligahjälpresurser såsom online-hjälp, manual, Internet eller annat. För att du ska få prova på fleradelar av programmet kan vi hjälpa dig vidare i vissa fall. Förutsättningen är att du provat attkomma vidare och helt kört fast. Vi ber dig dock att först och främst försöka som du skulle hagjort om vi inte varit närvarande.

Vi kommer att spela in skärmen, tangentbordet, musen, samt i och med det dina händer med envideokamera. Även ljudet kommer att spelas in. En av oss kommer också att föraminnesanteckningar över vad som händer. Inspelat material och anteckningar kommer atthanteras konfidentiellt av oss och Propellerheads. Materialet kommer att användas för attförbättra Propellerheads produkter, samt i ett examensarbete av Anders Ljung.

Page 55: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

51

Bilaga D: Kritiskt indexHär presenteras kritisktindex från testerna sorterat efter vilka användarmål de påverkade.

Frekvens Allvarlighet Kritiskt index % av totalTOTAL: 667,3

GLOBALA PROBLEMGlömmer hur han/hon gjort tidigare 2 2,5 4,5Börjar om hellre än att laga 1 2,0 3,0Scrollar iväg från aktiv enhet 1 1,0 2,0START

Problem att få överblick och konceptuell förståelse 108,9 16,3Dubbelklick på rfl-fil ger bara ett felmeddelande 1 2,0 3,0Ser inte skillnad mellan Reason och systemet 1 2,0 3,0Vill ha två skärmar (separerar sequencerfönstret) 1 3,0 4,0Tycker det är läskigt med två transportpaneler 1 2,0 3,0Tror något är fel när han läser "no MIDI input" i Audio Hardware-enheten 1 2,0 3,0Tror han flyttat en enhet när han egentligen minimerat den 1 1,0 2,0Racket autoscrollar inte för varje spår 2 2,0 4,0Terminologi: förstår inte tekniska termer 3 2,3 5,3Vill skapa en trumtakt att sampla och sen använda 1 1,0 2,0Terminologi: förstår inte musikaliska termer 1 3,0 4,0Texten är för liten 2 2,5 4,5

Vill maximera dokumentfönstret 1 1,0 2,0Klarar sig inte utan Getting Started 1 3,0 4,0Kommer bort sig i alla knappar 2 2,3 4,3Förstår inte kopplingen mellan spåren och enheterna 3 2,7 5,7Tystar alla spår i demolåten genom att koppla ur enheterna i out-menyn, misslyckas på grund av patternenheter 1 2,0 3,0

Demolåten fungerar inte 52,2 7,8Blir överväldigad eller stressad 3 2,5 5,5Dokumentet heter "untitled" (Mac) eller "Document" (Win) 2 2,5 4,5Tror att demolåtens enheter är en standarduppsättning 2 2,5 4,5Tror demolåten är ett tomt dokument 2 2,0 4,0Demolåten undervisar inte användaren 1 3,0 4,0Förstår inte Combinatorn 2 2,7 4,7Förstår inte tredelningen av spåren 2 2,0 4,0Misstar automationsindikeringen för markering 1 2,0 3,0Ändrar en inställning men hör ingen skillnad 1 3,0 4,0Basstrumman är mute:ad i demolåten 1 3,0 4,0Terminologi: förstår inte lingot (Crusher på en Combinator) 1 3,0 4,0Förstår inte skillnaden mellan mute och automatiserad mute i Redrum (automationsindikering) 1 2,0 3,0Namnlappen för en inserteffekt ändras inte när användaren byter instrumentpatch (Hip Hop Lead) 1 2,0 3,0

Problem att arbeta med en ny sång 19,0 2,8Förväntade sig en fast uppsättning enheter när han skapade en ny sång 1 1,0 2,0Minimerad sequencer 2 4,0 6,0

Ingen visuell feedback de första pixlarna när man drar upp sequencern 2 4,0 6,0Förstår inte att man behöver flera enheter för att få flera olika ljud 2 3,0 5,0

FÅ REASON ATT LÅTAVet inte var man ska börja 33,9 5,1Förstår inte att enheter är ljudmoduler 2 3,0 5,0

Spelar på klaviaturen, Mixerns mute-indikatorer blinkar, tolkar om Mixern 2 3,0 5,0Vill dra objekt in i sequencern (Arrange Mode) 1 3,0 4,0Skapar sequencerspår före eller istället för en enhet 2 2,4 4,4Fastnar i eller förstår inte OUT-menyn 2 2,5 4,5Klickar i IN-kolumnens rubrik 1 2,0 3,0Kopplar ett spår till mixern för att få ljud 1 3,0 4,0

Omedveten solo tystar alla spår 1 3,0 4,0Problem att skapa en enhet 28,9 4,3Create-listan är lång 2 2,3 4,3Create-listan är inte i prioritetsordning 2 2,5 4,5Systemet kräver att användaren förstår olika syntesmetoder (subtraktiv vs granulär, sampler etc) 2 2,6 4,6Märker inte att han skapat en enhet 2 2,5 4,5Vågar inte skapa Advanced Reverb eller Sampler 2 1,0 3,0Förstår inte att markering = insättningspunkt, genererar följdfelet att ändra patch på fel enhet 1 3,0 4,0Väljer "fel" enhet för målet/uppgiften 1 3,0 4,0Problem att ta bort en enhet 12,0 1,8Tar bort mixern av misstag 1 4,0 5,0Tar bort fel av två likadana enheter 1 3,0 4,0Använder Undo-funktionen istället för radera 1 2,0 3,0Problem att få en enhet att låta 125,6 18,8MIDI Input på fel spår 4 3,3 7,3Inget grundljud i Redrum, samplers eller DrRex 3 2,5 5,5Ljuden är bara mappade till lägsta oktaven i Redrum 2 2,8 4,8

Problem att förstå vad en patch är 18,8 2,8Ändrar på inställningar istället för att ladda en patch 2 2,3 4,3Terminologi: "Patch" är för tekniskt, "Sound" skulle vara mer användarcentrerat 2 3,5 5,5Blandar ihop "patch" med koppling (patch-kabel…) 1 2,0 3,0

Redrum 6,0 0,9Förstår inte skillnaden mellan ett Redrum Kit och enskilda samples 1 2,0 3,0Förstår inte om "Kits" är ljud eller loopar (patterns?) 1 2,0 3,0

Problem att ladda en patch 89,3 13,4Bara mappen HipHop i Acoustic Drums 1 2,0 3,0Byter patch på fel enhet 2 2,5 4,5Vill importera en sampling, väljer "Import MIDI" i tron att MIDI = enkla ljud 1 3,0 4,0Använder hellre Browsern än pilknapparna 2 1,0 3,0Byta patch från endast aktuell mapp med piltangenterna bryter mentala modellen 1 2,0 3,0Vill se vågformer i Redrum 1 3,0 4,0

Patchvalsknapparna 16,5 2,5Kan inte hitta Folder Button 2 1,5 3,5

Patchvalsgrefiken är liten 1 2,0 3,0Olika enheter har patchvalet på olika ställen 2 2,0 4,0

Klickar på Save istället för Open 2 1,0 3,0Patchknapparna är för lika varandra 1 2,0 3,0

Browsern 22,8 3,4Browsern öppnas i Dokumentmappen, inte i en ljudbank 2 2,3 4,3Ljudbankar har avvikande utseende 1 2,0 3,0Har problem att navigera i trädstrukturen 1 3,0 4,0Autoplay fungerar inte för alla typer av ljud 2 3,0 5,0Dubbelklickar REX-fil i Browsern - märker inte Autoplay 1 2,0 3,0Browsern döljer racket 2 1,5 3,5Hitta rätt patch för rätt enhet 20,1 3,0Användaren får tomma mappar 3 3,1 6,1

Patchfiltret är aktiverat som default 0 0,0Filterlogik gäller inte för mapparna 0 0,0Subtractormappen får inte plats i vyn 1 3,0 4,0Endast textuell information i browsern 1 2,0 3,0Kan inte hitta ett basljud, byter enhet 1 3,0 4,0

Börjar om från roten istället för att klättra upp i hierarkin 1 2,0 3,0Crossbrowsing 8,3 1,2Förstår inte crossbrowsing 2 2,3 4,3Sequencerspåret döps inte om när användaren byter enhet 2 2,0 4,0

Page 56: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

52

Frekvens Allvarlighet Kritiskt index % av totalTOTAL: 667,3

Problem att spela en patch 8,0 1,2Kontrabasljudets omfång är fel 1 1,0 2,0Förstår inte REX-slices mappade till tangenter 1 2,0 3,0Vill ha en stor Run-knapp på DrRex, Preview är för liten 1 2,0 3,0Problem att ändra en patch 3,0 0,4Hittar inte filtret i Subtractorn 1 2,0 3,0

INSPELNINGVet inte var man ska börja med att spela in 11,8 1,8Förstår inte MIDI 2 2,8 4,8Vill skapa keyframes som i Flash 1 3,0 4,0Vill importera MIDI (men hittar ingen?) 1 2,0 3,0Problem att programmera en stegsequencer 31,0 4,6Förstår inte steps i Redrum 1 3,0 4,0Fel step view (17-32) i Redrum 2 3,0 5,0Märker inte att Redrum går pga färgblindhet 1 3,0 4,0Förstår inte att varje trumma har sin egen step lane 1 3,0 4,0Vill rensa ett pattern i Redrum, förstår inte att det finns flera trumljud 1 3,0 4,0Måste flytta varje ton för hand i Matrix 1 2,0 3,0Tolkar patterns som ljudbanker 1 2,0 3,0Vill spara ett pattern 2 2,0 4,0Problem att spela in 102,4 15,3Tror han jobbat i fel lager (som i Photoshop) 1 2,0 3,0Skillnad mellan grid- och quantize-menyerna 1 2,0 3,0

Att använda klaviatur 37,3 5,6Tolkar Rec Select som spår av/på 1 1,0 2,0Har problem att få MIDI Input och Rec Select att hamna i rätt läge 2 2,0 4,0Hittar inte [Rec] 1 3,0 4,0[Rec] istället för [Rec] + [Play] 2 3,3 5,3Ingen inspelning före ettan 1 3,0 4,0Trycker [Rec] efter tangentnedtryckning 1 3,0 4,0

Vill ha preroll 1 3,0 4,0Svag feedback på att man spelar in 2 3,0 5,0Gillar inte att man kan stänga av record med [Rec] 1 1,0 2,0Raderar Subtractor av misstag när han misslyckats med inspelning 1 2,0 3,0Använda pennan 16,0 2,4Ritar toner i Editorn istället för att spela in med klaviaturen (vet inte hur man gör) 1 3,0 4,0

Vill rita events i Arrange Mode 1 3,0 4,0Ingen klaviatur feedback i Edit Mode 2 3,0 5,0

Förstår inte varför det är möjligt att skapa noter av olika längd i Drum Lane 1 2,0 3,0Locators 15,3 2,3Förstår inte Locators 2 2,3 4,3Förstår inte SPL:en 1 2,0 3,0Loop On som default förvirrar användaren 2 3,0 5,0Har annan mental modell av loop 1 2,0 3,0Overdub/Replace 2,0 0,3Vet inte hur man ersätter noter 1 1,0 2,0Problem att spela in patternbyten 25,8 3,9Förstår inte hur man ska automatisera patternbyten 1 3,0 4,0Förstår inte skillnaden mellan patternmaskiner och sequencern 3 2,8 5,8"Pattern to track" är olika i Redrum/DrRex/Matrix 2 3,0 5,0Pattern byts bara på hel takt, inte direkt 1 3,0 4,0Kopplar inte A1, A2 etc till patterns 1 2,0 3,0Patternbyte verkar "försvinna" när Redrum går 1 3,0 4,0

Problem att förstå uppspelning 17,3 2,6Förstår inte Note On Events, vill ha grupper 2 2,8 4,8Förstår inte Controller Lane 1 1,0 2,0

Enheter med interna sequencers 10,5 1,6Förstår inte var ljuden kommer ifrån i Redrum 2 2,5 4,5"To Track" i Matrix går inte till den kontrollerade enheten 1 2,0 3,0Triggar både från spåret och pattern 1 2,0 3,0

ARRANGERINGGlömmer vad olika enheter gör (bas, slinga etc) 2 2,5 4,5Prövar att alt-klicka i förstoringsglaset för att zooma ut 1 1,0 2,0Förstår inte skillnaden mellan Arrange och Edit Mode 1 2,0 3,0Förstår inte hur man kommer tillbaka till Arrange Mode (efter att ha dubbelklickat en grupp) 1 3,0 4,0Vill använda notskrift 1 2,0 3,0Hittar inte scroll bars i sequencern 1 1,0 2,0

Problem att arbeta med låtstrukturen 31,0 4,6Problem med Snap To Grid 2 2,0 4,0

Grupper 10,0 1,5Bara Note On Events visar inte låtens struktur 1 2,0 3,0Kan inte kopiera/flytta toner för de inte är grupperade 1 2,0 3,0Förstår inte hur man grupperar toner 1 3,0 4,0Spår 4,0 0,6Track Mute tystar hela enheten och inte bara spåret 1 3,0 4,0Verktyg 5,0 0,7Tycker det är konstigt att linjeverktyget fungerar exakt som pilen i Arrange Mode 1 1,0 2,0Feltolkar pennan i Arrange Mode 1 2,0 3,0Locators 8,0 1,2Insert Bars Inside Locators utan feedback 1 4,0 5,0Vill kunna "loopa i 40 takter" 1 2,0 3,0

Problem att manipulera MIDI events 47,1 7,1Försöker manipulera MIDI events med handverktyget 2 1,4 3,4Pennen kan inte rita åt vänster 2 1,5 3,5Resize funkar inte åt vänster 1 2,0 3,0Kopierar och klistrar in spår istället för events 1 1,0 2,0Försöker nudge:a objekt med piltangenterna 1 1,0 2,0Vill flytta toner i tidsled i velocity lane 1 2,0 3,0Vill ändra storlek på staplarna i Velocity lane med pilen 1 2,0 3,0Note events är svåra att klicka på och markera 2 2,7 4,7Kvantiserar med fel markering (bara en ton) 1 3,0 4,0Förstår inte hur man raderar Controller data 1 2,0 3,0

Problem att läsa representationer i Edit Mode 15,5 2,3Misstolkar pennan i Edit Mode 1 2,0 3,0Förstår inte att det är halvtoner i Key Lane 1 1,0 2,0Vill att tonerna spelas när man klickar på dem i Key lane 1 1,0 2,0Förstår inte Velocity-staplarna 2 1,5 3,5Tror att Velocity-staplarna är delvis dolda 1 1,0 2,0Förstår inte Controller lane 1 2,0 3,0

Page 57: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

53

Frekvens Allvarlighet Kritiskt index % av totalTOTAL: 667,3

MIXNINGProblem att ändra mixerkanal 4,0 0,6Vrider på EQ:n fast den är avstängd 2 2,0 4,0Problem att använda effekter 17,0 2,5Tolkar Send:arnas namn som slots och vill skapa effekter där 1 2,0 3,0Vill ha reverb som inserteffekt, arv från Logic? 1 2,0 3,0Vill ha reverb på bara virveln i Redrum, förstår inte hur 1 3,0 4,0Får reverb på hela kitet i Redrum 1 3,0 4,0Förstår inte varför effektenheter inte får sitt eget sequencerspår 1 2,0 3,0Problem att koppla ihop enheter 11,0 1,6Vill göra en otillåten koppling 1 2,0 3,0Förstår inte autoroutening (markering = insättningspunkt) 1 3,0 4,0Gillar inte kablarna, vill ha en textbaserad funktion 1 3,0 4,0

HJÄLP / MANUALProblem med "Getting Started" 23,0 3,4Manualen är klumpig att hantera och leder blicken bort från skärmen 1 2,0 3,0Getting Started bygger på att man förstår allt till 100% 1 3,0 4,0För tidig introduktion av automation 1 1,0 2,0Skapar flera sånger pga Getting Started 1 1,0 2,0Skapar flera Mixers pga Getting Started 2 2,0 4,0Missledande formulering: "gör på samma sätt igen" 1 3,0 4,0Blir överväldigad 1 3,0 4,0Problem att använda hjälpen 4,5 0,7Hittar inte rätt hjälp 2 2,5 4,5

Page 58: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

54

Bilaga E: Allvarlighetsrankning per testpersonHär presenteras den uppskattade allvarligheten av användbarhetsproblemen från testernasorterat efter vilka användarmål de påverkade.

M M M M M K M M M M24 34 17 29 45 31 44 48 27 32

GLOBALA PROBLEMGlömmer hur han/hon gjort tidigare 2 3Börjar om hellre än att laga 2Scrollar iväg från aktiv enhet 1START

Problem att få överblick och konceptuell förståelseDubbelklick på rfl-fil ger bara ett felmeddelande 2Ser inte skillnad mellan Reason och systemet 2Vill ha två skärmar (separerar sequencerfönstret) 3Tycker det är läskigt med två transportpaneler 2Tror något är fel när han läser "no MIDI input" i Audio Hardware-enheten 2Tror han flyttat en enhet när han egentligen minimerat den 1Racket autoscrollar inte för varje spår 2 2Terminologi: förstår inte tekniska termer 3 3 3 3 1 1Vill skapa en trumtakt att sampla och sen använda 1Terminologi: förstår inte musikaliska termer 3Texten är för liten 3 2

Vill maximera dokumentfönstret 1Klarar sig inte utan Getting Started 3Kommer bort sig i alla knappar 3 2 2 2Förstår inte kopplingen mellan spåren och enheterna 3 2 2 3 3 3Tystar alla spår i demolåten genom att koppla ur enheterna i out-menyn, misslyckas på grund av patternenheter 2

Demolåten fungerar inteBlir överväldigad eller stressad 4 2 3 3 1 2Dokumentet heter "untitled" (Mac) eller "Document" (Win) 2 3Tror att demolåtens enheter är en standarduppsättning 3 2Tror demolåten är ett tomt dokument 2 2Demolåten undervisar inte användaren 3Förstår inte Combinatorn 3 2 3Förstår inte tredelningen av spåren 2 3 1Misstar automationsindikeringen för markering 2Ändrar en inställning men hör ingen skillnad 3Basstrumman är mute:ad i demolåten 3Terminologi: förstår inte lingot (Crusher på en Combinator) 3Förstår inte skillnaden mellan mute och automatiserad mute i Redrum (automationsindikering) 2Namnlappen för en inserteffekt ändras inte när användaren byter instrumentpatch (Hip Hop Lead) 2

Problem att arbeta med en ny sångFörväntade sig en fast uppsättning enheter när han skapade en ny sång 1Minimerad sequencer 4 4 4 4

Ingen visuell feedback de första pixlarna när man drar upp sequencern 4 4 4 4Förstår inte att man behöver flera enheter för att få flera olika ljud 3 3

FÅ REASON ATT LÅTAVet inte var man ska börjaFörstår inte att enheter är ljudmoduler 3 3 3 3

Spelar på klaviaturen, Mixerns mute-indikatorer blinkar, tolkar om Mixern 3 3Vill dra objekt in i sequencern (Arrange Mode) 3Skapar sequencerspår före eller istället för en enhet 2 2 3 2 3Fastnar i eller förstår inte OUT-menyn 3 2 2 3Klickar i IN-kolumnens rubrik 2Kopplar ett spår till mixern för att få ljud 3

Omedveten solo tystar alla spår 3Problem att skapa en enhetCreate-listan är lång 2 3 3 1Create-listan är inte i prioritetsordning 3 3 3 1Systemet kräver att användaren förstår olika syntesmetoder (subtraktiv vs granulär, sampler etc) 3 2 3 3 2Märker inte att han skapat en enhet 2 3Vågar inte skapa Advanced Reverb eller Sampler 1 1 1Förstår inte att markering = insättningspunkt, genererar följdfelet att ändra patch på fel enhet 3Väljer "fel" enhet för målet/uppgiften 3Problem att ta bort en enhetTar bort mixern av misstag 4Tar bort fel av två likadana enheter 3Använder Undo-funktionen istället för radera 2Problem att få en enhet att låtaMIDI Input på fel spår 4 3 3 3 4 3 4 3 3Inget grundljud i Redrum, samplers eller DrRex 3 3 2 3 1 3Ljuden är bara mappade till lägsta oktaven i Redrum 2 3 3 3

Problem att förstå vad en patch ärÄndrar på inställningar istället för att ladda en patch 3 3 3 0Terminologi: "Patch" är för tekniskt, "Sound" skulle vara mer användarcentrerat 4 4 3 3Blandar ihop "patch" med koppling (patch-kabel…) 2

RedrumFörstår inte skillnaden mellan ett Redrum Kit och enskilda samples 2Förstår inte om "Kits" är ljud eller loopar (patterns?) 2

Problem att ladda en patchBara mappen HipHop i Acoustic Drums 2Byter patch på fel enhet 2 3Vill importera en sampling, väljer "Import MIDI" i tron att MIDI = enkla ljud 3Använder hellre Browsern än pilknapparna 1 1Byta patch från endast aktuell mapp med piltangenterna bryter mentala modellen 2Vill se vågformer i Redrum 3

PatchvalsknapparnaKan inte hitta Folder Button 2 1

Patchvalsgrefiken är liten 2Olika enheter har patchvalet på olika ställen 2 2

Klickar på Save istället för Open 1 1Patchknapparna är för lika varandra 2

BrowsernBrowsern öppnas i Dokumentmappen, inte i en ljudbank 2 2 3Ljudbankar har avvikande utseende 2Har problem att navigera i trädstrukturen 3Autoplay fungerar inte för alla typer av ljud 3 3 3 3Dubbelklickar REX-fil i Browsern - märker inte Autoplay 2Browsern döljer racket 1 2 2 1Hitta rätt patch för rätt enhetAnvändaren får tomma mappar 4 3 2 3 2 4 3 4

Patchfiltret är aktiverat som defaultFilterlogik gäller inte för mapparnaSubtractormappen får inte plats i vyn 3Endast textuell information i browsern 2Kan inte hitta ett basljud, byter enhet 3

Börjar om från roten istället för att klättra upp i hierarkin 2CrossbrowsingFörstår inte crossbrowsing 3 2 2Sequencerspåret döps inte om när användaren byter enhet 2 2

Mia 1 Mia 2 Muso Switcher

Page 59: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

55

M M M M M K M M M M24 34 17 29 45 31 44 48 27 32

Problem att spela en patchKontrabasljudets omfång är fel 1Förstår inte REX-slices mappade till tangenter 2Vill ha en stor Run-knapp på DrRex, Preview är för liten 2Problem att ändra en patchHittar inte filtret i Subtractorn 2

INSPELNINGVet inte var man ska börja med att spela inFörstår inte MIDI 3 4 3 1Vill skapa keyframes som i Flash 3Vill importera MIDI (men hittar ingen?) 2Problem att programmera en stegsequencerFörstår inte steps i Redrum 3Fel step view (17-32) i Redrum 3 3Märker inte att Redrum går pga färgblindhet 3Förstår inte att varje trumma har sin egen step lane 3Vill rensa ett pattern i Redrum, förstår inte att det finns flera trumljud 3Måste flytta varje ton för hand i Matrix 2Tolkar patterns som ljudbanker 2Vill spara ett pattern 2 2Problem att spela inTror han jobbat i fel lager (som i Photoshop) 2Skillnad mellan grid- och quantize-menyerna 2

Att använda klaviaturTolkar Rec Select som spår av/på 1Har problem att få MIDI Input och Rec Select att hamna i rätt läge 2 2Hittar inte [Rec] 3[Rec] istället för [Rec] + [Play] 3 3 3 4Ingen inspelning före ettan 3Trycker [Rec] efter tangentnedtryckning 3

Vill ha preroll 3Svag feedback på att man spelar in 3 3Gillar inte att man kan stänga av record med [Rec] 1Raderar Subtractor av misstag när han misslyckats med inspelning 2Använda pennanRitar toner i Editorn istället för att spela in med klaviaturen (vet inte hur man gör) 3

Vill rita events i Arrange Mode 3Ingen klaviatur feedback i Edit Mode 3 3

Förstår inte varför det är möjligt att skapa noter av olika längd i Drum Lane 2LocatorsFörstår inte Locators 2 3 2Förstår inte SPL:en 2Loop On som default förvirrar användaren 3 3 3Har annan mental modell av loop 2Overdub/ReplaceVet inte hur man ersätter noter 1Problem att spela in patternbytenFörstår inte hur man ska automatisera patternbyten 3Förstår inte skillnaden mellan patternmaskiner och sequencern 3 3 3 2 3 3"Pattern to track" är olika i Redrum/DrRex/Matrix 3 3Pattern byts bara på hel takt, inte direkt 3Kopplar inte A1, A2 etc till patterns 2Patternbyte verkar "försvinna" när Redrum går 3

Problem att förstå uppspelningFörstår inte Note On Events, vill ha grupper 3 3 2 3 3Förstår inte Controller Lane 1

Enheter med interna sequencersFörstår inte var ljuden kommer ifrån i Redrum 3 2"To Track" i Matrix går inte till den kontrollerade enheten 2Triggar både från spåret och pattern 2

ARRANGERINGGlömmer vad olika enheter gör (bas, slinga etc) 3 2Prövar att alt-klicka i förstoringsglaset för att zooma ut 1Förstår inte skillnaden mellan Arrange och Edit Mode 2Förstår inte hur man kommer tillbaka till Arrange Mode (efter att ha dubbelklickat en grupp) 3Vill använda notskrift 2Hittar inte scroll bars i sequencern 1

Problem att arbeta med låtstrukturenProblem med Snap To Grid 2 2

GrupperBara Note On Events visar inte låtens struktur 2Kan inte kopiera/flytta toner för de inte är grupperade 2Förstår inte hur man grupperar toner 3SpårTrack Mute tystar hela enheten och inte bara spåret 3VerktygTycker det är konstigt att linjeverktyget fungerar exakt som pilen i Arrange Mode 1Feltolkar pennan i Arrange Mode 2LocatorsInsert Bars Inside Locators utan feedback 4Vill kunna "loopa i 40 takter" 2

Problem att manipulera MIDI eventsFörsöker manipulera MIDI events med handverktyget 1 2 1 1 2Pennen kan inte rita åt vänster 2 1Resize funkar inte åt vänster 2Kopierar och klistrar in spår istället för events 1Försöker nudge:a objekt med piltangenterna 1Vill flytta toner i tidsled i velocity lane 2Vill ändra storlek på staplarna i Velocity lane med pilen 2Note events är svåra att klicka på och markera 3 2 3Kvantiserar med fel markering (bara en ton) 3Förstår inte hur man raderar Controller data 2

Problem att läsa representationer i Edit ModeMisstolkar pennan i Edit Mode 2Förstår inte att det är halvtoner i Key Lane 1Vill att tonerna spelas när man klickar på dem i Key lane 1Förstår inte Velocity-staplarna 1 2Tror att Velocity-staplarna är delvis dolda 1Förstår inte Controller lane 2

Mia 1 Mia 2 Muso Switcher

Page 60: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

Bilagor

56

M M M M M K M M M M24 34 17 29 45 31 44 48 27 32

MIXNINGProblem att ändra mixerkanalVrider på EQ:n fast den är avstängd 2 2Problem att använda effekterTolkar Send:arnas namn som slots och vill skapa effekter där 2Vill ha reverb som inserteffekt, arv från Logic? 2Vill ha reverb på bara virveln i Redrum, förstår inte hur 3Får reverb på hela kitet i Redrum 3Förstår inte varför effektenheter inte får sitt eget sequencerspår 2Problem att koppla ihop enheterVill göra en otillåten koppling 2Förstår inte autoroutening (markering = insättningspunkt) 3Gillar inte kablarna, vill ha en textbaserad funktion 3

HJÄLP / MANUALProblem med "Getting Started"Manualen är klumpig att hantera och leder blicken bort från skärmen 2Getting Started bygger på att man förstår allt till 100% 3För tidig introduktion av automation 1Skapar flera sånger pga Getting Started 1Skapar flera Mixers pga Getting Started 2 2Missledande formulering: "gör på samma sätt igen" 3Blir överväldigad 3Problem att använda hjälpenHittar inte rätt hjälp 2 3

Mia 1 Mia 2 Muso Switcher

Page 61: Propellerhead Reason för nybörjare - KTH · Propellerhead Reason för nybörjare Användarcentrerad utvärdering och designprocess ANDERS LJUNG Examensarbete i människa-datorinteraktion

TRITA-CSC-E 2006:118 ISRN-KTH/CSC/E--06/118--SE

ISSN-1653-5715

www.kth.se