Data Bases • Custom Term Papers • Free Term Papers • Free Research Papers • Free Essays • Free Book Reports • Plagiarism? Links • Top 100 Term Paper Sites • Top 25 Essay Sites • Top 50 Essay Sites • Search 97,000 Papers @ DirectEssays.com • Search 101,000 Papers @ ExampleEssays.com • Search 90,000 Papers @ MegaEssays.com Free Essays • Term Paper Sites • Chuck III's Free Essays • Free College Essays • TermPaperSites.com • My Term Papers • Get Free Essays • Essay World • Planet Papers

Search Lots of Essays Back to Subjects - Computers hertyuo hertyuo komma ord och meningar kontrolleras av regler för phonemics ( skillnaderna mellan orden hand och land är första bokstaven, undvik dessa ord för att slippa missförstånd) Denna metod kan hantera större respons än vad concatenation kan göra, används när stora mängder av ord krävs. 12.6 Utvecklingen inom ”output” Det här är ”gårdagens nyheter och jag tänker inte gå in närmare på det. Man tar upp multimedians utveckling och hur man kan använda sig av både ljud och bild på mer avancerade sätt i datorvärlden. I detta kapitel tittar man på de faktorer som man bör titta på när man väljer interaktionsstil. En mängd termer har använts för att beskriva kommunikationen som sker mellan människan och datorn. Intill nyligen så har interaktionen med datorn involverat endast turordningen hut texten har hamnat på skärmen. Denna interaktion kallas dialogprocess. Från användarens sida kan denna dialog brytas ner i flera steg: I den här boken använder man ordet interaktionsstilar som ett generellt ord som står för alla typer av vägar man kan gå när det gäller hur användaren kommunicerar eller integrerar med datorn. Det fanns två (kommandodrivna och formulär) olika gränssnitt från början för vanliga formulär som hade datoriserats. De designades med tanke på att de skulle passa olika uppgifter. De kommandodrivna var generella och kunde användas till olika uppgifter, medan formulärformaten designades för en speciell uppgift. I dag använder många system flera olika stilar, man kombinerar t ex olika menyer med andra styrsätt. Kommandon är ett sätt att kunna ge instruktioner direkt till datorn ( ex DOS) . Man kan använd sig av hela funktioner, enstaka ord, förkortningar eller olika kombinationer av ord och uttryck. ( t ex använd *control* ihop med bokstaven ’e’ = EXIT ). Fördelen med att kunna använda sig av enstaka tecken eller funktioner är att du behöver bara ange dessa för att processen ska utföras i jämförelse med att sitta och skriva hela ord eller längre förkortningar. En meny är en uppsättning av val som syns på skärmen efter ett visst kommando har gjorts och beroende av valet så kommer gränssnittet att ändras på skärmen. I motsats till kommandodrivna system så har menyer den fördelen att användaren inte behöver komma ihåg vad punkten i menyn står för , det räcker att känna igen den. På senare tid (tänk på bokens ålder) har man fått problem med att menyerna tar så stor plats på skärmen. Två lösningar till detta är användningen av rullgardinsmenyer ( pull-down) och ikoner (pop-upp). Rullgardinerna ramlar ner på skärmen och du klickar på det val du vill ha, ikonerna fungerar genom att du klickar på ikonen och menyn kommer fram och du kan göra ditt val. När det finns flera menyer som var och en har flera val måste användaren veta var han ska söka efter rätt val. Enklaste sättet att lösa detta är genom att det man söker matchar ihop med något av valen i menyn , detta kallas entity match . Ett exempel på entity match kan när en användare vet att han vill numrera sidorna i sitt dokument och ett val finns som heter ”NUMRERING”. Menyer måste designas så de är lätta att tolka och förstå. Problemet med designen av menyer kan vara hur man ska gruppera de olika alternativen som finns i de olika menyerna. Det finns fyra logiska alternativ på hur man ska ordna alternativen i menyerna Konventionellt (hur pass vanligt är det) Kan refereras till en outvecklad typ av menysystem där varje interaktion bara tar upp en eller två rader på skärmen. Frågorna svaras en efter en beroende på vad föregående svar var. Detta kan användas t ex vid bankomater, söka bok på biblioteket mm . Frågor & svar dialoger är systemdrivan och därför enkla för nybörjare att använda, det är svårt att göra fel, kan däremot vara frustrerande för vana användare. När mycket data ska matas in på en skärm är det en fördel att designa skärmen som ett formulär, speciellt om samma typ av data matas in regelbundet om och om igen . Fördelen med denna typ av ifyllnadsformulär är att användaren hamnar på rätt ställe och kan därför inte fylla i fel data och därför behöver inte skärmen övervakas lika mycket som annars. Formulären ska designas så att användaren lätt ser vilket fält som rätt data ska fyllas i. Utformade enligt gamla vanliga pappersformat, men de har mycket mera funktonalitet. De kan erbjuda summering av beräkningar , procentsatser mm. Fördelen med dessa är att du ser resultatet samtidigt som du arbetar eftersom allt finns på skärmen. Typ av excel. Användningen av naturligt språk när det gäller kommunikationen med datorer ses som mycket önskvärt beroende på dess naturlighet Detta innebär att man ska kunna knappa in det naturliga språket via ett tangentbord. Systemet måste kunna kopiera samma problem som kan uppstå när två människor kommunicerar dvs. otydlighet, grammatiska fel, dialekt mm. Det finns idag ( när boken skrevs) inte något system som kan tolka det naturliga språket via tangentbordet. Experiment har dock gjorts med olika alternativ, dessa kräver att användaren förstår systemet och att meningarna sägs på ett sådant sätt att de kan tolkas rätt från systemet. Direktmanipulation beskriver system som har dessa kännetecken: Synlighet av objekt som är av intresse Återställning av komplex syntax av kommandospråk genom direktmanipulation av objekten som är av intresse. Typiska direktmanipulerande system har ikoner som representerar objekt, som kan flyttas runt på skärmen med hjälp av musen. The Apple Macintosh var först med att använda sig av direktmanipulation som lyckades väldigt bra. Det bygger på en metafor av skrivbordet där objekten representeras av ikoner . Ritprogrammen ( paintbrush) är ett exempel på direktmanipulation. Ett problem med direktmanipulation är att alla objekt kanske inte kan beskrivas konkret av en ikon. T ex klipp ut ord och klistra in är svårt att illustrera vad det egentligen betyder. 13.7 Kognitivt sätt att se på manipulation Tidigare har vi tittat på kommunikationen med direktmanipulation genom de beteende och sociala aspekterna vi har, nu ska vi titta på det via det kognitiva synsättet. Hutchins har tittat på detta och har arbetat fram ett ramverk som bygger på två ”klyftor” vilka beskriver gapet mellan användarens mål och systemets profil. Nivån av direkthet i direktmanipulation i gränssnittet kan ses som avståndet mellan två klyftor. Avstånden visar hur man kan tolka en persons uppfattning av en uppgift och hur uppgiften representeras av systemet. Se bild i boken s. 273. Vitsen med att visa dessa ”klyftor” mellan användaren och systemet är att man ska se relationen mellan systemet och dess användare. Man vill försöka minska ”gapet” mellan användare och system, därför att användarna lättare ska kunna utföra sina uppgifter. Semantik direkthet: Tittar på relationen mellan vad användaren vill uttrycka och hur detta är möjligt via gränssnittet. Vill jag lägga in bilder i ett dokument och detta går bra är semantiken bra. Artikulation direkthet: Tittar på relationen mellan betydelsen av uttryck och dess fysiska form. ( Se exempel med moped i boken s.275.) Där affordance försöker visa hur ett objekt ska användas så står restrektionerna för vilka begränsningar som finns för objektet. Stoppar vissa operationer man kanske vill göra på vissa objekt, en fyrkant passar inte i ett runt hål ! Beror på användarens kunskaper om den omgivning som personen och datorn befinner sig. Innehåller information om de regler och beteenden som man måste följa. Arbetar med att objekten ska ha en logisk ordning och position. Mappning är hur en beskrivning på en nivå av abstraktion kan översättas till en annan beskrivning på en annan nivå. God mappning är när beskrivningen ses som naturlig av användaren. Dålig mappning är när beskrivningen inte stämmer med verkligheten. Bra exempel ( på bra respektive dålig mappning) i boken med spisen , titta på sidan 280. Feedback definieras som ”det som sänds tillbaka till användaren om vad som har hänt och vilket som blev resultatet.. En nyckelprincip är att god systemprofil har en synlig feedback som är kompatibel med de principer som finns inom direktmanipulation. Sammanfattning av kapitel 12, 13 gjord av Marie Persson, nd97mpn@student.hig.se KAPITEL 14 - ATT DESIGNA FÖNSTERSYSTEM Fönster är avgränsade visuella displayer som delar den fysiska displayen till flera virtuella displayer. Rent allmänt kan man säga att fönstersystemet styr in- och utmatningskällor. Dessa källor (te x skärmar och möss) hanteras på liknade sätt som ett operativsystem styr diskutrymme och processortid. Fönstersystem innehåller vanligtvis funktioner som hjälper användaren att flytta, ändra, skrolla och överföra data mellan flera fönster. Fördelar med att använda fönstersystem och fönsterapplikationer är att: Användningen av begränsat displayutrymme kan optimeras Användare kan använda sig av flera källor samtidigt på skärmen för att utföra en uppgift Användare har möjligheten att se ett speciellt objekt från flera olika vyer samtidigt på skärmen Användningen av en grupp imatningsmedel för olika uppgifter kan koordineras på ett uniformt sätt Musaktioner som orsakar olika aktiviteter i olika sammanhang förstås lättare av användarna eftersom varje fönster ger ett visuellt och textbaserat innehåll för olika typer av interageranden Användarna är skyddade från komplicerade kommandospråk och tillåts specificera objekt och aktiviteter genom att peka och välja Sättet som gränssnittet arbetar på kan lättare bli standardiserat över flera applikationer. Detta gör det lättare för användarna att lära sig nya applikationer när de väl lärt sig en. Fönstersystem kan vara väldigt användbara för användare som använder en enda display och som jobbar med mer än ett dokument eller applikation i taget. Man skapar te x ett nytt dokument, använder kalkylblad, skickar e-mail etc. Effektiviteten på ett fönstersystem beror på storleken, modell för bildkonstruktion, hastighet och skärmupplösning. Andra faktorer som påverkar effektiviteten är sättet som systemet hanterar sökbilder, d vs hur lång tid det tar att öppna, stänga, arrangera och zooma fönster. Window working set kan definieras som mängden fönster som krävs för att utföra en speciell uppgift. Denna idé introducerades av Card 1984. Card menade att det är väldigt viktigt hur mycket tid som går åt till att arrangera fönsterna på skärmen jämfört med att ha flera skärmar med ett fullstort fönster på varje skärm. Han konstaterade att det finns fördelar med fönstersystem, men om det inte finns ett bra fönsterarrangemang tillgängligt så kan de ersättas med annat. Ett alternativ till window working set kom 1987 och kallades för Rooms model, arbetsrum. Systemet tillåter speciella fönsterarrangemang att bli lagrade av användare som ett rum. Varje rum illustreras av en ikon. Ökad effektivitet blev resultatet. Varje fönstersystem måste erbjuda appliaktionsprogrammen ett schema eller språk för att visa grafiska bilder via fönstren. Ett sådant schema kallas för imaging model eller bildlik modell på svenska. Det finns två viktiga sådana modeller, bitmaps och matematiska beskrivningar av kurvor. Bitmaps är oberoende av innehåll väldigt snabba att rita upp men de kan vara svåra att förstora och förminska. Matematiska beskrivningar av kurvor är lätta att ändra storleken på och även rotera men det kan ta lång tid att rita ut dem om det är komplexa objekt. Oftast förknippar man ordet inmatningsmedel med fysiska medel, gjorda av fysiska komponenter. De virtuella medlen kan dock vara lika viktiga som fysiska. Ett virtuellt medel är ett medel som enbart existerar när datorsystemet gör en operation. Virtuella medel för inmatning kan te x vara knappar och touchareor och för utmatning ljus, nummertangenter och toner. Vissa virtuella medel är både för in- och utmatning, te x kontrollpaneler och kalkylatorn. Widgets är gränssnittskomponenter som te x kontrollpaneler, menyer och knappar. Se figur 14.3 sidan 291-292 för vanliga fönsterkomponenter i olika system. Fönster är oftast rektangulära areor på skärmen som kan flyttas, förminskas, förstoras och renderas. Vanligtvis kan man ändra vyer i fönstren genom att använda scrollbar i ramen eller editering i arean. Innehållet beror på/bestäms av den öppnade applikationen. Det finns implicita eller explicita pop-up menyer. Implicita menyer är sådana som "poppar upp" när man te x högerklickar någonstans på skrivbordet och får upp en meny. Explicita menyer är sådana som man måste klicka på bestämd plats för att få fram, te x en ikon, menyraden, fönsterkontroller osv. Visuell feedback ges oftast genom att knappen man klickar på byter färg eller skuggas. Det kan även vara att kryss eller en bock kommer upp då man klickar på ett ord. Auditiv feedback kan vara en ton eller en signal. Kontroller kan vara sliders, knappar, checkrutor os v. (Se figur 14.9 sid. 297 för vanliga kontrollwidgets) Kontrollpaneler består vanligtvis av en samling kontroller och displayer som visar användaren tillståndet på ett objekt samt tillåter olika parametrar att bli valda samtidigt. Defaultvärden är vanligtvis de mest använda valen eller de säkraste valen. Dialogrutor är "on-screen" displayer som systemet visar för att bidra med textinformation. Det kan vara att systemet ber användaren om något, te x: Systemet ber användaren att göra en mängd val Systemet ber användaren att skriva in information Systemet meddelar om viktiga saker innan man fortsätter osv. Det finns olika typer av dialogrutor, modala dialogrutor tvingar användaren att svara på någon fråga innan någon annan aktivitet kan ske. Modeless dialogrutor bidrar med information och begär någon aktion men begränsar inte användarens aktiviteter. De kan flyttas, ignoreras eller minimeras medan man gör något annat. Frågerutor och meddelanderutor initieras av systemet, inte användaren. De kräver ofta bara enkla ja/nej svar. 14.3 Gemensamma funktioner i olika fönstersystem De flesta fönstersystem tillåter att man använder mus eller tangentbord eller en kombination för att kontrollera systemet och applikationsprogrammen. Det finns fem primära aktiviteter som går att göra med musen: peka, klicka, trycka, dra och dubbelklicka. Fönstersystemet måste tydligt visa vilket fönster som för närvarnade är aktivt bland flera fönster. Detta görs oftast genom att färgen I titelraden ändras. Click to focus innebär att användarens inmatning inte styrs till något annat fönster förrän användaren klickar i fönstret. Mouse focus innebär att användarens inmatning styrs till det fönster där markören för närvarnade befinner sig. De flesta fönstersystem tillåter att användaren flyttar fönster genom att flytta musen till titelraden och sedan klicka och dra. Hantera flera fönster - när inte alla fönster får plats på skärmen samtidigt Ikonisering är en metod som tillåter skärmutrymme att bli sparat genom att förminska fönster till ikoner. Dessa kan sedan bli fullstora vid klickning. Tiling(tegelvägg) används när system inte har någon överlappning utan använder all tillgänglig yta (jämför med att mura en tegelvägg). Kaskad/överlappning är den mest använda av fönsterhanteringsmetoderna. Fönster tillåts att delvis skymma varandra. Det är en flexibel metod men det kan bli förvirrat. Kaskad är en typ av överlappning som är bäst när ett stort antal fönster måste vara öppna samtidigt på skärmen. Se figur 14.13 sidan 303 för överlappning. Handlar om problematiken med delade fönster. Det finns vissa övervägande man måste göra, te x hur kan man hindra att en användare tar bort eller modifierar något som en annan användare precis väljer? Vilken typ av "undo" verktyg behövs för att stödja fleranvändarsystem? KAPITEL 15 - Användarsupport och On-Line information 15.1 Aktiv inlärning med minimalistmanualer När minimalistinstruktioner introducerades innebar de att man tog bort repetitioner, sammanfattningar, översikter, övningar och index. Man försökte alltså reducera mängden information som en som utbildas behöver för att lära sig använda en applikation. Manualen ( se figur 15.1) designades för att bli mer uppgiftsorienterad d vs inte systemorienterad. Stor vikt lades vid hur man kan återgå från lägen där man hamnat fel. Efter en iterativ design av dessa manualer samt användartestning så visade användarna överlägsna inlärningsmaterial jämfört med traditionella manualerna. The Training Wheels modellen följer samma filosofi som minimalistmanualen och begränsar eleven till enkla funktioner genom att dölja de avancerade funktionerna. I och med detta så skyddar man användaren från att göra för stora fel. Detta för att uppmuntra eleven till att våga göra mera på egen hand när risken för att göra fel är minimal. Man kan säga att Training Wheels är en strippad version av det riktiga programmet. Detta är en vidareutveckling av Training Wheels med mer förklaringar till varför visa funktioner är "blockerade". Att användas i inledningen av utbildningen. 15.2 Användarassistans och on-linehjälp När man använder ett verktyg i datorn så är man engagerad i två uppgifter: Den primära uppgiften, d vs den funktionalitet som gör att man valt att använda ett visst program/verktyg och den sekundära uppgiften som innebär att handha interaktionen med programmet. Denna finns till för att utföra den primära uppgiften. Alla on-line system måste stödja båda uppgifterna. De flesta vardagliga gränssnitt erbjuder åtminstone någon form av följande on-line information för användarassistans: Hjälpfunktioner genom att välja ett visst objekt, antingen via menyraden eller "officeassistenten". Generell hjälptext, tillgängliga genom hjälpkommandon, menyraden, funktionsknapp eller ikon Utvidgad on-linehjälp utformad som en bok Vi vet ju att boken inte är så aktuell inom vissa områden och detta är ett av dessa områden. Boken tar dock upp några vanliga hjälpfrågor (FAQs): Vill du läsa mer om detta så se sidorna 313-314. Även här är boken aningen gammelmodig, det har gjort stora framsteg vad gäller on-linehjälp med helpdesk osv. Boken menar att man ofta får svar på frågor som hur gör jag och vad är det, men inte lika mycket svar på taktiska frågor som när är A bättre än B. Kontextkänslig hjälp är bra när användaren söker information om vad han/hon ska göra i sitt nuvarande tillstånd. Det är mindre bra om man kommit till en plats av misstag och får kontextkänslig hjälp om den plats man råkat hamna i Sofia Johansson, *nd97sjn@student.hig.se* KAPITEL 15 (B) - Användarsupport och On-Line information Historien om hypermedia kan man spåra ända tillbaka till idéer av Vannevar Bush (1945), som beskrev ett konceptuellt system för att koppla samman olika bitar av information med en association. Under 1960-talet började Ted Nelson (1967) arbeta med storskaliga projekt som Xanadu, och 1974 myntades begreppet ”hypertext”. Doug Engelbart (1968) presenterade det första operationella systemet för hypertext och under 1980-talet kom produkter för PC, t ex Guide (bild 15.8 i boken) och Apples Hypercard (bild 15.9 i boken) in på marknaden. Prefixet ”hyper” antyder att notationen består av förgreningar och beslutsvägar, som i hypertext, en samling ickelinjära, textbaserade noder som är sammanlänkade. När olika media såsom video, ljud och animationer inkluderas i en sådan struktur kallas det för hypermedia. Både hypertext och hypermedia kans ses som databaser som innehåller stora kvantiteter av information, dessa kan man komma åt genom att använda särskilda navigeringsverktyg som gör det möjligt för användare att titta och leta efter information. Noder är det största innehållet av strukturen i ett hypermediesystem; länkar är strukturen av relationer. Människor ser nätverk med information genom att flytta sig från en nod till en annan, vanligen genom att följa länkar mellan informationsobjekt som skapats av författaren. Denne har bestämt vad innehållet i varje nod och vilken nod som länkar till vilken. Ett exempel kan vara noderna i ett litteratursystem som kan innehålla en ”bestseller”-lista, en sammanfattning av varje bok, en sammanfattning om författaren till varje bok, sammanfattningar av alla böcker av samme författare, en beskrivning av alla karaktärer i dessa böcker. Länkar skulle kunna gå från boklista till böcker, böckerna till dess författare, karaktärsbeskrivningar till rätt bok etc. De flesta applikationer lägger liten vikt vid att ge sin användare en holistisk bild av informationsutrymmet trots att systemen innefattar omfattande navigationshjälpmedel. Ett exempel är applikationen Guide (se bild 15.8 i boken), programmet har olika länktyper så att ny information kan visas utan att man behöver flytta sig till ett nytt ställe i hypertexten. HyperCArd visar grafiskt de senaste använda objekten. Ingen erbjuder en överblick av hypertexten. Passande metaforer, agenter eller karaktärer som agerar utifrån användaren i en virituellt baserad datormiljö och bra navigeringsverktyg behövs för att hjälpa användaren att svara på frågor såsom; Var är jag? Vad har jag sett? Vad mer kan jag se här? Hur kan jag komma åt det jag vill se? 15.4 Designa hypermedia för träning av MDI I följande fallstudie beskriver författarna några designuppgifter när det gäller utvecklandet av hypermediansystem för träning, sk HalClon (Preece and Crow 1994). HaClonsystemet är skapat för att: Motivera intresset för MDI bland ledare och beslutsfattare Erbjuda en användbar och informativ källa till nytta för designers HalClon är strukturerat som en multimediadatabas med videosekvenser, stillbilder, animationer, diagram, textsegment, röstexempel, och ljudeffekter. Trots en blandad, ordnad form av olika komponenter skulle dessa endast vara till begränsad nytta för en potentiell användare. Även om objekten var länkade till någon form av Web av okopplade objekt skulle många användare inte vara motiverade att använda och upptäcka virr varret av information som givits dem. Därför bör man erbjuda effektiva och belönande(rewarding) sätt för användaren att navigera sig igenom materialet. De bör även få bestämma sin egen väg igenom materialet, om de så önskar. Direktörer och ledare kräver motiverade berättelse om nyttan MDI kan ha i deras affärsverksamheter. Utövarna däremot är mer intresserade av hur man designar bättre system. De spenderar troligen mer tid med systemet och använder sig troligen av två ”modes” av interaktion; till att börja med vill de upptäcka den tillgängliga informationen för att få en bred förståelse om MDI-frågor; senare kräver de direkt åtkomlighet för specifika delar av kunnandet för att bistå med problemlösande aktiviteter. Systemet måste därför presentera sitt innehåll på olika sätt så att användaren kan bestämma sin egen väg för att uppnå sina mål. Ur användarens perspektiv kan navigerandet genom ett hypermediesystem vara skrämmande på flera sätt. Därför måste designern göra två saker; hjälpa användaren att skapa mentala modeller (kap 6) av informationsstrukturen, och erbjuda passande verktyg som tillåter användaren att navigera i det konceptuella utrymmet som de själva vill. För att bistå med förståelsen i ett fall av navigation har en metafor av en ”tryck tidning” skapats som alla användare av systemet skall förstå. Metaforen ger alltså naturlig information till användaren som t ex paragrafer, berättelser, kolumner, sektioner etc. De enkla navigerandet i tidningsmetaforen bygger på sidnumrering, förstärkt numrering av diagram och illustrationer, och referenser i slutet av artiklar. Referenserna används indirekt då en artikel refererar till en annan genom sidnummer. Innehållsförteckningen är ett sådant indirekt index. Ett hypermediesystem ger ett mycket mer sofistikerat navigerande, men syftet att förflytta sig direkt till relaterat material förstör tidningsmetaforen och användaren kan känna sig förvirrad. KAPITEL 16 - Att designa för grupparbete och virtuella omgivningar De flesta människor arbetar med andra människor. Organisationer litar på att människor arbetar och samverkar. Bara några datorsystem är designade för att underlätta för människor att sköta detta samarbete. De potentiella fördelarna, med att designa datorer och deras gränssnitt för att underlätta grupparbeten, verkar vara stora. Virtuella miljöer erbjuder en av de mest kraftfulla och naturliga metoder för att interagera med datorer. Två viktiga delar med CSCWsystem är de lägen av interaktion de erbjuder och den geografiska spridningen av användare. Olika lägen av interaktion kan vara asynkron (som är att infinna sig vid olika tid) eller synkront (som är att infinna sig vid samma tid) Den geografiska spridningen kan vara lokal eller avlägsen (dvs. olika lokalisering). Detta leder till en klassifikation av fyra kategorier. (Se bild 16.1 i boken). Dessa är följande: synkron-lokal, synkron-avlägsen, asynkron-lokal och asynkron-avlägsen. Synkron-lokal: Samma tid, samma plats Ett vardagligt exempel på en synkron-lokal grupp är ett möte. Vanligen i en miljö som är datorstödd. Varje deltagare har en varsin PC som används för att anteckna på. Denna är kopplad till en elektronisk whiteboard så man kan dela med sig till de andra eltagarna. En av de mest framgångsrika datorstödda mötesmiljöerna är idag (läs: när boken skrevs) Colab. Synkron-Avlägsen: Samma tid, olika lokalisering Telefonen är troligtvis den vanligaste mediat för att stödja grupparbete av typen synkron-avlägsen. När man jämför det med att mötas i verkligheten öga mot öga är nackdelarna uppenbara. Du kan inte se den du pratar med, du kan inte heller visa din partner bilder, gester eller referera till text på ett papper eller liknande. En av de vanligaste synkron-avlägsen CSCWsystem är distribuerade delade arbetsutrymmen (distributed shared workspace), dessa är designade för att stödja grupper som består av individer med olika geografiska lokaliseringar. Ett distribuerat delat arbetsutrymme (se bild 16.2 i boken) erbjuder ett multimedialt arbetsutrymme där varje deltagare samtidigt kan se ritande och skrivande av andra gruppdeltagare. Deltagarna kan även prata med varandra och se bilder av varandra. Postsystemet är kanske det vanligaste sätten för grupparbete av typen asynkron-avlägsen. Det elektroniska alternativet av post var de första och det mest spridda CSCWsystemet. Dessa system har idag blivit utökade med konferenssystem där deltagarna kan skicka och läsa artiklar. Ett exempel på asynkron-lokalt samarbete är kontorsarbete där kontoristerna kommunicerar med hjälp av in- och utfack trots att de sitter på samma kontor. Det är alltså ingen stor skillnad på asynkront-avlägset arbete och asynkront-lokalt arbete. Formella versus informella grupper Ett ökande antal undersökningar visar att informell, spontan kommunikation är lika viktigt som formell kommunikation, om inte ännu viktigare. Ett exempel är arbetande människor som möts i en korridor eller i fikarummet, de använder tillfället till att delge information, lösa problem eller identifiera möjligheter på ett oplanerat sätt. Där medarbetare är geografiskt spridda kommer möjligheten för denna sorts möten att minska. Därför försöker de som utvecklar CSCWsystem att utveckla system som ökar möjligheten att ha informella möten mellan geografiskt spridda arbetsplatser. Ett exempel är RAVE-miljön hos Xerox EuroPARC, där man har video och ljudsammankopplingar mellan arbetare på olika kontor. (Se bilder 16.3, 16.4, 16.5 i boken. Precis som vid design av vilket datorsystem som helst måste CSCWsystem bero på uppgiften den ska utföra, användaren och omgivningen. De följande designpunkterna har författarna hämtat från Sharples (1993) och studien av ett system (CYCLOPS). Graden av acceptans när det gäller CSCWsystem beror på de konkurrerande alternativen. Existerande mänskliga avtal för att arbeta tillsammans erbjuder en rik källa av idéer för CSCW gränssnittsdesigners. Om användarna blir vana vid ett CSCWsystem kommer de troligen att utveckla avtal och etikett för att använda systemet på ett smidigt och effektivt sätt. Sådana etikettregler bör introduceras för nya användare. Etikettregler beror mycket på den bakgrund människor har från olika uppgifter och kultur. När dessa människor använder samma teknologi kan användarnas förväntningar slås i bitar. Användare av ett CSCWsystem kan befinna sig i helt skilda tidszoner. Detta innebär att minst en arbetsgrupp måste jobba konstiga tider. Synkrona system som fungerar bra med två användare kan bli mindre effektiva med flera användare. Oförutsedda förseningar (t ex att uppdatera en videobild) kan vara väldigt frustrerande. 16.2 Virtual environment och virtual reality Termerna virtual enviroments och virtual reality (har valt att ej översätta dessa termer då de gör sig bäst i ursprungsspråk) som av författaren i detta kapitel använda mer eller mindre synonymt, refererar till variationen av interaktionssätt. Termerna används normalt för att referera till interaktionssätt som har dessa faktorer gemensamt: Känslan av direkt fysisk närvaro. Övertygande sensoriska antydningar är skapade av teknologin för att ge användaren en stark subjektiv känsla av fysisk närvaro och direkt upplevelser. Sensoriska antydningar i tre dimensioner. Antingen systemet använder sig av något sinne t.ex. syn, ljud eller känsel så presenteras informationen i åtminstone tre dimensioner via en av dessa sinneskanaler. Naturlig interaktion. virtual reality-system tillåter datorgenererade objekt att bli manipulerade genom att använda gester som är lika som dem man använder då man manipulerar riktiga objekt; plocka upp, vända sig om, kasta etc. Immersion (hittar ej något bra ord att översätta detta med) versus desktopsystem En av fördelarna med virtual reality sägs vara att användaren känner sig subjektivt ”immersed” i den datorgenererade världen och kan interagera väldigt naturligt genom att använda datahandskar (datagloves) och andra indataenheter. Av marknadsskäl har den virtuella verkligheten nu delats in i två områden, desktop och immersionsystem. Immersionsystem inkluderar saker såsom hjälmar och handskar, medan desktop inte har någon utav dessa. Vanliga desktopsystem använder sig av en stor färgskärm för både in och utdata. Ett tredimensionellt pekdon, kanske en tredimensionell mus tillsammans med ett tangentbord. Genom olika mjukvara och controller (ej översatt ev. styrenhet) kan man göra det möjligt att t ex ”flyga” runt en modell av ett hus, inspektera och överblicka alla rum. Eftersom vår applikation har som syfte att ge en subjektiv känsla av inlevelse passar ett immersive system ofta bättre. Genom en specifikation av den virtuella världen och tillräcklig datakraft är i princip möjligt att återge, ur vilken synvinkel som helst, en nästan godtycklig grad av fotografisk detaljering. Men det är datorintensivt och kan ta mycket tid. När man försöker visa upp det man återgett i realtid i en virtuell miljö använder man sig ofta av seriefigurliknande simplifieringar. T ex bryr man sig inte om att återge textur och skuggor, polygoner används istället för kurvor och antalet objekt begränsas. Studier har visat sig föreslå att fördröjning (hastigheten av uppdateringar av bilder i relation med rörelsen) är viktigare för användarens känsla av närvaro än det är med hög upplösning eller detaljerad återgivelse. Därför godtar vi en medelmåttig upplösning, enkla återgivelser om det görs till priset av snabba skärmuppdateringar. En annan oifrånkomlig faktor är långsamma tredimensionella trackers (sensorer). Vi måste insistera på snabba trackers . Antalet trackers har också betydelse. Om man använder fler än en tracker kommer de att göra systemet långsammare. Vi behöver åtminstone två trackers; en för ”headsetet” och en för handsken. Att göra en andra datahandske eller en hel datadräkt så att användaren kan se en representation av hela sin kropp, eller att ha möjlighet att ha fler än en användare samtidigt skulle ge höga kostnader och långsammare svarstider. Stereoskopiska versus monoskopiska displayer Virtuella verklighetsdisplayer finns i två olika typer: monoskopiska i vilken båda ögonen ser exakt samma sak och stereoskopiska där ögonen ser separata vyer. En viktig antydning i djup perception, rörelse parallax kan återskapas med en monoskopisk huvudmonterad display. Detta ger effekten att om man flyttar sitt huvud en kort bit kan objekt som inte är så långt borta rör sig i relation till varandra. Desto närmare de är desto mer rör de sig. Ett stereoskopiskt system skulle vara bra men det skulle antingen kosta väldigt mycket mer eller så skulle de ge ett långsammare system i övrigt. Om vi har lust att lägga till hörlurar och relativt billig hårdvara, kan vi associera olika ljudkällor till olika objekt i vår fysiska värld (se bild 16.7 i boken). Genom detta kan den visuella känslan av de flesta nuvarande system kännas undermålig, den fantastiska kvalitén av tredimensionellt ljud kan helt klart öka känslan av subjektivt närvarande. Preliminära bevis innebär att tredimensionellt ljud gör uppgifter som t ex känna av objekt i rörelse, navigering och lokaliseringskänsla blir lättare och trevligare att utföra. Sammanfattningsvis, den virtuellt fysiska applikation verkar kräva att minst ett immersion virtual reality-system med högkvalitets vidvinkels optik på en display drivs genom huvudrörelser. P ga rörelseparallax, kan ett monoskopiskt system mycket väl vara adekvat, även om ett stereoskopiskt system skulle vara att föredra. Upplösningen skall vara så hög den kan bli, men inte till priset av realtiduppdateringar. I kapitlet finns även en intervju på sidan 343 som jag valt att inte översätta eftersom denna är ”överkurs” och troligen inte heller är av vikt för en tenta. Skrivet av: Sofia Lundberg, nd97slg@student.hig.se. Med reservation för eventuella ändringar:-) KAPITEL 20 - Uppgiftsanalys, Task Analysis - TA (sid. 409-429) Att introducera läsaren i en rad tekniker för att analysera användarnas uppgifter. Efter att ha läst detta kapitel ska Du kunna: skilja på mål, uppgifter och handlingar föreställa Dig en användares ‘hur’-kunskap (‘how-to-do-it’-knowledge) identifiera behovet av att representera användarens uppgiftskunskap Begreppet uppgift (task) är centralt i användar-koncentrerad system design och många uppgiftsanalys-tekniker har utvecklats. Dessa tekniker koncentrerar sig på olika aspekter på uppgifter, som uppgiftsstruktur, hur lätt man lär sig en uppgift eller den kunskap som krävs av användarna för att utföra en uppgift. Att uppmärksamma användaruppgifter och hur uppgifterna delas upp i deluppgifter hjälper Dig att designa system som mer noggrant reflekterar vad användaren vill göra. är den allmänna termen för ett stort antal tekniker som skall beskriva vad människor gör, att representera dessa beskrivningar, förutsäga svårigheter och utvärdera system mot användbarhets- eller funktionella krav. Andra UA-tekniker har att göra med att förutsäga prestationer, mäta systemets komplexitet och ”lärbarhet” eller överföring till andra system. UA handlar om vad människor gör för att få saker gjorda. Funktioner är aktiviteter, processer eller handlingar som utförs av någon människa eller maskin. Uppgifter är nödvändiga för användaren, eller något som användaren tror är nödvändigt. För att företa sig uppgifter utför användare handlingar eller operationer, som att trycka på en tangent eller röra en mus. Mål (extern uppgift) är ett systemtillstånd som agenten (vilken självstyrande, förnuftig, människa, maskin eller system som helst som formulerar sina egna mål och strävar efter att hitta sätt att tillfredsställa målen) vill uppnå. Mål kan t ex vara att skriva ett brev. Ett mål uppfylls genom att använda ett eller flera instrument, metoder, agenter, tekniker, färdigheter, eller mer allmänt, något medel (device) som klarar av att ändra systemet till önskat tillstånd. Man väljer själv vilket medel man vill använda för att uppfylla målet. Uppgift (internal task) är de aktiviteter som erfordras eller upplevs som nödvändiga för att uppnå målet genom att använda ett visst medel. En uppgift är en strukturerad mängd aktiviteter i vilka handlingar företas i en viss sekvens. En handling är en uppgift som inte innehåller någon problemlösning. Ett strukturdiagram representerar en hierarkiskt nedbrytning av någon funktion i dess delfunktioner. Det visar aktiviteternas (rektanglar i diagrammet) ordningsföljd genom att ordna dem från vänster till höger. Aktiviteter som kan komma att repeteras ett antal gånger (iteration) markeras med en liten asterix (*) i rektangelns övre hörn. När en av ett antal aktiviteter kan väljas (selection) markeras detta med en liten cirkel i övre hörnet. En linje i rektangeln visar en saknad händelse. Vissa av deluppgifterna i diagrammet delas sedan vidare upp i fler deluppgifter och numreras enligt den ordning de utförs. (Detta diagram har stora likheter med JSP.) En metod (method, plan) består av ett antal uppgifter eller handlingar i hopsatta till en ordningsföljd (sekvens). Mål - ett systemtillstånd som agenten vill uppnå Medel - metoder, verktyg eller tekniker som passar för att uppnå mål Uppgifter - aktiviteter som är nödvändiga för att uppnå mål med hjälp av ett medel Deluppgifter - en uppgifts beståndsdelar Handlingar - enkla uppgifter, utan problemlösning 20.2 Hierarkisk uppgiftsanalys (HUA) (Hierarchial task analysis, HTA) bygger på grafisk representation av uppgiften uppdelad i dess beståndsdelar; operationer (handlingar) och deluppgifter. HUA inkluderar en iterativ process för att identifiera uppgifter och sedan kategorisera dem, bryta ned dem i deluppgifter och kontrollera att nedbrytningen gjorts korrekt. Målet för HUA är att beskriva uppgiften som en hierarki av uppgifter och planer. Planerna specificerar de förhållanden, under vilka en uppgift utförs enligt. En HUA kan beskrivas i tre steg; start, utveckling och slutförande. 20.3 Kognitiv uppgiftsanalys (KUA) (Cognitive task analysis - CTA) Om HUA är en beskrivning av de olika stegen i en uppgift, är KUA tekniker för att beskriva den representation av kunskap som människor har eller behöver för att klara en viss uppgift. Vissa handlingar är fysiska (t ex trycka på en knapp, flytta en pekare eller tala), andra är mentala eller kognitiva (t ex bestämma vilken knapp man ska trycka på eller var man ska placera pekaren, eller jämföra två objekt). Det finns ett antal KUA-tekniker som fokuserar på olika aspekter på den kognitiva behandlingen. Några olika KUA-tekniker är GOMS (Goals, Operations, Methods and Selection rules), TAG (Task Action Grammar), ETIT (External Task Internal Task), YSS (Yoked State Space), CLG (Command Language Grammar), KAT/TKS (Knowledge Analysis of Tasks/ Task Knowledge Structures). Mappning mellan nivåer är hur en beskrivning på en nivå översätts till en beskrivning på en annan nivå. 20.4 Modellera ‘hur’-kunskap (‘how-to-do-it’-knowledge) Viktigt för att någon bestämd design skall lyckas är den procedurella kunskapen som användarna behärskar - deras ‘hur’-kunskap. I samband med uppgiftsanalys är det effektiviteten som sätts i fokus - action mapping. Denna analys behandlar de handlingar som måste utföras, givet att användarna har förstått vad som måste göras för att uppnå målet. Den mest kända modellen för detta är GOMS, som består av beskrivningar av metoder (planer) som behövs för att uppnå ett visst mål. Metoderna är serier av steg, bestående av operationer (handlingar) som användaren utför. När det finns fler än en möjlig metod för att uppnå ett mål, har GOMS beslutsregler för att välja bland de alternativa metoderna, beroende på vilken som passar in i sammanhanget. GOMS-modellen, som beskriver de generella metoderna för att utföra en mängd uppgifter. The unit task level, som delar upp användarnas uppgifter i deluppgifter och sedan uppskattar hur lång tid det tar för användaren att utföra dessa. The keystroke level, knapptryckningsnivån, som beskriver och förutsäger den tid det tar att utföra en uppgift genom att specificera de knapptryckningar som behövs. utvärdering (evaluation) av designens naturlighet, fullständighet, konsistens och effektivitet. Förutsäga mänskligt utförande i designen. Ge förslag till förbättringar av designen. GOMS-modellen kan användas på flera olika sätt, t ex: för att förutsäga kvaliteten på ett befintligt system eller prototyp för att kontrollera metoders konsistens (för att försäkra att liknande mål uppnås genom liknande metoder) för att kontrollera att de mest förekommande målen uppnås genom relativt snabba metoder som en kvantitativ utvärderingsteknik för att välja mellan alternativa designer 20.5 Att representera uppgiftskunskap För att förstå användarnas kunskap är det viktigt att uppmärksamma dess tidigare kunskaper, både om den aktuella uppgiften och om mer allmänna uppgifter. Tänk ut en ”urvalsregel” som skulle kunna tillämpas på uppgiften ‘växla’ (en bil). Om bilen har manuell växellåda; tryck ned kopplingen, lägg i ettans växel, släpp upp kopplingen. Om bilen har automatlåda; välj ‘kör-läge’. (En chaufför som är van vid automatlåda kanske inte vet (har kunskap om) hur målet ‘lägg i en växel’ uppfylls…) Det finns ett antal mycket utarbetade metoder för detta; TKS som antar att människor har strukturer av kunskap om uppgiften i minnet, strukturerna består av kunskap om objekten i omvärlden och procedurerna el. metoderna som används för att genomföra uppgiften. Annan kunskap är typisk för uppgiften. KAT (Knowledge Analysis of Task) är en teknik som arbetar med att identifiera kunskap som är av betydelse för uppgiften. Greens kognitiva dimensioner för att beskriva aspekter på informationsstrukturer: Viskositet. Motstånd mot förändringar. Hur enkelt det är att göra ändringar i program. Fördröjd belöning. Ansträngningar som krävs för att nå ett mål. Det enklaste av mål (som det uppfattas av användaren) kan vara svårt att uppnå med ett visst gränssnitt. För tidigt ställningstagande. Användaren tvingas göra val för tidigt. T ex kan en användare tvingas sätta en gräns på några aspekter på systemet innan de vet hur stort de vill ha det. Dolda beteenden. Informationslänkar mellan saker i artefaktet vilka inte enkelt är synliga. T ex relationerna mellan celler i ett rutnät är inte alltid synliga. UA beskriver beteenden på tre nivåer; mål, uppgifter och handlingar. Uppgifter betraktas oftast i hierarkisk uppdelning av uppgifter i deluppgifter. HUA och andra relaterade tekniker fokuserar på vad som är verkliga händelser, snarare än på vad som skulle kunna hända. Kognitiv uppgiftsanalys-tekniker syftar till att beskriva några aspekter på de kognitiva metoder som kännetecknas av användarens uppgifter. Några metoder (som t ex GOMS) koncentrerar sig på användares ‘hur-kunskap’. Andra metoder fokuserar på kunskaper om uppgifter. Många av de tekniker som finns just nu är svåra att använda och ökar inte tillräckligt för kommersiella applikationer. Nyliga försök ser mer till en helhetsbild - för att försöka göra mer användbara verktyg. KAPITEL 21 - Strukturerad MDI-design Syftet med detta kapitel är att göra designmodeller eller -representationer som skall underlätta förståelsen för och informera om designprocessen. Efter att ha läst kapitlet skall Du kunna: förstå principerna med strukturerad MDI-design skilja konceptuell från fysisk design förstå uppgiftsfördelnings-processen förstå att design även handlar om tillhandahållande av hjälp och support, och inte enbart skärmlayouter I kapitel 20 talade man om att det finns tre huvudnivåer att ta hänsyn till - mål, uppgifter och handlingar. Det är dessa nivåer som tillhandahåller oss med stommen till vår design. Denna syn liknar en av de mest kända designmetoderna, Command Language Grammar (CLG). CLG är en symbolisk notation, tekniken representerar den tänkta designen i fyra nivåer. Varje nivå ger en fullständig beskrivning av systemet på den nivån. CLG består alltså av en sekvens av hierarkiska nivåer, där varje nivå är en förfining av föregående nivå. Konceptuell ”del” innefattar: uppgiftsnivå semantisk nivå Kommunikations ”del” innefattar: syntaktisk nivå interaktionsnivå Sammanfattning (av huvudfaktorerna) för varje CLG-nivå CLG-nivå Designern tar hänsyn till Designern gör Användaren tar i beaktande Uppgift Vad säger uppgiftsanalysen uppgiftsbeskrivn. Hur kan jag använda systemet att användaren kommer att för att göra X (t ex skriva ett Semantisk Vilka objekt, handlingar och semantisk beskrivn. Hur kan jag få systemet att metoder behövs för att göra göra X (t ex radera en sats)? varje deluppgift? Syntaktisk Hur skulle dialog och syntaktisk beskrivn. Hur markerar jag en sats? Vad informationsdisplayerna är ‘DELETE’-kommandot? Interaktion Vad skulle de exakta in- interaktions Vilka tangenter (el. mus, och output sekvenserna specifikation knappar etc) trycker jag på för bli om vi använde X och att markera en sats och sedan Y som in- och outputmedel, radera den? Konceptuell design motsvaras av den konceptuella och semantiska nivån i CLG och mål- och uppgiftsnivån i den generella modellen (fig. 20.1) samt mappningarna mellan dessa nivåer. Behandlar hur systemet måste se ut för att uppfylla ställda krav, men inte hur strukturen och funktionerna realiseras i ett fysiskt system. Vi behöver inte koncentrera oss på funktion och struktur förrän vi ser på interaktionsformen i detalj. Fysisk design är designen av det fysiska systemet. Den psykologiska stommen i vår design förutsätter att användarens kunskap är lagrad i nivåer. Man kan veta något på en nivå men ej på en annan. T ex: en användare kan veta hur en uppgift betecknas (som att radera en del av en text) och operationerna som behövs för att utföra uppgiften (som att välja en del av en text och sedan flytta den), men inte veta hur man gör det ( t ex i vilken ordning tangenter skall tryckas ned). Nivåerna används både för designern och användaren. Konceptuell aspekt: designern vill minimera konceptuell komplexitet i systemet genom att använda så få och kända objekt som möjligt och göra metoderna så enkla som möjligt. Användaren mappar en uppgift till dess associerade konceptuella objekt och operationer som finns i systemet. Det är därför viktigt att designerns konceptuella modell matchar användarens mentala modell av processen. Fysisk aspekt: att bädda in den konceptuella systemmodellen i en fysisk struktur så att användare kan kommunicera med systemet. Det viktigaste beslutet för designern är hur konceptuella operationer skall ”förpackas” till en dialog - de operationella (operational) aspekterna på fysisk design. Detta inkluderar beslut som enkla kommandon eller avancerad grafik, generella eller mer specifika kommandon med flera parametrar eller utan parametrar etc. Från användarens synvinkel består denna nivå av dialogstruktur och all information på skärmen, inkl. feedback. Förflyttning från den konceptuella till den fysiska nivån kräver att designern bestämmer vem eller vad som skall företa sig särskilda funktioner. Detta är task allocation-processen (uppgiftstilldelningsprocessen). Designern skapar uppgifter åt användaren genom att tilldela vissa logiska funktioner till människor, till datorn eller till människa-dator system. Uppgifter som tilldelas människor måste så mycket som möjligt matcha de uppgifter användare kan bilda sig en uppfattning om. (Hänsyn till användares kognitiva begränsningar). 21.3 Från logisk till fysisk design: uppgiftstilldelning (task allocation) En av de viktigaste besluten som måste tas under utvecklingen av ett människa-dator system är att tilldela uppgifter (vem ska göra vad) - människa, dator eller människa-dator system (MDI)? Utvecklaren måste fastställa vem (eller vad) som ska hålla med datat eller kunskapen som behövs för att utföra uppgiften och vem (eller vad) det är som fysiskt skall utföra uppgiften. Fig. 21.1 om Eurochange-systemet (en uppgiftsnivåbeskrivning av Eurochange, process 2 (KontrolleraKredit)). Vad kan datat ”ValutaMängd” innehålla? användaren kan trycka in ett belopp i den valuta som gäller på aktuell plats (lokal valuta) och begära samma belopp i en annan valuta, användaren kan begära ett belopp i den valuta som begärts, men skulle sedan behöva veta hur mycket det är i lokal valuta systemet kan erbjuda belopp i den främmande valutan och begränsa användaren till att välja ett av dessa Designern måste göra en mer detaljerad beskrivningsnivå av process 2 för att undersöka de olika alternativen (fig. 21.5). Ett annat alternativ är att användaren specificerar begärt output-belopp och valuta och systemet skulle räkna ut motsvarande i lokal valuta. Elin Tällberg, nd97etg@student.hig.se KAPITEL 21 (B) - Strukturerad MDI Design Identifiera processen som användaren måste utföra för följande scenarier i Eurochange. Logiskt sett ska användaren utföra 2.3, men det finns många fysiska designval, av vilka alla utför samma logiska process. Om datorn stöder denna process kan man peka på valutorna som är tillgångliga med en muspekare, välja från en lista med hjälp av piltangenterna, visa på en pekskärm eller visa med fasta knappar. När man har övervägt tilldelningen av uppgifter till människa och maskin kan man specificera och utveckla driftsaspekterna hos systemet. Driftsaspekter innebär vad användaren kan göra och vad systemet kommer att svara dvs. vad systemet gör. Samtidigt som man gör detta bör man tänka på hur systemet skall se ut. Det finns tre huvudaspekter för att beskriva driften av ett system: Hur kan systemet tala om vilket tillstånd et är i. Vilka operationer kan användaren utföra. Det finns två sätt på vilka systemet kan indikera vilket tillstånd den är i med hjälp av visuell information: Systemets tillstånd är synligt för användaren. Systemets tillstånd är inte omedelbart synligt men det är iakttagbart om användaren utför något. Vanligtvis så är den första av dessa att föredra. Det finns olika sätt för designern att klargöra vad användaren kan göra. Affordance-principen är mycket viktig här (13.7). Designen av knappar, skärmbilder osv. som tillåter tex. att kunna trycka, klicka, beröring osv. är viktigt. Det är också viktigt att tänka på felaktiga saker användaren gör. Avbrytsmekanismer som tex. ”avbryta”-knapp är också viktigt. En metod för att specificera detta är att använda ett flödesdiagram eller en dataflödesrepresentation av den logiska dialogen. Andra sätt att representera detta är i tillståndsdiagram, strukturdiagram och en notation som kallas UAN (User Action Notation method). Teckningar kan också användas men de saknar precisionen hos mer formella metoder. Fördelen med informella metoder är att de lätt kan testas på användare. En viktig aspekt hos alla notationer är att de ska visa kontrollflödet. Till skillnad mot konceptuell design måste fysisk design fokusera på när och vart händelser och beslut tas, vilka händelser som kan iterera, vilka händelser som är frivilliga och sekvensen där händelsen sker. Valet av vilken interaktionsstil (kap 15) som är lämplig spelar en central roll i operationell design, tex. kommandospråk, direktmanipulation, frågor och svar osv. Den måste passa för användarna, arbetet de gör, systemet och omgivningen. Det är viktigt att specificera hur ett system skall se ut. Det finns också mer generella ergonomiska angelägenheter som tex. form och storlek på knappar, ”fladder” på skärmar och höjden och lutningen på displayen. Det är viktigt att tänka på det övergripande sammanhanget och behovet att presentera en lämplig sammanhängande modell av strukturen och funktionen hos maskinen för de tilltänkta användarna. Att man är konsekvent är viktigt i interaktionsdesign, både när det gäller framställning och verksamhet. Systemet ska stödja endast ett fåtal sätt att utföra kommandon. Felmeddelanden bör se likadana ut och visa sig på ett ställe på displayen som stämmer ihop med resten av dialogen. Generellt ska objekt av en klass visa sig i samma stil som de andra. En sak att tänka på här ar att systemet ska stämma ihop med användarnas förväntningar, tex. så är ”D” ett dåligt val för ett ”spara-kommando”, där vore ”S” ett bättre val, en öppen dörr för ett ”stäng-kommando” likaså. En annan sak är att enheter inom samma klass bör behandlas lika, tex. att deleta ett ord bör man göra på samma sätt som när man deletar ett stycke. Sist men inte minst så bör användaren kunna utföra liknande uppgifter på liknande objekt. Eftersom olika människor upplever saker på olika sätt, kan de tycka att det som designern tycker är konsekvent är inkonsekvent. Kombinationen av beteende, utseende och stil och konsekvent bild kommer att försäkra att designen når upp till användarnas behov. För att uppnå detta måste man testa designen på användare i olika stadier av utvecklingen. Man bör komma ihåg att design är ett kreativt arbete, som kan hjälpas med formella, strukturerade metoder, men tekniken kan inte utföra designen åt dig. Det strukturerade synsättet att designa fokuserar på beskrivning på de konceptuella och fysiska nivåerna. Konceptuell design har att göra med vad systemet måste göra för att uppnå syftet och den nödvändiga strukturen. Fysisk design har att göra med hur systemet gör saker och hur det ser ut. Övergången från konceptuell design till fysisk design har att göra med tilldelningen av uppgifter till människa och dator och genom detta känna igen krav och underförstådda ”constraints” i besluten. De operationella aspekterna på designen har att göra med hur systemet kontrollerar dialogen, som användaren måste utföra och med systemets feedback. Represenationella aspekterna har att göra med visningen av data, presentationen av en sammanhängande systembild och de metoder genom vilka systemet ”reveals itself”. Användarsupport är en viktig del i designen. Enligt det ”holistiska” sättet att se är design en helhet i vilken beslut om hur ett interface ska se ut är gjorda med tanke på hur detta kommer att bli fysiskt kommunicerat med användaren. Till skillnad från det strukturerade sättet finns inga tydliga skillnader mellan olika nivåer i systemet. Designen är mycket mindre strukturerad. Man fokuserar på framträdandet och presentationen av den konceptuella modellen och sedan använder man sig av verkliga exempel. Det holistiska synsättet fokuserar på utseendet hos interfacet och dess beteende. Se även kapitel 1 om utvecklingen av Star user interface. Ett sätt att ”designa holistiskt” är ”game playing”. En mer och mer vanlig teknik är att designa en konceptuell modell som en tydlig interface bild (kapitel 7) som desktop analogi. Metaforer kan användas för att presentera en sammanhängande bild av hela systemet eller att rikta in sig på speciella funktioner eller delar av systemet. Rit-tekniker kan vara användbara för att utforska olika sorters design idéer (se fig. 22.2 sid. 457). Såväl som att underlätta kommunikation kan man använda sig av visuell ”brainstorming” för att utforska alternativa designsätt. Efter att ha gjort bilder av de bästa idéerna kan man utveckla detta genom att göra en pappersframställning av designen, som kan utvärderas av användarna. Detta kan följas av utvecklingsscenarier, mjukvara eller videoprototyper. Det kan bli billigare att använda sig av papper och penna på tidiga stadier och datorbaserade och videoprototyper kan vara viktigt i senare stadier för att utforska och demonstrera interaktionen och designen. Prova att rita ett känt användar-interface. Använd mer än fem minuter att göra det på. Är det möjligt att se hur interfacet fungerar från din teckning? Vilka problem upptäckte du? Tex. hur lätt tyckte du att det var att representera dynamiken hos interfacet och den konceptuella modellen hos systemet? Vilka grafiska tekniker använde du (tex. pilar, linjer)? Denna övning ska uppmuntra dig att utveckla ditt eget grafiska ordförråd. Det är viktigt för designers att ha en meningsfull grafisk representation för att indikera elementen hos ett helt systems omgivning. Med detta menas att ha snabba sätt att representera objekt som datasystemet, input och output anordningar och människor. Titta på figur 22.3 sid. 459 och fuska som det föreslås. Även fast en naturlig begåvning för att teckna hjälper, har Verplank och hans kollegor kommit på att det är möjligt att lära sig att vara kreativ. En viktig del är att utveckla och använda ett ordförråd av enkla grafiska former. Denna övning ska uppmuntra dig att använda brainstorming som ett sätt att utveckla visuella begrepp för hela eller delar av systemet. Försök utveckla enkla visuella bilder för ett anta ikoner som representerar olika storlekar av datasystem: stor, medelstor, liten och PC. Gör detta genom att skriva rubriker högst upp på ett tomt papper och längs vänstersidan några kategorier som man kan använda för att representera storlek - som storlek och form, endast storlek, komplexitet osv. Utforska sedan olika visuella former, en rad i taget. Prova att rita minst fem kompletta rader. Det kan tyckas lättare att rita bilder för delar av ett interface än att försöka rita ett helt system. Försök nu att utveckla visuella metaforer för följande: edit, debug, string, execute, declare, loop, field. Eftersom dessa är abstrakta, kan du alternativt använda verbala metaforer. De visuella metaforer som du nu har utvecklat kan vara mer användbara för design av ikoner. Verplank rekommenderar att vi tittar på saker som finns i vår omgivning som fordon, kläder, tidningar och verktyg (se fig. 22.5 sid. 461). Om man tänker på dessa saker kan de ge inspiration och idéer. 22.3 Scenarios, storyboards and snapshots. Ett scenario är en personifierad, påhittad historia med roller, händelser, produkter och omgivningar. De hjälper designern att utforska idéer och följden av olika designval. Snapshots är ofta serietidningsliknande bilder som fångar en speciell eventuell interaktion. Storyboards är sekvenser av snapshots som fokuserar på huvudfunktionen i en eventuell situation. Genom att använda dessa tekniker kan designers gå från befintliga till potentiella interaktioner och därigenom förutsäga problem. Det krävs prototyping och evaluering tillsammans med användare för att uppnå en bra balans mellan de olika faktorerna. Meningen med representationen är att se vad som händer i specifika situationer. Scenarier tvingar designern att tänka på det passande i designen, även typen och mängden av användarsupport och andra aspekter på omgivningen. Snapshots av kritiska situationer och storyboards är andra effektiva metoder. Kreativiteten hos designen kommer oftast från att man har använt tekniker som stimulerar tanken och uppmuntrar betraktandet av ett brett designområde. Rit-tekniker kan bli utlärda till och använda av designers, man behöver inte vara en konstnär för att använda dem. Att känna igen det sociala sammanhanget i designen och vikten av speciella situationer kan avslöjas i scenarier, snapshots och storyboards. KAPITEL 24 - Riktlinjer: Principer och regler De bästa riktlinjerna för användarinterface är principer som är på hög nivå och är vitt tillämpliga, tex. så erbjuder följande principer råd som är användbara: Ta reda på vem som ska använda interfacet. Minska inlärningen för användarna genom att vara konsekvent. Skapa med tanke på fel. Människor kommer alltid att göra fel och de ska även göra det för att lära sig. Gör bra felmeddelanden osv. Upprätthåll följdriktighet och klarhet. För att använda dessa principer praktisk, måste de sättas in i rätt sammanhang beroende på vad de ska användas. Att bara tillämpa riktlinjer kommer inte att leda till bra design. En design-regel är en instruktion som kan följas med minimal översättning av designern, tex. datafält ska vara i formatet DD-MM-YY och MM-DD-YY i Nord Amerika. Högnivå principer däremot måste översättas till en strategi för att producera en entydig design-regel som är lämplig för systemet i fråga, input-mediet bör vara lämpligt för systemets omgivning. Klassificera följande riktlinjer som principer eller design-regler Utfärda alltid ett varningsmeddelande till användaren innan man deleter en fil. Designa för ökning av antalet användare Anpassa efter olika användarnivåer och stilar. Säkerställ att det är lätt att förstå. Visa ”avsluta-knappen” längst ner till vänster på skärmen. Designa för ökning av antalet användare Anpassa efter olika användarnivåer och stilar Utfärda alltid ett varningsmeddelande till användaren innan man deleter en fil. Visa ”avsluta-knappen” längst ner till vänster på skärmen. Man måste tänka på att tolka principerna på ett passande sätt, riktlinjer kan och har utvecklats vilket förenklar och förvrider den psykologiska teorin på vilken de är baserade. Ett exempel på det är det att kapaciteten hos korttidsminnet är begränsat till att komma ihåg mellan 2 och 7 saker (kapitel 5). I många riktlinjer har det blivit översatt till en designprincip som föreskriver det maximala antalet saker som kan visas på samma gång. Tex. antalet färger på en skärmbild. Även fast det är sant att man inte ska använda för många färger på en gång är inte skälet till det att vi inte kan komma ihåg mer än ett fåtal färger per gång, utan för att för många färger skapar förvirring. Det är därför ett problem med iakttagelseförmåga och uppmärksamhet och inte ett som har med igenkännande att göra. Användningen av riktlinjer är begränsade. De kan dock vara till hjälp för designers att fokusera på vad som behövs. Tänk dig att du ska designa ett interface för en omgivning som stöder fem saker. Dessa är textredigering, e-post, grafik, networking och åtkomst till en on-line referens databas. Använd riktlinjerna av Smith och Mosier (sid 491), hur skulle du designa interfacet för de olika applikationerna? Vilka underliggande psykologiska principer är relevanta här? Baserad på riktlinjen av konsekvent format, är ett sätt att representera de olika applikationerna i olika fönster som kan associeras med varje applikation. För att uppnå detta kan man använda sig av färgkodning för det olika fönstren. Formatet i fönstren bör vara konsekventa så att tex. fönstrens titel är på samma ställen. De underliggande psykologiska faktorerna är om fokuserad och delad uppmärksamhet. Fast användarna inte kan utföra två eller flera uppgifter samtidigt kan de utföra flera uppgifter genom att hoppa mellan dem. Ett sätt för användarna att byta mellan fönstren snabbt och enkelt borde därför finnas. Riktlinjer har två ursprung: psykologisk teori och praktisk erfarenhet. Riklinjer innehåller oundvikligt en del sammanfallande och motsägelsefulla råd. Att vara konsekvent kan vara viktigt för att lära sig att använda ett visst system men bekymmersamt när en användare blir erfaren. Många av dessa motsägelser uppstår tidigt och försvinner sedan under designprocessen allteftersom högnivå-principer blir förädlade till lägre nivå designregler. Att utvärdera riktlinjer kräver en stor skicklighet. Denna skicklighet tar två former: att ta hjälp av publicerade fakta och från egna erfarenheter. Det bästa sättet att kontrollera en riktlinje är att testa den och observera resultatet, och lägga stor vikt vid vilken situation den används. 24.4 Ett exempel på att använda motstridande riktlinjer Även fast vissa riktlinjer ger motstridiga råd, försvinner många av dessa motsägelser när man arbetar med designen. Man märker oftast vilken riktlinje som passar på vilket ställe. Vissa konflikter följer dock med till implementationen och andra kanske man inte märker förrän man implementerar. Principer är hög nivå och mycket tillämpliga; design-regler är låg nivå-instruktioner Principer måste tolkas och appliceras med tanke på en speciell situation Riktlinjer kan baseras på psykologisk teori eller praktisk erfarenhet Publicerade riktlinjer kan hittas i tidningar, heminredningsguider och generella handböcker Helena Andersson, nd97han@student.hig.se Kapitel 26 - Designens motivering, Design Rationale (s 523-536) Att förstå vikten med att protokollföra beslut fattade angående designen. Efter att ha läst detta kapitel skall du kunna Kritisera stödet som är tillgängligt för kommunikation och redogörelse av beslut fattade angående designen Diskutera relevansen av lämpliga undersökningar och sedan protokollföra designbesluten Det traditionella sättet att få igång en diskussion mellan olika parter då man talar om ett informationssystem är att ta användning av systemdokumentationen. Det är flera berörda som kan dra nytta av dokumentationen. Först och främst så behöver utvecklarna av systemet ha tillgång till en sammanhängande beskrivning av struktur och syfte. Andra personer som kan behöva ta del av dokumentationen är de som skall underhålla systemet, de som skall sköta utbildning och de som skall sköta marknadsföring. Även ny personal som skall ta del av ett projekt kan lätt sätta sig in i ett arbete då man kan ta del av dokumentationen. Dokumentationen är även bra då den underlättar återanvändning. Vad kan mjukvaruutvecklare, utbildare och marknadsföringspersonal dra för nytta av att förstå tanken bakom ett system? Mjukvaruutvecklarna måste förstå varför designen är utformad som den är för att kunna göra ändringar när de behövs utan att hela systemet stabilitet skall behöva sönderfalla Marknadsförare skall sälja systemet till potentiella kunder. De behöver därför förstå varför systemet gör vissa saker och varför det inte gör andra. Att förstå systemets uppbyggnad gör att de kan ge lämpliga svar på kunders frågor. De som skall utbilda slutanvändarna skall förstå varför olika funktioner fungerar på de sätt de gör så att de kan hjälpa slutanvändarna så att de får god förståelse för systemet. Det är svårt att veta hur man på bästa sätt skall kunna dokumentera tanken bakom systemet. Ett alternativ är att göra en tabell där man antecknar datum, alternativ som övervägts, anledningar till varför man valt ett visst alternativ och inte ett annat osv. Tre olika former för att dokumentationen av designens motivering är: IBIS, Mångdesignanalys och Fordringsanalys. IBIS (Frågebaserade informationssystem) är ett system framställt för att fatta beslut om designen allt efter som arbetet fortlider. IBIS skall utgöra en biprodukt av designen. Huvuduppgiften för IBIS är att genom att utgå från medvetna överväganden och analysera för- och motargument samt tänkbara svar på frågor. Ett exempel på en fråga som kan behandlas med hjälp av IBIS är ”vad skall systemet göra?” och denna fråga leder sedan till flera bifrågor. Se exempel 26.1. Den fråga man utgår från kallas grundfråga och beskriver sedan relationer mellan frågorna. 26.2 Mångdesignanalys (Design space analysis) Det finns många olika designer för att uppfylla ett systems specifikationer. I Mångdesignanalys testar designern många olika alternativ för att få fram det bästa alternativet. Detta leder till att kvalitén på systemet blir bättre. QOC (Questions, Options and Criteria) är en notation som användas för att undersöka alla alternativa designer så att resultatet blir något mer än bara en detaljerad beskrivning av ”varför” och ”därför” man valt en viss design. Se exempel figur 26.3. Skillnaden mellan IBIS och QOC är att IBIS frågor och svar mer gäller ett generellt syfte för hela systemet och QOC gäller enbart för designen. Det är svårt att fatta designbeslut enbart utifrån QOC för kriterierna väger olika beroende på kontext och användning. QOC kan dock ge stöd genom att belysa interaktion mellan principer, konsistens och prioritering. 26.3 Fordringsanalys (Claim analysis) Vid Fordringsanalys är tanken att man skall analysera och förbättra en befintlig design. Fordringsanalys kan användas för att guida en omdesign av ett system eller för att hjälpa till vid utvecklingen av ett nytt system då prototypen skall framställas. Det går ut på att man undersöker de psykologiska krav som designen försöker lösa med avseende på användare, användning, kontext mm. Fordringsanalysen görs genom att man skapar några senarier för systemets användningsområde och sedan analyserar man vilka krav man kommit fram till. Kärnuppgifter som systemet skall kunna klara och olika fel som systemet skall kunna hantera skall inkluderas, men huvudsyftet är att identifiera hur systemet på ett positivt sätt skall tjäna användaren.. Fordrings analysen skall även identifiera de situationer då inte designen inte var den bästa tänkbara för att ge användaren support. Beslut angående designen behöver protokollföras och diskuteras av flera olika personer. Dokumentationen är ett malplacerat sätt att kommunicera information angående designen med användarna. Att dokumentera tanken bakom designen är en tidskrävande process. Mångdesign analys uppmuntrar designers att undersöka flera alternativ. Fordringsanalys koncentreras på att förbättra en design. KAPITEL 27 - Prototyping (s 537-555) Att introducera läsaren till ett flertal prototyping tekniker. Efter att ha läst detta kapitel skall du kunna: Känna till en rad av olika prototypingtekniker Kunna beskriva hur och när du skall använda en viss teknik Det finns två olika typer av prototyping: pappersbaserad och databaserad. Framställningen av pappersbaserade prototyper går snabbt och är billigt, samt ger värdefulla inblickar i systemet men kan inte demonstrera funktonaliteten. Databaserad prototyping ger en version av systemet med begränsad funktonalitet så att användaren kan samspela med det. Följaktligen så skiljer sig prototypen från det slutliga systemet i storlek, driftsäkerhet, helhet och konstruktionsmaterial. En mjukvaruprototyp är ett system som: fungerar, dvs. det är ingen föreställning eller ritning inte har någon generaliserad livstid, ibland slängs den direkt efter den använts och ibland utvecklas den till det slutliga systemet 27.1 Prototypningstekniker (Prototyping techniques) Prototyping skall användas för att se hur väl designen passar användarens behov. Den hjälper designers att fatta beslut genom att få fram information från användarna om: den nödvändiga funktonaliteten av systemet operationsföljder, vilken ordning operationerna skall ha Olika tekniker för att göra prototyper : Krav på funktioner (requirements animation) Snabbprototypframställning, för att samla information om funktioner och om lämpligheten hos vissa designer Incremental prototyping, man installerar systemet i faser, bestämmer vilka funktioner som är med från början och sedan fasas resten över när det är färdigt Utvecklingsprototyping (Evolutonary pr.), man utvecklar en prototyp som man sedan bygger på till dess att den blivit ett fullt system. Varför skulle systemen bli mer acceptabla om Utvecklingsprototyping skulle blandas med ”krav på funktioner” eller ”snabbprototypframställning”? ”Utvecklingsprototyping” är en blandning av full produktion och ”snabb prototyping” av ett system. Den slutliga produkten växer fram ur den första prototypen. Varje utvecklingssteg kan ses som ett eget miniprojekt. Om ”snabb prototyping” skulle användas i varje steg skulle en bättre produkt erhållas. (förstår inte riktigt vad de menar, se sid. 540) Full prototyping - alla funktioner finns med men med lägre prestanda Horisontell prototyping - visar användargränssnittet men har ingen funktionalitet bakom knapparna Vertikal prototyping - innehåller all funktionalitet för en begränsad del av systemet Naturtrogen ljudåtergivning (high fidelity) - prototyping genom någon form av media, te x video, som skall påminna så mycket om systemet som möjligt. Low fidelity - för framställning av prototypen används något material som är billigt och snabbt te x. storyboards Chaufför prototyping - en användare för studera en annan person, vanligtvis en utvecklare, när denne kör systemet ”Trollkarlen från Oz” prototyping - en användare sitter vid en skärm och utför sina uppgifter men istället för att det är ett system som svarar sitter en utvecklare vid en annan skärm och svara på frågorna. 27.2 Prototyping för att stödja designen (Prototyping to support design) Prototyping kan vara användbart i flera steg av designen, te x. produktkonceptualisering, på uppgiftsnivån och för att bestämma skärmdesignen. Produktkonceptualisering ”Product conceptualization” I de tidiga stadierna av produktutvecklingen kan prototyping användas för att man skall få en bättre förståelse för vilken typ av produkt som förväntas. Flera olika skisser över designen kan presenteras för användare och medlemmar i utvecklingslaget för kommentarer och förbättring. Varför kan det vara fördelaktigt för medlemmarna i utvecklingslaget att se en prototypdesign? Om designen är gjord av flera utvecklare är det viktigt att medlemmarna kan kommunicera effektivt och en prototyp underlättar detta. Quick Time gör så att man kan använda ljud, videoklipp och animering i dokument. Det används bland annat i utbildningsprogram, affärspresentationer och inom vetenskap och teknik. Uppgiftsnivåprototyping (Task level prototyping) När kraven för systemet är fastställda och funktionaliteten blivit tydligare kan prototyping hjälpa till att grunda ett ändamålsenligt gränssnitt på uppgiftsnivån. Syftet är att säkerställa att användarna kan utföra de nödvändiga uppgifterna för jobbet. Det är nödvändigt att göra scenarier byggda på uppgiftsanalysen, det räcker inte med att testa fritt. De metoder som används inom systemering kan då tillämpas t ex. acceptanstest och systemtest. Skärmdesignprototyping (Screen design prototyping) Skärmdesignprototyping innefattar b la ikoner, menyeroch skärmlayouter. Det är viktigt att tänka på att man använder passande ikoner, lämpliga färger, visuella och audioeffekter och en bra gruppering av kommandon i menyer. Skärmdesignen kan inledningsvis göras med papper och penna men kräver på slutet användning av någon mjukvara. Lämpligheten för interface element och layouter beror på i vilket sammanhang systemet skall användas. Till exempel så beror betydelsen av en ikon på fem aspekter (tas upp i kapitel 5). En annan fråga att tänka på är kategoriseringen använd för menydialoger. I ISO 924 står det bl a att interfacedesignen beror på uppgiften, användaren, omgivningen och den tillgängliga teknologin och om valen i menyn kan delas in i grupper som är naturliga för användaren så skall man göra det. 27.3 Mjukvara för prototyping (Software prototyping tools) Det är viktigt att den som skall utveckla interfacet kan välja ett lämpligt verktyg som passar både för den prototypingmetod som är vald och för det syfte som prototypen skall uppfylla. Det är bra att veta om man skall utveckla vidare på den prototyp man skapar eller om den skall slängas efter det att den använts. Det är även bra om prototypingverktyget inte kräver för hög grad av programmeringskunskaper då man vill att prototypen skall vara klar så fort som möjligt. Två olika verktyg används för prototypframställning: produktionsverktyg (kan användas både för prototyping och design)och verktyg som är speciellt gjorda för prototyping Prototypa med produktionsverktyg (Prototyping with production tools) Nackdelen med produktionsverkyg är att de måste vara väldigt omfattande och de drar med vissa begränsningar så att fullständig, driftsäker, robust och underhållningsbar mjukvara kan produceras. Detta kan medföra att prototypingen tar längre tid och blir dyrare. Prototypingsverktyg (Prototyping tools) Användning av prototypingsverktyg medför en försämring av kvalitén för prototypen pga. att prototypen måste konstrueras snabbt. Man kan tex. använda text istället för grafik för att snabba upp framställningen. KAPITEL 27 (B) - Prototyping (s 556-564) HyperCard-applikationer går under benämningen stack. Varje stack har en eller flera bakgrunder, en mall som är gemensam för flera kort (se fig 27.6 s 557).Varje bakgrund associeras till ett eller flera kort. Korten kan innehålla bitmappbilder, knappar och textfält. Varje HyperCard-objekt associeras till ett script, som talar om vad som ska hända när man klickar på ett objekt (se exempel på script på s 558). HyperCard är bäst lämpat när man snabbt vill sätta ihop en prototyp, särskilt i början av en systemutveckling. Viss animation kan göras, men knappast med det fina detaljarbete som krävs hos slutprodukten. HyperCard är utvecklat för Macintosh, vilket ytterligare begränsar dess användbarhet något. Prototyputveckling är ett sätt att visa användarna olika designlösningar. Tala om att det är en prototyp, varför man har gjort en sådan. Olika slags prototyper behövs vid olika stadier av utvecklingen. Det kan vara svårt att hitta ett CASE-verktyg som passar till en speciell applikation. Verktyget kan inte alltid anpassas efter utvecklarens behov. Systemutvecklingsverktyg ger ingen toppkvalitet; dock en fungerande prototyp som enkelt kan modifieras. KAPITEL 29 - Evalueringens roll (s 601-624) Att förklara vad som menas med evaluering, varför man bör göra en sådan och hur man går tillväga. Efter att ha läst kapitlet bör du ha fått en uppfattning om: sambandet mellan design, utveckling och evaluering varför man ska sätta användaren i centrum En evaluering innebär att man samlar data om hur ett användargränssnitt fungerar praktiskt. Det sker genom att en grupp användare får utföra en viss uppgift. Boken betraktar evaluering som ett helhetsbegrepp: den enklare sortens evaluering innebär att man frågar användaren direkt vad vederbörande tycker om en speciell designlösning. I den andra änden på skalan finns den mera strikta metodiken, där man arbetar i en laboratoriesituation under rigorösa former. I båda fallen gäller att tänka på detta: Vem är användaren? Tillhör testpersonen programmets målgrupp? Tänk på kön, tidigare erfarenhet, ålder, fysiologi, psykologi. Vad kommer användaren att vilja göra med programmet? Man kan begära vissa, starkt begränsade uppgifter eller låta användaren själv besluta. Var utförs testet? Det kan vara en sluten laboratoriemiljö eller en autentisk arbetsplats, alltså en fältstudie. Vilken typ av objekt ger man till försökspersonen för utvärdering? Det kan vara en serie skisser, en arbetsprototyp, eller en kommersiell produkt. Dessa fyra punkter är viktiga för att förutsäga hur ett system ska fungera, alltså innan man har gjort användartester. Man försöker göra en grov uppskattning över vad ’normalanvändaren’ kan tänkas vilja göra, fokuserar på människan, vilket arbete som ska utföras, omgivningen och teknologin. Men om man vill utvärdera en verklig arbetsplats är laboratoriemetaforen inte tillämplig. 29.1 Vad vill vi ta reda på, och varför? Varför gör man en evaluering? Jo, för att då vet man bättre vad användaren behöver, och kan utforma systemet därefter. Risken är annars att systemets gränssnitt bara speglar utvecklarens intentioner. Det måste testas i verkliga situationer innan man börjar sprida det i stor skala. Det finns även internationella standarder att ta hänsyn till. Evalueringen är alltså en viktig del av programutvecklingen. När programmeraren behöver feedback från den stora användargruppen säger man att evalueringen är av formativ natur. Motsatsen, evaluering av ett färdigt program, kallas summativ. En sådan utvärdering görs mest av kosmetiska skäl, varför vi inte befattar oss vidare med den här. Använd din kunskap om design; ställ frågor som ett designteam kan ha när de utformar ett system. Här är några förslag till ovanstående övning: Vilka är problemen med det gamla systemet? Hur används det gamla systemet egentligen? Vilken av de fem typerna av ikondesign bör vi använda? Kommer användaren att föredra en viss skärmlayout före en annan? Hur stödjer vi användaren med systemet? Följer programmet den stil som företagets tidigare produkter har? Har vi tagit hänsyn till internationell standard? Vilken specifikation har den största möjligheten att fungera? Anledningen till att man gör en evaluering: För att förstå hur verkligheten ser ut. För att jämföra olika designfilosofier. Att följa marknadens standarder, ISO etc. Under arbetets gång, för att kontinuerligt utvärdera produkten och dess användbarhet, från den minsta detalj till helheten. Man bör till en början inrikta sig på användarens verkliga behov och studera redan existerande system. Evaluering ger möjlighet att tidigt testa olika idéer på ett informellt sätt (se kap 22). Längre fram i designprocessen flyttar man uppmärksamheten till de smådetaljer som hindrar användaren, för att senare kunna ge ut uppgraderingar (se kap 31). En allmän regel är att vilken testning som helst är bättre än ingen alls. Det finns värdefull information att hämta i de flesta fall. Exempel; Forte Travelodge bokningssystem Detta försök gjordes av IBM Usability Evaluation Centre i London. Målsättningen var följande: Att identifiera och eliminera övergripande problem innan arbetet påbörjas. Affärerna skulle inte bli lidande under systemets inkörningsperiod. Även mindre kvalificerade medarbetare skulle kunna använda systemet. Utbildningsmaterial skulle tas fram. Speciellt dessa egenskaper hos systemet ville man arbeta på: Navigationen inom programmet, så att den bokningsansvarige kan fullfölja en bokning samtidigt som kunden finns i tillgänglig på telefon. Skärmlayouten, användarvänligheten, enkelheten; d v s effektiviteten. Ändamålsenlig on-line-hjälp och relevanta felmeddelanden. Vilken slags affordance erbjuder tangentbordet en användare utan datorvana? Femton ofta förekommande situationer simulerades, och ett statistiskt utvald grupp av anställda fick prova på en prototyp av systemet. Resultatet av en veckas testning var, enligt IBM:s konsulter, att: De anställdas produktivitet ökade och deras resurser utnyttjades mer effektivt. Bokningsförfarandet gick smidigare, och kunderna fick en bättre servicegrad. Personalomsättningen förblev låg och deras arbetsmoral påverkades inte heller. Systemet har expanderat i takt med efterfrågan. Kostnaderna för utbildning har varit överkomliga. Fundera lite på varför man gjorde all testning vid ett och samma tillfälle i utvecklingsförloppet? Jämför OMS-exemplet, där använde man sig av en iterativ designprincip (s 360). Oftast låter man nog användarna testa en ny programvara vid olika stadier i dess utveckling. Praktiska skäl kan ha varit avgörande i fallet med bokningssystemet. Kanske IBM-folket använde programmoduler som redan tidigare var testade. Detta förfarande gav dock inte en lika god funktionalitet som den iterativa programutvecklingen. Översikt över olika metoder (tabell 29.1 s 611) De flesta evalueringar innehåller något av följande: observation och övervakning av samspelet människa-dator, att inhämta användarnas synpunkter, att experimentera med olika lösningar och jämförande tester, benchmarks. Man analyserar ’naturligt’ förekommande dialoger och försöker förutsäga hur en viss lösning kommer att tas emot. Hur gör man då för att samla in data? En förbisedd aspekt är att ett program kan få höga poäng i ett test, men när det kommer ut på marknaden går det inte så bra. Någon liten detalj som utvecklarteamet har förbisett kan göra användaren avogt inställd mot programmet. Det kan handla om brister i affordance eller genomskinlighet (se kap 1 och 13, Donald Norman). Enkätundersökningar kan fånga upp sådana brister i ett tidigt skede. S k benchmarks erbjuder ett delvis vetenskapligt synsätt. Undersökningsledaren har kontroll över vissa parametrar, och noterar hur olika variabler inverkar. Man lägger stor vikt vid att data behandlas korrekt rent statistiskt (se vidare kap 31). Den interpretativa (tolkade) evalueringen har ett mer humanistiskt perspektiv; man har lånat en del från etnografin, vilket i sin tur hör hemma inom antropologin. Man gör en participativ (deltagande) och kontextuell utvärdering (beror på sammanhanget). Datainhämtningen sker på ett mer informellt än vid de andra metoderna. Vid den prediktiva (förutsägande) evalueringen låter man en expert utvärdera en specifikation, lågnivåprototyp, attrapp eller liknande (se vidare kapitel 33). Innan man gör en breddundersökning kan det vara ett bra beslut att först göra en mindre s k pilotundersökning. Fördelarna med en sådan är: Underlättar; lättare att korrigera monumentala fel inför en större studie. Tekniken för datainhämtningen kan finslipas. En generalrepetition där misstag är tillåtna. Formativ evaluering ger information till programutvecklaren. Summativ evaluering är ett slags utvärdering av den färdiga produkten. Evalueringen sker i ett ändamålsenligt sammanhang av en användare som någorlunda väl motsvarar en genomsnittlig användare. Evalueringen kan genomföras när som helst i programutvecklingscykeln. Fyra olika anledningar: jämföra olika design, verklighetsanpassning, målinriktad systemutveckling och anpassning efter internationella standarder. Fem olika klasser av evalueringsmetoder: observation/övervakning, experimenterande/benchmarking, enkäter, tolkning (interpreting) av olika situationer samt förutsägande (predicting usability). Registrering sker med video, audio eller datalogger, men situationerna varierar. Pilotstudien, en mindre studie som görs för att trimma in procedurerna i den större. Användaren har alltid rätt, rätt att vara anonym, rätt att tacka nej till att medverka i ett test. Skrivet av Sven Danhall, na97sdl@student.hig.se KAPITEL 30 - Usage Data:Observations, Monitoring, Users Opinions Visa på olika metoder att samla och analysera användardata men också olika sätt att komma fram till hur användare tänker och känner för ett system. Vid design finns det ett flertal situationer där du vill observera hur olika användare använder och reagerar på de idéer du har. Exakt vad du ber användaren att göra och hur de gör det beror på anledningen till varför de observeras. Du vill kanske se hur de utför en speciell uppgift? Du kanske är intresserad hur de använder teknologin i sin egen arbetsmiljö helt oberoende av dig. Anledningen till att du gör en undersökning , tillsammans med din tillgång till resurser såsom utrustning, kommer att avgöra hur du tar hand om information erhållen utifrån dina observationer. Användare kan direkt observeras när de utför en specifikt anvisad uppgift eller en av sina vanliga arbetsuppgifter, samtidigt som observatören noterar intressanta iakttagelser i beteendet eller studerar användarens prestation på något sätt t ex genom att ta tid på vissa sekvenser i arbetet. Direkt observationer kan dock medföra vissa problem, då de iakttagna kan förändra sin prestation och sitt beteende p g a vetskapen om att de observeras. Detta fenomen är känt under namnet: ”Hawthorne effekten”, efter en studie av arbetare i Hawthorne Illinois 1939. Direkt observationer kan vara väldigt användbara i tidigt i ett projekt när du är ute efter informell feedback för att skapa dig en bild av vad användaren gör och vad denne gillar och inte gillar. Föreställ dig att du är i London och ska evaluera en prototyp av ett växlingssystem (Eurochange) som diskuterats i sektion 21.2. Du ska undersöka hur långt tid en genomsnittlig transaktion tar och identifiera problem som användaren stöter på. Vilken typ av problem kan du stöta på? Du bör hitta en postition varifrån du kan se vilka knappar användaren trycker på samtidigt som du måste vara diskret, då människor kan bli störda av det faktum att du iakttar dem speciellt då det handlar om en finansiell transaktion. Det skulle också vara rätt svårt att exakt ta tiden på en transaktion då det blir svårt att se när den startade och avslutades. Och om det nu är utomhus och det regnar så kan dina anteckningar förstöras utav regnet. Inderekta observationer: Video inspelning Att använda video inspelningar är ett alternativ till direkt observationer. Du kan kombinera flera olika kameror för att få den bästa bilden utav ett användarfall dvs hur användaren agerar. Det finns några viktiga frågor som att beakta: Du måste planera dina observationer. Vad vill du få ut av dem? Vilken typ av data vill du ha? Det kan finnas praktiska problem förknippade med att sätta upp video utrustning. Oberoende hur diskret du än försöker att vara kommer troligen användaren att påverkas utav att denne blir filmad. En lösning kan vara att låta utrustning vara en del av arbets/test miljön under några dagar och på så sätt minska utrustningens påverkan av användarens beteende. Analys av data från videoinspelningar Forskare är överens om att analys av denna typ av data är mycket tidskrävande. Det finns två olika typer av analys: Uppgiftsbaserad analys - Denna analys metod försöker att fastställa hur användaren löser det angivna problemet, vart de huvudsakliga svårigheterna ligger och vad som kan göras åt dessa. Prestationsbaserad analys - Denna analys metod försöker att uppnå tydligt definierade prestations mått från den insamlade datan. De mest vanliga är: antal rätt genomförda uppgifter, tidtagning på tidsåtgång vid genomförande, användning av kommandon, antal användarfel och hur mycket tidsåtgången är för kognitiva aktiviteter som t ex pauser inom och emellan olika kommandon eller läsning och inspektion av olika delar av skärmen. Video inspelningar är ofta kopplat till en slags ljudinspelning vilket i sin tur är känt som ett verbalt protokoll. Ett ”tänka högt protokoll” innebär att användaren hela tiden ”tänker högt”, hur denne tänker när den utför en uppgift eller löser ett problem. Detta medför svårigheter för användaren som måste göra två saker samtidigt. Ofta klarar användaren bara av detta under en kortare tid och under ett längre test måste man få bukt med problemet att användaren efterhand tystnar…Post-event protokoll är ett protokoll som upprättas efter att användaren är klar med uppgiften. Med denna teknik kollar användaren på inspelningar av sitt förfaringssätt under själva ”testet” och försöker återberätta vad de hade för avsikt att göra under testet. Analys av ett exemple på ett tänka högt protokoll Se exemplet på sidan 623. Jakob Stensson nd97jso@student.hig.se KAPITEL 30 (B) - Usage Data:Observations, Monitoring, Users Opinions Läs exemplet under ”Analys av ett exemple på ett tänka högt protokoll” (Se exemplet på sidan 623). Man kan identifiera åtta slags inlärnings (nybörjar)problem: De får utgå från ”scratch” då de gör tolkningar De generaliserar utifrån vad de känner till Nybörjare har problem med att följa direktiv Gränssnittsdetaljer är inte självklara Hjälpfunktioner underlättar inte alltid 30.3 Mjukvaru loggning (software logging) Mjukvaruloggning har alltid varit populärt bland en del forskare eftersom det inte kräver personlig närvaro hela tiden. Endel av databearbetningen brukar man kunna automatisera. Vidare är det icke påträngande vilket är en fördel, men kan väcka etiska tvivel. Man måste informera användarna om att de kommer att bli loggade även om de inte kommer att märka något av det. Mjukvaru loggnings verktyg kan delas in i två kategorier: De som bara noterar tidsstämplade tangenttryckningar: gör en notering av varje tangent som användaren trycker på och exakt när det sker och de som gör en realtidsnotering av interaktionen mellan användaren och teknologin. Interaktionsloggning är ungefär likadan förutom att noteringarna sker i realtid, så att de kan återspelas så att den som observerar kan se interaktionen exakt så som den skedde. Ofta kombineras video, audio och tangenttryckning- eller interaktionsloggning. Exempel är det nu berömda playback systemet (Neal och Simons(1983)): forskaren observerar via en videoskärm användarens input på en terminal i ett annat rum. Skärmen visar användarens loggning och systemets respons. Forskaren kan lägga till sitt eget input i form av kod och korta kommentarer för varje användaroperation. Forskaren kan återspela loggen av användarens handlingar på olika hastigheter och företa ytterligare detaljerade analyser under denna körning. De olika hastigheterna gör det möjligt att spela snabbt förbi passager där användaren inte har några särskilda problem. Fördelen med att använda olika tekniker är att undersökaren kan relatera avslöjande fakta om kroppsspråket (poser, leenden osv), kommentarer och annan hörselinfo med registreringar av den faktiska människa-dator interaktionen. Två stora nackdelar finns dock: kostnad (dyr utrustning) och volymen data som kan bli svårhanterligt stor. Vad avgör om ett insamlat material är kvalitativt eller kvantitativt? En rå dataström är en sekvens av händelser (som på en video), kommentarer (som på en bandupptagning) och tiden (som i tid loggning). De får endast mening när man tänker på dem som kvalitativa eller kvantitativa efter att de har analyserats. T ex delar av en video kan brytas ut vilka kan vara kvalitativa, medan samma videodelar kan analyseras så att man kategoriserar och räknar olika sorters fel, vilket får fram kvantitativa mätningar. 30.4 Användarnas åsikter: intervjuer och frågeformulär (enkäter) Att ta reda på användarnas åsikter är viktigt eftersom deras attityder är avgörande för användandet , såväl vid kravanalysen som för acceptansen av den färdiga produkten. Att kontrollera användarnas åsikter i olika steg under designen är mycket viktigt. Det kan spara mycket tid genom att oanvändbara, onödiga detaljer undviks. Intervjuer och enkäter är sätt att samla in data om vad användarna tycker. Data insamlat i intervjuer är oftast kvalitativa, data insamlat via frågeformulär är kvantitativa. I enkätundersökningar kan många människor delta och man har möjlighet att statistiskt kunna säkerställa resultatet. En strukturerad intervju har i förväg bestämda frågor som ställs i en bestämd ordningsföljd. Ingen plats finns för individuella attityder. Återfinns ofta i opinionsmätningar och är viktig om man vill kunna jämföra svaren mellan försökspersoner och göra statistiska beräkningar. I en flexibel intervju har man ett givet ämne men ingen bestämd frågeföljd. Intervjuaren är fri att komma med följdfrågor och att ta reda på personliga attityder. Används i ett tidigt skede för kravsamling och för att ta reda på användarnas ideer om något särskilt. Viktigt att förbereda båda typerna av intervjuer. Man måste veta vad man vill täcka, inte minst i flexibel intervju. Också viktigt att skapa en bra kontakt med försökspersonen. Annars kanske man inte får fram den information man vill få fram. Checklisteintervju: intervjuaren har en checklista som han kan pricka av på under intervjun om den intervjuade inte säger så mycket. Prompted intervju:en teknik som används för att få fram mer information från intervjuobjektet: ”kan du säga lite mer om det eller det?” eller ”Vad menar du med det?” Ju mer strukturerad frågorna är, ju lättare är det för intervjuaren. Trade-off här: Ju mindre strukturerad ju bättre möjlighet att plocka fram relevanta ämnen (men svårare för intervjuaren). Frågeformulär och surveyundersökningar Här måste frågorna vara entydiga. Det är viktigt med ett ordentligt förarbete när man gör frågorna. De ska helst inte kunna missuppfattas. Man måste ha minst en pilotstudie för att se vad folk trots allt missuppfattar. Man skiljer på två typer av frågestrukturer: Fasta svarsalternativ där respondenten väljer ut ett av ett antal givna svarsalternativ och öppna frågor där respondenten skriver ett eget svar. Fasta svarsalternativ har oftast någon form av rankingskala, tex den enklaste kan bestå av ”ja”, ”nej” och ”vet ej”. Se olika rankingskalor på sid 632-633. En populär form av attitydskala är semantisk differential, där man mellan två motpooler ska ange vart man befinner sig. På en skala med rankad ordning ska tex faktorer anges i ordning efter användbarhet. När man analyserar datat räknar man, om svarsalternativen tillåter, om svaren till numeriska värden, och bearbetar dem statistiskt. Man kan tex räkna ut medelvärde och standardavvikelse. Det är viktigt att man planerar enkäten med en statistiker från början. Då kan svarsalternativen utformas så att det sedan går att göra de statiska beräkningar man avser göra. Det är också mycket viktigt att svarsfrekvensen blir hög! 60-70% bör den vara enligt Eva Carling. Därför ska det vara lätt att svara på frågorna (sänd med frankerat svarskuvert och ge liten belöning till dem som svarar inom given tidsram) och enkäten bör inte vara lång (max två ark). Se olika exempel på enkäter på sid 634, 636-637. Ibland använder man pre- och post ”före och efter” enkäter för att se hur attityden förändras. Samma enkät delas då ut både före och efter att respondenten får vara med om ett test, en erfarenhet el dyl. Observerande kan ändra det som observeras - Hawthorne-effekten Verbala protokoll hjälper till att avslöja vad användaren tänker Problem med tänka-högt-protokoll: i svåra problemlösningssituationer upphör användarna oftast att tänka högt. Promptade frågor eller att arbeta med ett par användare avhjälper tystnad. Det finns två typer av mjukvaruloggning: tidsstämplade tangenttryckningar och interaktiv loggning. Användare måste alltid informeras om att de blir loggade. Strukturerade intervjuer är lättare att genomföra än ostrukturerade, men man har ingen möjlighet att plocka upp intressanta trådar. Frågor i enkäter måste vara entydiga och klara. Försök alltid genomföra en pilotstudie för att testa ett frågeformulärs design, speciellt om det ska skickas ut till en stor population. Pre- och postenkäter (före och efter) gör det möjligt att kolla förändringar i attityd eller uppförande. KAPITEL 31- Experiment och benchmarking Efter att ha studerat detta kapitel ska man: Kunna kritisera experimentell design Veta vad hypotes, oberoende- och beroende variabel är Veta vad som skiljer experiment från benchmarking Förstå hur och till vad användbarhetstestning (usability engineering testing) används. Experiment som används i MDI har oftast ett snävt mål och avser en specifik aspekt angående något MDI gränssnitt. Det är viktigt att undersökaren kan manipulera ett antal faktorer som avser design och studera effekten av olika aspekter på användbarhet. Innan experimentet måste nivån på användarnas erfarenhet och designen på experimentet beslutas. Väldesignade experiment har en klar hypotes som uttrycker vilket utfall man förväntar sig i experimentet och avslutas med en statistisk analys av det insamlade datat. Det är viktigt att man inte manipulerar för många faktorer, endast en eller två, så att man sedan kan dra slutsatser om orsakssambandet mellan faktorerna. Experimentsituationer blir oftast ganska ”avskalade”: hårda krav ställs på kontroll och då får man göra avkall på naturligheten i uppgiften. Detta kan leda till att möjligheten att generalisera minskar. Box 31.1 Exempel på ett experiment sid 643 När man planerar experimentet ska man tänka på tre saker: Anledningen till experimentet - vad ska ändras, vad ska hållas konstant och vad ska mätas Hypotesen - måste utformas så att den kan testas Vilka statistiska test vill jag göra på datat och varför Den oberoende variabeln är den som experimentledaren manipulerar (ofta input i organismen eller systemet). Den beroende variabeln är den som påverkas, den i vilken man ser resultatet av den experimentella observationen (ofta output). Det är den som mäts. Den oberoende variabeln (tex ålder) ska förbli opåverkad av den beroende variabeln (tex skicklighet att skriva maskin), men den beroende variabeln förväntas bli påverkad av den oberoende variabeln. Man måste veta hur man ska mäta den beroende variabeln, tex antalet misstag i maskinskrivning.(Innan måste man besluta exakt vad ett misstag kan vara). Viktiga krav på beroendemåttet är reliabilitet och validitet. Man ska se till att mäta rätt saker med giltigt mått. Beroende på skalnivån, tex ordinalskala, nominalskala, intervallskala och kvotskala kan olika statistiska mått användas. Man måste vara noga vid urvalet av deltagare så att man undviker biasis (snedeffekter). Helst bör det vara ett obundet slumpmässigt urval (OSU). Två grupper bör alltså ha likartad sammansättning vad gäller fp´s egenskaper som tex ålder, kön, datavana och utbildning (om de ska göra någon form av dataexperiment). En grupp fp kallas till experimentet och delas sedan slumpmässigt in i grupper som får genomföra experimentet under olika förhållanden. Här matchas fp i par. Tex en man och en kvinna bildar ett par (för att undvika sned könsfördelning). Sedan fördelas paren slumpmässigt till någon av experimentgrupperna. Varje fp deltar i båda grupperna, dvs fp utför först försöket utan manipulerad oberoende variabel och därefter en gång till med manipulerad oberoende variabel. Risken här är att man kan lära sig från ena gången till den andra, bli trött eller uttråkad och därför prestera olika vid de båda tillfällena. Detta kallas confounding eller inlärningseffekter. Risken för confounding minskar om man gör omvänd presentationsordning: halva gruppen får först utföra försöket med manipulerad oberoende variabel och andra halvan får börja med icke manipulerad oberoende variabel Experimentell effekt kallas en förändring i den beroende variabeln som orsakas av en förändring i den oberoende variabeln Kritisk granskning av experimentell procedur Viktigt att granska om experimentet gav vad det var tänkt att det skulle ge och hur man kan använda sig av resultatet man fick fram. Viktigt att försöka se det från fp’s perspektiv. Fyra viktiga saker att överväga: Användarförberedelse: om instruktionerna innan var vettiga och om de fick träna så mycket som de behövde. Påverkan av variabler: vad förändringen i den oberoende variabeln betyder för användaren. Uppgiftens struktur: om den var tillräckligt komplex för att användaren skulle kunna utnyttja de möjligheter som gränssnittet erbjöd, och om användaren förstod målet med uppgiften. Tiden: om längden på uppgiften bidrog till att användaren blev uttråkad. Mycket viktigt att göra pilotstudie innan man genomför själva experimentet för att undvika ovan nämnda fallgropar. Resultatet ska granskas kritiskt för att fastställa exakt vad man har fått fram och hur användbart det är och om det har praktisk och teoretisk signifikans. Det finns fyra huvudpunkter att beakta: Effektens storlek: den absoluta storleken på effekten är intressant. Några sekunders skillnad kan vara statistiskt säkerställt men i en vardagssituation har det liten eller ingen betydelse. Alternativa tolkningar: experimentella resultat tolkas som om de beror på manipuleringen av den oberoende variabeln. Men kan det finnas några alternativa tolkningar av resultatet? Kan det bero på någon annan variabel som inte har kontrollerats i experimentet? Tex otillräcklig övning inför en komplex uppgift. Konsistens mellan beroendevariabler: då flera beroendevariabler används i samma experiment kan relationen mellan dem ge motsägande svar pga inkonsistens. I sådana situationer kan man behöva göra flera experiment för att reda ut begreppen (vad som beror på vad). Generalisering av resultaten: det är ofta farligt att generalisera ett experiments resultat till en annan situation vad gäller andra användare och miljöer. Men det görs ofta trots att det egentligen inte går att göra det. Särskilt farligt om man ger det status av ”guideline”. 31.2 Usability engineering (användbarhet) En definition på usability engineering kan sägas vara: en process i vilken en produkt specificeras kvantitativt och i förväg. Senare när produkten byggs kan man se om den når uppställd användbarhetsnivå eller inte. Det underliggande målet är att skapa/konstruera för förbättring. Användbarhetsmål definieras genom kvantitativa mått (man kan använda matriser) och man sätter upp användbarhetsnivåer som ska uppnås. Sedan analyserar man inflytandet av möjliga designlösningar. Metoden inbegriper användarfeedback i produktdesignen. Man ställer sig frågan ”närmar vi oss målet nu då?” ”nej inte ännu” och man itererar ”design-evaluera-design”-loopen till den planerade nivån är uppnådd. På så sätt har man redan garanterat kvaliteten eller användbarheten när produkten är klar. Usability engineering baseras huvudsakligen på en form av test som kallas benchmarking tasks. De utförs i ett användarlaboratorium. Videokameror placeras så att man samtidigt kan se film och användarens hand på tangentbordet. Dessutom loggas ofta tangenttryckningar. De data man får fram används vanligtvis för att få fram information om hur lång tid det tog användaren att utföra vissa uppgifter, felfrekvensen och typ av fel, användande av manualen osv. För att standardisera experimentmetoden så mycket som möjligt är huvudregeln med usability engineering att ge en specificerad mängs användare specificerade uppgifter att utföra i kontrollerade omgivningar - med andra ord , att kontrollera så många variabler som möjligt. Användarnas åsikter är också viktiga och erhålls genom frågeformulär och intervjuer. Från svaren görs attitydmatriser, som tas med i användbarhetsspecifikationen (se tabell 31.1 på sid 651). När designteamet ska göra användbarhetsspecifikationen måste man acceptera lägre standard för vissa attribut för att kunna erhålla vissa andra. Man måste bestämma prioritet. Ett sätt att göra det är genom en impact analysis. Man listar användbarhetsattribut och väger/mäter fördelar och nackdelar med respektive attribut mot varandra för att få fram styrkor och svagheter med lösningen som helhet. (Se sid 653 för bättre förklaring). Usability engineering har bidragit med struktur i MDI design. Det har också varit viktigt att få alla deltagare i designprocessen att arbeta mot samma övergripande och överenskomna mål. På så sätt är användbarhetsspecifikationen ett viktigt dokument som representerar de allmänna målen. Den är också ett kommunikationsmedium mellan teknisk expertis som programmerare och andra med mindre teknisk kunskap som användare. Användbarhet omfattar en produkts totala liv. Man kommer överens om en definition på användbarhet Man sätter definitionen i termer av matriser och användbarhets mål Användbarhet blir ett av andra ”ingengörs” mål Tillhandahåller en metod för att prioritera avvändarproblem Svagheter med usability engineering: Slutsatsen att användbarhet kan operationaliseras Kravet att användaren ska vara förtrogen med laboratoriemetoder Testningen innebär en mycket artificiell situation. Hur många användare sitter och arbetar helt för sig själva bakom en glasruta utan att bli avbrutna av något? Inte många. Det är också dyrt att utföra sådana tester. Alternativ kan vara informella fältobservationer på arbetsplatsen eller interpretativa undersökningar, som tex sammanhangsförfrågningar (se kap 32). Experiment möjliggör att manipulera variabler associerade med design och att studera deras effekter. För att planera och designa ett giltigt experiment måste experimentledaren veta anledningen till experimentet, formulera en hypotes så att den kan testas överväga och välja rätt statistiska analyser. Beakta praktiska faktorer som tex användarförberedelse, variabelpåverkan, uppgifternas struktur och tiden det kommer att ta att genomföra experimentet. Pilotstudie är viktigt för att avgöra om den experimentella designen är bra innan man genomför experimentet i full skala. Usability engineering baseras på en form av experiment som kallas benchmarking tasks. Försökspersoner genomför dessa uppgifter i kontrollerad laboratoriemiljö. Notering av försökspersonernas beteende sker med video och tangenttryckningsloggning. Ett problem med usability engineering är att testmiljön är onaturlig och inte representativ för verkligheten. Den är dock bra för finjustering av produktuppgraderingar. Fr o m 30.3 fram till hit (sid 625-655) sammanfattat av: Anna-Karin Wedin, nd97awn@student.hig.se KAPITEL 32 - Tolkande utvärdering (evaluering) Syftet med detta kapitel är att peka på olika sätt att samla in uppgifter om och analysera hur personer i sin vardag använder teknisk apparatur, så som på jobbet, i skolan, hemma, etc. Målsättningen är att efter kapitlet skall du kunna: peka på varför tolkande evaluering är värdefull och hur den skiljer sig mot mer objektiva former av evaluering. skilja på olika metoder för att tolka och analysera insamlat data. Hittills har alla de metoder som diskuterats i boken varit sådana att testledaren har haft en stark kontroll över testpersonen på något sätt. Detta har gjort att "vi och dom" -känslan mellan testledare och testperson har förstärkts. Även sättet att samla in data på har varit väldigt formellt. Nackdelen med detta sätt är att den lite mer informella och situationsanpassade användningen aldrig kommit fram. Under senare delen av 80-talet och början av 90-talet har man mer och mer frångått de mer kontrollerade formerna av evaluering till en mer informell metod, nämligen tolkande evaluering. En viktig skillnad mellan tolkande evaluering och de gamla metoder, beskrivna tidigare i boken, är att vid tolkande evaluering så ger sig ordningen vid undersökningen av sig själv vartefter testet fortskrider, och är ofta gemensamt överenskommet mellan undersökare och testpersonen. De olika metoder som presenteras i detta kapitel kan variera i frågan om hur tolkande de är, men de är alla exempel på steg bort från de objektiva evalueringsmetoderna mot de mer subjektiva formerna. Vid tester i laboratoriemiljöer, sterila miljöer, har knappast testpersonen någon kontroll på vad, hur och varför han/hon gör en sak. Eftersom detta inte ger en korrekt bild av hur det ser ut i verkligheten så har man idag tagit fram en ny metod där man gör testerna mer naturliga, kallad Sammanhangs evaluering. Det går ut på att man genomför testerna i en så naturlig miljö för testpersonen som möjligt och gärna i vardagslivet. Några exempel finns att läsa i boken på sidorna 659-660. Whiteside m.fl. (1988) pekar på det onaturliga i laboratorietester: Testpersonen är ofta under påverkan av testledaren Testerna utförs ofta i en väldigt ovan miljö för testpersonen Testpersonen vet att de skall utföra ett test Inga störande moment som påverkar resultatet Och ofta vet testpersonerna inte syftet med testet. Sammanhangs evaluering har sina rötter i etnografernas världsbild (beskriven i kap 32.2). Testpersonen gör testen och letar efter eventuella problem, antingen själv eller tillsammans med testledaren, under arbete i sin vanliga arbetsmiljö och under vardagliga förhållanden. Detta spelas in på video och utvärderas senare av testpersonen och testledaren tillsammans. De saker som är av speciellt intresse för testledaren är: Hur är strukturen på arbetet och hur är språket som används Expliciva och impliciva aspekter på arbetet. Det är svårt att få några exakt mätbara resultat med denna metod, men som Whiteside m.fl. (1988) säger. Det viktiga är inte att få fram mätbara data från ett test, utan det viktiga är att få fram om och hur det fungerar samt hur människor reagerar ute i det verkliga livet. 32.3 Kooperativ och deltagande utvärdering Kooperativ evaluering kan beskrivas enligt följande: En teknik för att utveckla ett användarinterface genom att upptäcka eventuella problem för användaren i ett tidigt skede. Det innebär att programdesignern arbetar tillsammans med ett utvalt antal testpersoner som använder produkten i sitt dagliga arbete för att tidigt upptäcka eventuella brister och kunna rätta till dessa. Denna typ av undersökning är ett lågbudgetalternativ för designers och testare utan någon speciell kunskap om MDI. Det behövs väldigt lite träning för att genomföra denna typ av test. Testpersonerna uppmuntras att kommentera, föreslå alternativa lösningar och ställa frågor. Målet är att göra testen så naturlig som möjligt. Skapa en lugn och avslappnad atmosfär under testen. Under testen gäller det att deltagarna tänker högt. Detta skall skrivas ned för att senare analyseras. Det finns några saker som man bör tänka på under en sådan här test: Viktigt vilken typ av testpersoner som är med. Det skall ju vara typiska slutanvändare. Att ha noggrant genomtänkta testscenarier som man tror att komma att hända. Testpersonen måste tänka högt under testen. Efter testen så gör man en kort genomgång av testet så att inga missförstånd kan ha uppstått. Sammanställ testresultatet och rapportera vidare för åtgärd. Ett exempel på denna typ av test finns i boken på s. 662-663. Deltagande evaluering skiljer sig från kooperativ evaluering på så sätt att den är mer öppen och tillåter mer kontroll till testpersonerna/användarna. Deltagande design (se kap.18) och deltagande evaluering delar samma slags filosofi. Ja, de har i praktiken så mycket gemensamt att det kan vara svårt att särskilja dem. Greenbaum och Kyng skriver i sin bok Design at work (1991) att de föredrar tester i vardagsmiljöer. Detta för att dessa tester är inte så skrämmande för testpersonerna och det i sin tur kan skapa ett större intresse för att deltaga i testerna. Det finns några viktiga punkter att tänka på vid denna typ av tester: Väl utvalda grupper. De gäller att välja personer från hela skalan av användare. Designern leder arbetet med att tillsammans med användarna ta fram prototyper. Kontrollera att det på går en kommunikation hela tiden. Peka på fördelarna med deltagande evaluering så att deltagarna hela tiden är positiva. Ett antal MDI-undersökarer har nu börjat att intressera sig för etnografi som en metod att samla in data i det vardagliga arbetet. Man vill inte bara peka på nackdelarna med "laboratorietesterna" utan man pekar också på vikten av att lära sig mer om hur tekniken används i "vardagen". Monk m.fl. (1993a) har ställt upp några punkter som han tycker är negativt med "laboratorietester": Laboratoriet är inte den verkliga världen. Man kan inte kontrollera alla olika variabler som påverkar människans beteende. Testerna sker under en väldigt kort tid. Etnografin är inte någon ny metod. Antropologerna har använt sig av metoden under en lång tid. Etnografiska undersökare försöker alltid att försätta sig själva i den situation de vill studera. Ett exempel som nämns är när en antropolog vill undersöka ett speciellt bergsfolk, så ser han till att flytta till byn, bli accepterad av innevånarna, lägger sig till med deras vanor , klär sig som dem, helt enkelt bli en av dem. Allt detta för att verkligen kunna studera det han vill, och helst ur ”deras egen synvinkel”. Hjälpmedel som kan användas för att samla in data vid denna typ av undersökningar kan t.ex. vara videokameror, notebooks, vanliga kameror e.t.c. Inom MDI verkar videon anta en mer central roll vid undersökningar. Ett problem med detta är att det tar så lång tid att göra analysen. Dels handlar det ju om realtid och dessutom kanske man måste köra bandet om och om igen om man är tveksam på någonting. Att sammanställa det insamlade materialet kan göras både manuellt och automatiskt. Boken beskriver en typ av databas som är gjord av Murray och Hewitt (1992). Den står beskriven under Box.32.2. (sid. 667) Sammanhangs, kooperativ och deltagande evaluering är metoder där deltagarna och undersökarna samarbetar för att finna och förstå problem som kan uppstå i det dagliga användandet. Kooperativ evaluering är en billig typ av undersökning som kan användas av personer utan speciella kunskaper om MDI. Etnografiska undersökare strävar efter att sätt sig in i den situation som de vill undersöka. Videokameror tenderar att allt mer bli det vanligaste verktyget för att samla in data. Syftet med detta kapitel är att introducera olika typer prediktiva utvärderingsmetoder som inte innehåller användartestning. Efter att läst detta kapitel ska du kunna: Beskriva vad en återblick är och säga hur du kan frammana feedback. Kritiskt diskutera de positiva och negativa sidorna av expert övervakning som en utvärderings metod. Känna igen de sätt som utvärderingar kan göras billigare, d.v.s. heuristiska och discount metoder. Enkelt kunna sammanfatta hur en strukturerad användarsimulering så som cognitiv walkthrough kan hjälpa till att upptäcka problem. Använda tangenttrycknings analys för att utvärdera eventuella effekter på utförandet. Användartestning kan ofta innebära höga kostnader. Metoderna i detta kapitel beskriver hur man kan minska kostnaderna genom att förutse hur det skall användas snarare än att observera det direkt. I de flesta metoder du kommer att läsa om i detta kapitel tar man inte hjälp av användarna. man använder någon av följande metoder: review eller heuristisk undersökning eller tangentbordstrycknings analys. man använder sig inte av testpersoner så metoden är väldigt snabb och billig. Dessutom behövs ingen specialutrustning. Dessa metoder är väldigt använda av mjukvarukonstruktörer. Varken tangentbords- eller walkthrough metoden kräver någon prototyp, utan de kan göras utifrån specifikationen. Undantaget är heuristisk undersökning då man använder sig av viss användartestning. Kapitlet startar med att beskriva hur en typisk review genomförs. Det fortsätter sedan med en diskussion om fördelar och nackdelar med reviews och hur heuristisk och discount metoderna kan erbjuda ett alternativ under vissa omständigheter. Walkthrough och tangentbords metoderna diskuteras sedan kort. Inspektions metoden innebär att man använder specialister som både känner till tekniken och vilka som kommer att använda systemet. Vanligtvis koncentrerar man sig på interaktionen mellan användaren och interfacet i systemet. Nielsen (1993) beskriver Inspektionsmetoden som en kostnadseffektiv metod att finna problemen med interfacet. Huvudmålet med inspektionsmetoden är att få fram en lista med användarproblem. Ofta kan man lösa dessa problem i ett tidigt stadium. Vid standard inspektioner använder man sig av experter för att titta på compabiliteten mot given standard. Vid Consistency inspektioner använder man sig av designerteam för att kontrollera interfacet för en viss programfamilj. Användarsimulering görs oftast av experter. Man låtsas att vara en ovan användare för att upptäcka eventuella fel i programmen. Idealet är om dessa testare är experter på MDI och samtidigt har en stor kunskap och erfarenhet av olika system. Dessa har oftast lättare att hitta designproblem. Huvudskälet till att använda experter till att spela nybörjare har att göra med effektivitet. Ofta kan ett fåtal experter hitta flera fel under en kort testning än vad verkliga nybörjare gör på mycket längre tid. Experter kan dessutom ofta komma med lösningar hur systemet skall förbättras. Ett exempel som nämns är en studie av Hammond m.fl.(1984) där man använde par av experter , den ena spelade användare och den andra antecknade resultatet vid en test av ett ordbehandlingsprogram. Man var tillsagd att testa systemet både som nybörjare och mer van användare. Rapporten innehöll en lista på flera saker som undersökarna hade upplevt som problem och förslag på lösningar för dessa. Det är viktigt att man tänker på följande vid användarsimulering: Undersökarna får inte ha varit inblandade i tidigare versioner av systemet. Detta för att kunna vara neutrala. Undersökarna skall ha passande erfarenhet, både av applikationen och av MDI. Att finna dessa personer kan vara svårt så ibland måste man göra kompromisser. Undersökarens roll måste vara klart definierad innan testet börjar. Detta för att kunna utföra testet på rätt sätt. Under testerna är det viktigt att systemet eller prototypen likväl så som manualer är desamma för undersökarna så som de är tänkta att vara för de slutgiltiga användarna. Under datainsamlandet och analysen är målet att hitta de viktigaste problemen. Målet kan uppnås på tre olika sätt: Undersökarna måste rapportera observationer på ett speciellt sätt. T.ex. beskriva hur problemen de stötte på uppkom, källan, hur viktigt är det att problemet löses för användarna och hur förslag på hur det skall lösas. Undersökarna rapporterar sina resultat och sedan kategoriseras problemen i olika områden för att lösas. Undersökarna får en lista med problemkategorier och de rapporterar vilka fel de hittar i dess kategorier. Strukturerad Enkelt att analysera Tar tid att katagorisera. Inbjuder inte till spontana förslag om lösningar. Ostrukturerad Inbjuder till spontana förslag på lösningar och kommentarer. Svårare att analysera. Svårare att kategorisera vanliga problem Fördefinierade kategorier Kategorier av problem är redan bestämda. Väldigt enkel att analysera. Inbjuder definitivt inte till spontana kommentarer och förslag på lösningar. Man kan missa problem som inte är Fördefinierade. Tabell 33.1. För - och nackdelar med de olika rapportsätten. Denna metod verkar vara en attraktiv metod vad gäller dess effektivitet och feedback. Men det finns en del saker som man måste ha i åtanke som kan skapa problem. Dessa saker är vinklad rapportering, hitta passande undersökare, rollerna som skall spelas och beteendet hos de ”riktiga” användarna. Experter är kända för deras starka åsikter, med risk för vinklad rapportering. De koncentrerar sig på vissa saker och ignorerar andra. Man skall därför använda flera olika experter för att minska den vinklade rapporteringen. Att hitta undersökare med den rätta erfarenheten kan vara svårt. Speciellt för ett litet företag. Det krävs väldigt stor kunskap för att kunna spela de olika rollerna som krävs. T.ex. att spela en 9-13-åring för att testa ett program för barn. Det kan vara svårt att spela ovana användare. De kan göra sådana fel som man aldrig tror att någon kan göra. När vet man då att alla problem har blivit upptäckta? Heuristisk- och discount simulering är två tekniker som försöker lösa detta problem. 33.3 Strukturerad expert undersökning De tre metoder som kommer att nämns i detta stycke är också en form av expert undersökning. Men till skillnad mot dessa som vi tittade på i kapitel 33.2 så är dessa mer strukturerade och