HEADSET I SPEL Interaktionsdesign av system för audiell kommunikation via headset i spel

Transkript

1 HEADSET I SPEL Interaktionsdesign av system för audiell kommunikation via headset i spel Mikael Onsjö, CTH f00mion@dd.chalmers.se Interaktionsdesign grafiska gränssnitt Mikael Onsjö f00mion@dd.chalmers.se 1

2 Sammanfattning Den här uppsatsen avser att diskutera hur man kan implementera interaktionen för ett system som går ut på att ett antal användare med var sitt headset skall kunna välja vilka de talar till. Systemet skall finnas i ett spel som konstrueras i ett projekt på Chalmers. Vi lägger fram tre designer och finner att vilken som är lämplig beror på exakt hur stor kontroll man vill låta användaren ha över systemet. Detta i sin tur är en avvägning mellan å ena sidan användbarhet och å andra sidan enkelhet, men det kan också hända att den mer komplexa lösningen blir rellevant eftersom den lätt kan lösa andra problem i spelets interface. De olika nivåerna av kontroll vi diskuterar är: 1. endast val mellan alla, medspelare eller ingen. 2. val mellan alla, medspelare, ingen eller enskilld person. 3. full kontroll över grupperingar Mikael Onsjö f00mion@dd.chalmers.se 2

3 Innehållsförteckning Sammanfattning... 2 Innehållsförteckning... 3 Inledning... 4 Bakgrund... 4 Förutsättningar... 4 Designkategorier... 5 Användarens kontroll över systemet... 5 Visuell återgivning av systemstatus... 5 Styrning... 5 Designförslag... 6 Ett annorlunda förslag med hög valfrihet... 6 En mycket enkel design... 7 En variant med större frihet... 8 Diskussion... 9 Slutligen... 9 Referenser Mikael Onsjö f00mion@dd.chalmers.se 3

4 Inledning Den här uppsatsen skrivs i kursen Interaktionsdesign Grafiska Gränssnitt på Chalmers. Den avser att utifrån vissa givna förutsättningar diskutera möjliga designer för ett delsystem; den avser ej att göra någon sofistikerad användar- eller upgiftsanalys och prototyperna kommer vara mycket enkla i form av bilder. Evaluering av designförslag görs informellt heuristiskt eller med kognitiva genomgångar; användare kommer ej personligen att involveras. Bakgrund Spelprojektgrupp B i kursen Projektkurs D på Datateknik har beslutat att göra ett slags mechspel med namnet Dtektor. Spelet skall kunna spelas av flera användare över nätverk och det har beslutats att systemet skall stödja direkt audiell kommunikation mellan spelare genom att var och en har ett headset. Problemet som uppstår är hur interaktionen med systemet som sköter headsetet skall fungera. Förutsättningar Spelets övriga interface är i skrivande stund inte designat så förslagen i den här uppsatsen kommer att hållas allmänna för att lätt kunna införlivas i designer eller för att ge riktlinjer om hur den övriga designen kan stödja kommunikationssystemet. Gruppen har beslutat att spelet skall uppmuntra till social interaktion mellan användarna och att det skall vara ett lagspel med två lag. Kommunikationssystemet bör därför göra det möjligt för en användare att välja vilka han talar till (vilka som skall höra vad han säger i headsetet). Användaren måste hela tiden veta vilka som adresseras; misstag som tex. innebär att motståndarlaget hör något som det egna laget håller hemligt måste undvikas eftersom det skulle leda till misstro mot systemet och motverka dess syfte (social interaktion). Därför önskas en konstant och tydlig återgivning av aktuell systemstatus. Gränssnittet får inte kräva för mycket av användarens resurser eftersom denne är fokuserad på spelet som ofta kommer att vara mycket händelserikt. Detta leder återigen till ett krav på tydlig återgivning av systemstatus eftersom det annars belastar användarens minnesresurser. Därtill måste gränssnittet vara diskret och inte störa för mycket av den övriga designen eller i onödan påkalla användarens uppmärksamhet. Spelet kommer styras med tangentbord och mus, men musen kommer vara starkt kopplad till andra funktioner och bör därför inte användas till att styra kommunikationssystemet. Det lämnar tangentbordet eller mikrofonen i headsetet men speech recognition ligger förmodligen utanför projektets omfång och kommer därför inte att beaktas här. Mikael Onsjö f00mion@dd.chalmers.se 4

5 Designkategorier Rimliga designer kan lätt indelas/uppdelas i olika kategorier. Användarens kontroll över systemet För det första har vi en viss frihet i att välja exakt hur stor kontroll användaren skall ha över kommunikationssystemet. Den ena extremen är att inte alls stödja val av mottagare utan bestämma att alla hör alla; den andra extremen är att låta användaren kunna välja exakt vem eller vilka han vill adressera. Förmodligen är det dock önskvärt med något mellanting som inte är för komplicerat med fortfarande ger användaren frihet att utföra merparten av allt han kan tänkas vilja göra. Eftersom spelet innehåller två lag så kan det vara mycket lämpligt att tydligt och enkelt stödja val av dessa som grupp att adressera. Merparten av det som sägs angående spelet är sannolikt riktat till det egna laget, typ taktiksnack. Det kan dock fortfarande vara av intresse för andra grupperingar av spelare att kommunicera tex. provocerande kommentarer till motståndarlaget, diskussioner om speltyp eller privat snack mellan vilka som helst. Möjligheter som vi kommer att behandla i designförslagen är: 1. Val mellan egna laget eller alla. 2. Val mellan egna laget, alla eller en enda enskilld person. 3. Helt valfria grupperingar. Visuell återgivning av systemstatus Det är viktigt att användaren hela tiden vet vem han adresserar via headsetet. Man kan förvisso tänka sig någon form av ljudfeedback men eftersom användarens hörselförmåga redan är belastad av tex. musik, ljudeffekter och tal från andra spelare så kommer vi huvudsakligen att utesluta denna möjlighet. Istället intresserar vi oss för olika metoder av visuell återgivning, dvs. med ikoner, text och/eller annan grafik på skärmen som innehåller information. De första kategorierna vi skiljer på här är: 1. Konstant återgivning, dvs. information som alltid är lika synlig på skärmen. 2. Temporär återgivning, vilket avser information som blir synlig när den är rellevant. 3. Semikonstant återgivning, med vilket vi då avser grafik som alltid finns där men som ändrar utseende beroende på hur viktig den är för användaren för tillfället. Risken med konstant återgivning är att å ena sidan att den kan vara i vägen för själva spelet och störa spelarens upplevelse men också åt andra sidan att användaren vänjer sig vid det och inte uppmärksammar förändringar. Fördelarna är den viktiga informationen alltid finns tillgänglig och användaren tillåts själv avgöra när den är intressant. Temporär återgivning kan till exempel avse textmeddelanden som dyker upp varje gång förutsättningar ändras och har fördelen att de kan göras rellevanta för varje tillfälle. Nackdelen är dock att användaren måste komma ihåg eller begära informationen då han behöver den. Ett mellanting skulle exempelvis kunna vara en ikon som får skarpare färger, blinkar eller blir större när den är aktuell men blir diskretare när den inte är lika aktuell. Styrning Styrningen bör enligt tidigare argumentering göras via tangentbord. Vilket styrsätt som är lämpligt beror naturligtvis i hög grad på exakt vad användaren skall kunna välja, men det finns ändå en uppdelning som kan vara intressant: 1. Användning av ett fåtal tangenter; systemet styrs med endast ett par olika tangenter 2. Användning av flera tangenter; tex. att varje möjligt tillstånd mappas till en egen knapp Det är naturligtvis önskvärt att inte involvera en mängd olika knappar eftersom detta ställer höga krav på användarnas minne och ökar inlärningstiden för systemet. Nackdelen med att minska ned antalet knappar är å andra sidan dels att val måste göras genom sekvenser av knapptryckningar (vilket också kan leda till stora krav på användarens förmågor om det designas dåligt) och dels att det kan vara svårt att hitta en naturlig mappning av knappar mot funktioner i systemet. Mikael Onsjö f00mion@dd.chalmers.se 5

6 Designförslag Här följer några olika designförslag som kan bilda grunden för en diskussion. Ett annorlunda förslag med hög valfrihet Den här designen grundar sig på att användaren skall ha total frihet att adressera vem som helst i spelet. Eftersom det redan för ett ganska litet antal spelare blir ganska många olika möjliga kombinationer av grupper så är det inte en möjlighet att binda en tangent till var grupp. Likaså blir det svårt att finna något rimligt sätt att browsa igenom grupperna, dels eftersom det inte finns någon naturlig ordningsföljd och dels eftersom det skulle ta för lång tid. Istället väljer vi att binda varje spelare till en siffra och mappa dessa mot siffrorna på tangentbordet (alternativt funktionstangenterna). Vidare låter vi varje spelare ha en ikon som alltid är synlig på skärmen och delar upp spelarna i två grupper efter huruvida de adresseras eller ej. I ena hörnet på varje ikon sätter vi den siffra som spelaren tilldelats och detta är anledningen till att ikonerna bör vara konstant synliga: en användare måste kunna se vem som tillhör vilken siffra och ikoner (bilder) är mycket lättare att minnas associativt än siffror. Medspelare flyttas mellan de olika grupperna genom att motsvarande siffertangent trycks. Naturligtvis kan en användare inte behöva omedelbart minnas vilken ikon som tillhör vem för alla spelare. Därför låter vi ett tillfälligt textmeddelande dyka upp längst ned på skärmen med information om spelaren, hans ikon och nummer varje gång det trycks. Det verkar naturligt att lägga allting till höger på skärmen, en anledning till detta kan vara att det handlar om kommunikation och att de flesta håller telefoner i höger hand intill höger öra. Vi väljer att göra en avlång meny för att inte inkräkta för mycket på resten av spelytan. Vi väljer att göra bakgrunden mörk med mycket låg färgmättnad för att inte störa resten av gränssnittet och en aning (ca 50%) genomskinlig för att öka 3d-världens (i bakgrunden) synlighet. För de ikoner som är aktiva (symboliserar adresserade spelare) väljer vi en blå bakgrund dels eftersom blicken inte dras till blått och dels eftersom blått lätt kan förknippas med ok eller fritt fram. Knutet till det blå fältet lägger vi en ikon i form av ett öra som tydligt borde tala om vad markeringen innebär. Textmeddelandet som visas bör försvinna efterett par sekunder beroende på inställningar från användaren själv eller avvägningar efter hur avancerad målgruppen för spelet är. Om användaren väljer flera nummer i snabb följd så bör meddelandena ersätta varandra istället för hamna i en lista, detta för att inte inkräkta på spelytan och eftersom en användare som trycker siffror i snabb följd antingen kan antas läsa snabbt eller redan vet vad meddelandet säger. Mikrofon av/på kan styras med hjälp av en extra knapp, lämpligen 0, och markeras med ett rött kryss över ikonen med örat. Den röda färgen väljs med låg mättnad för att inte i alltför hög grad dra åt sig uppmärksamhet. Anledningen till att vi väljer att implementera on/off när man skulle kunna åstadkomma samma sak genom att välja bort alla spelare är att det ofta finns anledning för en spelare att inte vilja förmedla ljud via mikrofonen överhuvudtaget, men det skulle vara onödigt besvär att för honom att behöva välja alla spelare fram och tillbaka varje gång. Vidare bör det naturligtvis finnas snabbtangenter för välj medspelare och välj alla. Prototyp 1a: två valda spelare adresseras (nr 6 och 7) Prototyp 1b: mikrofonen avstängd men systemstatus i övrigt oförändrat Mikael Onsjö f00mion@dd.chalmers.se 6

7 En mycket enkel design Ett självklart alternativ skulle kunna vara att endast tillåta användaren att adressera vänner, alla eller ingen. Eftersom systemet endast har tre tillstånd så väljer vi att repressentera vart och ett med en ikon. Ikonen är en avrundad fyrkant som symboliserar mängden av samtliga spelare, med ytterligare en avrundad fyrkant uthuggen som symboliserar det egna laget. Den uthuggna fyrkanten ligger i nederdelen av ikonen eftersom denna riktning brukar förknippas med hemmaplan och vi har valt att göra fyrkanten lite mindre än resten av ikonen och omringad av fiender för att öka känslan av att den symboliserar ett tätt hopknutet team. Dessa bilder skulle sannolikt vara tillräckliga för att de flesta användare skall förstå systemet efter en kort tid, men för att underlätta inlärning så väljer vi att under varje ikon skriva ett kort ord för vilka som adresseras: team, all eller off. Detta kan även underlätta för människor som har svårt att skilja mellan färgerna i ikonen. Eftersom spelet riktar sig till ganska erfarna människor (inte till barn) så väljer vi här att inte visa ett textmeddelande när systemstatus ändras. Ett sådant skulle ta upp onödigt mycket plats på skärmen och göra förhållandevis lite nytta. Istället väljer vi att låta varje ikon få mjukare röda färger och bli lätt (ca 40%) genomskinlig efter det att systemstatus har varit oförändrat en stund (ca 3 sekunder) och när systemstatus ändras så låter vi de viktiga delarna av ikonen (de som är röda) omedelbart bli skarpare och hela ikonen ogenomskinlig. Detta borde orsaka en tydlig förändring på skärmen som drar till sig uppmärksamheten hos användaren. Efter att systemstatus varit offörändrat i ca två sekunder börjar ikonen långsamt bli mattare och genomskinlig, en förändring som inte borde påkalla uppmärksamhet. Att vi låter ikonen vänta med att tunnas ut har även den stora fördelen att om användaren ändrar systemstatus flera gånger i snabb följd så blir det inga konstiga effekter som blinkningar i ikonen. Vi har valt en mättad röd färg för de delar av ikonen som symboliserar adresserade spelare (hädanefter de aktiva delarna av ikonen) då ikonen är aktuell, detta för att dra till sig användarens uppmärksamhet. När ikonen inte är aktuell väljer vi en omättad röd färg för att den inte skall vara störande, den röda nyansen är naturligtvis fortfarande kvar för att inte störa enhetligheten genom nya färgval. Vidare har vi valt en omättad grön färg för de delar av ikonen som symboliserar icke adresserade spelare, detta eftersom färgen måste vara åt den kalla delen av spektrat för att inte dra till sig uppmärksamhet men blått skulle skära sig mot det röda och grått är trots allt för otydligt. Runt varje fält i ikonerna finns en tunn svart linje som framhäver dem ifall bakgrunden skulle få en likartad nyans. Valet av svart beror på att ikonernas övriga färger är ganska ljusa för att de skall bli tydligare mot mörk bakgrund, vilket förväntas bli vanligt i spelet. Prototyp 2a: tre möjliga tillstånd för systemet representeras av tre olika ikoner som vardera har två varianter: aktuell (till höger) och mindre aktuell (till vänster) Mikael Onsjö f00mion@dd.chalmers.se 7

8 En variant med större frihet Naturligtvis kan det tänkas att användaren vill kunna tala med en enda spelare också, precis som i telefon (vilket de flesta är vana vid). För att lösa detta överväger vi att utöka det föregående förslaget enligt figuren till höger, men finner omedelbart ett problem: En enskilld person tillhör antingen det ena eller det andra laget, men att sätta honom i mitten skulle göra att ikonen blir mer svårförstådd (en person kan ju inte tillhöra båda lagen, så pricken tolkas lätt som ett litet tredje lag i mitten) Att flytta markeringen till rätt fält beroende på vilket lag han är med i skulle förstöra konsekvensen i bilden. Istället väljer vi en variant där en prick för spelare är markerad i vardera laget, på det sättet bibehåller vi konsekvensen i bilden utan att behöva bekymra oss om tvetydigheter. Värt att notera är att vi också visar mer information än föregående exempel, nämligen vilket lag den valde spelaren är med i. Detta är passande eftersom det är lämpligt att påminna användaren om vilket fårhållande han har till den han adresserar, så att han inte avslöjar laghemligheter tex.. Färgen för det egna laget har gjorts en aning mer mättad för att ge en större kontrast mellan de båda ytorna, eftersom det nu tillkommit en relltivt stor mängd information som annars skulle stört intrycket lite och försvårat förståelse av skillnaden mellan fälten. Den högre mättnadsgraden väljs för det fält som repressenterar det egna laget eftersom det då blir tydligare, medan motståndarlaget avlägsnare. Prickarna blir dock väldigt små i ikonerna, vilket är ett problem. Vi var naturligtvis tvugna att ta bort den mörka bordern runt dem (jmf. Prototyp 3a med 3b) vilket inte försämrade resultatet men inte heller var riktigt tillräckligt. För att ordna problemet väljer vi att inte bara låta ikonerna ändra färgmättnad och genomskinlighet som i föregående design, utan också låta storlek ändras en liten aning. Ändringen får naturligtvis bara handla om några få pixlar för hela bilden och ytterligare ett par pixlar för det av de små fälten som är valt (om det är valt). Prototyp 3a: Ensam spelare markerad i mitten Prototyp 3b: Ensam spelare markerad i rätt lag Mikael Onsjö f00mion@dd.chalmers.se 8

9 Diskussion Det första designförslaget ger väldigt mycket mer än bara kontroll över headsetet, vilket skulle kunna utnyttjas. Att alla spelarna ligger synliga med numrering i bordern till höger gör att spelaren hela tiden ser vilka som är med i spelet och snabbt kan få reda på deras namn genom att trycka motsvarande siffra. Genom att göra om designen på olika sätt så kan man lätt klämma in ännu mer information eller möjligheter som inte har med headsetet i sig att göra. Snabbtangenten för välj medspelare erbjuder tex. en möjlighet för spelaren att snabbt se sitt eget team. De uppenbara nackdelarna med designen är: 1. Det tar upp mycket utrymme 2. Det visar mycket mer information än vad som behövs för att styra systemet 3. Det är i grunden komplicerat att använda eftersom det erbjuder en mängd möjligheter som aldrig kommer vara av intresse för de flesta spelare 4. Det är tekniskt svårt att implementera. Alla dessa nackdelar försviner dock snabbt om man kan hitta kombinerade användningsområden för funktionerna, eller om man gör om det för att passa in i ett annat interface som också konstant visar alla aktiva spelare. Ett mycket större problem är dock det som uppstår om användaren tilltalas av en spelare som han inte själv ställt in för att tala med. Impulsen blir ju då att svara, men då kanske någon annan hör som inte hört den förste spelaren etc. Den andra designen i ordningen är mycket liten och okomplicerad, vilket som vanligt är en mycket stor fördel. Placeringen av ikonen på skärmen är dessutom väldigt godtycklig vilket gör att den blir lätt att inkludera i ett beffintligt interface. Baksidan är naturligtvis att möjligheterna för användaren är ytterst begränsade. Att ikonen förändras beroende på hur aktuell informationen är, i den meningen att användaren har intresse av den, är naturligtvis bra. Problemet är bara att avgöra hur stort intresse användaren egentligen har... Om han gör en inställning och sedan glömmer bort den så är det mycket möjligt att han börjar prata med fel person eftersom han inte uppmärkasammar systemstatusen som diskret tonat bort. Ett bra alternativ skulle kunna vara att även låta ikonen bli aktuell varje gång användaren börjar tala i mikrofonen, dvs. genom avkänning av ljudnivå. Det tredje förslaget ger förmodligen de möjligheter som är rellevantast för en spelare. Om han absolut vill framföra något till flera personer men inte hela laget etc. Så bör det inte vara för betungande att adressera personerna en i taget precis som med telefon. Återigen dyker det upp ett problem med att spelare kan bli tilltalade av någon som de inte valt att prata med, men situationerna blir mycket mindre komplexa och är sannolikt lätta att reda ut för spelarna. Slutligen Ett problem som vi över huvudtaget inte behandlat är om spelare skall kunna välja vilka de vill lyssna på. Som det är nu så kan flera tala i mun på varandra, vilket är ytterst problematiskt. Om spelare inte ömsesidigt väljer att tala med varandra i slutna partitioner så kan det rent av bli så att de för en annan lyssnande spelare talar i mun på varandra utan att själva veta om det. Människor brukar dock inte ha något problem med att välja ut en person att lyssna på i en mängd, så problemet är sannolikt inte kritiskt. Det bidrar ändå starkt till att förespråka någon av de enklare modellerna där användaren är begränsad i vilka han talar med. Det kan också vara lämpligt att lägga in någon heuristik för vem som skall höras högst i en användares hörlurar (de som användaren själv valt att tala till, tex., eller medspelare) Att lösa problemet med någon form av rendevous (som telefoner, ena parten ringer upp och andra parten väljer att svara ) skulle kunna vara ett alternativ, men blir förmodligen alldeles för invecklat och skulle sannolikt orsaka att användarna undviker att tala till varandra eller inte hinner gå igenom handskakningsprocessen innan samtalet har blivit irrellevant. Mikael Onsjö f00mion@dd.chalmers.se 9

10 Referenser 1. Tufte, E. R. Envisioning Information 2. Preece, J et al Interaction Design beyond Human Computer Interaction. 3. Prelliminära designdokument för D3 projekt B 2003/04 Mikael Onsjö f00mion@dd.chalmers.se 10