HERTYUO
komma ord och meningar kontrolleras av regler for phonemics ( skillnaderna mellan orden
hand och land ar forsta bokstaven, undvik dessa ord for att slippa missforstand) Denna
metod kan hantera storre respons an vad concatenation kan gora, anvands nar stora mangder
av ord kravs.
12.6 Utvecklingen inom "output"
Det har ar "gardagens nyheter och jag tanker inte ga in narmare pa det. Man tar upp
multimedians utveckling och hur man kan anvanda sig av bade ljud och bild pa mer
avancerade satt i datorvarlden.
KAPITEL 13 - Interaktionsstilar
I detta kapitel tittar man pa de faktorer som man bor titta pa nar man valjer
interaktionsstil. En mangd termer har anvants for att beskriva kommunikationen som sker
mellan manniskan och datorn. Intill nyligen sa har interaktionen med datorn involverat
endast turordningen hut texten har hamnat pa skarmen. Denna interaktion kallas
dialogprocess. Fran anvandarens sida kan denna dialog brytas ner i flera steg:
Peka
Skriva
Tala
Gestikulera
Mm
13.1 Interaktionsstilar
I den har boken anvander man ordet interaktionsstilar som ett generellt ord som star for
alla typer av vagar man kan ga nar det galler hur anvandaren kommunicerar eller
integrerar med datorn.
Historik:
Det fanns tva (kommandodrivna och formular) olika granssnitt fran borjan for vanliga
formular som hade datoriserats. De designades med tanke pa att de skulle passa olika
uppgifter. De kommandodrivna var generella och kunde anvandas till olika uppgifter, medan
formularformaten designades for en speciell uppgift.
I dag anvander manga system flera olika stilar, man kombinerar t ex olika menyer med
andra styrsatt.
13.2 Kommandon
Kommandon ar ett satt att kunna ge instruktioner direkt till datorn ( ex DOS) . Man kan
anvand sig av hela funktioner, enstaka ord, forkortningar eller olika kombinationer av
ord och uttryck. ( t ex anvand *control* ihop med bokstaven 'e' = EXIT ). Fordelen med
att kunna anvanda sig av enstaka tecken eller funktioner ar att du behover bara ange
dessa for att processen ska utforas i jamforelse med att sitta och skriva hela ord eller
langre forkortningar.
13.3 Menyer och navigering
En meny ar en uppsattning av val som syns pa skarmen efter ett visst kommando har gjorts
och beroende av valet sa kommer granssnittet att andras pa skarmen. I motsats till
kommandodrivna system sa har menyer den fordelen att anvandaren inte behover komma ihag
vad punkten i menyn star for , det racker att kanna igen den. Pa senare tid (tank pa
bokens alder) har man fatt problem med att menyerna tar sa stor plats pa skarmen. Tva
losningar till detta ar anvandningen av rullgardinsmenyer ( pull-down) och ikoner
(pop-upp). Rullgardinerna ramlar ner pa skarmen och du klickar pa det val du vill ha,
ikonerna fungerar genom att du klickar pa ikonen och menyn kommer fram och du kan gora
ditt val. Nar det finns flera menyer som var och en har flera val maste anvandaren veta
var han ska soka efter ratt val. Enklaste sattet att losa detta ar genom att det man
soker matchar ihop med nagot av valen i menyn , detta kallas entity match . Ett exempel
pa entity match kan nar en anvandare vet att han vill numrera sidorna i sitt dokument och
ett val finns som heter "NUMRERING".
Menyer maste designas sa de ar latta att tolka och forsta. 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 pa hur man ska ordna alternativen i menyerna
Alfabetisk ordning
Kategoriskt
Konventionellt (hur pass vanligt ar det)
Frekvent (hur ofta anvands det)
Fragor & svarsdialoger
Kan refereras till en outvecklad typ av menysystem dar varje interaktion bara tar upp en
eller tva rader pa skarmen. Fragorna svaras en efter en beroende pa vad foregaende svar
var. Detta kan anvandas t ex vid bankomater, soka bok pa biblioteket mm . Fragor & svar
dialoger ar systemdrivan och darfor enkla for nyborjare att anvanda, det ar svart att
gora fel, kan daremot vara frustrerande for vana anvandare.
13.4 Formular och blad
Formular
Nar mycket data ska matas in pa en skarm ar det en fordel att designa skarmen som ett
formular, speciellt om samma typ av data matas in regelbundet om och om igen . Fordelen
med denna typ av ifyllnadsformular ar att anvandaren hamnar pa ratt stalle och kan darfor
inte fylla i fel data och darfor behover inte skarmen overvakas lika mycket som annars.
Formularen ska designas sa att anvandaren latt ser vilket falt som ratt data ska fyllas
i.
Blad
Utformade enligt gamla vanliga pappersformat, men de har mycket mera funktonalitet. De
kan erbjuda summering av berakningar , procentsatser mm. Fordelen med dessa ar att du ser
resultatet samtidigt som du arbetar eftersom allt finns pa skarmen. Typ av excel.
13.5 Naturligt sprak dialog
Anvandningen av naturligt sprak nar det galler kommunikationen med datorer ses som mycket
onskvart beroende pa dess naturlighet Detta innebar att man ska kunna knappa in det
naturliga spraket via ett tangentbord. Systemet maste kunna kopiera samma problem som kan
uppsta nar tva manniskor kommunicerar dvs. otydlighet, grammatiska fel, dialekt mm. Det
finns idag ( nar boken skrevs) inte nagot system som kan tolka det naturliga spraket via
tangentbordet. Experiment har dock gjorts med olika alternativ, dessa kraver att
anvandaren forstar systemet och att meningarna sags pa ett sadant satt att de kan tolkas
ratt fran systemet.
13.6 Direktmanipulation
Direktmanipulation beskriver system som har dessa kannetecken:
Synlighet av objekt som ar av intresse
Snabba och atergangbar funktioner
Aterstallning av komplex syntax av kommandosprak genom direktmanipulation av objekten som
ar av intresse.
Typiska direktmanipulerande system har ikoner som representerar objekt, som kan flyttas
runt pa skarmen med hjalp av musen. The Apple Macintosh var forst med att anvanda sig av
direktmanipulation som lyckades valdigt bra. Det bygger pa en metafor av skrivbordet dar
objekten representeras av ikoner . Ritprogrammen
( paintbrush) ar ett exempel pa direktmanipulation. Ett problem med direktmanipulation ar
att alla objekt kanske inte kan beskrivas konkret av en ikon. T ex klipp ut ord och
klistra in ar svart att illustrera vad det egentligen betyder.
13.7 Kognitivt satt att se pa manipulation
Tidigare har vi tittat pa kommunikationen med direktmanipulation genom de beteende och
sociala aspekterna vi har, nu ska vi titta pa det via det kognitiva synsattet. Hutchins
har tittat pa detta och har arbetat fram ett ramverk som bygger pa tva "klyftor" vilka
beskriver gapet mellan anvandarens mal och systemets profil. Nivan av direkthet i
direktmanipulation i granssnittet kan ses som avstandet mellan tva klyftor. Avstanden
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 anvandaren och systemet ar att man ska se relationen mellan systemet och dess
anvandare. Man vill forsoka minska "gapet" mellan anvandare och system, darfor att
anvandarna lattare ska kunna utfora sina uppgifter.
Semantik direkthet: Tittar pa relationen mellan vad anvandaren vill uttrycka och hur
detta ar mojligt via granssnittet. Vill jag lagga in bilder i ett dokument och detta gar
bra ar semantiken bra.
Artikulation direkthet: Tittar pa relationen mellan betydelsen av uttryck och dess
fysiska form.
( Se exempel med moped i boken s.275.)
Begransningar, restrektioner
Dar affordance forsoker visa hur ett objekt ska anvandas sa star restrektionerna for
vilka begransningar som finns for objektet.
Fysiska begransningar
Stoppar vissa operationer man kanske vill gora pa vissa objekt, en fyrkant passar inte i
ett runt hal !
Semantiska begransningar
Beror pa anvandarens kunskaper om den omgivning som personen och datorn befinner sig.
Kulturella begransningar
Innehaller information om de regler och beteenden som man maste folja.
Logiska begransningar
Arbetar med att objekten ska ha en logisk ordning och position.
Mappning
Mappning ar hur en beskrivning pa en niva av abstraktion kan oversattas till en annan
beskrivning pa en annan niva. God mappning ar nar beskrivningen ses som naturlig av
anvandaren. Dalig mappning ar nar beskrivningen inte stammer med verkligheten. Bra
exempel ( pa bra respektive dalig mappning)
i boken med spisen , titta pa sidan 280.
Feedback
Feedback definieras som "det som sands tillbaka till anvandaren om vad som har hant och
vilket som blev resultatet.. En nyckelprincip ar att god systemprofil har en synlig
feedback som ar 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 FONSTERSYSTEM
14.1 Allmanna fragor
Fonster ar avgransade visuella displayer som delar den fysiska displayen till flera
virtuella displayer.
Rent allmant kan man saga att fonstersystemet styr in- och utmatningskallor. Dessa kallor
(te x skarmar och moss) hanteras pa liknade satt som ett operativsystem styr diskutrymme
och processortid. Fonstersystem innehaller vanligtvis funktioner som hjalper anvandaren
att flytta, andra, skrolla och overfora data mellan flera fonster.
Fordelar med att anvanda fonstersystem och fonsterapplikationer ar att:
Anvandningen av begransat displayutrymme kan optimeras
Anvandare kan anvanda sig av flera kallor samtidigt pa skarmen for att utfora en uppgift
Anvandare har mojligheten att se ett speciellt objekt fran flera olika vyer samtidigt pa
skarmen
Anvandningen av en grupp imatningsmedel for olika uppgifter kan koordineras pa ett
uniformt satt
Musaktioner som orsakar olika aktiviteter i olika sammanhang forstas lattare av
anvandarna eftersom varje fonster ger ett visuellt och textbaserat innehall for olika
typer av interageranden
Anvandarna ar skyddade fran komplicerade kommandosprak och tillats specificera objekt och
aktiviteter genom att peka och valja
Sattet som granssnittet arbetar pa kan lattare bli standardiserat over flera
applikationer. Detta gor det lattare for anvandarna att lara sig nya applikationer nar de
val lart sig en.
Anvandning
Fonstersystem kan vara valdigt anvandbara for anvandare som anvander en enda display och
som jobbar med mer an ett dokument eller applikation i taget. Man skapar te x ett nytt
dokument, anvander kalkylblad, skickar e-mail etc.
Effektiviteten pa ett fonstersystem beror pa storleken, modell for bildkonstruktion,
hastighet och skarmupplosning. Andra faktorer som paverkar effektiviteten ar sattet som
systemet hanterar sokbilder, d vs hur lang tid det tar att oppna, stanga, arrangera och
zooma fonster.
Window working set kan definieras som mangden fonster som kravs for att utfora en
speciell uppgift.
Denna ide introducerades av Card 1984. Card menade att det ar valdigt viktigt hur mycket
tid som gar at till att arrangera fonsterna pa skarmen jamfort med att ha flera skarmar
med ett fullstort fonster pa varje skarm. Han konstaterade att det finns fordelar med
fonstersystem, men om det inte finns ett bra fonsterarrangemang tillgangligt sa kan de
ersattas med annat.
Ett alternativ till window working set kom 1987 och kallades for Rooms model, arbetsrum.
Systemet tillater speciella fonsterarrangemang att bli lagrade av anvandare som ett rum.
Varje rum illustreras av en ikon. Okad effektivitet blev resultatet.
Se figur 14.2 sidan 289.
Mjukvarufragor
Varje fonstersystem maste erbjuda appliaktionsprogrammen ett schema eller sprak for att
visa grafiska bilder via fonstren. Ett sadant schema kallas for imaging model eller
bildlik modell pa svenska. Det finns tva viktiga sadana modeller, bitmaps och matematiska
beskrivningar av kurvor. Bitmaps ar oberoende av innehall valdigt snabba att rita upp men
de kan vara svara att forstora och forminska.
Matematiska beskrivningar av kurvor ar latta att andra storleken pa och aven rotera men
det kan ta lang tid att rita ut dem om det ar komplexa objekt.
14.2 Fonsterkomponenter
Oftast forknippar man ordet inmatningsmedel med fysiska medel, gjorda av fysiska
komponenter. De virtuella medlen kan dock vara lika viktiga som fysiska. Ett virtuellt
medel ar ett medel som enbart existerar nar datorsystemet gor en operation. Virtuella
medel for inmatning kan te x vara knappar och touchareor och for utmatning ljus,
nummertangenter och toner. Vissa virtuella medel ar bade for in- och utmatning, te x
kontrollpaneler och kalkylatorn.
Widgets ar granssnittskomponenter som te x kontrollpaneler, menyer och knappar.
Se figur 14.3 sidan 291-292 for vanliga fonsterkomponenter i olika system.
Fonster
Fonster ar oftast rektangulara areor pa skarmen som kan flyttas, forminskas, forstoras
och renderas. Vanligtvis kan man andra vyer i fonstren genom att anvanda scrollbar i
ramen eller editering i arean. Innehallet beror pa/bestams av den oppnade applikationen.
Menyer
Det finns implicita eller explicita pop-up menyer. Implicita menyer ar sadana som poppar
upp nar man te x hogerklickar nagonstans pa skrivbordet och far upp en meny. Explicita
menyer ar sadana som man maste klicka pa bestamd plats for att fa fram, te x en ikon,
menyraden, fonsterkontroller osv.
Visuell feedback ges oftast genom att knappen man klickar pa byter farg eller skuggas.
Det kan aven vara att kryss eller en bock kommer upp da man klickar pa ett ord. Auditiv
feedback kan vara en ton eller en signal.
Kontroller och kontrollpaneler
Kontroller kan vara sliders, knappar, checkrutor os v.
(Se figur 14.9 sid. 297 for vanliga kontrollwidgets)
Kontrollpaneler bestar vanligtvis av en samling kontroller och displayer som visar
anvandaren tillstandet pa ett objekt samt tillater olika parametrar att bli valda
samtidigt.
Defaultvarden ar vanligtvis de mest anvanda valen eller de sakraste valen.
Dialogrutor
Dialogrutor ar on-screen displayer som systemet visar for att bidra med textinformation.
Det kan vara att systemet ber anvandaren om nagot, te x:
Systemet ber anvandaren att gora en mangd val
Systemet ber anvandaren att skriva in information
Systemet meddelar om viktiga saker innan man fortsatter osv.
Det finns olika typer av dialogrutor, modala dialogrutor tvingar anvandaren att svara pa
nagon fraga innan nagon annan aktivitet kan ske. Modeless dialogrutor bidrar med
information och begar nagon aktion men begransar inte anvandarens aktiviteter. De kan
flyttas, ignoreras eller minimeras medan man gor nagot annat. Fragerutor och
meddelanderutor initieras av systemet, inte anvandaren. De kraver ofta bara enkla ja/nej
svar.
14.3 Gemensamma funktioner i olika fonstersystem
Hantering av inmatning
De flesta fonstersystem tillater att man anvander mus eller tangentbord eller en
kombination for att kontrollera systemet och applikationsprogrammen.
Det finns fem primara aktiviteter som gar att gora med musen:
peka, klicka, trycka, dra och dubbelklicka.
Andring av fonsterfokusering
Fonstersystemet maste tydligt visa vilket fonster som for narvarnade ar aktivt bland
flera fonster. Detta gors oftast genom att fargen I titelraden andras.
Tva satt att fokusera:
Click to focus innebar att anvandarens inmatning inte styrs till nagot annat fonster
forran anvandaren klickar i fonstret.
Mouse focus innebar att anvandarens inmatning styrs till det fonster dar markoren for
narvarnade befinner sig.
Se figur 14.11 sidan 301.
Hantera enstaka fonster
De flesta fonstersystem tillater att anvandaren flyttar fonster genom att flytta musen
till titelraden och sedan klicka och dra.
Hantera flera fonster - nar inte alla fonster far plats pa skarmen samtidigt
Ikonisering ar en metod som tillater skarmutrymme att bli sparat genom att forminska
fonster till ikoner. Dessa kan sedan bli fullstora vid klickning.
Tiling(tegelvagg) anvands nar system inte har nagon overlappning utan anvander all
tillganglig yta (jamfor med att mura en tegelvagg).
Kaskad/overlappning ar den mest anvanda av fonsterhanteringsmetoderna. Fonster tillats
att delvis skymma varandra. Det ar en flexibel metod men det kan bli forvirrat. Kaskad ar
en typ av overlappning som ar bast nar ett stort antal fonster maste vara oppna samtidigt
pa skarmen.
Se figur 14.13 sidan 303 for overlappning.
14.4 Fonstersystem for CSCW
Handlar om problematiken med delade fonster. Det finns vissa overvagande man maste gora,
te x hur kan man hindra att en anvandare tar bort eller modifierar nagot som en annan
anvandare precis valjer? Vilken typ av undo verktyg behovs for att stodja
fleranvandarsystem?
Sofia Johansson
nd97sjn@student.hig.se
KAPITEL 15 - Anvandarsupport och On-Line information
15.1 Aktiv inlarning med minimalistmanualer
Nar minimalistinstruktioner introducerades innebar de att man tog bort repetitioner,
sammanfattningar, oversikter, ovningar och index. Man forsokte alltsa reducera mangden
information som en som utbildas behover for att lara sig anvanda en applikation.
Manualen ( se figur 15.1) designades for att bli mer uppgiftsorienterad d vs inte
systemorienterad. Stor vikt lades vid hur man kan aterga fran lagen dar man hamnat fel.
Efter en iterativ design av dessa manualer samt anvandartestning sa visade anvandarna
overlagsna inlarningsmaterial jamfort med traditionella manualerna.
The Training Wheels
The Training Wheels modellen foljer samma filosofi som minimalistmanualen och begransar
eleven till enkla funktioner genom att dolja de avancerade funktionerna. I och med detta
sa skyddar man anvandaren fran att gora for stora fel. Detta for att uppmuntra eleven
till att vaga gora mera pa egen hand nar risken for att gora fel ar minimal. Man kan saga
att Training Wheels ar en strippad version av det riktiga programmet.
Scenariomaskinen
Detta ar en vidareutveckling av Training Wheels med mer forklaringar till varfor visa
funktioner ar blockerade. Att anvandas i inledningen av utbildningen.
15.2 Anvandarassistans och on-linehjalp
Nar man anvander ett verktyg i datorn sa ar man engagerad i tva uppgifter:
Den primara uppgiften, d vs den funktionalitet som gor att man valt att anvanda ett visst
program/verktyg och
den sekundara uppgiften som innebar att handha interaktionen med programmet. Denna finns
till for att utfora den primara uppgiften.
Alla on-line system maste stodja bada uppgifterna.
De flesta vardagliga granssnitt erbjuder atminstone nagon form av foljande on-line
information for anvandarassistans:
Hjalpfunktioner genom att valja ett visst objekt, antingen via menyraden eller
officeassistenten.
Innehallskanslig hjalp
Generell hjalptext, tillgangliga genom hjalpkommandon, menyraden, funktionsknapp eller
ikon
Utvidgad on-linehjalp utformad som en bok
Vad vet vi om on-linesystem?
Vi vet ju att boken inte ar sa aktuell inom vissa omraden och detta ar ett av dessa
omraden. Boken tar dock upp nagra vanliga hjalpfragor (FAQs):
Vad kan programmet gora?
Vad ar detta? vad anvands det till?
Hur gor jag detta?
Hur kunde det ske?
Var ar jag?
Vill du lasa mer om detta sa se sidorna 313-314.
Hur ser on-linehjalp ut idag?
Aven har ar boken aningen gammelmodig, det har gjort stora framsteg vad galler
on-linehjalp med helpdesk osv.
Boken menar att man ofta far svar pa fragor som hur gor jag och vad ar det, men inte lika
mycket svar pa taktiska fragor som nar ar A battre an B. Kontextkanslig hjalp ar bra nar
anvandaren soker information om vad han/hon ska gora i sitt nuvarande tillstand. Det ar
mindre bra om man kommit till en plats av misstag och far kontextkanslig hjalp om den
plats man rakat hamna i
Sofia Johansson, *nd97sjn@student.hig.se*
KAPITEL 15 (B) - Anvandarsupport och On-Line information
15.3 Hypertext och Hypermedia
Historien om hypermedia kan man spara anda tillbaka till ideer av Vannevar Bush (1945),
som beskrev ett konceptuellt system for att koppla samman olika bitar av information med
en association. Under 1960-talet borjade Ted Nelson (1967) arbeta med storskaliga projekt
som Xanadu, och 1974 myntades begreppet "hypertext". Doug Engelbart (1968) presenterade
det forsta operationella systemet for hypertext och under 1980-talet kom produkter for
PC, t ex Guide (bild 15.8 i boken) och Apples Hypercard (bild 15.9 i boken) in pa
marknaden.
Prefixet "hyper" antyder att notationen bestar av forgreningar och beslutsvagar, som i
hypertext, en samling ickelinjara, textbaserade noder som ar sammanlankade.
Nar olika media sasom video, ljud och animationer inkluderas i en sadan struktur kallas
det for hypermedia. Bade hypertext och hypermedia kans ses som databaser som innehaller
stora kvantiteter av information, dessa kan man komma at genom att anvanda sarskilda
navigeringsverktyg som gor det mojligt for anvandare att titta och leta efter
information. Noder ar det storsta innehallet av strukturen i ett hypermediesystem; lankar
ar strukturen av relationer.
Manniskor ser natverk med information genom att flytta sig fran en nod till en annan,
vanligen genom att folja lankar mellan informationsobjekt som skapats av forfattaren.
Denne har bestamt vad innehallet i varje nod och vilken nod som lankar till vilken. Ett
exempel kan vara noderna i ett litteratursystem som kan innehalla en "bestseller"-lista,
en sammanfattning av varje bok, en sammanfattning om forfattaren till varje bok,
sammanfattningar av alla bocker av samme forfattare, en beskrivning av alla karaktarer i
dessa bocker. Lankar skulle kunna ga fran boklista till bocker, bockerna till dess
forfattare, karaktarsbeskrivningar till ratt bok etc.
De flesta applikationer lagger liten vikt vid att ge sin anvandare en holistisk bild av
informationsutrymmet trots att systemen innefattar omfattande navigationshjalpmedel. Ett
exempel ar applikationen Guide (se bild 15.8 i boken), programmet har olika lanktyper sa
att ny information kan visas utan att man behover flytta sig till ett nytt stalle i
hypertexten. HyperCArd visar grafiskt de senaste anvanda objekten. Ingen erbjuder en
overblick av hypertexten. Passande metaforer, agenter eller karaktarer som agerar utifran
anvandaren i en virituellt baserad datormiljo och bra navigeringsverktyg behovs for att
hjalpa anvandaren att svara pa fragor sasom; Var ar jag? Vad har jag sett? Vad mer kan
jag se har? Hur kan jag komma at det jag vill se?
15.4 Designa hypermedia for traning av MDI
I foljande fallstudie beskriver forfattarna nagra designuppgifter nar det galler
utvecklandet av hypermediansystem for traning, sk HalClon (Preece and Crow 1994).
HaClonsystemet ar skapat for att:
Motivera intresset for MDI bland ledare och beslutsfattare
Erbjuda en anvandbar och informativ kalla till nytta for designers
HalClon ar strukturerat som en multimediadatabas med videosekvenser, stillbilder,
animationer, diagram, textsegment, rostexempel, och ljudeffekter. Trots en blandad,
ordnad form av olika komponenter skulle dessa endast vara till begransad nytta for en
potentiell anvandare. Aven om objekten var lankade till nagon form av Web av okopplade
objekt skulle manga anvandare inte vara motiverade att anvanda och upptacka virr varret
av information som givits dem. Darfor bor man erbjuda effektiva och belonande(rewarding)
satt for anvandaren att navigera sig igenom materialet. De bor aven fa bestamma sin egen
vag igenom materialet, om de sa onskar. Direktorer och ledare kraver motiverade
berattelse om nyttan MDI kan ha i deras affarsverksamheter. Utovarna daremot ar mer
intresserade av hur man designar battre system. De spenderar troligen mer tid med
systemet och anvander sig troligen av tva "modes" av interaktion; till att borja med vill
de upptacka den tillgangliga informationen for att fa en bred forstaelse om MDI-fragor;
senare kraver de direkt atkomlighet for specifika delar av kunnandet for att bista med
problemlosande aktiviteter. Systemet maste darfor presentera sitt innehall pa olika satt
sa att anvandaren kan bestamma sin egen vag for att uppna sina mal.
Ur anvandarens perspektiv kan navigerandet genom ett hypermediesystem vara skrammande pa
flera satt. Darfor maste designern gora tva saker; hjalpa anvandaren att skapa mentala
modeller (kap 6) av informationsstrukturen, och erbjuda passande verktyg som tillater
anvandaren att navigera i det konceptuella utrymmet som de sjalva vill.
For att bista med forstaelsen i ett fall av navigation har en metafor av en "tryck
tidning" skapats som alla anvandare av systemet skall forsta. Metaforen ger alltsa
naturlig information till anvandaren som t ex paragrafer, berattelser, kolumner,
sektioner etc. De enkla navigerandet i tidningsmetaforen bygger pa sidnumrering,
forstarkt numrering av diagram och illustrationer, och referenser i slutet av artiklar.
Referenserna anvands indirekt da en artikel refererar till en annan genom sidnummer.
Innehallsforteckningen ar ett sadant indirekt index. Ett hypermediesystem ger ett mycket
mer sofistikerat navigerande, men syftet att forflytta sig direkt till relaterat material
forstor tidningsmetaforen och anvandaren kan kanna sig forvirrad.
KAPITEL 16 - Att designa for grupparbete och virtuella omgivningar
Inledning
De flesta manniskor arbetar med andra manniskor. Organisationer litar pa att manniskor
arbetar och samverkar. Bara nagra datorsystem ar designade for att underlatta for
manniskor att skota detta samarbete. De potentiella fordelarna, med att designa datorer
och deras granssnitt for att underlatta grupparbeten, verkar vara stora.
Virtuella miljoer erbjuder en av de mest kraftfulla och naturliga metoder for att
interagera med datorer.
16.1 Datorstott samarbete (CSCW)
Tva viktiga delar med CSCWsystem ar de lagen av interaktion de erbjuder och den
geografiska spridningen av anvandare. Olika lagen av interaktion kan vara asynkron (som
ar att infinna sig vid olika tid) eller synkront (som ar att infinna sig vid samma tid)
Den geografiska spridningen kan vara lokal eller avlagsen (dvs. olika lokalisering).
Detta leder till en klassifikation av fyra kategorier. (Se bild 16.1 i boken). Dessa ar
foljande: synkron-lokal, synkron-avlagsen, asynkron-lokal och asynkron-avlagsen.
Synkron-lokal: Samma tid, samma plats
Ett vardagligt exempel pa en synkron-lokal grupp ar ett mote. Vanligen i en miljo som ar
datorstodd. Varje deltagare har en varsin PC som anvands for att anteckna pa. Denna ar
kopplad till en elektronisk whiteboard sa man kan dela med sig till de andra eltagarna.
En av de mest framgangsrika datorstodda motesmiljoerna ar idag (las: nar boken skrevs)
Colab.
Synkron-Avlagsen: Samma tid, olika lokalisering
Telefonen ar troligtvis den vanligaste mediat for att stodja grupparbete av typen
synkron-avlagsen. Nar man jamfor det med att motas i verkligheten oga mot oga ar
nackdelarna uppenbara. Du kan inte se den du pratar med, du kan inte heller visa din
partner bilder, gester eller referera till text pa ett papper eller liknande. En av de
vanligaste synkron-avlagsen CSCWsystem ar distribuerade delade arbetsutrymmen
(distributed shared workspace), dessa ar designade for att stodja grupper som bestar av
individer med olika geografiska lokaliseringar. Ett distribuerat delat arbetsutrymme (se
bild 16.2 i boken) erbjuder ett multimedialt arbetsutrymme dar varje deltagare samtidigt
kan se ritande och skrivande av andra gruppdeltagare. Deltagarna kan aven prata med
varandra och se bilder av varandra.
Asynkron: olika tid
Postsystemet ar kanske det vanligaste satten for grupparbete av typen asynkron-avlagsen.
Det elektroniska alternativet av post var de forsta och det mest spridda CSCWsystemet.
Dessa system har idag blivit utokade med konferenssystem dar deltagarna kan skicka och
lasa artiklar. Ett exempel pa asynkron-lokalt samarbete ar kontorsarbete dar
kontoristerna kommunicerar med hjalp av in- och utfack trots att de sitter pa samma
kontor. Det ar alltsa ingen stor skillnad pa asynkront-avlagset arbete och
asynkront-lokalt arbete.
Formella versus informella grupper
Ett okande antal undersokningar visar att informell, spontan kommunikation ar lika
viktigt som formell kommunikation, om inte annu viktigare. Ett exempel ar arbetande
manniskor som mots i en korridor eller i fikarummet, de anvander tillfallet till att
delge information, losa problem eller identifiera mojligheter pa ett oplanerat satt. Dar
medarbetare ar geografiskt spridda kommer mojligheten for denna sorts moten att minska.
Darfor forsoker de som utvecklar CSCWsystem att utveckla system som okar mojligheten att
ha informella moten mellan geografiskt spridda arbetsplatser. Ett exempel ar RAVE-miljon
hos Xerox EuroPARC, dar man har video och ljudsammankopplingar mellan arbetare pa olika
kontor. (Se bilder 16.3, 16.4, 16.5 i boken.
Designfragor for CSCWsystem
Precis som vid design av vilket datorsystem som helst maste CSCWsystem bero pa uppgiften
den ska utfora, anvandaren och omgivningen. De foljande designpunkterna har forfattarna
hamtat fran Sharples (1993) och studien av ett system (CYCLOPS).
Graden av acceptans nar det galler CSCWsystem beror pa de konkurrerande alternativen.
Existerande manskliga avtal for att arbeta tillsammans erbjuder en rik kalla av ideer for
CSCW granssnittsdesigners.
Om anvandarna blir vana vid ett CSCWsystem kommer de troligen att utveckla avtal och
etikett for att anvanda systemet pa ett smidigt och effektivt satt. Sadana etikettregler
bor introduceras for nya anvandare.
Etikettregler beror mycket pa den bakgrund manniskor har fran olika uppgifter och kultur.
Nar dessa manniskor anvander samma teknologi kan anvandarnas forvantningar slas i bitar.
Anvandare av ett CSCWsystem kan befinna sig i helt skilda tidszoner. Detta innebar att
minst en arbetsgrupp maste jobba konstiga tider.
Synkrona system som fungerar bra med tva anvandare kan bli mindre effektiva med flera
anvandare.
Oforutsedda forseningar (t ex att uppdatera en videobild) kan vara valdigt frustrerande.
16.2 Virtual environment och virtual reality
Termerna virtual enviroments och virtual reality (har valt att ej oversatta dessa termer
da de gor sig bast i ursprungssprak) som av forfattaren i detta kapitel anvanda mer eller
mindre synonymt, refererar till variationen av interaktionssatt. Termerna anvands normalt
for att referera till interaktionssatt som har dessa faktorer gemensamt:
Kanslan av direkt fysisk narvaro. Overtygande sensoriska antydningar ar skapade av
teknologin for att ge anvandaren en stark subjektiv kansla av fysisk narvaro och direkt
upplevelser.
Sensoriska antydningar i tre dimensioner. Antingen systemet anvander sig av nagot sinne
t.ex. syn, ljud eller kansel sa presenteras informationen i atminstone tre dimensioner
via en av dessa sinneskanaler.
Naturlig interaktion. virtual reality-system tillater datorgenererade objekt att bli
manipulerade genom att anvanda gester som ar lika som dem man anvander da man manipulerar
riktiga objekt; plocka upp, vanda sig om, kasta etc.
Se aven Box 16.1 i boken
COMMENT
Immersion (hittar ej nagot bra ord att oversatta detta med) versus desktopsystem
En av fordelarna med virtual reality sags vara att anvandaren kanner sig subjektivt
"immersed" i den datorgenererade varlden och kan interagera valdigt naturligt genom att
anvanda datahandskar (datagloves) och andra indataenheter. Av marknadsskal har den
virtuella verkligheten nu delats in i tva omraden, desktop och immersionsystem.
Immersionsystem inkluderar saker sasom hjalmar och handskar, medan desktop inte har nagon
utav dessa. Vanliga desktopsystem anvander sig av en stor fargskarm for bade in och
utdata. Ett tredimensionellt pekdon, kanske en tredimensionell mus tillsammans med ett
tangentbord. Genom olika mjukvara och controller (ej oversatt ev. styrenhet) kan man gora
det mojligt att t ex "flyga" runt en modell av ett hus, inspektera och overblicka alla
rum. Eftersom var applikation har som syfte att ge en subjektiv kansla av inlevelse
passar ett immersive system ofta battre.
Fordrojning (latency)
Genom en specifikation av den virtuella varlden och tillracklig datakraft ar i princip
mojligt att aterge, ur vilken synvinkel som helst, en nastan godtycklig grad av
fotografisk detaljering. Men det ar datorintensivt och kan ta mycket tid. Nar man
forsoker visa upp det man atergett i realtid i en virtuell miljo anvander man sig ofta av
seriefigurliknande simplifieringar. T ex bryr man sig inte om att aterge textur och
skuggor, polygoner anvands istallet for kurvor och antalet objekt begransas. Studier har
visat sig foresla att fordrojning (hastigheten av uppdateringar av bilder i relation med
rorelsen) ar viktigare for anvandarens kansla av narvaro an det ar med hog upplosning
eller detaljerad atergivelse. Darfor godtar vi en medelmattig upplosning, enkla
atergivelser om det gors till priset av snabba skarmuppdateringar. En annan oifrankomlig
faktor ar langsamma tredimensionella trackers (sensorer). Vi maste insistera pa snabba
trackers . Antalet trackers har ocksa betydelse. Om man anvander fler an en tracker
kommer de att gora systemet langsammare. Vi behover atminstone tva trackers; en for
"headsetet" och en for handsken.
Att gora en andra datahandske eller en hel datadrakt sa att anvandaren kan se en
representation av hela sin kropp, eller att ha mojlighet att ha fler an en anvandare
samtidigt skulle ge hoga kostnader och langsammare svarstider.
Stereoskopiska versus monoskopiska displayer
Virtuella verklighetsdisplayer finns i tva olika typer: monoskopiska i vilken bada ogonen
ser exakt samma sak och stereoskopiska dar ogonen ser separata vyer. En viktig antydning
i djup perception, rorelse parallax kan aterskapas med en monoskopisk huvudmonterad
display. Detta ger effekten att om man flyttar sitt huvud en kort bit kan objekt som inte
ar sa langt borta ror sig i relation till varandra. Desto narmare de ar desto mer ror de
sig. Ett stereoskopiskt system skulle vara bra men det skulle antingen kosta valdigt
mycket mer eller sa skulle de ge ett langsammare system i ovrigt.
Tredimensionellt virtuellt ljud
Om vi har lust att lagga till horlurar och relativt billig hardvara, kan vi associera
olika ljudkallor till olika objekt i var fysiska varld (se bild 16.7 i boken). Genom
detta kan den visuella kanslan av de flesta nuvarande system kannas undermalig, den
fantastiska kvaliten av tredimensionellt ljud kan helt klart oka kanslan av subjektivt
narvarande. Preliminara bevis innebar att tredimensionellt ljud gor uppgifter som t ex
kanna av objekt i rorelse, navigering och lokaliseringskansla blir lattare och trevligare
att utfora.
Sammanfattning av designval
Sammanfattningsvis, den virtuellt fysiska applikation verkar krava att minst ett
immersion virtual reality-system med hogkvalitets vidvinkels optik pa en display drivs
genom huvudrorelser. P ga rorelseparallax, kan ett monoskopiskt system mycket val vara
adekvat, aven om ett stereoskopiskt system skulle vara att foredra. Upplosningen skall
vara sa hog den kan bli, men inte till priset av realtiduppdateringar.
Se aven Box 16.2 i boken.
I kapitlet finns aven en intervju pa sidan 343 som jag valt att inte oversatta eftersom
denna ar "overkurs" och troligen inte heller ar av vikt for en tenta.
Skrivet av: Sofia Lundberg, nd97slg@student.hig.se.
Med reservation for eventuella andringar:-)
KAPITEL 20 - Uppgiftsanalys, Task Analysis - TA (sid. 409-429)
Malet med detta kapitel
Att introducera lasaren i en rad tekniker for att analysera anvandarnas uppgifter. Efter
att ha last detta kapitel ska Du kunna:
skilja pa mal, uppgifter och handlingar
gora en hierarkisk uppgiftsanalys
forestalla Dig en anvandares 'hur'-kunskap ('how-to-do-it'-knowledge)
identifiera behovet av att representera anvandarens uppgiftskunskap
Begreppet uppgift (task) ar centralt i anvandar-koncentrerad system design och manga
uppgiftsanalys-tekniker har utvecklats. Dessa tekniker koncentrerar sig pa olika aspekter
pa uppgifter, som uppgiftsstruktur, hur latt man lar sig en uppgift eller den kunskap som
kravs av anvandarna for att utfora en uppgift. Att uppmarksamma anvandaruppgifter och hur
uppgifterna delas upp i deluppgifter hjalper Dig att designa system som mer noggrant
reflekterar vad anvandaren vill gora.
Uppgiftsanalys, UA
ar den allmanna termen for ett stort antal tekniker som skall beskriva vad manniskor gor,
att representera dessa beskrivningar, forutsaga svarigheter och utvardera system mot
anvandbarhets- eller funktionella krav. Andra UA-tekniker har att gora med att forutsaga
prestationer, mata systemets komplexitet och "larbarhet" eller overforing till andra
system. UA handlar om vad manniskor gor for att fa saker gjorda. Funktioner ar
aktiviteter, processer eller handlingar som utfors av nagon manniska eller maskin.
Uppgifter ar nodvandiga for anvandaren, eller nagot som anvandaren tror ar nodvandigt.
For att foreta sig uppgifter utfor anvandare handlingar eller operationer, som att trycka
pa en tangent eller rora en mus.
20.1 Mal, uppgifter och handlingar
Mal (extern uppgift) ar ett systemtillstand som agenten (vilken sjalvstyrande, fornuftig,
manniska, maskin eller system som helst som formulerar sina egna mal och stravar efter
att hitta satt att tillfredsstalla malen) vill uppna. Mal kan t ex vara att skriva ett
brev. Ett mal uppfylls genom att anvanda ett eller flera instrument, metoder, agenter,
tekniker, fardigheter, eller mer allmant, nagot medel (device) som klarar av att andra
systemet till onskat tillstand. Man valjer sjalv vilket medel man vill anvanda for att
uppfylla malet. Uppgift (internal task) ar de aktiviteter som erfordras eller upplevs som
nodvandiga for att uppna malet genom att anvanda ett visst medel. En uppgift ar en
strukturerad mangd aktiviteter i vilka handlingar foretas i en viss sekvens. En handling
ar en uppgift som inte innehaller nagon problemlosning.
Strukturdiagram (structure chart)
Ett strukturdiagram representerar en hierarkiskt nedbrytning av nagon funktion i dess
delfunktioner. Det visar aktiviteternas (rektanglar i diagrammet) ordningsfoljd genom att
ordna dem fran vanster till hoger. Aktiviteter som kan komma att repeteras ett antal
ganger (iteration) markeras med en liten asterix (*) i rektangelns ovre horn. Nar en av
ett antal aktiviteter kan valjas (selection) markeras detta med en liten cirkel i ovre
hornet. En linje i rektangeln visar en saknad handelse. Vissa av deluppgifterna i
diagrammet delas sedan vidare upp i fler deluppgifter och numreras enligt den ordning de
utfors. (Detta diagram har stora likheter med JSP.)
En metod (method, plan) bestar av ett antal uppgifter eller handlingar i hopsatta till en
ordningsfoljd (sekvens).
Mal - ett systemtillstand som agenten vill uppna
Medel - metoder, verktyg eller tekniker som passar for att uppna mal
Uppgifter - aktiviteter som ar nodvandiga for att uppna mal med hjalp av ett medel
Deluppgifter - en uppgifts bestandsdelar
Handlingar - enkla uppgifter, utan problemlosning
20.2 Hierarkisk uppgiftsanalys (HUA) (Hierarchial task analysis, HTA)
bygger pa grafisk representation av uppgiften uppdelad i dess bestandsdelar; operationer
(handlingar) och deluppgifter. HUA inkluderar en iterativ process for att identifiera
uppgifter och sedan kategorisera dem, bryta ned dem i deluppgifter och kontrollera att
nedbrytningen gjorts korrekt. Malet for HUA ar att beskriva uppgiften som en hierarki av
uppgifter och planer. Planerna specificerar de forhallanden, under vilka en uppgift
utfors enligt. En HUA kan beskrivas i tre steg; start, utveckling och slutforande.
20.3 Kognitiv uppgiftsanalys (KUA) (Cognitive task analysis - CTA)
Om HUA ar en beskrivning av de olika stegen i en uppgift, ar KUA tekniker for att
beskriva den representation av kunskap som manniskor har eller behover for att klara en
viss uppgift. Vissa handlingar ar fysiska (t ex trycka pa en knapp, flytta en pekare
eller tala), andra ar mentala eller kognitiva (t ex bestamma vilken knapp man ska trycka
pa eller var man ska placera pekaren, eller jamfora tva objekt). Det finns ett antal
KUA-tekniker som fokuserar pa olika aspekter pa den kognitiva behandlingen. Nagra olika
KUA-tekniker ar 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 nivaer ar hur en beskrivning pa en niva oversatts till en beskrivning pa
en annan niva.
20.4 Modellera 'hur'-kunskap ('how-to-do-it'-knowledge)
Viktigt for att nagon bestamd design skall lyckas ar den procedurella kunskapen som
anvandarna beharskar - deras 'hur'-kunskap. I samband med uppgiftsanalys ar det
effektiviteten som satts i fokus - action mapping. Denna analys behandlar de handlingar
som maste utforas, givet att anvandarna har forstatt vad som maste goras for att uppna
malet. Den mest kanda modellen for detta ar GOMS, som bestar av beskrivningar av metoder
(planer) som behovs for att uppna ett visst mal. Metoderna ar serier av steg, bestaende
av operationer (handlingar) som anvandaren utfor. Nar det finns fler an en mojlig metod
for att uppna ett mal, har GOMS beslutsregler for att valja bland de alternativa
metoderna, beroende pa vilken som passar in i sammanhanget.
GOMS har tre detaljeringnivaer:
GOMS-modellen, som beskriver de generella metoderna for att utfora en mangd uppgifter.
The unit task level, som delar upp anvandarnas uppgifter i deluppgifter och sedan
uppskattar hur lang tid det tar for anvandaren att utfora dessa.
The keystroke level, knapptryckningsnivan, som beskriver och forutsager den tid det tar
att utfora en uppgift genom att specificera de knapptryckningar som behovs.
GOMS mal:
utvardering (evaluation) av designens naturlighet, fullstandighet, konsistens och
effektivitet. Forutsaga manskligt utforande i designen. Ge forslag till forbattringar av
designen.
GOMS-modellen kan anvandas pa flera olika satt, t ex:
for att forutsaga kvaliteten pa ett befintligt system eller prototyp
for att kontrollera metoders konsistens (for att forsakra att liknande mal uppnas genom
liknande metoder)
for att kontrollera att de mest forekommande malen uppnas genom relativt snabba metoder
som en kvantitativ utvarderingsteknik
for att valja mellan alternativa designer
20.5 Att representera uppgiftskunskap
For att forsta anvandarnas kunskap ar det viktigt att uppmarksamma dess tidigare
kunskaper, bade om den aktuella uppgiften och om mer allmanna uppgifter.
Ovning
Tank ut en "urvalsregel" som skulle kunna tillampas pa uppgiften 'vaxla' (en bil).
Kommentar
Om bilen har manuell vaxellada; tryck ned kopplingen, lagg i ettans vaxel, slapp upp
kopplingen. Om bilen har automatlada; valj 'kor-lage'. (En chauffor som ar van vid
automatlada kanske inte vet (har kunskap om) hur malet 'lagg i en vaxel'
uppfylls…)
Det finns ett antal mycket utarbetade metoder for detta; TKS som antar att manniskor har
strukturer av kunskap om uppgiften i minnet, strukturerna bestar av kunskap om objekten i
omvarlden och procedurerna el. metoderna som anvands for att genomfora uppgiften. Annan
kunskap ar typisk for uppgiften. KAT (Knowledge Analysis of Task) ar en teknik som
arbetar med att identifiera kunskap som ar av betydelse for uppgiften.
Greens kognitiva dimensioner for att beskriva aspekter pa informationsstrukturer:
Viskositet. Motstand mot forandringar. Hur enkelt det ar att gora andringar i program.
Fordrojd beloning. Anstrangningar som kravs for att na ett mal. Det enklaste av mal (som
det uppfattas av anvandaren) kan vara svart att uppna med ett visst granssnitt.
For tidigt stallningstagande. Anvandaren tvingas gora val for tidigt. T ex kan en
anvandare tvingas satta en grans pa nagra aspekter pa systemet innan de vet hur stort de
vill ha det.
Dolda beteenden. Informationslankar mellan saker i artefaktet vilka inte enkelt ar
synliga. T ex relationerna mellan celler i ett rutnat ar inte alltid synliga.
Sammanfattning, kap. 20
UA beskriver beteenden pa tre nivaer; mal, uppgifter och handlingar.
Uppgifter betraktas oftast i hierarkisk uppdelning av uppgifter i deluppgifter.
HUA och andra relaterade tekniker fokuserar pa vad som ar verkliga handelser, snarare an
pa vad som skulle kunna handa.
Kognitiv uppgiftsanalys-tekniker syftar till att beskriva nagra aspekter pa de kognitiva
metoder som kannetecknas av anvandarens uppgifter.
Nagra metoder (som t ex GOMS) koncentrerar sig pa anvandares 'hur-kunskap'.
Andra metoder fokuserar pa kunskaper om uppgifter.
Manga av de tekniker som finns just nu ar svara att anvanda och okar inte tillrackligt
for kommersiella applikationer.
Nyliga forsok ser mer till en helhetsbild - for att forsoka gora mer anvandbara verktyg.
KAPITEL 21 - Strukturerad MDI-design
Syftet med detta kapitel ar att gora designmodeller eller -representationer som skall
underlatta forstaelsen for och informera om designprocessen. Efter att ha last kapitlet
skall Du kunna:
forsta principerna med strukturerad MDI-design
skilja konceptuell fran fysisk design
forsta uppgiftsfordelnings-processen
forsta att design aven handlar om tillhandahallande av hjalp och support, och inte enbart
skarmlayouter
gora designer till enkla system
I kapitel 20 talade man om att det finns tre huvudnivaer att ta hansyn till - mal,
uppgifter och handlingar. Det ar dessa nivaer som tillhandahaller oss med stommen till
var design. Denna syn liknar en av de mest kanda designmetoderna, Command Language
Grammar (CLG). CLG ar en symbolisk notation, tekniken representerar den tankta designen i
fyra nivaer. Varje niva ger en fullstandig beskrivning av systemet pa den nivan. CLG
bestar alltsa av en sekvens av hierarkiska nivaer, dar varje niva ar en forfining av
foregaende niva.
Tabell 21.1:
Del (component) CLG-niva
Konceptuell "del" innefattar: uppgiftsniva semantisk niva
Kommunikations "del" innefattar: syntaktisk niva interaktionsniva
Sammanfattning (av huvudfaktorerna) for varje CLG-niva
CLG-niva Designern tar hansyn till Designern gor Anvandaren tar i beaktande
Uppgift Vad sager uppgiftsanalysen uppgiftsbeskrivn. Hur kan jag anvanda systemet
att anvandaren kommer att for att gora X (t ex skriva ett
vilja gora? brev)?
Semantisk Vilka objekt, handlingar och semantisk beskrivn. Hur kan jag fa systemet att
metoder behovs for att gora gora X (t ex radera en sats)? varje deluppgift?
Syntaktisk Hur skulle dialog och syntaktisk beskrivn. Hur markerar jag en sats? Vad
informationsdisplayerna ar 'DELETE'-kommandot?
se ut?
Interaktion Vad skulle de exakta in- interaktions Vilka tangenter (el. mus,
och output sekvenserna specifikation knappar etc) trycker jag pa for
bli om vi anvande X och att markera en sats och sedan
Y som in- och outputmedel, radera den?
var for sig?
Konceptuell design motsvaras av den konceptuella och semantiska nivan i CLG och mal- och
uppgiftsnivan i den generella modellen (fig. 20.1) samt mappningarna mellan dessa nivaer.
Behandlar hur systemet maste se ut for att uppfylla stallda krav, men inte hur strukturen
och funktionerna realiseras i ett fysiskt system. Vi behover inte koncentrera oss pa
funktion och struktur forran vi ser pa interaktionsformen i detalj. Fysisk design ar
designen av det fysiska systemet.
21.1 Ett ramverk for design.
Den psykologiska stommen i var design forutsatter att anvandarens kunskap ar lagrad i
nivaer. Man kan veta nagot pa en niva men ej pa en annan. T ex: en anvandare kan veta hur
en uppgift betecknas (som att radera en del av en text) och operationerna som behovs for
att utfora uppgiften (som att valja en del av en text och sedan flytta den), men inte
veta hur man gor det ( t ex i vilken ordning tangenter skall tryckas ned). Nivaerna
anvands bade for designern och anvandaren.
Konceptuell aspekt: designern vill minimera konceptuell komplexitet i systemet genom att
anvanda sa fa och kanda objekt som mojligt och gora metoderna sa enkla som mojligt.
Anvandaren mappar en uppgift till dess associerade konceptuella objekt och operationer
som finns i systemet. Det ar darfor viktigt att designerns konceptuella modell matchar
anvandarens mentala modell av processen.
Fysisk aspekt: att badda in den konceptuella systemmodellen i en fysisk struktur sa att
anvandare kan kommunicera med systemet. Det viktigaste beslutet for designern ar hur
konceptuella operationer skall "forpackas" till en dialog - de operationella
(operational) aspekterna pa fysisk design. Detta inkluderar beslut som enkla kommandon
eller avancerad grafik, generella eller mer specifika kommandon med flera parametrar
eller utan parametrar etc. Fran anvandarens synvinkel bestar denna niva av dialogstruktur
och all information pa skarmen, inkl. feedback. Forflyttning fran den konceptuella till
den fysiska nivan kraver att designern bestammer vem eller vad som skall foreta sig
sarskilda funktioner. Detta ar task allocation-processen (uppgiftstilldelningsprocessen).
Designern skapar uppgifter at anvandaren genom att tilldela vissa logiska funktioner till
manniskor, till datorn eller till manniska-dator system. Uppgifter som tilldelas
manniskor maste sa mycket som mojligt matcha de uppgifter anvandare kan bilda sig en
uppfattning om. (Hansyn till anvandares kognitiva begransningar).
21.3 Fran logisk till fysisk design: uppgiftstilldelning (task allocation)
En av de viktigaste besluten som maste tas under utvecklingen av ett manniska-dator
system ar att tilldela uppgifter (vem ska gora vad) - manniska, dator eller
manniska-dator system (MDI)? Utvecklaren maste faststalla vem (eller vad) som ska halla
med datat eller kunskapen som behovs for att utfora uppgiften och vem (eller vad) det ar
som fysiskt skall utfora uppgiften.
Ovning
Fig. 21.1 om Eurochange-systemet (en uppgiftsnivabeskrivning av Eurochange, process 2
(KontrolleraKredit)). Vad kan datat "ValutaMangd" innehalla?
Kommentar
Nagra mojligheter:
anvandaren kan trycka in ett belopp i den valuta som galler pa aktuell plats (lokal
valuta) och begara samma belopp i en annan valuta,
anvandaren kan begara ett belopp i den valuta som begarts, men skulle sedan behova veta
hur mycket det ar i lokal valuta
systemet kan erbjuda belopp i den frammande valutan och begransa anvandaren till att
valja ett av dessa
Designern maste gora en mer detaljerad beskrivningsniva av process 2 for att undersoka de
olika alternativen (fig. 21.5). Ett annat alternativ ar att anvandaren specificerar
begart output-belopp och valuta och systemet skulle rakna ut motsvarande i lokal valuta.
Elin Tallberg, nd97etg@student.hig.se
KAPITEL 21 (B) - Strukturerad MDI Design
Ovning (se fig 21.5 sid 442
Identifiera processen som anvandaren maste utfora for foljande scenarier i Eurochange.
Jag vill ha motsvarande ?100 i DM.
Jag vill ha 2000 francs.
Kommentar
Anvandaren utfor 2.1, 2.2 och 2.3
Anvandaren utfor 2.3 och 2.4
Logiskt sett ska anvandaren utfora 2.3, men det finns manga fysiska designval, av vilka
alla utfor samma logiska process. Om datorn stoder denna process kan man peka pa
valutorna som ar tillgangliga med en muspekare, valja fran en lista med hjalp av
piltangenterna, visa pa en pekskarm eller visa med fasta knappar.
21.4 Fysisk design
Nar man har overvagt tilldelningen av uppgifter till manniska och maskin kan man
specificera och utveckla driftsaspekterna hos systemet. Driftsaspekter innebar vad
anvandaren kan gora och vad systemet kommer att svara dvs. vad systemet gor. Samtidigt
som man gor detta bor man tanka pa hur systemet skall se ut. Det finns tre huvudaspekter
for att beskriva driften av ett system:
Hur kan systemet tala om vilket tillstand et ar i.
Vilka operationer kan anvandaren utfora.
Feedback
Det finns tva satt pa vilka systemet kan indikera vilket tillstand den ar i med hjalp av
visuell information:
Systemets tillstand ar synligt for anvandaren.
Systemets tillstand ar inte omedelbart synligt men det ar iakttagbart om anvandaren utfor
nagot.
Vanligtvis sa ar den forsta av dessa att foredra. Det finns olika satt for designern att
klargora vad anvandaren kan gora. Affordance-principen ar mycket viktig har (13.7).
Designen av knappar, skarmbilder osv. som tillater tex. att kunna trycka, klicka,
beroring osv. ar viktigt. Det ar ocksa viktigt att tanka pa felaktiga saker anvandaren
gor. Avbrytsmekanismer som tex. "avbryta"-knapp ar ocksa viktigt.
En metod for att specificera detta ar att anvanda ett flodesdiagram eller en
dataflodesrepresentation av den logiska dialogen. Andra satt att representera detta ar i
tillstandsdiagram, strukturdiagram och en notation som kallas UAN (User Action Notation
method). Teckningar kan ocksa anvandas men de saknar precisionen hos mer formella
metoder. Fordelen med informella metoder ar att de latt kan testas pa anvandare. En
viktig aspekt hos alla notationer ar att de ska visa kontrollflodet. Till skillnad mot
konceptuell design maste fysisk design fokusera pa nar och vart handelser och beslut tas,
vilka handelser som kan iterera, vilka handelser som ar frivilliga och sekvensen dar
handelsen sker.
Valet av vilken interaktionsstil (kap 15) som ar lamplig spelar en central roll i
operationell design, tex. kommandosprak, direktmanipulation, fragor och svar osv. Den
maste passa for anvandarna, arbetet de gor, systemet och omgivningen.
Det ar viktigt att specificera hur ett system skall se ut. Det finns ocksa mer generella
ergonomiska angelagenheter som tex. form och storlek pa knappar, "fladder" pa skarmar och
hojden och lutningen pa displayen. Det ar viktigt att tanka pa det overgripande
sammanhanget och behovet att presentera en lamplig sammanhangande modell av strukturen
och funktionen hos maskinen for de tilltankta anvandarna.
21.5 Slutfora designen
Box 21.2
Physical Consistensy
Att man ar konsekvent ar viktigt i interaktionsdesign, bade nar det galler framstallning
och verksamhet. Systemet ska stodja endast ett fatal satt att utfora kommandon.
Felmeddelanden bor se likadana ut och visa sig pa ett stalle pa displayen som stammer
ihop med resten av dialogen. Generellt ska objekt av en klass visa sig i samma stil som
de andra.
Conceptual consistensy
En sak att tanka pa har ar att systemet ska stamma ihop med anvandarnas forvantningar,
tex. sa ar "D" ett daligt val for ett "spara-kommando", dar vore "S" ett battre val, en
oppen dorr for ett "stang-kommando" likasa. En annan sak ar att enheter inom samma klass
bor behandlas lika, tex. att deleta ett ord bor man gora pa samma satt som nar man
deletar ett stycke. Sist men inte minst sa bor anvandaren kunna utfora liknande uppgifter
pa liknande objekt. Eftersom olika manniskor upplever saker pa olika satt, kan de tycka
att det som designern tycker ar konsekvent ar inkonsekvent.
Kombinationen av beteende, utseende och stil och konsekvent bild kommer att forsakra att
designen nar upp till anvandarnas behov. For att uppna detta maste man testa designen pa
anvandare i olika stadier av utvecklingen. Man bor komma ihag att design ar ett kreativt
arbete, som kan hjalpas med formella, strukturerade metoder, men tekniken kan inte utfora
designen at dig.
Sammanfattning
Det strukturerade synsattet att designa fokuserar pa beskrivning pa de konceptuella och
fysiska nivaerna.
Konceptuell design har att gora med vad systemet maste gora for att uppna syftet och den
nodvandiga strukturen.
Fysisk design har att gora med hur systemet gor saker och hur det ser ut.
Overgangen fran konceptuell design till fysisk design har att gora med tilldelningen av
uppgifter till manniska och dator och genom detta kanna igen krav och underforstadda
"constraints" i besluten.
De operationella aspekterna pa designen har att gora med hur systemet kontrollerar
dialogen, som anvandaren maste utfora och med systemets feedback.
Represenationella aspekterna har att gora med visningen av data, presentationen av en
sammanhangande systembild och de metoder genom vilka systemet "reveals itself".
Anvandarsupport ar en viktig del i designen.
KAPITEL 22 - Envisioning Design
22.1 Holistic design
Enligt det "holistiska" sattet att se ar design en helhet i vilken beslut om hur ett
interface ska se ut ar gjorda med tanke pa hur detta kommer att bli fysiskt kommunicerat
med anvandaren. Till skillnad fran det strukturerade sattet finns inga tydliga skillnader
mellan olika nivaer i systemet. Designen ar mycket mindre strukturerad. Man fokuserar pa
framtradandet och presentationen av den konceptuella modellen och sedan anvander man sig
av verkliga exempel. Det holistiska synsattet fokuserar pa utseendet hos interfacet och
dess beteende. Se aven kapitel 1 om utvecklingen av Star user interface.
Ett satt att "designa holistiskt" ar "game playing".
22.2 Sketching and metaphor
En mer och mer vanlig teknik ar att designa en konceptuell modell som en tydlig interface
bild (kapitel 7) som desktop analogi. Metaforer kan anvandas for att presentera en
sammanhangande bild av hela systemet eller att rikta in sig pa speciella funktioner eller
delar av systemet.
Rit-tekniker kan vara anvandbara for att utforska olika sorters design ideer (se fig.
22.2 sid. 457). Saval som att underlatta kommunikation kan man anvanda sig av visuell
"brainstorming" for att utforska alternativa designsatt. Efter att ha gjort bilder av de
basta ideerna kan man utveckla detta genom att gora en pappersframstallning av designen,
som kan utvarderas av anvandarna. Detta kan foljas av utvecklingsscenarier, mjukvara
eller videoprototyper. Det kan bli billigare att anvanda sig av papper och penna pa
tidiga stadier och datorbaserade och videoprototyper kan vara viktigt i senare stadier
for att utforska och demonstrera interaktionen och designen.
Ovning
Prova att rita ett kant anvandar-interface. Anvand mer an fem minuter att gora det pa.
Kommentarer
Ar det mojligt att se hur interfacet fungerar fran din teckning? Vilka problem upptackte
du? Tex. hur latt tyckte du att det var att representera dynamiken hos interfacet och den
konceptuella modellen hos systemet? Vilka grafiska tekniker anvande du (tex. pilar,
linjer)?
Ovning
Denna ovning ska uppmuntra dig att utveckla ditt eget grafiska ordforrad. Det ar viktigt
for designers att ha en meningsfull grafisk representation for att indikera elementen hos
ett helt systems omgivning. Med detta menas att ha snabba satt att representera objekt
som datasystemet, input och output anordningar och manniskor. Titta pa figur 22.3 sid.
459 och fuska som det foreslas.
Kommentar
Aven fast en naturlig begavning for att teckna hjalper, har Verplank och hans kollegor
kommit pa att det ar mojligt att lara sig att vara kreativ. En viktig del ar att utveckla
och anvanda ett ordforrad av enkla grafiska former.
Ovning
Denna ovning ska uppmuntra dig att anvanda brainstorming som ett satt att utveckla
visuella begrepp for hela eller delar av systemet. Forsok utveckla enkla visuella bilder
for ett anta ikoner som representerar olika storlekar av datasystem: stor, medelstor,
liten och PC. Gor detta genom att skriva rubriker hogst upp pa ett tomt papper och langs
vanstersidan nagra kategorier som man kan anvanda for 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.
Kommentar
Det kan tyckas lattare att rita bilder for delar av ett interface an att forsoka rita ett
helt system.
Ovning
Forsok nu att utveckla visuella metaforer for foljande: edit, debug, string, execute,
declare, loop, field. Eftersom dessa ar abstrakta, kan du alternativt anvanda verbala
metaforer.
Kommentar
Se figur 22.4 sid. 460.
De visuella metaforer som du nu har utvecklat kan vara mer anvandbara for design av
ikoner. Verplank rekommenderar att vi tittar pa saker som finns i var omgivning som
fordon, klader, tidningar och verktyg (se fig. 22.5 sid. 461). Om man tanker pa dessa
saker kan de ge inspiration och ideer.
22.3 Scenarios, storyboards and snapshots.
Ett scenario ar en personifierad, pahittad historia med roller, handelser, produkter och
omgivningar. De hjalper designern att utforska ideer och foljden av olika designval.
Snapshots ar ofta serietidningsliknande bilder som fangar en speciell eventuell
interaktion. Storyboards ar sekvenser av snapshots som fokuserar pa huvudfunktionen i en
eventuell situation. Genom att anvanda dessa tekniker kan designers ga fran befintliga
till potentiella interaktioner och darigenom forutsaga problem. Det kravs prototyping och
evaluering tillsammans med anvandare for att uppna en bra balans mellan de olika
faktorerna. Meningen med representationen ar att se vad som hander i specifika
situationer.
Scenarier tvingar designern att tanka pa det passande i designen, aven typen och mangden
av anvandarsupport och andra aspekter pa omgivningen. Snapshots av kritiska situationer
och storyboards ar andra effektiva metoder.
Sammanfattning
Kreativiteten hos designen kommer oftast fran att man har anvant tekniker som stimulerar
tanken och uppmuntrar betraktandet av ett brett designomrade.
Rit-tekniker kan bli utlarda till och anvanda av designers, man behover inte vara en
konstnar for att anvanda dem.
Att kanna igen det sociala sammanhanget i designen och vikten av speciella situationer
kan avslojas i scenarier, snapshots och storyboards.
KAPITEL 24 - Riktlinjer: Principer och regler
24.1 Principer och regler
De basta riktlinjerna for anvandarinterface ar principer som ar pa hog niva och ar vitt
tillampliga, tex. sa erbjuder foljande principer rad som ar anvandbara:
Ta reda pa vem som ska anvanda interfacet.
Minska inlarningen for anvandarna genom att vara konsekvent.
Skapa med tanke pa fel. Manniskor kommer alltid att gora fel och de ska aven gora det for
att lara sig. Gor bra felmeddelanden osv.
Uppratthall foljdriktighet och klarhet.
For att anvanda dessa principer praktisk, maste de sattas in i ratt sammanhang beroende
pa vad de ska anvandas. Att bara tillampa riktlinjer kommer inte att leda till bra
design.
En design-regel ar en instruktion som kan foljas med minimal oversattning av designern,
tex. datafalt ska vara i formatet DD-MM-YY och MM-DD-YY i Nord Amerika. Hogniva principer
daremot maste oversattas till en strategi for att producera en entydig design-regel som
ar lamplig for systemet i fraga, input-mediet bor vara lampligt for systemets omgivning.
Ovning
Klassificera foljande riktlinjer som principer eller design-regler
Utfarda alltid ett varningsmeddelande till anvandaren innan man deleter en fil.
Tillhandahall ett reset-kommando
Designa for okning av antalet anvandare
Tillat flexibilitet i inputen
Anpassa efter olika anvandarnivaer och stilar.
Sakerstall att det ar latt att forsta.
Ge lamplig mangd respons
Visa "avsluta-knappen" langst ner till vanster pa skarmen.
Kommentarer
Det ar fem principer pa listan:
Designa for okning av antalet anvandare
Tillat flexibilitet i inputen
Anpassa efter olika anvandarnivaer och stilar
Ge lamplig mangd respons
Det ar tre design-regler
Utfarda alltid ett varningsmeddelande till anvandaren innan man deleter en fil.
Tillhandahall ett reset-kommando
Visa "avsluta-knappen" langst ner till vanster pa skarmen.
Man maste tanka pa att tolka principerna pa ett passande satt, riktlinjer kan och har
utvecklats vilket forenklar och forvrider den psykologiska teorin pa vilken de ar
baserade. Ett exempel pa det ar det att kapaciteten hos korttidsminnet ar begransat till
att komma ihag mellan 2 och 7 saker (kapitel 5). I manga riktlinjer har det blivit
oversatt till en designprincip som foreskriver det maximala antalet saker som kan visas
pa samma gang. Tex. antalet farger pa en skarmbild. Aven fast det ar sant att man inte
ska anvanda for manga farger pa en gang ar inte skalet till det att vi inte kan komma
ihag mer an ett fatal farger per gang, utan for att for manga farger skapar forvirring.
Det ar darfor ett problem med iakttagelseformaga och uppmarksamhet och inte ett som har
med igenkannande att gora.
Anvandningen av riktlinjer ar begransade. De kan dock vara till hjalp for designers att
fokusera pa vad som behovs.
Ovning
Tank dig att du ska designa ett interface for en omgivning som stoder fem saker. Dessa ar
textredigering, e-post, grafik, networking och atkomst till en on-line referens databas.
Anvand riktlinjerna av Smith och Mosier (sid 491), hur skulle du designa interfacet for
de olika applikationerna? Vilka underliggande psykologiska principer ar relevanta har?
Kommentar
Baserad pa riktlinjen av konsekvent format, ar ett satt att representera de olika
applikationerna i olika fonster som kan associeras med varje applikation. For att uppna
detta kan man anvanda sig av fargkodning for det olika fonstren. Formatet i fonstren bor
vara konsekventa sa att tex. fonstrens titel ar pa samma stallen.
De underliggande psykologiska faktorerna ar om fokuserad och delad uppmarksamhet. Fast
anvandarna inte kan utfora tva eller flera uppgifter samtidigt kan de utfora flera
uppgifter genom att hoppa mellan dem. Ett satt for anvandarna att byta mellan fonstren
snabbt och enkelt borde darfor finnas.
24.2 Vart kommer riktlinjer fran?
Riktlinjer har tva ursprung: psykologisk teori och praktisk erfarenhet.
24.3 Utvardera riktlinjer
Riklinjer innehaller oundvikligt en del sammanfallande och motsagelsefulla rad. Att vara
konsekvent kan vara viktigt for att lara sig att anvanda ett visst system men
bekymmersamt nar en anvandare blir erfaren. Manga av dessa motsagelser uppstar tidigt och
forsvinner sedan under designprocessen allteftersom hogniva-principer blir foradlade till
lagre niva designregler.
Att utvardera riktlinjer kraver en stor skicklighet. Denna skicklighet tar tva former:
att ta hjalp av publicerade fakta och fran egna erfarenheter. Det basta sattet att
kontrollera en riktlinje ar att testa den och observera resultatet, och lagga stor vikt
vid vilken situation den anvands.
24.4 Ett exempel pa att anvanda motstridande riktlinjer
Aven fast vissa riktlinjer ger motstridiga rad, forsvinner manga av dessa motsagelser nar
man arbetar med designen. Man marker oftast vilken riktlinje som passar pa vilket stalle.
Vissa konflikter foljer dock med till implementationen och andra kanske man inte marker
forran man implementerar.
Sammanfattning
Principer ar hog niva och mycket tillampliga; design-regler ar lag niva-instruktioner
Principer maste tolkas och appliceras med tanke pa en speciell situation
Riktlinjer kan baseras pa psykologisk teori eller praktisk erfarenhet
Publicerade riktlinjer kan hittas i tidningar, heminredningsguider och generella
handbocker
Helena Andersson, nd97han@student.hig.se
Kapitel 26 - Designens motivering, Design Rationale (s 523-536)
Malet med detta kapitel
Att forsta vikten med att protokollfora beslut fattade angaende designen. Efter att ha
last detta kapitel skall du kunna
Kritisera stodet som ar tillgangligt for kommunikation och redogorelse av beslut fattade
angaende designen
Diskutera relevansen av lampliga undersokningar och sedan protokollfora designbesluten
Dokumentationens anvandbarhet
Det traditionella sattet att fa igang en diskussion mellan olika parter da man talar om
ett informationssystem ar att ta anvandning av systemdokumentationen. Det ar flera
berorda som kan dra nytta av dokumentationen. Forst och framst sa behover utvecklarna av
systemet ha tillgang till en sammanhangande beskrivning av struktur och syfte. Andra
personer som kan behova ta del av dokumentationen ar de som skall underhalla systemet, de
som skall skota utbildning och de som skall skota marknadsforing. Aven ny personal som
skall ta del av ett projekt kan latt satta sig in i ett arbete da man kan ta del av
dokumentationen. Dokumentationen ar aven bra da den underlattar ateranvandning.
Ovning
Vad kan mjukvaruutvecklare, utbildare och marknadsforingspersonal dra for nytta av att
forsta tanken bakom ett system?
Kommentarer
Mjukvaruutvecklarna maste forsta varfor designen ar utformad som den ar for att kunna
gora andringar nar de behovs utan att hela systemet stabilitet skall behova sonderfalla
Marknadsforare skall salja systemet till potentiella kunder. De behover darfor forsta
varfor systemet gor vissa saker och varfor det inte gor andra. Att forsta systemets
uppbyggnad gor att de kan ge lampliga svar pa kunders fragor.
De som skall utbilda slutanvandarna skall forsta varfor olika funktioner fungerar pa de
satt de gor sa att de kan hjalpa slutanvandarna sa att de far god forstaelse for
systemet.
Det ar svart att veta hur man pa basta satt skall kunna dokumentera tanken bakom
systemet. Ett alternativ ar att gora en tabell dar man antecknar datum, alternativ som
overvagts, anledningar till varfor man valt ett visst alternativ och inte ett annat osv.
Tre olika former for att dokumentationen av designens motivering ar: IBIS,
Mangdesignanalys och Fordringsanalys.
26.1 IBIS
IBIS (Fragebaserade informationssystem) ar ett system framstallt for att fatta beslut om
designen allt efter som arbetet fortlider. IBIS skall utgora en biprodukt av designen.
Huvuduppgiften for IBIS ar att genom att utga fran medvetna overvaganden och analysera
for- och motargument samt tankbara svar pa fragor. Ett exempel pa en fraga som kan
behandlas med hjalp av IBIS ar "vad skall systemet gora?" och denna fraga leder sedan
till flera bifragor. Se exempel 26.1. Den fraga man utgar fran kallas grundfraga och
beskriver sedan relationer mellan fragorna.
26.2 Mangdesignanalys (Design space analysis)
Det finns manga olika designer for att uppfylla ett systems specifikationer. I
Mangdesignanalys testar designern manga olika alternativ for att fa fram det basta
alternativet. Detta leder till att kvaliten pa systemet blir battre. QOC (Questions,
Options and Criteria) ar en notation som anvandas for att undersoka alla alternativa
designer sa att resultatet blir nagot mer an bara en detaljerad beskrivning av "varfor"
och "darfor" man valt en viss design. Se exempel figur 26.3. Skillnaden mellan IBIS och
QOC ar att IBIS fragor och svar mer galler ett generellt syfte for hela systemet och QOC
galler enbart for designen. Det ar svart att fatta designbeslut enbart utifran QOC for
kriterierna vager olika beroende pa kontext och anvandning. QOC kan dock ge stod genom
att belysa interaktion mellan principer, konsistens och prioritering.
26.3 Fordringsanalys (Claim analysis)
Vid Fordringsanalys ar tanken att man skall analysera och forbattra en befintlig design.
Fordringsanalys kan anvandas for att guida en omdesign av ett system eller for att hjalpa
till vid utvecklingen av ett nytt system da prototypen skall framstallas. Det gar ut pa
att man undersoker de psykologiska krav som designen forsoker losa med avseende pa
anvandare, anvandning, kontext mm. Fordringsanalysen gors genom att man skapar nagra
senarier for systemets anvandningsomrade och sedan analyserar man vilka krav man kommit
fram till. Karnuppgifter som systemet skall kunna klara och olika fel som systemet skall
kunna hantera skall inkluderas, men huvudsyftet ar att identifiera hur systemet pa ett
positivt satt skall tjana anvandaren.. Fordrings analysen skall aven identifiera de
situationer da inte designen inte var den basta tankbara for att ge anvandaren support.
Sammanfattning av kapitel 26
Beslut angaende designen behover protokollforas och diskuteras av flera olika personer.
Dokumentationen ar ett malplacerat satt att kommunicera information angaende designen med
anvandarna.
Att dokumentera tanken bakom designen ar en tidskravande process.
Mangdesign analys uppmuntrar designers att undersoka flera alternativ.
Fordringsanalys koncentreras pa att forbattra en design.
KAPITEL 27 - Prototyping (s 537-555)
Malet med detta kapitel
Att introducera lasaren till ett flertal prototyping tekniker. Efter att ha last detta
kapitel skall du kunna:
Kanna till en rad av olika prototypingtekniker
Kunna beskriva hur och nar du skall anvanda en viss teknik
Det finns tva olika typer av prototyping: pappersbaserad och databaserad. Framstallningen
av pappersbaserade prototyper gar snabbt och ar billigt, samt ger vardefulla inblickar i
systemet men kan inte demonstrera funktonaliteten. Databaserad prototyping ger en version
av systemet med begransad funktonalitet sa att anvandaren kan samspela med det.
Foljaktligen sa skiljer sig prototypen fran det slutliga systemet i storlek,
driftsakerhet, helhet och konstruktionsmaterial.
En mjukvaruprototyp ar ett system som:
fungerar, dvs. det ar ingen forestallning eller ritning
inte har nagon generaliserad livstid, ibland slangs den direkt efter den anvants och
ibland utvecklas den till det slutliga systemet
kan passa for flera olika syften
maste byggas snabbt och billigt
27.1 Prototypningstekniker (Prototyping techniques)
Prototyping skall anvandas for att se hur val designen passar anvandarens behov. Den
hjalper designers att fatta beslut genom att fa fram information fran anvandarna om:
den nodvandiga funktonaliteten av systemet
operationsfoljder, vilken ordning operationerna skall ha
anvandarens behov av hjalp
nodvandiga representationer
granssnittets utseende och kansla
Olika tekniker for att gora prototyper :
Krav pa funktioner (requirements animation)
Snabbprototypframstallning, for att samla information om funktioner och om lampligheten
hos vissa designer
Incremental prototyping, man installerar systemet i faser, bestammer vilka funktioner som
ar med fran borjan och sedan fasas resten over nar det ar fardigt
Utvecklingsprototyping (Evolutonary pr.), man utvecklar en prototyp som man sedan bygger
pa till dess att den blivit ett fullt system.
Se tab. 27.1.
Ovning
Varfor skulle systemen bli mer acceptabla om Utvecklingsprototyping skulle blandas med
"krav pa funktioner" eller "snabbprototypframstallning"?
Kommentarer
"Utvecklingsprototyping" ar en blandning av full produktion och "snabb prototyping" av
ett system. Den slutliga produkten vaxer fram ur den forsta prototypen. Varje
utvecklingssteg kan ses som ett eget miniprojekt. Om "snabb prototyping" skulle anvandas
i varje steg skulle en battre produkt erhallas. (forstar inte riktigt vad de menar, se
sid. 540)
Tekniker for att gora prototyper
Full prototyping - alla funktioner finns med men med lagre prestanda
Horisontell prototyping - visar anvandargranssnittet men har ingen funktionalitet bakom
knapparna
Vertikal prototyping - innehaller all funktionalitet for en begransad del av systemet
Naturtrogen ljudatergivning (high fidelity) - prototyping genom nagon form av media, te x
video, som skall paminna sa mycket om systemet som mojligt.
Low fidelity - for framstallning av prototypen anvands nagot material som ar billigt och
snabbt te x. storyboards
Chauffor prototyping - en anvandare for studera en annan person, vanligtvis en
utvecklare, nar denne kor systemet
"Trollkarlen fran Oz" prototyping - en anvandare sitter vid en skarm och utfor sina
uppgifter men istallet for att det ar ett system som svarar sitter en utvecklare vid en
annan skarm och svara pa fragorna.
27.2 Prototyping for att stodja designen (Prototyping to support design)
Prototyping kan vara anvandbart i flera steg av designen, te x. produktkonceptualisering,
pa uppgiftsnivan och for att bestamma skarmdesignen.
Produktkonceptualisering "Product conceptualization"
I de tidiga stadierna av produktutvecklingen kan prototyping anvandas for att man skall
fa en battre forstaelse for vilken typ av produkt som forvantas. Flera olika skisser over
designen kan presenteras for anvandare och medlemmar i utvecklingslaget for kommentarer
och forbattring.
Ovning
Varfor kan det vara fordelaktigt for medlemmarna i utvecklingslaget att se en
prototypdesign?
Kommentarer
Om designen ar gjord av flera utvecklare ar det viktigt att medlemmarna kan kommunicera
effektivt och en prototyp underlattar detta.
Box 27.1
Quick Time gor sa att man kan anvanda ljud, videoklipp och animering i dokument. Det
anvands bland annat i utbildningsprogram, affarspresentationer och inom vetenskap och
teknik.
Uppgiftsnivaprototyping (Task level prototyping)
Nar kraven for systemet ar faststallda och funktionaliteten blivit tydligare kan
prototyping hjalpa till att grunda ett andamalsenligt granssnitt pa uppgiftsnivan. Syftet
ar att sakerstalla att anvandarna kan utfora de nodvandiga uppgifterna for jobbet. Det ar
nodvandigt att gora scenarier byggda pa uppgiftsanalysen, det racker inte med att testa
fritt. De metoder som anvands inom systemering kan da tillampas t ex. acceptanstest och
systemtest.
Skarmdesignprototyping (Screen design prototyping)
Skarmdesignprototyping innefattar b la ikoner, menyeroch skarmlayouter. Det ar viktigt
att tanka pa att man anvander passande ikoner, lampliga farger, visuella och
audioeffekter och en bra gruppering av kommandon i menyer. Skarmdesignen kan
inledningsvis goras med papper och penna men kraver pa slutet anvandning av nagon
mjukvara.
Kommentarer
Lampligheten for interface element och layouter beror pa i vilket sammanhang systemet
skall anvandas. Till exempel sa beror betydelsen av en ikon pa fem aspekter (tas upp i
kapitel 5). En annan fraga att tanka pa ar kategoriseringen anvand for menydialoger. I
ISO 924 star det bl a att interfacedesignen beror pa uppgiften, anvandaren, omgivningen
och den tillgangliga teknologin och om valen i menyn kan delas in i grupper som ar
naturliga for anvandaren sa skall man gora det.
27.3 Mjukvara for prototyping (Software prototyping tools)
Det ar viktigt att den som skall utveckla interfacet kan valja ett lampligt verktyg som
passar bade for den prototypingmetod som ar vald och for det syfte som prototypen skall
uppfylla. Det ar bra att veta om man skall utveckla vidare pa den prototyp man skapar
eller om den skall slangas efter det att den anvants. Det ar aven bra om
prototypingverktyget inte kraver for hog grad av programmeringskunskaper da man vill att
prototypen skall vara klar sa fort som mojligt. Tva olika verktyg anvands for
prototypframstallning: produktionsverktyg (kan anvandas bade for prototyping och
design)och verktyg som ar speciellt gjorda for prototyping
Prototypa med produktionsverktyg (Prototyping with production tools)
Nackdelen med produktionsverkyg ar att de maste vara valdigt omfattande och de drar med
vissa begransningar sa att fullstandig, driftsaker, robust och underhallningsbar mjukvara
kan produceras. Detta kan medfora att prototypingen tar langre tid och blir dyrare.
Prototypingsverktyg (Prototyping tools)
Anvandning av prototypingsverktyg medfor en forsamring av kvaliten for prototypen pga.
att prototypen maste konstrueras snabbt. Man kan tex. anvanda text istallet for grafik
for att snabba upp framstallningen.
Sophie Lif, nd97slf@student.hig.se
KAPITEL 27 (B) - Prototyping (s 556-564)
27.5 HyperCard
HyperCard-applikationer gar under benamningen stack. Varje stack har en eller flera
bakgrunder, en mall som ar gemensam for flera kort (se fig 27.6 s 557).Varje bakgrund
associeras till ett eller flera kort. Korten kan innehalla bitmappbilder, knappar och
textfalt. Varje HyperCard-objekt associeras till ett script, som talar om vad som ska
handa nar man klickar pa ett objekt (se exempel pa script pa s 558).
Kommentar
HyperCard ar bast lampat nar man snabbt vill satta ihop en prototyp, sarskilt i borjan av
en systemutveckling. Viss animation kan goras, men knappast med det fina detaljarbete som
kravs hos slutprodukten. HyperCard ar utvecklat for Macintosh, vilket ytterligare
begransar dess anvandbarhet nagot.
Sammanfattning av kapitel 27
Prototyputveckling ar ett satt att visa anvandarna olika designlosningar.
Tala om att det ar en prototyp, varfor man har gjort en sadan.
Olika slags prototyper behovs vid olika stadier av utvecklingen.
Det kan vara svart 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)
Malet med detta kapitel
Att forklara vad som menas med evaluering, varfor man bor gora en sadan och hur man gar
tillvaga. Efter att ha last kapitlet bor du ha fatt en uppfattning om:
olika metoder for evaluering
sambandet mellan design, utveckling och evaluering
varfor man gor pilotstudier
varfor man ska satta anvandaren i centrum
Vad ar evaluering?
En evaluering innebar att man samlar data om hur ett anvandargranssnitt fungerar
praktiskt. Det sker genom att en grupp anvandare far utfora en viss uppgift. Boken
betraktar evaluering som ett helhetsbegrepp: den enklare sortens evaluering innebar att
man fragar anvandaren direkt vad vederborande tycker om en speciell designlosning. I den
andra anden pa skalan finns den mera strikta metodiken, dar man arbetar i en
laboratoriesituation under rigorosa former. I bada fallen galler att tanka pa detta:
Vem ar anvandaren? Tillhor testpersonen programmets malgrupp? Tank pa kon, tidigare
erfarenhet, alder, fysiologi, psykologi.
Vad kommer anvandaren att vilja gora med programmet? Man kan begara vissa, starkt
begransade uppgifter eller lata anvandaren sjalv besluta.
Var utfors testet? Det kan vara en sluten laboratoriemiljo eller en autentisk
arbetsplats, alltsa en faltstudie.
Vilken typ av objekt ger man till forsokspersonen for utvardering? Det kan vara en serie
skisser, en arbetsprototyp, eller en kommersiell produkt.
Dessa fyra punkter ar viktiga for att forutsaga hur ett system ska fungera, alltsa innan
man har gjort anvandartester. Man forsoker gora en grov uppskattning over vad
'normalanvandaren' kan tankas vilja gora, fokuserar pa manniskan, vilket arbete som ska
utforas, omgivningen och teknologin. Men om man vill utvardera en verklig arbetsplats ar
laboratoriemetaforen inte tillamplig.
29.1 Vad vill vi ta reda pa, och varfor?
Varfor gor man en evaluering? Jo, for att da vet man battre vad anvandaren behover, och
kan utforma systemet darefter. Risken ar annars att systemets granssnitt bara speglar
utvecklarens intentioner. Det maste testas i verkliga situationer innan man borjar sprida
det i stor skala. Det finns aven internationella standarder att ta hansyn till.
Evalueringen ar alltsa en viktig del av programutvecklingen. Nar programmeraren behover
feedback fran den stora anvandargruppen sager man att evalueringen ar av formativ natur.
Motsatsen, evaluering av ett fardigt program, kallas summativ. En sadan utvardering gors
mest av kosmetiska skal, varfor vi inte befattar oss vidare med den har.
Ovning
Anvand din kunskap om design; stall fragor som ett designteam kan ha nar de utformar ett
system.
Kommentar
Har ar nagra forslag till ovanstaende ovning:
Vilka ar problemen med det gamla systemet?
Hur anvands det gamla systemet egentligen?
Finn en lamplig metafor!
Vilken av de fem typerna av ikondesign bor vi anvanda?
Kommer anvandaren att foredra en viss skarmlayout fore en annan?
Hur stodjer vi anvandaren med systemet?
Foljer programmet den stil som foretagets tidigare produkter har?
Har vi tagit hansyn till internationell standard?
Vilken specifikation har den storsta mojligheten att fungera?
Anledningen till att man gor en evaluering:
For att forsta hur verkligheten ser ut.
For att jamfora olika designfilosofier.
Att satta upp ett mal for arbetet.
Att folja marknadens standarder, ISO etc.
Nar bor man gora en evaluering?
Under arbetets gang, for att kontinuerligt utvardera produkten och dess anvandbarhet,
fran den minsta detalj till helheten. Man bor till en borjan inrikta sig pa anvandarens
verkliga behov och studera redan existerande system. Evaluering ger mojlighet att tidigt
testa olika ideer pa ett informellt satt (se kap 22). Langre fram i designprocessen
flyttar man uppmarksamheten till de smadetaljer som hindrar anvandaren, for att senare
kunna ge ut uppgraderingar (se kap 31).
En allman regel ar att vilken testning som helst ar battre an ingen alls. Det finns
vardefull information att hamta i de flesta fall.
Exempel; Forte Travelodge bokningssystem
Detta forsok gjordes av IBM Usability Evaluation Centre i London. Malsattningen var
foljande:
Att identifiera och eliminera overgripande problem innan arbetet paborjas.
Affarerna skulle inte bli lidande under systemets inkorningsperiod.
Aven mindre kvalificerade medarbetare skulle kunna anvanda systemet.
Utbildningsmaterial skulle tas fram.
Speciellt dessa egenskaper hos systemet ville man arbeta pa:
Navigationen inom programmet, sa att den bokningsansvarige kan fullfolja en bokning
samtidigt som kunden finns i tillganglig pa telefon.
Skarmlayouten, anvandarvanligheten, enkelheten; d v s effektiviteten.
Andamalsenlig on-line-hjalp och relevanta felmeddelanden.
Vilken slags affordance erbjuder tangentbordet en anvandare utan datorvana?
Traningsprogrammets funktionalitet.
Dokumentationen
Femton ofta forekommande situationer simulerades, och ett statistiskt utvald grupp av
anstallda fick prova pa en prototyp av systemet. Resultatet av en veckas testning var,
enligt IBM:s konsulter, att:
De anstalldas produktivitet okade och deras resurser utnyttjades mer effektivt.
Bokningsforfarandet gick smidigare, och kunderna fick en battre servicegrad.
Personalomsattningen forblev lag och deras arbetsmoral paverkades inte heller.
Systemet har expanderat i takt med efterfragan.
Kostnaderna for utbildning har varit overkomliga.
Ovning
Fundera lite pa varfor man gjorde all testning vid ett och samma tillfalle i
utvecklingsforloppet? Jamfor OMS-exemplet, dar anvande man sig av en iterativ
designprincip (s 360).
Kommentar
Oftast later man nog anvandarna testa en ny programvara vid olika stadier i dess
utveckling. Praktiska skal kan ha varit avgorande i fallet med bokningssystemet. Kanske
IBM-folket anvande programmoduler som redan tidigare var testade. Detta forfarande gav
dock inte en lika god funktionalitet som den iterativa programutvecklingen.
Oversikt over olika metoder (tabell 29.1 s 611)
De flesta evalueringar innehaller nagot av foljande: observation och overvakning av
samspelet manniska-dator, att inhamta anvandarnas synpunkter, att experimentera med olika
losningar och jamforande tester, benchmarks. Man analyserar 'naturligt' forekommande
dialoger och forsoker forutsaga hur en viss losning kommer att tas emot.
Hur gor man da for att samla in data? En forbisedd aspekt ar att ett program kan fa hoga
poang i ett test, men nar det kommer ut pa marknaden gar det inte sa bra. Nagon liten
detalj som utvecklarteamet har forbisett kan gora anvandaren avogt installd mot
programmet. Det kan handla om brister i affordance eller genomskinlighet (se kap 1 och
13, Donald Norman). Enkatundersokningar kan fanga upp sadana brister i ett tidigt skede.
S k benchmarks erbjuder ett delvis vetenskapligt synsatt. Undersokningsledaren har
kontroll over vissa parametrar, och noterar hur olika variabler inverkar. Man lagger stor
vikt vid att data behandlas korrekt rent statistiskt (se vidare kap 31).
Den interpretativa (tolkade) evalueringen har ett mer humanistiskt perspektiv; man har
lanat en del fran etnografin, vilket i sin tur hor hemma inom antropologin. Man gor en
participativ (deltagande) och kontextuell utvardering (beror pa sammanhanget).
Datainhamtningen sker pa ett mer informellt an vid de andra metoderna.
Vid den prediktiva (forutsagande) evalueringen later man en expert utvardera en
specifikation, lagnivaprototyp, attrapp eller liknande (se vidare kapitel 33).
Pilotstudie
Innan man gor en breddundersokning kan det vara ett bra beslut att forst gora en mindre s
k pilotundersokning. Fordelarna med en sadan ar:
Underlattar; lattare att korrigera monumentala fel infor en storre studie.
Tekniken for datainhamtningen kan finslipas.
En generalrepetition dar misstag ar tillatna.
Sammanfattning
Formativ evaluering ger information till programutvecklaren. Summativ evaluering ar ett
slags utvardering av den fardiga produkten.
Evalueringen sker i ett andamalsenligt sammanhang av en anvandare som nagorlunda val
motsvarar en genomsnittlig anvandare.
Evalueringen kan genomforas nar som helst i programutvecklingscykeln.
Fyra olika anledningar: jamfora olika design, verklighetsanpassning, malinriktad
systemutveckling och anpassning efter internationella standarder.
Fem olika klasser av evalueringsmetoder: observation/overvakning,
experimenterande/benchmarking, enkater, tolkning (interpreting) av olika situationer samt
forutsagande (predicting usability).
Registrering sker med video, audio eller datalogger, men situationerna varierar.
Pilotstudien, en mindre studie som gors for att trimma in procedurerna i den storre.
Anvandaren har alltid ratt, ratt att vara anonym, ratt 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
Mal med kapitlet
Visa pa olika metoder att samla och analysera anvandardata men ocksa olika satt att komma
fram till hur anvandare tanker och kanner for ett system.
30.1 Att observera anvandare
Vid design finns det ett flertal situationer dar du vill observera hur olika anvandare
anvander och reagerar pa de ideer du har. Exakt vad du ber anvandaren att gora och hur de
gor det beror pa anledningen till varfor de observeras. Du vill kanske se hur de utfor en
speciell uppgift? Du kanske ar intresserad hur de anvander teknologin i sin egen
arbetsmiljo helt oberoende av dig. Anledningen till att du gor en undersokning ,
tillsammans med din tillgang till resurser sasom utrustning, kommer att avgora hur du tar
hand om information erhallen utifran dina observationer.
Direkt observationer
Anvandare kan direkt observeras nar de utfor en specifikt anvisad uppgift eller en av
sina vanliga arbetsuppgifter, samtidigt som observatoren noterar intressanta iakttagelser
i beteendet eller studerar anvandarens prestation pa nagot satt t ex genom att ta tid pa
vissa sekvenser i arbetet.
Direkt observationer kan dock medfora vissa problem, da de iakttagna kan forandra sin
prestation och sitt beteende p g a vetskapen om att de observeras. Detta fenomen ar kant
under namnet: "Hawthorne effekten", efter en studie av arbetare i Hawthorne Illinois
1939.
Direkt observationer kan vara valdigt anvandbara i tidigt i ett projekt nar du ar ute
efter informell feedback for att skapa dig en bild av vad anvandaren gor och vad denne
gillar och inte gillar.
Ovning
Forestall dig att du ar i London och ska evaluera en prototyp av ett vaxlingssystem
(Eurochange) som diskuterats i sektion 21.2. Du ska undersoka hur langt tid en
genomsnittlig transaktion tar och identifiera problem som anvandaren stoter pa. Vilken
typ av problem kan du stota pa?
Kommentar
Du bor hitta en postition varifran du kan se vilka knappar anvandaren trycker pa
samtidigt som du maste vara diskret, da manniskor kan bli storda av det faktum att du
iakttar dem speciellt da det handlar om en finansiell transaktion. Det skulle ocksa vara
ratt svart att exakt ta tiden pa en transaktion da det blir svart att se nar den startade
och avslutades. Och om det nu ar utomhus och det regnar sa kan dina anteckningar
forstoras utav regnet.
Ovning
Kommentar
Inderekta observationer: Video inspelning
Att anvanda video inspelningar ar ett alternativ till direkt observationer.
Du kan kombinera flera olika kameror for att fa den basta bilden utav ett anvandarfall
dvs hur anvandaren agerar.
Det finns nagra viktiga fragor som att beakta:
Du maste planera dina observationer. Vad vill du fa ut av dem? Vilken typ av data vill du
ha?
Det kan finnas praktiska problem forknippade med att satta upp video utrustning.
Oberoende hur diskret du an forsoker att vara kommer troligen anvandaren att paverkas
utav att denne blir filmad. En losning kan vara att lata utrustning vara en del av
arbets/test miljon under nagra dagar och pa sa satt minska utrustningens paverkan av
anvandarens beteende.
Analys av data fran videoinspelningar
Forskare ar overens om att analys av denna typ av data ar mycket tidskravande.
Det finns tva olika typer av analys:
Uppgiftsbaserad analys - Denna analys metod forsoker att faststalla hur anvandaren loser
det angivna problemet, vart de huvudsakliga svarigheterna ligger och vad som kan goras at
dessa.
Prestationsbaserad analys - Denna analys metod forsoker att uppna tydligt definierade
prestations matt fran den insamlade datan. De mest vanliga ar: antal ratt genomforda
uppgifter, tidtagning pa tidsatgang vid genomforande, anvandning av kommandon, antal
anvandarfel och hur mycket tidsatgangen ar for kognitiva aktiviteter som t ex pauser inom
och emellan olika kommandon eller lasning och inspektion av olika delar av skarmen.
Box 30.1
30.2 Verbala protokoll
Video inspelningar ar ofta kopplat till en slags ljudinspelning vilket i sin tur ar kant
som ett verbalt protokoll.
Ett "tanka hogt protokoll" innebar att anvandaren hela tiden "tanker hogt", hur denne
tanker nar den utfor en uppgift eller loser ett problem. Detta medfor svarigheter for
anvandaren som maste gora tva saker samtidigt. Ofta klarar anvandaren bara av detta under
en kortare tid och under ett langre test maste man fa bukt med problemet att anvandaren
efterhand tystnar…Post-event protokoll ar ett protokoll som upprattas efter att
anvandaren ar klar med uppgiften. Med denna teknik kollar anvandaren pa inspelningar av
sitt forfaringssatt under sjalva "testet" och forsoker aterberatta vad de hade for avsikt
att gora under testet.
Ovning
Kommentar
Analys av ett exemple pa ett tanka hogt protokoll Se exemplet pa sidan 623.
Snabb sammanfattning utav:
Jakob Stensson nd97jso@student.hig.se
KAPITEL 30 (B) - Usage Data:Observations, Monitoring, Users Opinions
Las exemplet under "Analys av ett exemple pa ett tanka hogt protokoll" (Se exemplet pa
sidan 623).
Ovning
Man kan identifiera atta slags inlarnings (nyborjar)problem:
Inlarning ar svart
Nyborjare saknar grundkunskap
De far utga fran "scratch" da de gor tolkningar
De generaliserar utifran vad de kanner till
Nyborjare har problem med att folja direktiv
Ett problem foder ett annat
Granssnittsdetaljer ar inte sjalvklara
Hjalpfunktioner underlattar inte alltid
30.3 Mjukvaru loggning (software logging)
Mjukvaruloggning har alltid varit populart bland en del forskare eftersom det inte kraver
personlig narvaro hela tiden. Endel av databearbetningen brukar man kunna automatisera.
Vidare ar det icke patrangande vilket ar en fordel, men kan vacka etiska tvivel. Man
maste informera anvandarna om att de kommer att bli loggade aven om de inte kommer att
marka nagot av det.
Mjukvaru loggnings verktyg kan delas in i tva kategorier:
De som bara noterar tidsstamplade tangenttryckningar: gor en notering av varje tangent
som anvandaren trycker pa och exakt nar det sker och de som gor en realtidsnotering av
interaktionen mellan anvandaren och teknologin. Interaktionsloggning ar ungefar likadan
forutom att noteringarna sker i realtid, sa att de kan aterspelas sa att den som
observerar kan se interaktionen exakt sa som den skedde.
Ofta kombineras video, audio och tangenttryckning- eller interaktionsloggning. Exempel ar
det nu beromda playback systemet (Neal och Simons(1983)): forskaren observerar via en
videoskarm anvandarens input pa en terminal i ett annat rum. Skarmen visar anvandarens
loggning och systemets respons. Forskaren kan lagga till sitt eget input i form av kod
och korta kommentarer for varje anvandaroperation. Forskaren kan aterspela loggen av
anvandarens handlingar pa olika hastigheter och foreta ytterligare detaljerade analyser
under denna korning. De olika hastigheterna gor det mojligt att spela snabbt forbi
passager dar anvandaren inte har nagra sarskilda problem.
Fordelen med att anvanda olika tekniker ar att undersokaren kan relatera avslojande fakta
om kroppsspraket (poser, leenden osv), kommentarer och annan horselinfo med
registreringar av den faktiska manniska-dator interaktionen. Tva stora nackdelar finns
dock: kostnad (dyr utrustning) och volymen data som kan bli svarhanterligt stor.
Ovning
Vad avgor om ett insamlat material ar kvalitativt eller kvantitativt?
En ra datastrom ar en sekvens av handelser (som pa en video), kommentarer (som pa en
bandupptagning) och tiden (som i tid loggning). De far endast mening nar man tanker pa
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 sa
att man kategoriserar och raknar olika sorters fel, vilket far fram kvantitativa
matningar.
30.4 Anvandarnas asikter: intervjuer och frageformular (enkater)
Att ta reda pa anvandarnas asikter ar viktigt eftersom deras attityder ar avgorande for
anvandandet , saval vid kravanalysen som for acceptansen av den fardiga produkten.
Att kontrollera anvandarnas asikter i olika steg under designen ar mycket viktigt. Det
kan spara mycket tid genom att oanvandbara, onodiga detaljer undviks. Intervjuer och
enkater ar satt att samla in data om vad anvandarna tycker. Data insamlat i intervjuer ar
oftast kvalitativa, data insamlat via frageformular ar kvantitativa. I
enkatundersokningar kan manga manniskor delta och man har mojlighet att statistiskt kunna
sakerstalla resultatet.
Intervjuer
En strukturerad intervju har i forvag bestamda fragor som stalls i en bestamd
ordningsfoljd. Ingen plats finns for individuella attityder. Aterfinns ofta i
opinionsmatningar och ar viktig om man vill kunna jamfora svaren mellan forsokspersoner
och gora statistiska berakningar. I en flexibel intervju har man ett givet amne men ingen
bestamd fragefoljd. Intervjuaren ar fri att komma med foljdfragor och att ta reda pa
personliga attityder. Anvands i ett tidigt skede for kravsamling och for att ta reda pa
anvandarnas ideer om nagot sarskilt.
Viktigt att forbereda bada typerna av intervjuer. Man maste veta vad man vill tacka, inte
minst i flexibel intervju. Ocksa viktigt att skapa en bra kontakt med forsokspersonen.
Annars kanske man inte far fram den information man vill fa fram.
Checklisteintervju: intervjuaren har en checklista som han kan pricka av pa under
intervjun om den intervjuade inte sager sa mycket.
Prompted intervju:en teknik som anvands for att fa fram mer information fran
intervjuobjektet: "kan du saga lite mer om det eller det?" eller "Vad menar du med det?"
Ju mer strukturerad fragorna ar, ju lattare ar det for intervjuaren. Trade-off har: Ju
mindre strukturerad ju battre mojlighet att plocka fram relevanta amnen (men svarare for
intervjuaren).
Frageformular och surveyundersokningar
Har maste fragorna vara entydiga. Det ar viktigt med ett ordentligt forarbete nar man gor
fragorna. De ska helst inte kunna missuppfattas. Man maste ha minst en pilotstudie for
att se vad folk trots allt missuppfattar.
Man skiljer pa tva typer av fragestrukturer: Fasta svarsalternativ dar respondenten
valjer ut ett av ett antal givna svarsalternativ och oppna fragor dar respondenten
skriver ett eget svar. Fasta svarsalternativ har oftast nagon form av rankingskala, tex
den enklaste kan besta av "ja", "nej" och "vet ej". Se olika rankingskalor pa sid
632-633.
En popular form av attitydskala ar semantisk differential, dar man mellan tva motpooler
ska ange vart man befinner sig. Pa en skala med rankad ordning ska tex faktorer anges i
ordning efter anvandbarhet.
Nar man analyserar datat raknar man, om svarsalternativen tillater, om svaren till
numeriska varden, och bearbetar dem statistiskt. Man kan tex rakna ut medelvarde och
standardavvikelse. Det ar viktigt att man planerar enkaten med en statistiker fran
borjan. Da kan svarsalternativen utformas sa att det sedan gar att gora de statiska
berakningar man avser gora. Det ar ocksa mycket viktigt att svarsfrekvensen blir hog!
60-70% bor den vara enligt Eva Carling. Darfor ska det vara latt att svara pa fragorna
(sand med frankerat svarskuvert och ge liten beloning till dem som svarar inom given
tidsram) och enkaten bor inte vara lang (max tva ark). Se olika exempel pa enkater pa sid
634, 636-637.
Ibland anvander man pre- och post "fore och efter" enkater for att se hur attityden
forandras. Samma enkat delas da ut bade fore och efter att respondenten far vara med om
ett test, en erfarenhet el dyl.
Viktiga punkter i kapitel 30
Observerande kan andra det som observeras - Hawthorne-effekten
Verbala protokoll hjalper till att avsloja vad anvandaren tanker
Problem med tanka-hogt-protokoll: i svara problemlosningssituationer upphor anvandarna
oftast att tanka hogt.
Promptade fragor eller att arbeta med ett par anvandare avhjalper tystnad.
Det finns tva typer av mjukvaruloggning: tidsstamplade tangenttryckningar och interaktiv
loggning.
Anvandare maste alltid informeras om att de blir loggade.
Strukturerade intervjuer ar lattare att genomfora an ostrukturerade, men man har ingen
mojlighet att plocka upp intressanta tradar.
Fragor i enkater maste vara entydiga och klara.
Rankingskalor ska inte overlappa.
En enkat ska inte vara for lang.
Forsok alltid genomfora en pilotstudie for att testa ett frageformulars design, speciellt
om det ska skickas ut till en stor population.
Pre- och postenkater (fore och efter) gor det mojligt att kolla forandringar i attityd
eller uppforande.
KAPITEL 31- Experiment och benchmarking
Efter att ha studerat detta kapitel ska man:
Kunna kritisera experimentell design
Veta vad hypotes, oberoende- och beroende variabel ar
Kunna formulera testbara hypoteser
Veta vad som skiljer experiment fran benchmarking
Forsta hur och till vad anvandbarhetstestning (usability engineering testing) anvands.
31.1 Traditionella experiment
Experiment som anvands i MDI har oftast ett snavt mal och avser en specifik aspekt
angaende nagot MDI granssnitt. Det ar viktigt att undersokaren kan manipulera ett antal
faktorer som avser design och studera effekten av olika aspekter pa anvandbarhet. Innan
experimentet maste nivan pa anvandarnas erfarenhet och designen pa experimentet beslutas.
Valdesignade experiment har en klar hypotes som uttrycker vilket utfall man forvantar sig
i experimentet och avslutas med en statistisk analys av det insamlade datat. Det ar
viktigt att man inte manipulerar for manga faktorer, endast en eller tva, sa att man
sedan kan dra slutsatser om orsakssambandet mellan faktorerna. Experimentsituationer blir
oftast ganska "avskalade": harda krav stalls pa kontroll och da far man gora avkall pa
naturligheten i uppgiften. Detta kan leda till att mojligheten att generalisera minskar.
Box 31.1 Exempel pa ett experiment sid 643
Viktigt vid experiment
Nar man planerar experimentet ska man tanka pa tre saker:
Anledningen till experimentet - vad ska andras, vad ska hallas konstant och vad ska
matas
Hypotesen - maste utformas sa att den kan testas
Vilka statistiska test vill jag gora pa datat och varfor
Variabler
Den oberoende variabeln ar den som experimentledaren manipulerar (ofta input i organismen
eller systemet). Den beroende variabeln ar den som paverkas, den i vilken man ser
resultatet av den experimentella observationen (ofta output). Det ar den som mats. Den
oberoende variabeln (tex alder) ska forbli opaverkad av den beroende variabeln (tex
skicklighet att skriva maskin), men den beroende variabeln forvantas bli paverkad av den
oberoende variabeln.
Man maste veta hur man ska mata den beroende variabeln, tex antalet misstag i
maskinskrivning.(Innan maste man besluta exakt vad ett misstag kan vara). Viktiga krav pa
beroendemattet ar reliabilitet och validitet. Man ska se till att mata ratt saker med
giltigt matt. Beroende pa skalnivan, tex ordinalskala, nominalskala, intervallskala och
kvotskala kan olika statistiska matt anvandas.
Urvalet av deltagare
Man maste vara noga vid urvalet av deltagare sa att man undviker biasis (snedeffekter).
Helst bor det vara ett obundet slumpmassigt urval (OSU). Tva grupper bor alltsa ha
likartad sammansattning vad galler fp?s egenskaper som tex alder, kon, datavana och
utbildning (om de ska gora nagon form av dataexperiment).
Experimentell design
Oberoende forsoksperson design
En grupp fp kallas till experimentet och delas sedan slumpmassigt in i grupper som far
genomfora experimentet under olika forhallanden.
Matchad forsoksperson design
Har matchas fp i par. Tex en man och en kvinna bildar ett par (for att undvika sned
konsfordelning). Sedan fordelas paren slumpmassigt till nagon av experimentgrupperna.
Upprepad matnings design
Varje fp deltar i bada grupperna, dvs fp utfor forst forsoket utan manipulerad oberoende
variabel och darefter en gang till med manipulerad oberoende variabel. Risken har ar att
man kan lara sig fran ena gangen till den andra, bli trott eller uttrakad och darfor
prestera olika vid de bada tillfallena. Detta kallas confounding eller
inlarningseffekter. Risken for confounding minskar om man gor omvand
presentationsordning: halva gruppen far forst utfora forsoket med manipulerad oberoende
variabel och andra halvan far borja med icke manipulerad oberoende variabel
Experimentell effekt kallas en forandring i den beroende variabeln som orsakas av en
forandring i den oberoende variabeln
Kritisk granskning av experimentell procedur
Viktigt att granska om experimentet gav vad det var tankt att det skulle ge och hur man
kan anvanda sig av resultatet man fick fram. Viktigt att forsoka se det fran fp's
perspektiv. Fyra viktiga saker att overvaga:
Anvandarforberedelse: om instruktionerna innan var vettiga och om de fick trana sa mycket
som de behovde.
Paverkan av variabler: vad forandringen i den oberoende variabeln betyder for
anvandaren.
Uppgiftens struktur: om den var tillrackligt komplex for att anvandaren skulle kunna
utnyttja de mojligheter som granssnittet erbjod, och om anvandaren forstod malet med
uppgiften.
Tiden: om langden pa uppgiften bidrog till att anvandaren blev uttrakad.
Mycket viktigt att gora pilotstudie innan man genomfor sjalva experimentet for att
undvika ovan namnda fallgropar.
Kritisk granskning av resultatet
Resultatet ska granskas kritiskt for att faststalla exakt vad man har fatt fram och hur
anvandbart det ar och om det har praktisk och teoretisk signifikans. Det finns fyra
huvudpunkter att beakta:
Effektens storlek: den absoluta storleken pa effekten ar intressant. Nagra sekunders
skillnad kan vara statistiskt sakerstallt men i en vardagssituation har det liten eller
ingen betydelse.
Alternativa tolkningar: experimentella resultat tolkas som om de beror pa manipuleringen
av den oberoende variabeln. Men kan det finnas nagra alternativa tolkningar av
resultatet? Kan det bero pa nagon annan variabel som inte har kontrollerats i
experimentet? Tex otillracklig ovning infor en komplex uppgift.
Konsistens mellan beroendevariabler: da flera beroendevariabler anvands i samma
experiment kan relationen mellan dem ge motsagande svar pga inkonsistens. I sadana
situationer kan man behova gora flera experiment for att reda ut begreppen (vad som beror
pa vad).
Generalisering av resultaten: det ar ofta farligt att generalisera ett experiments
resultat till en annan situation vad galler andra anvandare och miljoer. Men det gors
ofta trots att det egentligen inte gar att gora det. Sarskilt farligt om man ger det
status av "guideline".
31.2 Usability engineering (anvandbarhet)
En definition pa usability engineering kan sagas vara: en process i vilken en produkt
specificeras kvantitativt och i forvag. Senare nar produkten byggs kan man se om den nar
uppstalld anvandbarhetsniva eller inte. Det underliggande malet ar att skapa/konstruera
for forbattring. Anvandbarhetsmal definieras genom kvantitativa matt (man kan anvanda
matriser) och man satter upp anvandbarhetsnivaer som ska uppnas. Sedan analyserar man
inflytandet av mojliga designlosningar. Metoden inbegriper anvandarfeedback i
produktdesignen. Man staller sig fragan "narmar vi oss malet nu da?" "nej inte annu" och
man itererar "design-evaluera-design"-loopen till den planerade nivan ar uppnadd. Pa sa
satt har man redan garanterat kvaliteten eller anvandbarheten nar produkten ar klar.
Benchmarking tasks (uppgifter)
Usability engineering baseras huvudsakligen pa en form av test som kallas benchmarking
tasks. De utfors i ett anvandarlaboratorium. Videokameror placeras sa att man samtidigt
kan se film och anvandarens hand pa tangentbordet. Dessutom loggas ofta
tangenttryckningar. De data man far fram anvands vanligtvis for att fa fram information
om hur lang tid det tog anvandaren att utfora vissa uppgifter, felfrekvensen och typ av
fel, anvandande av manualen osv. For att standardisera experimentmetoden sa mycket som
mojligt ar huvudregeln med usability engineering att ge en specificerad mangs anvandare
specificerade uppgifter att utfora i kontrollerade omgivningar - med andra ord , att
kontrollera sa manga variabler som mojligt.
Anvandarnas asikter
Anvandarnas asikter ar ocksa viktiga och erhalls genom frageformular och intervjuer. Fran
svaren gors attitydmatriser, som tas med i anvandbarhetsspecifikationen (se tabell 31.1
pa sid 651).
Trade-offs
Nar designteamet ska gora anvandbarhetsspecifikationen maste man acceptera lagre standard
for vissa attribut for att kunna erhalla vissa andra. Man maste bestamma prioritet. Ett
satt att gora det ar genom en impact analysis. Man listar anvandbarhetsattribut och
vager/mater fordelar och nackdelar med respektive attribut mot varandra for att fa fram
styrkor och svagheter med losningen som helhet. (Se sid 653 for battre forklaring).
Usability engineering har bidragit med struktur i MDI design. Det har ocksa varit viktigt
att fa alla deltagare i designprocessen att arbeta mot samma overgripande och
overenskomna mal. Pa sa satt ar anvandbarhetsspecifikationen ett viktigt dokument som
representerar de allmanna malen. Den ar ocksa ett kommunikationsmedium mellan teknisk
expertis som programmerare och andra med mindre teknisk kunskap som anvandare.
Anvandbarhet omfattar en produkts totala liv.
Styrkor med usability engineering:
Man kommer overens om en definition pa anvandbarhet
Man satter definitionen i termer av matriser och anvandbarhets mal
Anvandbarhet blir ett av andra "ingengors" mal
Tillhandahaller en metod for att prioritera avvandarproblem
Svagheter med usability engineering:
Slutsatsen att anvandbarhet kan operationaliseras
Kravet att anvandaren ska vara fortrogen med laboratoriemetoder
Kostnaden for att genomfora tester
Den onaturliga testningsmiljon
Testningen innebar en mycket artificiell situation. Hur manga anvandare sitter och
arbetar helt for sig sjalva bakom en glasruta utan att bli avbrutna av nagot? Inte manga.
Det ar ocksa dyrt att utfora sadana tester.
Alternativ kan vara informella faltobservationer pa arbetsplatsen eller interpretativa
undersokningar, som tex sammanhangsforfragningar (se kap 32).
Viktiga punkter i kapitel 31
Experiment mojliggor att manipulera variabler associerade med design och att studera
deras effekter.
For att planera och designa ett giltigt experiment maste experimentledaren veta
anledningen till experimentet, formulera en hypotes sa att den kan testas overvaga och
valja ratt statistiska analyser.
Beakta praktiska faktorer som tex anvandarforberedelse, variabelpaverkan, uppgifternas
struktur och tiden det kommer att ta att genomfora experimentet.
Pilotstudie ar viktigt for att avgora om den experimentella designen ar bra innan man
genomfor experimentet i full skala.
Usability engineering baseras pa en form av experiment som kallas benchmarking tasks.
Forsokspersoner genomfor dessa uppgifter i kontrollerad laboratoriemiljo. Notering av
forsokspersonernas beteende sker med video och tangenttryckningsloggning.
Ett problem med usability engineering ar att testmiljon ar onaturlig och inte
representativ for verkligheten. Den ar dock bra for 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 utvardering (evaluering)
Syfte och malsattning
Syftet med detta kapitel ar att peka pa olika satt att samla in uppgifter om och
analysera hur personer i sin vardag anvander teknisk apparatur, sa som pa jobbet, i
skolan, hemma, etc.
Malsattningen ar att efter kapitlet skall du kunna:
peka pa varfor tolkande evaluering ar vardefull och hur den skiljer sig mot mer objektiva
former av evaluering.
skilja pa olika metoder for att tolka och analysera insamlat data.
Overblick
Hittills har alla de metoder som diskuterats i boken varit sadana att testledaren har
haft en stark kontroll over testpersonen pa nagot satt. Detta har gjort att vi och dom
-kanslan mellan testledare och testperson har forstarkts. Aven sattet att samla in data
pa har varit valdigt formellt. Nackdelen med detta satt ar att den lite mer informella
och situationsanpassade anvandningen aldrig kommit fram. Under senare delen av 80-talet
och borjan av 90-talet har man mer och mer frangatt de mer kontrollerade formerna av
evaluering till en mer informell metod, namligen tolkande evaluering. En viktig skillnad
mellan tolkande evaluering och de gamla metoder, beskrivna tidigare i boken, ar att vid
tolkande evaluering sa ger sig ordningen vid undersokningen av sig sjalv vartefter testet
fortskrider, och ar ofta gemensamt overenskommet mellan undersokare och testpersonen.
De olika metoder som presenteras i detta kapitel kan variera i fragan om hur tolkande de
ar, men de ar alla exempel pa steg bort fran de objektiva evalueringsmetoderna mot de mer
subjektiva formerna.
32.1 Sammanhangs utvardering
Vid tester i laboratoriemiljoer, sterila miljoer, har knappast testpersonen nagon
kontroll pa vad, hur och varfor han/hon gor en sak. Eftersom detta inte ger en korrekt
bild av hur det ser ut i verkligheten sa har man idag tagit fram en ny metod dar man gor
testerna mer naturliga, kallad Sammanhangs evaluering. Det gar ut pa att man genomfor
testerna i en sa naturlig miljo for testpersonen som mojligt och garna i vardagslivet.
Nagra exempel finns att lasa i boken pa sidorna 659-660.
Whiteside m.fl. (1988) pekar pa det onaturliga i laboratorietester:
Spraket, ofta valdigt formellt
Testpersonen ar ofta under paverkan av testledaren
Testerna utfors ofta i en valdigt ovan miljo for testpersonen
Testpersonen vet att de skall utfora ett test
Inga storande moment som paverkar resultatet
Och ofta vet testpersonerna inte syftet med testet.
Sammanhangs evaluering har sina rotter i etnografernas varldsbild (beskriven i kap 32.2).
Testpersonen gor testen och letar efter eventuella problem, antingen sjalv eller
tillsammans med testledaren, under arbete i sin vanliga arbetsmiljo och under vardagliga
forhallanden.
Detta spelas in pa video och utvarderas senare av testpersonen och testledaren
tillsammans. De saker som ar av speciellt intresse for testledaren ar:
Hur ar strukturen pa arbetet och hur ar spraket som anvands
Hur reagerar individen och gruppen
Hur paverkar kulturen arbetet
Expliciva och impliciva aspekter pa arbetet.
Det ar svart att fa nagra exakt matbara resultat med denna metod, men som Whiteside m.fl.
(1988) sager.
Det viktiga ar inte att fa fram matbara data fran ett test, utan det viktiga ar att fa
fram om och hur det fungerar samt hur manniskor reagerar ute i det verkliga livet.
32.3 Kooperativ och deltagande utvardering
Kooperativ utvardering
Kooperativ evaluering kan beskrivas enligt foljande:
En teknik for att utveckla ett anvandarinterface genom att upptacka eventuella problem
for anvandaren i ett tidigt skede. Det innebar att programdesignern arbetar tillsammans
med ett utvalt antal testpersoner som anvander produkten i sitt dagliga arbete for att
tidigt upptacka eventuella brister och kunna ratta till dessa.
Denna typ av undersokning ar ett lagbudgetalternativ for designers och testare utan nagon
speciell kunskap om MDI. Det behovs valdigt lite traning for att genomfora denna typ av
test. Testpersonerna uppmuntras att kommentera, foresla alternativa losningar och stalla
fragor. Malet ar att gora testen sa naturlig som mojligt. Skapa en lugn och avslappnad
atmosfar under testen. Under testen galler det att deltagarna tanker hogt. Detta skall
skrivas ned for att senare analyseras. Det finns nagra saker som man bor tanka pa under
en sadan har test:
Viktigt vilken typ av testpersoner som ar med. Det skall ju vara typiska slutanvandare.
Att ha noggrant genomtankta testscenarier som man tror att komma att handa.
Testpersonen maste tanka hogt under testen.
Efter testen sa gor man en kort genomgang av testet sa att inga missforstand kan ha
uppstatt.
Sammanstall testresultatet och rapportera vidare for atgard.
Ett exempel pa denna typ av test finns i boken pa s. 662-663.
Deltagande utvardering
Deltagande evaluering skiljer sig fran kooperativ evaluering pa sa satt att den ar mer
oppen och tillater mer kontroll till testpersonerna/anvandarna. Deltagande design (se
kap.18) och deltagande evaluering delar samma slags filosofi. Ja, de har i praktiken sa
mycket gemensamt att det kan vara svart att sarskilja dem.
Greenbaum och Kyng skriver i sin bok Design at work (1991) att de foredrar tester i
vardagsmiljoer. Detta for att dessa tester ar inte sa skrammande for testpersonerna och
det i sin tur kan skapa ett storre intresse for att deltaga i testerna. Det finns nagra
viktiga punkter att tanka pa vid denna typ av tester:
Val utvalda grupper. De galler att valja personer fran hela skalan av anvandare.
Designern leder arbetet med att tillsammans med anvandarna ta fram prototyper.
Ta fram realistiska prototyper.
Kontrollera att det pa gar en kommunikation hela tiden.
Peka pa fordelarna med deltagande evaluering sa att deltagarna hela tiden ar positiva.
32.3 Etnografi
Ett antal MDI-undersokarer har nu borjat att intressera sig for etnografi som en metod
att samla in data i det vardagliga arbetet. Man vill inte bara peka pa nackdelarna med
laboratorietesterna utan man pekar ocksa pa vikten av att lara sig mer om hur tekniken
anvands i vardagen. Monk m.fl. (1993a) har stallt upp nagra punkter som han tycker ar
negativt med laboratorietester:
Laboratoriet ar inte den verkliga varlden.
Man kan inte kontrollera alla olika variabler som paverkar manniskans beteende.
Testerna sker under en valdigt kort tid.
Etnografin ar inte nagon ny metod. Antropologerna har anvant sig av metoden under en lang
tid.
Etnografiska undersokare forsoker alltid att forsatta sig sjalva i den situation de vill
studera. Ett exempel som namns ar nar en antropolog vill undersoka ett speciellt
bergsfolk, sa ser han till att flytta till byn, bli accepterad av innevanarna, lagger sig
till med deras vanor , klar sig som dem, helt enkelt bli en av dem. Allt detta for att
verkligen kunna studera det han vill, och helst ur "deras egen synvinkel".
Hjalpmedel som kan anvandas for att samla in data vid denna typ av undersokningar kan
t.ex. vara videokameror, notebooks, vanliga kameror e.t.c. Inom MDI verkar videon anta en
mer central roll vid undersokningar. Ett problem med detta ar att det tar sa lang tid att
gora analysen. Dels handlar det ju om realtid och dessutom kanske man maste kora bandet
om och om igen om man ar tveksam pa nagonting. Att sammanstalla det insamlade materialet
kan goras bade manuellt och automatiskt. Boken beskriver en typ av databas som ar gjord
av Murray och Hewitt (1992). Den star beskriven under Box.32.2. (sid. 667)
Nyckel punkter i kapitlet:
Sammanhangs, kooperativ och deltagande evaluering ar metoder dar deltagarna och
undersokarna samarbetar for att finna och forsta problem som kan uppsta i det dagliga
anvandandet.
Kooperativ evaluering ar en billig typ av undersokning som kan anvandas av personer utan
speciella kunskaper om MDI.
Etnografiska undersokare stravar efter att satt sig in i den situation som de vill
undersoka.
Videokameror tenderar att allt mer bli det vanligaste verktyget for att samla in data.
KAPITEL 33 - Prediktiv utvardering
Syfte och malsattning
Syftet med detta kapitel ar att introducera olika typer prediktiva utvarderingsmetoder
som inte innehaller anvandartestning. Efter att last detta kapitel ska du kunna:
Beskriva vad en aterblick ar och saga hur du kan frammana feedback.
Kritiskt diskutera de positiva och negativa sidorna av expert overvakning som en
utvarderings metod.
Kanna igen de satt som utvarderingar kan goras billigare, d.v.s. heuristiska och discount
metoder.
Enkelt kunna sammanfatta hur en strukturerad anvandarsimulering sa som cognitiv
walkthrough kan hjalpa till att upptacka problem.
Anvanda tangenttrycknings analys for att utvardera eventuella effekter pa utforandet.
Overblick
Anvandartestning kan ofta innebara hoga kostnader. Metoderna i detta kapitel beskriver
hur man kan minska kostnaderna genom att forutse hur det skall anvandas snarare an att
observera det direkt. I de flesta metoder du kommer att lasa om i detta kapitel tar man
inte hjalp av anvandarna. man anvander nagon av foljande metoder: review eller heuristisk
undersokning eller tangentbordstrycknings analys. man anvander sig inte av testpersoner
sa metoden ar valdigt snabb och billig. Dessutom behovs ingen specialutrustning. Dessa
metoder ar valdigt anvanda av mjukvarukonstruktorer. Varken tangentbords- eller
walkthrough metoden kraver nagon prototyp, utan de kan goras utifran specifikationen.
Undantaget ar heuristisk undersokning da man anvander sig av viss anvandartestning.
Kapitlet startar med att beskriva hur en typisk review genomfors. Det fortsatter sedan
med en diskussion om fordelar och nackdelar med reviews och hur heuristisk och discount
metoderna kan erbjuda ett alternativ under vissa omstandigheter. Walkthrough och
tangentbords metoderna diskuteras sedan kort.
33.1 Inspektions metoder
Inspektions metoden innebar att man anvander specialister som bade kanner till tekniken
och vilka som kommer att anvanda systemet. Vanligtvis koncentrerar man sig pa
interaktionen mellan anvandaren och interfacet i systemet. Nielsen (1993) beskriver
Inspektionsmetoden som en kostnadseffektiv metod att finna problemen med interfacet.
Huvudmalet med inspektionsmetoden ar att fa fram en lista med anvandarproblem. Ofta kan
man losa dessa problem i ett tidigt stadium. Vid standard inspektioner anvander man sig
av experter for att titta pa compabiliteten mot given standard. Vid Consistency
inspektioner anvander man sig av designerteam for att kontrollera interfacet for en viss
programfamilj.
33.3 Anvandar simulering
Anvandarsimulering gors oftast av experter. Man latsas att vara en ovan anvandare for att
upptacka eventuella fel i programmen. Idealet ar om dessa testare ar experter pa MDI och
samtidigt har en stor kunskap och erfarenhet av olika system. Dessa har oftast lattare
att hitta designproblem. Huvudskalet till att anvanda experter till att spela nyborjare
har att gora med effektivitet. Ofta kan ett fatal experter hitta flera fel under en kort
testning an vad verkliga nyborjare gor pa mycket langre tid. Experter kan dessutom ofta
komma med losningar hur systemet skall forbattras. Ett exempel som namns ar en studie av
Hammond m.fl.(1984) dar man anvande par av experter , den ena spelade anvandare och den
andra antecknade resultatet vid en test av ett ordbehandlingsprogram. Man var tillsagd
att testa systemet bade som nyborjare och mer van anvandare. Rapporten inneholl en lista
pa flera saker som undersokarna hade upplevt som problem och forslag pa losningar for
dessa.
Det ar viktigt att man tanker pa foljande vid anvandarsimulering:
Undersokarna far inte ha varit inblandade i tidigare versioner av systemet. Detta for att
kunna vara neutrala.
Undersokarna skall ha passande erfarenhet, bade av applikationen och av MDI. Att finna
dessa personer kan vara svart sa ibland maste man gora kompromisser.
Undersokarens roll maste vara klart definierad innan testet borjar. Detta for att kunna
utfora testet pa ratt satt.
Under testerna ar det viktigt att systemet eller prototypen likval sa som manualer ar
desamma for undersokarna sa som de ar tankta att vara for de slutgiltiga anvandarna.
Under datainsamlandet och analysen ar malet att hitta de viktigaste problemen. Malet kan
uppnas pa tre olika satt:
Strukturerad rapportering.
Undersokarna maste rapportera observationer pa ett speciellt satt. T.ex. beskriva hur
problemen de stotte pa uppkom, kallan, hur viktigt ar det att problemet loses for
anvandarna och hur forslag pa hur det skall losas.
Ostrukturerad rapportering
Undersokarna rapporterar sina resultat och sedan kategoriseras problemen i olika omraden
for att losas.
Fordefinierad kategorisering
Undersokarna far en lista med problemkategorier och de rapporterar vilka fel de hittar i
dess kategorier.
Rapport satt Fordelar Nackdelar
Strukturerad Enkelt att analysera Tar tid att katagorisera. Inbjuder inte till spontana
forslag om losningar.
Ostrukturerad Inbjuder till spontana forslag pa losningar och kommentarer. Svarare att
analysera. Svarare att kategorisera vanliga problem
Fordefinierade kategorier Kategorier av problem ar redan bestamda. Valdigt enkel att
analysera. Inbjuder definitivt inte till spontana kommentarer och forslag pa losningar.
Man kan missa problem som inte ar Fordefinierade.
Tabell 33.1. For - och nackdelar med de olika rapportsatten.
Denna metod verkar vara en attraktiv metod vad galler dess effektivitet och feedback. Men
det finns en del saker som man maste ha i atanke som kan skapa problem.
Dessa saker ar vinklad rapportering, hitta passande undersokare, rollerna som skall
spelas och beteendet hos de "riktiga" anvandarna.
Experter ar kanda for deras starka asikter, med risk for vinklad rapportering. De
koncentrerar sig pa vissa saker och ignorerar andra. Man skall darfor anvanda flera olika
experter for att minska den vinklade rapporteringen.
Att hitta undersokare med den ratta erfarenheten kan vara svart. Speciellt for ett litet
foretag.
Det kravs valdigt stor kunskap for att kunna spela de olika rollerna som kravs. T.ex. att
spela en 9-13-aring for att testa ett program for barn.
Det kan vara svart att spela ovana anvandare. De kan gora sadana fel som man aldrig tror
att nagon kan gora.
Nar vet man da att alla problem har blivit upptackta?
Heuristisk- och discount simulering ar tva tekniker som forsoker losa detta problem.
33.3 Strukturerad expert undersokning
De tre metoder som kommer att namns i detta stycke ar ocksa en form av expert
undersokning. Men till skillnad mot dessa som vi tittade pa i kapitel 33.2 sa ar dessa
mer strukturerade och mer noggrant planerade.
Heuristisk undersokning
Heuristisk undersokning ar en billig och kostnadseffektiv metod framtagen for sma foretag
av Monk och Nielsen (1990).I heuristisk undersokning sa undersoks systemet eller
prototypen som vid vanlig undersokning eller vid anvandarsimulering. Men undersokningen
styrs av ett antal punkter som ska leda till att fokusera pa det viktigaste vid
anvandandet. Lista som foljer ar typiska punkter som kan finnas med.
Anvand enkel och naturliga dialoger.
Prata anvandarnas sprak.
Minimera antalet saker som anvandaren maste komma ihag.
Var kortfattad.
Ge feedback.
Tala om genvagar.
Ge bra felmeddelanden.
Undvik fel.
En typisk heuristisk undersokning tar mellan en och tva timmar. Nielsen sager att med
heuristisk undersokning upptackte man 40 problem medan man med hjalp av anvandartestning
bara hittade 17. Men samtidigt sa hittade anvandarna andra problem som inte de
heuristiska undersokarna fann. Nielsen forslar darfor att man anvander bagge typerna av
tester for att komplettera varandra. Hur manga undersokare behovs vid heuristisk
undersokning? Enligt undersokningar sa ar fem stycken lagom. Dessa upptackte 75% av
problemen sa detta far anses vara det mest kostnadseffektiv antalet.
Forenklad anvandar undersokning
Forenklad anvandarundersokning upptacktes ocksa av Nielsen. Iden bakom detta var att fa
utvecklare med lite resurser , t.ex. pengar, tid eller expertis att dra nytta av
anvandartestning under produktutveckling och design. Metoden var i forsta hand tankt for
sma foretag som inte hade rad med fullskaletester. Forenklad undersokning ar egentligen
en blandning av anvandartestning och heuristisk testning. I forsta fasen anvands
anvandartestning och innehaller tester med scenarier dar testarna "tanker hogt" under
testet. Med resultatet som bakgrund sa andrar man scenariot och testar igen. I den andra
delen av testet anvander man den heuristiska testmetoden.
Fordelen med denna typ av test ar:
Scenarierna ar sma och latta att andra.
"Tank hogt" metoden ar valdigt informel och kraver inga psykologer.
For hela testen behovs endast tre testpersoner for att antalet upptackta fel med fler
testare star inte i proportion till fler testare.
Box 33.1 pa sidan 678 beskriver ett sadant test.
Walkthrough
Den tredje metoden av exp |