Print

Aanvullingen Human-Computer Interaction
INFOHCI (2008/09)

Cognitie
Aanvulling op Benyon

Deze tekst is een bewerking van twee presentaties, verzorgd door Hermi Schijf.

Herkennen, herinneren en onthouden

De struktuur van de mens bepaalt hoe informatie wordt ingenomen en verwerkt. Neem licht. Onze ogen verwerken alleen licht met een frequentie tussen de 400 en 700 nanometer. Daaronder en daarboven bestaat licht gewoon niet voor ons - althans, het kan niet op normale wijze waargenomen worden. Hetzelfde geldt voor het oor, dat verwerkt ook maar zekere frequenties. Daaronder, daarboven ‘hoor‘ je niet. Een hond of een vleermuis horen wel hogere frequenties, een vleermuis juist weer geen lagere. Idem dito is het gesteld met voelen, proeven en ruiken.

Om je in te beelden wat een ander ervaart is moeilijk. Van alle lezers van deze tekst is een gedeelte (8% mannen en 0.5 % vrouwen) kleurenzwak of kleurenblind. Waarschijnlijk zit die zwakte in de onderscheiding tussen rood en groen. Die kleuren bestaan gewoon niet, al heeft ook deze groep wellicht geleerd om aan bepaalde objecten een "kleur" toe te kennen. Rozen zijn hoogstwaarschijnlijk ‘rood‘, bomen ‘groen‘. Als de rozen aan een struik wat donkerder rood zijn, tussen groen van dezelfde intensiteit, ziet zo iemand de rozen alleen aan de verschillen in vorm. Kleurenzwakke mensen weten dus niet wat rood is, of wat groen is. En eigenlijk is ieder‘s ervaring van kleur wel anders. Er zit variatie in hoe je sensoren, je zintuigen, informatie oppikken.

Zintuigen nemen slechts een deel van de beschikbare informatie op, en ze verschillen onderling. Zintuigen zien, horen, voelen, proeven of ruiken alleen bepaalde soorten informatie, en daarom zijn ook de hersenen ingesteld op die bepaalde informatie, want daar gaat, logischerwijs, alleen die informatie naar toe die de zintuigen kunnen verwerken. Informatie moet altijd in een vorm zijn die wij kunnen verwerken. Er zijn vormen die wij gemakkelijker kunnen verwerken en vormen die wij moeilijker kunnen verwerken.

Hoe geven we informatie terug naar de wereld? Dat is eigenlijk ook heel beperkt. We kunnen praten, waarbij de intonatie ook veel informatie weergeeft, gebaren, we hebben motoriek waarmee we dingen in de wereld kunnen maken, veranderen, of ons kunnen verplaatsen zodat we iets kunnen doen aan een ander deel van de wereld. Waar je misschien minder aan denkt, maar dat toch aardig wat informatie overbrengt, is onze lichaamstaal en gezichtsuitdrukking. Dat merk je wel eens bij het communiceren met iemand die slecht Nederlands spreekt. Heb je zo iemand aan de telefoon, is hij veel moeilijker te verstaan dan als je tegenover hem staat. Helaas kunnen we hersenenergie niet direct overbrengen - althans niet op zo‘n manier dat je ermee kunt communiceren!

Binnenkomende informatie wordt via de zintuigen omgezet naar informatie die het zenuwstelsel kan gebruiken, waarna de hersenen er wat mee kunnen doen, zoals vergelijken met reeds opgeslagen informatie, opslaan, gebruiken in berekeningen enz. enz. Daarin worden twee hoofdtypes informatieverwerking onderscheiden:

  1. Perceptie: Het omzetten van informatie (vormen van energie) beschikbaar buiten het lichaam naar informatie (andere vormen van energie) beschikbaar binnen het lichaam.
  2. Cognitie: Het in verband brengen van de nieuwe informatie met reeds opgeslagen informatie, het aanmaken van bruikbare kennis, en het gebruiken van die kennis.
Hoe dat allemaal gebeurt dat leer je in Cognitie en Informatieverwerking in het volgende blok.

Kennis wordt vastgelegd door middel van het ontstaan van neuronactiviteitspatronen. Maar hoe precies weten we eigenlijk nog niet. Zulke patronen ontstaan in de mens op minstens twee manieren.

De eerste manier is ‘hardwired‘, door de eeuwen heen, ingebouwd in de ‘perceptie‘ delen van de hersenen, dat zijn qua evolutie oudere delen. Deze verzamelingen van neurons zijn op een bepaalde manier gespecialiseerd en geordend, klaar om een bepaald soort energie te verwerken. Dit systeem maakt het eenvoudig voor ons om bepaalde informatie in te nemen en te verwerken. Bijvoorbeeld, de visuele cortex staat helemaal klaar om licht-informatie te ontvangen, en de auditory (gehoor) cortex om geluidsinformatie te ontvangen. We hoeven niet te ‘leren‘ om te zien of te horen: Dit gebeurt automatisch want we zien of horen gewoon. Natuurlijk betekent dit niet dat we ook automatisch weten wat we zien of horen. Ook veroorzaakt dit systeem dat er sommige dingen zijn die wij makkelijk, spelenderwijs eigenlijk, kunnen leren. Voorbeelden hiervan zijn lopen (bewegingspatronen worden geleerd met behulp van de cerebellum) en taal (er is een taalgebied dat wel veel jonger is dan horen/zien/motorische gespecialiseerde gebieden). Andere dingen leren is veel moeilijker, bijvoorbeeld abstracte kennis zoals wiskunde; daar hebben wij geen kant-en-klaar neuronpatroon voor.

Deze ingebouwde ‘kennis‘ is zeer stabiel. Eigenlijk de enige manier om ze te verliezen is door hersenbeschadigingen van verschillende soorten, infarcten bijvoorbeeld, of trauma's. De keerzijde dat deze gebieden hogelijk gespecialiseerd zijn voor 1 taak (die ze dan ook prima doen) is dat ze moeilijk inzetbaar zijn voor een andere taak. Blinden bijvoorbeeld kunnen visuele gebieden ten dele gebruiken om gehoor-informatie te verwerken, maar alleen werken ze dan niet optimaal.

De tweede manier waarop neuronactiviteitspatronen ontstaan is via de ‘cognitie‘ delen van de hersenen, jonger in evolutionaire termen, en maakt het mogelijk om bijv. wiskunde te leren. Opslag van dit soort kennis zit in de neocortex. Dit is een groot, vrij dun vel van aan elkaar verbonden lagen neurons, dat helemaal opgepropt om de oudere hersendelen heen ligt. Met dit systeem verwerven wij andere soorten kennis door wat wij noemen het "leren": het dynamisch vormen van neuronactiviteitspatronen. Dit is het systeem dat door de gehele schoolcarriere heen getraind wordt en volgestopt wordt met kennis. Ook dit systeem heeft gespecialiseerde gebieden, maar lang niet zo sterk. Een van de meest gespecialiseerde gebieden is dat voor taal. Zelfs bij doven wordt het taalgebied gebruikt voor hun taal, gebarentaal. Gebarentaal is een echte taal, met eenzelfde struktuur als gesproken talen!

Deze dynamisch gevormde patronen kunnen dan ook gebruikt worden om informatie waarop ze getraind zijn te verwerken. Vele soorten taken kunnen daardoor uitgevoerd worden.

De prijs van dit systeem is geringe stabiliteit: Dynamisch gevormde patronen zijn veel minder stabiel dan 'hardwired' patronen. Een andere prijs is dat het individueel leren van kennis veel tijd kost. Er zijn veel variaties in de soorten kennis en soorten kennisstrukturen die door verschillende mensen geleerd kunnen worden. Dus hebben we middelbare scholen die van LBO t/m VWO lopen. Hierbij moet worden aangetekend dat er verschillende soorten intelligenties bestaan, waarbij het kunnen aanleren van abstracte kennis, zoals in het VWO, er maar een is. Een andere intelligentie is het aanleren van motorische kennis, iemand kan heel goed zijn in motorische taken, zoals dansen of sport, of gewoon ‘gouden handen‘ hebben en prachtige muurtjes kunnen metselen. Zo zijn er nog veel meer: musiceren, menselijke communicatie (bijv. goede verkopers) enz.

Zoals hiervoor al opgemerkt is bestaan er behoorlijke verschillen in leren, de manier waarop iemand de informatie zo snel mogelijk terugroepbaar zijn/haar hersenen in krijgt. Kennis toevoegen aan de hersenen kan iemand dus alleen zelf; dat kan niemand anders! Daar moet je ook nog moeite voor doen ook, een boek onder je kussen werkt dus echt niet, helaas. Leren kan op een meer of minder efficiente manier gebeuren: "Studeren kun je leren" heet het. Een van de manieren om te leren is zoals we het in school doen: bewust voor een boek gaan zitten en proberen de informatie erin je eigen te maken, of goed te luisteren naar iemand die informatie probeert over te brengen. Het punt waar het om draait is dat je zelf goed met nieuwe informatie bezig bent, deze probeert in te passen bij wat je al weet, te vergelijken met wat je al weet, enzovoort.

Maar er zijn ook andere manieren om kennis op te nemen dan via de weg die we in school bewandelen. Een daarvan is het leren door een schok: Veel jeugdherinneringen zijn naast de dingen die heel vaak voorgekomen zijn, routines eigenlijk, zoals spelletjes spelen met je ouders, of een verhaaltje voor bedtijd, een kopje thee als je thuiskwam van school, juist eenmalige en zeer bijzondere, vaak schokkende, dingen. Bijvoorbeeld de dood van een grootouder of een geliefd huisdier. Ook goede dingen kunnen natuurlijk 'schokken'. Zoals de totale verassing om op je verjaardig een felbegeerd maar nooit verwacht stuk speelgoed te krijgen. Een ander soort schok is dat iemand iets doet wat je totaal niet verwacht had, omdat het niet bij ze 'paste': Als je vader het sterke type is dat nooit huilt, herinner je je juist die ene keer dat het wel gebeurde.

Een andere manier om te leren is simpelweg door de informatie keer na keer onbewust in je op te nemen. Ook dit creeert patronen, zij het veelal niet beschikbaar voor bewuste cognitie: D.w.z., je kunt ze wel gebruiken voor herkenning (activeren van kennis met behulp van perceptueel binnengekomen energie), en voor het aanleren van motoriek (zwemmen, fietsen) maar niet bewust herinneren, het zonder de energie die binnenkomt via perceptie activeren. Meer over herkennen en herinneren verderop. Wij leren erg veel op deze manier, waarschijnlijk meer dan we op school leren. Voorbeelden: onbewust leer je je gedrag af te stemmen op dat van andere mensen, leer je dingen die iemand anders voordoet, of leer je gewoon maar door met dingen te interacteren. Een ander voorbeeld is de impact van reclame. Keer op keer zie je bijvoorbeeld bier geassocieerd met het goede leven. Of je het wilt of niet, je leert deze patronen: als je denkt aan het geven van een feestje, komt automatisch die geleerde associatie met bier naar boven.

In de coginitieve wetenschap bestaan controverses m.b.t. de wijze waarop ons kennissysteem functioneert en het belang van de rol die de genoemde verschillen spelen. Aan het ingebouwde systeem wordt gerefereerd door de ecologische perceptie-theorie, aan het verworven-kennis systeem door de constructivistische perceptie-theorie. Al hoewel dit twee concurrerende theorieën zijn, is er veel voor te zeggen beiden als complementair te beschouwen. Beiden kunnen dus vreedzaam naast elkaar leven (al zal niet iedereen het daarmee eens zijn). De volgende tabel vergelijkt de eigenschappen van beide soorten van kennis.

Tabel: Ingebouwde versus geleerde kennis

  Ingebouwde kennis Geleerde kennis
Duurzaamheid Permanent Tijdelijk
Beschikbaarheid Altijd Soms
Ontstaan van patronen

Zeer, zeer lang-zaam (eeuwen) Snel (Ī10 sec. per stukje)
Wie heeft het? Iedereen Alleen leerders
Flexibiliteit Nauwelijks Veel
Verwerkbare soorten kennis Niet zo veel Bijna oneindig
  Groen: voordeel
Rood: nadeel
Geel:kleiner nadeel

'Hardwired' en verworven kennis hebben gevolgen voor HCI.

Wat gebeurt er als je een item maakt op je interface, dat op de juiste manier gebruik maakt van ingebouwde kennis. Hoera! we krijgen altijd de juiste handeling. Maar helaas is de praktijk anders: De meeste items maken gebruik van geleerde kennis. Dan is succes voor de gebruiker dus afhankelijk of hij/zij het wel geleerd heeft:

Het grootste gevolg van ons leersysteem is dan ook dat iedereen andere kennis heeft, die op een andere manier is georganiseerd en opgeslagen. Ieder‘s mentaal model van een taak zal daardoor toch anders zijn, al zullen er groepsgewijs grote overeenkomsten bestaan.

Maar helaas, ga je er tegenin met een item, dan zul je altijd de verkeerde handeling krijgen. Een bekend voorbeeld is de layout van het gasfornuis. Welke knop hoort bij welke gaspit? Niet alleen maken mensen fouten in het begin met deze layout, maar ze blijven vrijwel evenveel fouten maken ook na vele jaren gebruik. De 'mapping' van de knoppen naar de branders blijft gewoon ambigue - het is niet echt te leren. Zouden de knoppen beter met de branders geassocieerd worden, dan maken mensen in het begin geen fouten en later ook nooit: Het blijft eenduidig.

Tabel: Gevolgen voor HCI m.b.t. ingebouwde en geleerde kennis.
  Ingebouwd Geleerd
Reactie op goed item Altijd juiste handeling Geleerd: juiste handeling.
Passend in mentaal model: makkelijk te leren
Niet passend in mentaal model:
- leren vereist aanpassing m.m.
- of leren als een uitzondering
Reactie op slecht item Altijd verkeerde handeling Juiste handeling moeilijk tot zeer moeilijk te leren
  Groen: voordeel
Cyaan: kleiner voordeel
Rood: nadeel
Geel:kleiner nadeel

De eerste soort kennis is dan ook niet cultuur-gebonden (als het goed is) maar verworven kennis wel, want binnen een bepaalde cultuur hebben mensen aardig wat kennis die overeenkomt, veelal onbewust geleerd. Dat is makkelijk want dan hoef je elkaar niet alles uit te leggen. Als je echter een interface ontwerpt waar ook mensen uit andere culturen mee te maken krijgen (openbaar vervoer, NS kaartjesmachine, dienstroosters enz; banktransacties) dan moet je in het testen ook mensen van andere culturen meenemen.

Gevolgen van de sterkte van de opslag van geleerde kennis

Fysiek gezien, bij neuronen, kunnen verbindingen op twee manieren sterker worden: doordat de cel meer potentiŽle energie kan opbouwen, en doordat de axon vaker kan vuren. Hoe vaker je kan vuren, met hoe meer energie, hoe groter het effect op neuroncellen die op die neuroncel aansluiten: hoe meer deze geactiveerd worden. We vatten deze twee effecten samen door te zeggen dat het ‘activatie niveau‘ van de cel hoger of lager kan worden.

Een goed geoefend, sterk neuronactiviteitspatroon wordt ‘routine‘ kennis genoemd: kennis die je onder normale omstandigheden ten allen tijde ter beschikking hebt. Bijvoorbeeld, je kennis van de Nederlandse taal. Normaliter denk je niet na bij de verwerking van een stukje Nederlandse tekst: dit wordt automatisch, routinematig verwerkt. Dat is heel handig want dan gaat zo‘n handeling heel vlug. Echter, daarom kan het ook mis gaan als je tegen de normale betekenis van een woord in gaat. Een ander voorbeeld is de ‘catch-up‘ handeling in BSCW. Je zou denken (helemaal als je Engelstalig bent) dat dit betekent: laat mij alles zien wat ik nog niet gezien heb. Maar nee, in feite betekent het: ‘mark as read‘ - alle markeringen dat iets nieuw voor jou is verdwijnen. De kans dat het voor de beginner fout gaat is vrijwel 100%, de kans dat je herhaaldelijk fout gaat is groot, helemaal als Engels je moedertaal is. Je moet als het ware gaan leren om TEGEN je routinematige kennis in te gaan.

Echter als je iets maar een keer leert, zoals even vlug leren voor een tentamen, dan resulteren zwakke neuronactiviteitspatronen. Dan kan je die kennis wellicht op het tentamen nog even tevoorschijn toveren, maar vergeet het maar als iemand je er een half jaar of zelfs maar een week later naar vraagt!

Kennis vervaagt als je het niet gebruikt. De verbindingen worden niet gebruikt en worden zwakker. Je vergeet het - of, op z‘n minst, je kunt het niet meer vinden. Zelfs routine kennis vervaagt, als je het niet meer gebruikt.

Geleerde kennis waarmee je veel geoefend hebt wordt een soort routine-kennis, en gaat zich bijna gedragen als hard-wired kennis. De volgende tabel maakt de verschillen duidelijk:

Tabel: Sterke versus zwakke kennis
  Sterk routine Zwak-niet routine
Duurzaamheid Vrijwel permanent Tijdelijk
Beschikbaarheid Meestal Soms
Leren Vaak, op meerdere wijzen leren + oefenen Een keer encoderen
Wie heeft het? Wie het geleerd heeft Wie het geleerd heeft
  Groen: voordeel
Cyaan: kleiner voordeel
Rood: nadeel
Geel:kleiner nadeel

Herinneren en herkennen

In cognitie wordt een onderscheid gemaakt tussen herkennen (ik neem iets waar, en herken het als iets dat ik eerder heb waargenomen) en herinneren (bewust gaan zoeken in je geheugen naar opgeslagen kennis). Herkennen is makkelijker dan herinneren, want het patroon wordt al aangeboden; je hoeft niet in je hoofd een patroon te gaan vormen (dit is slechts beperkt mogelijk, komen we zo op terug) en dan te gaan zoeken naar een match. Gek is wel dat je over het algemeen wel weet of je iets weet, maar niet waar je het kan vinden.

Duidelijk is dus, dat zowel zwakke als sterke kennis gevonden kan worden via herkennen, maar dat de kans dat kennis wordt gevonden via herinneren veel meer afhankelijk is van de sterkte van de opslag van het patroon: hoe sterker, hoe groter de kans.

Dit heeft direct gevolgen voor HCI.

Als je in de interface vervolg-handelingen perceptueel aanbiedt, bijvoorbeeld door een menu, middels een iconenbalk, of via hyperlinks, dan kunnen mensen daarop reageren.
Als daarentegen de volgende handeling ergens verborgen staat zodat je ernaar moet zoeken, of je moet iets intypen (bijv. een bestand inclusief het path op de disk) dan is de kans op mislukking groot. Nu ga je herinneren vergen, en tenzij die kennis goed geleerd is, kan je het wel vergeten.
Dus:
Perceptueel aanbieden = herkennen = waarschijnlijk succes, zelfs als het niet goed geleerd is.
Niet perceptueel beschikbaar = herinneren = goede kans op mislukking, tenzij het goed geleerd is.

De populariteit voor Windows tegenover andere commando-gestuurde besturingssystemen (zoals Unix), vooral voor beginners zonder kennis, is hieruit overduidelijk te begrijpen.

Welke gevolgen heeft de structuur van de mens voor HCI?

De struktuur van de mens bepaalt hoe informatie wordt ingenomen en verwerkt. We hebben gezien, in het visuele systeem, hoe perceptie is geschakeld aan cognitie, het gebruik van kennis. De zenuwprikkels lopen gewoon door naar de kennisopslag. Dit betekent dat veel gebruik van kennis niet optioneel is, maar automatisch. Wij weten vaak niet dat we kennis gebruiken. Meestal niet, in feite. Kennis wordt gebruikt of je het wilt of niet. Of het waar is, of goed is, of niet. Die kennis zit er dus in, en waar of onwaar, goed of slecht, ze wordt gebruikt. Je kunt dus je eigen kennis niet uitschakelen.

Het gevolg voor HCI ligt op het gebied van het verschil tussen ontwikkelaars en gebruikers.
Iedereen heeft andere kennis vanwege dat fantastische dynamische systeem. Je kunt wellicht wel sommige kennis bewust proberen te onderdrukken. Ook kun je iemand ander‘s kennis proberen te simuleren, door een rol te spelen. Maar net zoals je je wel kunt inbeelden hoe het is om een vleermuis te zijn en radar te hebben in plaats van te kunnen zien, kun je op z‘n hoogst zover komen als je in te beelden hoe het is voor een mens om vleermuis te zijn, nooit hoe het voor een vleermuis is om een vleermuis te zijn.

Een ontwikkelaar kan geen gebruiker zijn. Niet echt. Hoe kijkt een ontwerper of programmeur tegen software aan? En hoe kijkt een gebruiker er tegen aan? Beiden hebben heel andere kennis en een heel andere achtergrond. Het is maar de vraag of de programmeur wel precies weet heeft van de taak die de gebruiker met de software gaat uitvoeren. Beiden hebben een geheel ander 'mentaal model'. Als de interface voor de ontwikkelaar duidelijk is (die kennis heeft over de constructie van het programma, en deze kennis nooit uit kan schakelen) is het niet vanzelfsprekend dat de gebruiker er ook mee overweg kan. Dit is belanrijkste reden waarom gebruikers bij het ontwerpen moeten worden ingeschakeld.

Gescheiden opbouw van kennis: Problem Spaces

Kennis wordt als het ware in compartimenten opgebouwd. In de cognitieve psychologie wordt zo‘n stukje aan-elkaar-gerelateerde kennis een Problem Space genoemd. Een ‘virtuele ruimte‘ dus waarin je geleerd hebt om bepaalde problemen op te lossen, een taak te verrichten of wat dies meer zij. Het probleem is dat er maar een zeer klein aantal, vaak maar één problem space tegelijk geactiveerd kan zijn. Het is niet dat we de kennis, opgebouwd in een bepaald gebied, niet zouden kunnen toepassen in een ander gebied, want dat kan natuurlijk in principe. Nee, we zijn ons niet gewaar dat we kennis hebben die op dat andere gebied toepasbaar zou kunnen zijn! Je denkt er gewoon niet eens aan, en dat kan ook niet, want die kennis in die andere ‘problem spaces‘ wordt niet geactiveerd. Eigenlijk is dit maar goed, want anders zou je zo‘n vloed van informatie over je krijgen elke keer als je je iets probeerde te herinneren, dat je er waarschijnlijk in zou verdrinken. Maar het heeft ook nadelen: Je moet er bijvoorbeeld zelf voor zorgen dat kennis opgedaan onder verschillende omstandigheden aan elkaar gerelateerd wordt.

Het gevolg voor HCI ligt op het gebied van de consistentie.
Heb je je gebruiker in een p.s. gezet, kan je verwachten dat hij:

Kennisopslag in netwerken

Onderzoek heeft uitgewezen dat informatie associatief of categorisch wordt opgeslagen in netwerken (zie figuur).


Figuur: Spreading Activation Network (Collins & Loftus, 1975)

Dit betekent:

Dit heeft enkele gevolgen voor HCI.

Als je wilt dat iemand iets onthoudt, probeer het dan op verscheidene, verschillende wijzen te presenteren. Elaboratie, het op meerdere wijzen opslaan van informatie, maakt het makkelijker om een bepaalde handeling terug te vinden in je geheugen. De betekenis van een icoontje waar een verbaal labeltje bij staat wordt beter onthouden dan een zonder verbaal labeltje. Je encodeert het dan nl. op twee manieren: als plaatje en als woord: Twee kansen om aan te sluiten bij een bestaand netwerk.

Als je een nieuw soort handeling/begrip moet representeren, probeer aan te sluiten bij geassocieerde representaties. Atypische handelingen/betekenissen zullen moeilijker geleerd worden dan handelingen die bij elkaar aansluiten. Stel dat je een nieuw soort handeling moet representeren. Probeer dan aan te sluiten bij geassocieerde presentaties in de huidige omgeving (metafoor) of presentaties van geassocieerde handelingen/begrippen. Bijvoorbeeld, je wilt een icoontje maken voor "alle applicaties sluiten". Er bestaat al een icoontje voor ‘applicatie sluiten‘, dat is een gesloten foldertje met een pijlje erboven waarmee de sluitingsactie wordt aangeduid. Dan zou je kunnen proberen of gebruikers het begrijpen als je 3 gesloten foldertjes met pijltjes achter elkaar zet. Zo wordt er met het ‘mandje‘ of het ‘winkelwagentje‘ in een webwinkel keurig aangesloten op een representatie die sterk geassocieerd is met zowel ‘straks kopen‘ als ‘er kan nog meer in‘ in een bestaande situatie in de huidige overbekende omgeving.

Aan de negatieve kant, probeer met je ontwerpen geen associaties op te roepen met iets dat ‘slecht‘ of ‘lelijk‘ gevonden wordt. Daar zal de opdrachtgever je niet dankbaar voor zijn. Dat betekent namelijk dat mensen zijn bedrijf of product daarmee gaan associeren. Een slecht bedienbare site gemaakt? Overal van die flitsende reclame? Onleesbare proza, pietepeuterige lettertjes? Hou je van gifgroen op paars? Of van hakenkruizen? Yuck - nou, ik surf wel naar een ander, van jou hoef ik echt niets meer te bestellen en ik krijg ook al een naar gevoel in mijn maag als ik naar het product in de winkel kijk

Opslag is efficient georganiseerd

Als er al een sterk netwerk van geassocieerde informatie bestaat, hoeft maar een gedeelte van de nieuwe informatie te worden opgeslagen, het meeste hebben we al gehoord en we hoeven alleen het nieuwe op te slaan. De waarschijnlijkheid dat je een bepaald iets leert neemt toe naarmate je al meer weet over dingen die ermee geassocieerd zijn. Dan past het lekker in het netwerk, en hoeft er niet veel energie te worden besteed aan de opslag. Bijvoorbeeld, iemand is een Amerikaanse Democraat. Zijn buurman is een Republikein. Beiden luisteren naar een speech van iemand die geen politieke associatie heeft. Die speech bevat zowel elementen van een Republikeinse als van een Democratische zienswijze. Wat denk je dat de Democraat onthoudt? Juist, dat wat goed past in hun respectievelijke netwerken. En de Republikein? Het gevolg is dat de spreker door beiden als behorend bij ‘hun‘ partij gezien wordt. Wat we al weten ‘kleurt‘ dus wat we gaan onthouden. Zo komt het dus dat die oude informatie die met de paplepel is ingegoten, zo lekker blijft hangen en bepaalt welke informatie het makkelijkst wordt opgeslagen: dat wat er lekker in past (vooroordelen . . .).

Het merendeel van wat we waarnemen slaan we niet letterlijk op. We slaan de betekenis op. Als iemand de zin wordt geleerd "De hond stond tegen de paal te plassen" en later moet kiezen welke zin geleerd is, "De hond stond tegen de paal te plassen" of "De hond plaste tegen de paal", dan kan dat niet meer onderscheiden worden. Opgeslagen is namelijk: hond, paal, plassen. Beide gepresenteerde zinnen voldoen hier gelijk aan.

De gevolgen voor HCI hebben te maken met de leerbaarheid van programma's en zijn eenvoudig af te leiden.

Beperkingen in het werkgeheugen (working memory, WM)

Algemeen wordt er vanuit gegaan dat stimuli uit onze sensoren in eerste instantie in een relatief onbewerkte vorm in ons werkgeheugen terechtkomen. Het werkgeheugen is een korte-termijn geheugen waarvan de inhoud bestaat uit huidig geactiveerde kennis en perceptuele input. Ook items die we uit ons lange termijn geheugen halen dmv herkennen of herinneren komen hierin terecht. Het WM is hiertoe maar voor korte tijd in staat en heeft een beperkte capaciteit. Het laatste wordt aangeduid als 'Miller's law': 7±2 (George Miller, 1956). Hiermee wordt gerefereerd aan het aantal items dat tegelijkertijd actief kan zijn binnen het werkgeheugen, dat 7 plus of min 1 of 2 is. Overigens is dit later door de cognitieve psycholoog Nelson Cowan [1] weerlegd: Hij heeft aangetoond dat het kortetermijngeheugen doorgaans niet verder komt dan 4. Is het meer, dan is vrijwel altijd sprake van 'chunking'.

De definitie voor 'item' (of element) in deze context is datgene waarvoor we een 'label' hebben, of dat als een aparte 'chunk' (brok) herkend wordt. Een voorbeeld van 'brokken' herkennen is de string BBC KRO SBS RTL: elke 3 letters zijn een omroepzender en dus onthouden we gemakkelijk 4 brokken is 4*3=12 letters. Dit lukt niet met bijv. BCB KOR SSB TRL (en nog minder met BCBKORSSBTRL). Voorbeelden van labels zijn getallen, woorden, namen e.d. In de muziek kunnen het losse tonen zijn, maar ook heel goed bepaalde melodische figuren (die elk uit meerdere tonen bestaan).

De toepassing voor HCI ligt op het vlak van informatie waar direct iets mee gedaan moet worden. Die hoeveelheid moet niet te groot zijn.
Bijvoorbeeld het aantal options in een listbox waar je de gebruiker uit laat kiezen. Houd dat onder de zeven. Er kunnen wel meer keuzes staan, maar in dit geval zal een bepaalde organisatie de gebruiker ondersteunen; bijvoorbeeld een alfabetisch of hierarchisch geordende lijst.

1. N. Cowan, Attention and Memory: An Integrated Framework. Oxford Univ. Press and Clarendon Press, New York and Oxford, 1995.

 


 

Diagrammen

Diagrammen worden veel gebruikt bij systeemontwikkeling. Er zijn erg veel typen (waarover je meer hoort in het vak 'Methoden voor Systeemontwikkeling'). Het belang dat algemeen aan diagrammen wordt toegekend is de mogelijkheid een deel of aspect van het ontwerp op een consistente wijze uit te drukken. Een beschrijving in taal is moeilijker te controleren op volledigheid en consistentie dan een beschrijving met behulp van (vooraf gedefinieerde) symbolen.
Diagrammen zijn dus voor menselijke consumptie. Je kunt het doel ook bereiken door inzet van een geformaliseerde taal. Dit wordt echter door mensen minder makkelijk verwerkt (maar weer eenvoudiger door machines). Het gaat bij diagrammen dan ook vooral om de communicatie over het ontwerp: enerzijds tussen ontwerpers in het team onderling, en anderzijds tussen de ontwerpers en opdrachtgever.

Diagrammen bestaan uit 'Nodes' en 'Edges' (verbindingen tussen nodes). Diagrammen worden in het algemeen moeilijker leesbaar naarmate het aantal gebruikte nodes toeneemt. Een goede richtwaarde is maximaal 10 per diagram. Omdat niet alles in max. 10 nodes is weer te geven, wordt ook wel gebruik gemaakt van z.g. explosie. Een node kan worden 'geopend', waarna er een diagram verschijnt dat dit facet gedetailleerder uitwerkt (stapsgewijze decompositie; zie figuur). Het nadeel hiervan is dat je snel het overzicht kwijtraakt.

In het hci-project worden voor het ontwerp drie typen diagrammen gebruikt: Use Case Diagram, Activity Diagram en State Transition Diagram. Gezien de geringe omvang van het hci-project is het in de regel niet nodig om diagrammen te maken in hoofd- en subniveaus, en kan dit zelfs beter worden vermeden: één niveau is genoeg. Van de drie gebruikte diagramtypen volgt hierna een korte beschrijving. Voor de volledige specificaties wordt verwezen naar de offiële UML (Unified Modeling Language) documentatie van de OMG (Object Management Group, http://www.omg.org), conform de afspraak binnen Informatiekunde. De korte beschrijvingen zijn een inleiding c.q. 'leeswijzer' op de offiële specificaties en geven aan waarom in het project een diagram ingezet wordt.

Use Case diagram

De specificatie van het Use Case Diagram vind je in de offiële documentatie in Section 3, part 6: Dit document (PDF) is te downloaden op http://www.omg.org/cgi-bin/doc?formal/03-03-01 [6321 KB].

In het project wordt het Use Case diagram gebruikt voor het weergeven van het gehele te ontwikkelen systeem. Het systeem wordt opgedeeld in, in de regel afzonderlijk te ontwikkelen, Use Cases, elke Use Case een stuk functionaliteit. Het Use Case diagram geeft de systeemgrenzen aan, geeft mogelijke onderlinge relaties tussen Use Cases weer, en laat vooral zien welke relaties er zijn tussen de actoren (gebruikers) en de Use Cases.
In de theorie-aanvulling "Scenario's en Use Cases" wordt ingegaan op de wijze van identificeren van Use Cases.

Het Use Case diagram is erg eenvoudig: de drie belangijkste symbolen zijn:


Figuur: Voorbeeld van een Use Case Diagram

Opmerking
Use Cases kunnen onderling twee soorten relaties hebben: 'uses' of 'extends'. Het is, gezien de relatieve eenvoud van de hci-casus, niet waarschijnlijk dat er 'uses' of 'extends' relaties tussen Use Cases zullen zijn. Voor de volledigheid volgt een korte uitleg.
Een 'extends' relatie gebruik je als je een Use Case hebt die overeenkomt met een andere Use Case, maar iets meer doet. Dit 'ietsje meer' haal je uit de Use Case weg en plaats je in een aparte Use Case. Deze nieuwe Use Case 'extends' dan de andere Use Case.
Als je een stuk gedrag hebt dat in meerdere Use Cases voorkomt is het beter dat er uit te modelleren, in plaats van het te herhalen. Op deze wijze ontstaat een Use Case die gebruikt wordt ('use' relatie) door andere Use Cases. Een simpel voorbeeld is een Use Case die de kredietwaardigheid van een persoon nagaat. Dit kan, afhankelijk van het soort klant (niet-vast, vast) gebruikt worden zowel door de Use Cases 'aankoop afhandelen' en 'kredietlimiet aanpassen', en wordt er dus uitgemodelleerd als Use Case 'kredietwaardigheid bepalen'.
De overeenkomst tussen extends en use is dat je in beide gevallen overeenkomstig gedrag verwijderd om herhaling te voorkomen. Het verschil tussen beiden is dat in geval van een 'uses' relatie, de 'used' Use Case vaak geen actor meer kent.
Je gebruikt 'extends' wanneer je een variatie van het normale gedrag wil beschrijven. Je 'gebruikt' uses als je merkt dat er herhaling plaatsvindt. Dit moet zoveel mogelijk vermeden worden.

Activity Diagram

De specificatie van het Activity Diagram vind je in de offiële documentatie in Section 3, part 10: Dit document (PDF) is te downloaden op http://www.omg.org/cgi-bin/doc?formal/03-03-01 [6321 KB].

In het project wordt het activity diagram gebruikt voor het weergeven van het Use Case scenario. Het diagram geeft (conform het doel van diagrammen) het scenario op een consistente manier weer, zodat het te controleren is op volledigheid e.d. Deze weergave is een tussenstap die in het hci-project de vertaling naar een State Transition Diagram (STD) moet vergemakkelijken. Het STD is het belangrijkste doel: het geeft de verschillende schermtoestanden weer (en de gebruikersacties die de verschillende schermovergangen bewerkstelligen). Dat is uiteraard nodig voor het ontwerp.

Het gebruik van dit diagram in het hci-project beperkt zich hoofdzakelijk tot 4 symbolen: Action State, Fork/Join en de lijn (Edge) (met pijlrichting) tussen action states c.q. forks/joins. Het label van de action state geeft de activiteit weer, bijv. 'pincode toetsen'. Het diagram kent meer symbolen (o.a. begin en end), zie ook de opmerking. De basis voor de tekentechniek in het project is:

Figuur: Basis voor de tekentechniek in het hci-project

Opmerkingen

State Transition Diagram (Statecharts)

De specificatie van het Statechart Diagram vind je in de offiële documentatie in Section 3, part 9: Dit document (PDF) is te downloaden op http://www.omg.org/cgi-bin/doc?formal/03-03-01 [6321 KB].
State Transition Diagrams worden al heel erg veel jaren gebruikt. De offiële aanduiding in UML is Statechart maar in plaats hiervan kom je vaak de aanduiding State Transition Diagram (STD) tegen: STD's vormen de kern van Statecharts. In het hci-project beperken we ons tot deze kern en gebruiken we de STD-variant die 'Mealy diagram' heet, omdat het een 'Mealy Machine' weergeeft.
We gebruiken het STD voor het weergeven van de dialoogstuctuur: Elke state representeert een interface-toestand. Elke state komt in het storyboard dan ook overeen met een schets van het beeldscherm. O.a. heb je het STD nodig bij de storyboard-evaluatie: in het STD zie je welke volgende schets moet worden getoond n.a.v. de acties van de proefpersoon.

STD's blijken in de praktijk wat lastiger te hanteren dan Use Case of Activity diagrammen. Het probleem zit in de omgang met 'state'. Voor een goed begrip is het nuttig om eerst in de theorie-aanvulling over mentale gebruikersmodellen (User Models) in de paragraaf 'User Models' de bullet 'State-transition modellen' door te nemen.
Gelet op de complexiteit in de UML specificatie volgt een samenvatting c.q. leeswijzer.

Gebruikte termen

Boolean (boolean expression, boolean operator)
De uitkomst van een boolean expression is waar of onwaar.
Bijv. de bewering 'de temperatuur is hoger dan 20°' is waar of onwaar. Waar en onwaar zijn boolean values ('waar' of 'onwaar', 'true' of 'false', 'ja' of 'nee', '0' of '1'). Een boolean value wordt kortweg boolean genoemd.
Booleans kunnen in een expressie verbonden worden met de boolean operatoren 'and' en 'or'. Bijvoorbeeld de expressie true and false heeft als uitkomst false, en true or false is true.
Boolean values kunnen voorafgegaan worden door de 'not' boolean operator. Not true = false en vice versa. Als de temperatuur 21° is, dan heeft not(temperatuur > 20°) de uitkomst false.
Class diagram
Dit ligt buiten de context van HCI en kan verder genegeerd worden.
Event
Een algemene aanduiding voor iets wat in een applicatie gebeurt: Een gebruiker die ergens op klikt en dus een systeemactie lanceert, een deel van de applicatie dat in een ander deel een actie aanroept, e.d.
Guard
Die conditie (van het type boolean) die bepaalt of de bij een event behorende actie(s) uitgevoerd wordt/worden.
Node
Ned.: knoop; bestandsdeel van een diagram. Een boomdiagram bestaat uit knopen, verbonden door lijnen. Bijvoorbeeld de knoop 'gezin' kan met lijnen verbonden worden aan de knopen 'vader', 'moeder' en 'kind'. In een STD zijn de 'states' de knopen.
State
Ned.: toestand. Dit is één van de toestanden waarin een systeem (applicatie) kan verkeren. Een lamp heeft twee toestanden: 'aan' en 'uit'. Elk systeem heeft tenminste één state. Een defecte lamp bijvoorbeeld heeft de enkele state 'uit'.
STD
State Transition Diagram (Ned.: toestands-verandering diagram)
In een STD worden het gedrag van een applicatie uitgedrukt in de verschillende mogelijke states en de transitions die tot de state leiden.
Transition
Ned.: overgang. D.i. de overgang van de ene state naar de andere state.
Variable
Ned.: variabele. 'Iets' dat meerdere waarden kan hebben. Bijvoorbeeld kan de 'lengte' van een object een oneindige reeks waarden hebben, wordt 'watertemperatuur' begrensd door 100 (graden C), en heeft de variabele 'lamptoestand' de waarden 'aan' en 'uit'. Variabelen worden gebruikt in de condities (guard expression) van een transition. Bijvoorbeeld de conditie 'temperatuur' (de variabele) is 'te hoog' (de waarde) kan genoteerd worden als temp > 10.

Scope van het STD

State Transition Diagrams (STD) worden gebruikt om het gedrag van een systeem (applicatie) in beeld te brengen. Een systeem verkeert telkens in verschillende toestanden ('states'), evenals er aanleidingen ('events') zijn om in die toestanden te geraken. De overgang van een 'state' in een volgende heet 'transition'.

In het hoofdstuk over 'conceptionele modellen bij gebruikers' (user models) vinden we state-transition terug als een vorm van een (dynamisch) mentaal model. Als voorbeeld wordt daar de telefoon gebruikt: deze verkeert na een bepaalde gebruikersactie (hoorn van de haak, nummerkeuze) steeds in een volgende state: 'open lijn', 'verbinding totstand gebracht' (nummer gaat over), 'beantwoord' (persoon aan de andere kant meldt zich). Dergelijke user models hebben betrekking op sequenties, waarbij de gebruiker het systeem telkens in een volgende toestand waant. Uiteraard zijn het niet alleen gebruikersacties die tot nieuwe states leiden: Nadat het nummer een bepaalde tijd overgegaan is, wordt de verbinding door het systeem verbroken ('niet thuis') en komen we in een 'error state', duidelijk gemaakt door het repeterende foutsignaal (tuut-tuut-tuut- ).

De inzet van STD's beperkt zich niet tot dergelijke sequenties. In ieder systeem is sprake van toestandsveranderingen op basis van gebruikers- en systeemacties. In HCI komen deze overeen met interface (beeldscherm) veranderingen. Een STD is dan ook een heel geschikt diagram om het verloop van de verschillende interface-toestanden vast te leggen. Hierbij richten we ons in eerste instantie op de gebruikershandelingen, die in een ruwe vorm al beschreven zijn in het use case scenario en het begeleidende activity diagram. Het belang van het activity diagram is vooral gelegen in de informatie m.b.t. gebruikersacties, of deze wel of niet specifieke opeenvolging vereisen ('parallelle acties'), en de condities in deze 'workflow'. Dit tussenresultaat wordt, nu uitgaande van de diverse vereiste states van het systeem, waar nodig verder gedifferentieerd en daarna weergegeven in het STD: Het STD beschrijft dan exact de gevolgen van gebruikersacties ('user actions') voor de interface, aangevuld met de gevolgen veroorzaakt door 'system actions'. De stap van het activity diagram naar het STD is niet groot, maar let er wel op dat de nodes in het activity diagram iets anders weergeven dan de nodes in het STD: resp. 'activities' en 'states'.

Syntax van het Mealy diagram

Het Mealy diagram:

De aanleiding voor een transition is een bepaalde event, bijvoorbeeld een gebruikershandeling. Een transition bestaat uit drie elementen:

  1. 'event expression'
    Beschrijving van het event dat de overgang aan de orde stelt
  2. 'guard expression'
    De uitdrukking van de (boolean) conditie die bepaalt of de overgang wel of niet plaatsvindt
  3. 'action expressions'
    Een opsomming van uit te voeren acties die tot de nieuwe state leiden. Acties gescheiden door komma's worden gelijktijdig uitgevoerd. Acties gescheiden door puntkomma's worden achtereenvolgens uitgevoerd.
Syntax: event expression [guard expression] / action expressions.
Het bestaan van elk van deze drie componenten van een transition is optioneel: Bijv. kan de conditie ontbreken, zodat het event altijd tot de nieuwe state leidt. De slash is er altijd.
N.B.: Together presenteert dit iets anders: event name [guard condition]^send clause
Alleen de allereerste transition, die van de initiële state naar de volgende, wordt niet door een event (en dus ook zonder conditie) veroorzaakt, maar mogelijk wel door een initialisatie-actie. Bijvoorbeeld in geval van telefoneren de actie 'hoorn van de haak nemen': Dit brengt het systeem in de state 'open lijn, wacht op nummerkeuze'.

Er zijn verschillende soorten events (named event, condition change event, temporal event). Een voorbeeld van een temporal event is als je (in geval van telefoneren) te lang wacht nadat je de hoorn van de haak hebt genomen, dus in de state van het systeem volgend op de initialisatie-actie: Na .. seconden (temporal event) komt het systeem in een fouttoestand, aan de gebruiker duidelijk gemaakt met een repeterende toon (foutsignaal).

De regels voor de notatie van de labels van de transitions zijn belangrijk. Deze moeten nauwkeurig gevolgd worden!

Variabelen

Het gebruik van variabelen en operatoren maakt het mogelijk om (onnauwkeurige) taalkundige beschrijvingen te vervangen door nauwkeuriger expressies.
Een variabele vervangt een taalkundig begrip door een symbool (bijvoorbeeld t of time) met specifieke eigenschappen: Een variabele kan meerdere waarden hebben (vandaar de naam), heeft een bepaald type waarde, en vaak is ook sprake van een bepaald waardebereik. Bijvoorbeeld kan de 'lengte' van een object uitgedrukt worden in centimeters vanaf 0 tot oneindig, wordt 'watertemperatuur' (althans in de keuken) begrensd door 100 (graden Celsius), en heeft de variabele 'lamp' de waarden 'aan' en 'uit'. In het laatste geval is het type van de waarde 'boolean', en in de eerdere gevallen is het type 'werkelijk getal' ('real'). Voorbeelden van andere typen zijn 'geheel getal' ('integer'), 'datum', 'string' e.d.
Voorbeelden van operatoren zijn >, <, == etc. Een expressie heeft de vorm variabele operator variabele. Boolean expressies worden gebruikt in de condities (guard expression) van transitions. Het resultaat van een boolean expressie is 'true' of 'false'. Bijvoorbeeld t > 10 (waarbij t voor temperatuur staat), wat een nauwkeuriger uitdrukking is dan 'temperatuur te hoog'.

Wait en Activity States

Dat er twee soorten states zijn (Wait States en Activity States) is vaak verwarrend: de meeste mensen hanteren intuitief Wait States. Het gebruik van STD's in HCI betreft veel 'wait states': er gebeurt niets dan wachten op een (gebruikers) event. Een voorbeeld is het presenteren van een commando-paneel en het wachten tot de gebruiker op de OK button klikt. Pas daarna wordt de invoer gecheckt, wordt bekeken of aan condities voldaan is en kan de volgende transition plaatsvinden. Een voorbeeld van een activity state is de 'open lijn' state in een telefoongesprek. Er is een teller actief die na verloop van een bepaalde tijd (1) en het niet ontvangen van de gebruikersrespons 'nummerkeuze' (2) het systeem in een fouttoestandzet. De teller wordt onderbroken door de nummerkeuze.

Voorbeeld

Een voorbeeld van een STD vind je in het 'stappenplan fase 3' Merk op dat ook in dit voorbeeld sprake is van activity states (ook in een geldautomaat wordt de transactie afgebroken na een bepaalde inactieve tijd), die niet verder uitgewerkt zijn in volgende states: Om een balans te houden tussen volledigheid en leesbaarheid van het diagram kan men er voor kiezen niet alle details op te nemen. (Een pragmatische aanpak hierbij is het opnemen van dat deel dat in het prototype uitgewerkt moet worden om het te kunnen evalueren).

 


 

Zie ook c.q. aanvullend: How to Conduct a Heuristic Evaluation, by Jakob Nielsen op diens website http://www.useit.com/papers/heuristic/heuristic_evaluation.html

 

skip navigation Task-Centered User Interface Design
A Practical Introduction
by Clayton Lewis and John Rieman
Copyright ©1993, 1994: Please see the "shareware notice" at the front of the book.
Contents | Foreword | Process | Users&Tasks | Design | Inspections | User-testing | Tools | Documentation | Legal | Managing | Exercises

Chapter 4: Evaluating the Design Without Users
(fragment)

Example: Selecting Background Printing with the Mac Chooser

We've presented this example in the rough format that a system designer might use to describe a suggested system to his colleagues. This is the point in an interface design when you should be using the techniques described in this chapter, either alone or as a group -- don't wait until after the system is implemented!

START

User is working with word processor. Task is to turn on background printing. Screen shows the current application window and the following menubar of pulldown menus:

    ------------------------------------------
     @ File Edit Search Font Utilities
    ------------------------------------------
("@" stands for the apple icon.)

ACTION 1: Pull down the apple menu.

Apple pulldown menu looks like this:

      | @ |
       ------------------
      | About UltraWord  |
      | ---------------- |
      | Alarm Clock      |
      | Calculator       |
      | Chooser          |
      | Control Panel    |
      | Find File        |
      | Keycaps          |
      | Scrapbook        |
       ------------------

ACTION 2: Select "Chooser" from the menu.

A dialog box appears:

      ---------------------------------------------------
     | [ ]                                               |
      ---------------------------------------------------
     |                                                   |
     |   --------------------    ----------------------  |
     |  | [laser printer   |^|  |                      | |
     |  | icon]            |-|  |                      | |
     |  |                  | |  |                      | |
     |  | [dot matrix      | |  |                      | |
     |  | printer icon]    |-|  |                      | |
     |  |                  |v|  |                      | |
     |   --------------------    ----------------------  |
     |                                                   |
     |                                                   |
     |                          User name:               |
     |                            --------------------   |
     |                           | Sneezy             |  |
     |                            --------------------   |
     |                          Appletalk:               |
     |                            o active   * inactive  |
      ---------------------------------------------------

ACTION 3: Click on current printer type, which is Laser.

The laser printer icon highlights and new things appear in the dialog box:

      ---------------------------------------------------
     | [ ]                                               |
      ---------------------------------------------------
     |                          Select a laser printer:  |
     |   --------------------    ----------------------  |
     |  | [LASER PRINTER   |^|  | Hotshot              | |
     |  | ICON (high-      |-|  | Mary's               | |
     |  | lighted)]        | |  | Last Chance          | |
     |  |                  | |  |                      | |
     |  | [dot matrix      |-|  |                      | |
     |  | printer icon]    |v|  |                      | |
     |   --------------------    ----------------------  |
     |                          Background printing      |
     |                             o On      * Off       |
     |                          User name:               |
     |                            --------------------   |
     |                           | Sneezy             |  |
     |                            --------------------   |
     |                          Appletalk:               |
     |                            o active   * inactive  |
      ---------------------------------------------------

ACTION 4: Click the On button under background printing.

The On button highlights and the Off button unhighlights.

ACTION 5: Click the Close Box in the upper left window.

The screen appears as it did at startup.

4.3 Heuristic Analysis

Heuristics, also called guidelines, are general principles or rules of thumb that can guide design decisions. As soon as it became obvious that bad interfaces were a problem, people started proposing heuristics for interface design, ranging from short lists of very general platitudes ("be informative") to a list of over a thousand very detailed guidelines dealing with specific items such as menus, command names, and error messages. None of these efforts has been strikingly successful in improving the design process, although they're usually effective for critiquing favorite bad examples of someone else's design. When the short lists are used during the design process, however, a lot of problems get missed; and the long lists are usually too unwieldy to apply. In addition, all heuristics require that an analyst have a fair amount of user interface knowledge to translate the general principles into the specifics of the current situation.

Recently, Jacob Nielsen and Rolf Molich have made a real breakthrough in the use of heuristics. Nielsen and Molich have developed a short list of general heuristics, and more importantly, they've developed and tested a procedure for using them to evaluate a design. We give the details of that procedure below, but first we want to say something about why heuristics, which are not necessarily a task-oriented evaluation technique, can be an important part of task- centered design.

The other two evaluation methods described in this chapter, the cognitive walkthrough and action analysis, are task- oriented. That is, they evaluate an interface as applied to a specific task that a user would be doing with the interface. User testing, discussed in chapter 6, is also task oriented. Task-oriented evaluations have some real advantages. They focus on interface problems that occur during work the user would actually be doing, and they give some idea of the importance of the problems in the context of the job. Many of the problems they reveal would only be visible as part of the sequence of actions needed to complete the task. But task-oriented evaluations also have some shortcomings. The first shortcoming is coverage: There's almost never time to evaluate every task a user would perform, so some action sequences and often some controls aren't evaluated. The second shortcoming is in identifying cross-task interactions. Each task is evaluated standing alone, so task-oriented evaluations won't reveal problems such as command names or dialog-box layouts that are done one way in one task, another way in another.

Task-free evaluation methods are important for catching problems that task-oriented methods miss. Both approaches should be used as the interface develops. Now, here's how the heuristic analysis approach works.

Nielsen and Molich used their own experience to identify nine general heuristics (see table, below), which, as they noted, are implicit or explicit in almost all the lists of guidelines that have been suggested for HCI. Then they developed a procedure for applying their heuristics. The procedure is based on the observation that no single evaluator will find every problem with an interface, and different evaluators will often find different problems. So the procedure for heuristic analysis is this: Have several evaluators use the nine heuristics to identify problems with the interface, analyzing either a prototype or a paper description of the design. Each evaluator should do the analysis alone. Then combine the problems identified by the individual evaluators into a single list. Combining the individual results might be done by a single usability expert, but it's often useful to do this as a group activity.

Table: Nielsen and Molich's Nine Heuristics


In plaats van de bovenstaande 9 heuristics gebruiken we in het project de volgende 10 heuristics, eveneens van Nielsen.

Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
User control and freedom Users often choose system functions by mistake and will need a clearly marked \"emergency exit\" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
Recognition rather than recall Make objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Flexibility and efficiency of use Accelerators unseen by the novice user may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced user. Allow users to tailor frequent actions.
Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task list concrete steps to be carried out, and not be too large.

Figure 2.7 Ten usability guidelines derived from a factor analysis of 249 usability problems encountered in 11 projects (Nielsen, 1994).


The procedure works. Nielsen and Molich have shown that the combined list of interface problems includes many more problems than any single evaluator would identify, and with just a few evaluators it includes most of the major problems with the interface. Major problems, here, are problems that confuse users or cause them to make errors. The list will also include less critical problems that only slow or inconvenience the user.

How many evaluators are needed to make the analysis work? That depends on how knowledgeable the evaluators are. If the evaluators are experienced interface experts, then 3 to 5 evaluators can catch all of the "heuristically identifiable" major problems, and they can catch 75 percent of the total heuristically identifiable problems. (We'll explain what "heuristically identifiable" means in a moment.) These experts might be people who've worked in interface design and evaluation for several years, or who have several years of graduate training in the area. For evaluators who are also specialists in the specific domain of the interface (for example, graphic interfaces, or voice interfaces, or automated teller interfaces), the same results can probably be achieved with 2 to 3 evaluators. On the other hand, if the evaluators have no interface training or expertise, it might take as many as 15 of them to find 75 percent of the problems; 5 of these novice evaluators might find only 50 percent of the problems.

We need to caution here that when we say "all" or "75 percent" or "50 percent," we're talking only about "heuristically identifiable" problems. That is, problems with the interface that actually violate one of the nine heuristics. What's gained by combining several evaluator's results is an increased assurance that if a problem can be identified with the heuristics, then it will be. But there may still be problems that the heuristics themselves miss. Those problems might show up with some other evaluation method, such as user testing or a more task-oriented analysis.

Also, all the numbers are averages of past results, not promises. Your results will vary with the interface and with the evaluators. But even with these caveats, the take-home message is still very positive: Individual heuristic evaluations of an interface, performed by 3 to 5 people with some expertise in interface design, will locate a significant number of the major problems.

To give you a better idea of how Nielsen and Molich's nine heuristics apply, one of the authors has done a heuristic evaluation of the Macintosh background printing controls (see Box).

Example: One Evaluator's Heuristic Analysis of the Mac Background Printing Controls

Remember, for an effective heuristic analysis, SEVERAL evaluators should check out the interface independently and combine their notes into a single problem list.

Since heuristic analysis is usually a task-free approach, the Mac background printing controls would probably be presented to the evaluator as part of an overall description of the Chooser, or perhaps of the Mac system interface as a whole. If just the Chooser were being checked, the design description might specify how the dialog box would be brought up through the Apple menu (shown in Steps 1 and 2) and it might have sketches of how the box would look before and after a printer was specified (shown in Steps 3 and 4). It would also give some description of how to use the controls in the dialog box.

Here's my evaluation. This piece of the interface is small enough that I can just go through the nine heuristics one at a time and look for possible problems anywhere in the design. (For a larger design, I might want to step through the nine heuristics several times, once for each manageable chunk of the interface.)

The first heuristic is "simple and natural dialog." OK, the idea of this design seems to be that I select what kind of printer I'm going to use, then specify some options. I guess that will work, but why do I have to select the kind of printer and say which one? Couldn't I tell it which one and let the system figure out whether it's a laser or dot-matrix printer?

Second heuristic: "speak the user's language." I can see an effort to do this. They've called it the "Chooser" instead of "Output options." But an even better name might be "Printer" -- parallel to "Alarm Clock" and "Calculator." I don't know what "Appletalk" is, though. Is there some more common name for this? And why don't the printers have names like "central office" or "library," indicating where they are?

Heuristic: "Minimize user memory load." This heuristic primarily applies to things the user has to notice in one step and remember one or more steps later. Everything stays pretty visible here, so the memory load is low. But I do have to remember what kind of printer I'm using and what its name is.

Heuristic: "Be consistent." I don't think I've seen a scrolling list of clickable icons in any other dialog box. Do the icons add anything here? Maybe there should just be a scrolling list of text entries.

Heuristic: "Provide feedback." Design seems good to me. Something happens whenever I do anything. Of course, there's no evidence of what I've done after the dialog box goes away. But that seems OK here. I don't mind having some options set "behind the scenes," as long as I can check them whenever I want.

Heuristic: "Provide clearly marked exits." Well, looking at the dialog box, I see that it has a "close box" in the upper left. I kind of expect an "OK" and a "Cancel" button in a dialog box. Maybe I should have noted this under consistency with the rest of the interface? Anyway, it might confuse some people.

Heuristic: "Provide shortcuts." I suppose the usual Mac menu-selection shortcuts work -- like typing "M" to select "Mary's" printer." Should there be other shortcuts? I dunno. Depends on whether people need to do something really often, like toggling AppleTalk or Background printing. Need some more task analysis here.

Heuristic: "Good error messages." Current design doesn't describe any error messages. I guess I'd like users to get an error if they selected a printer that wasn't connected to the computer. Need to check on that. Also, what if they turn off background printing while something is in the queue?

Heuristic: "Prevent errors." Same comments as for error messages, except it would be better if the user wasn't given options that wouldn't work. So if there isn't an ImageWriter connected, they shouldn't be able to select it -- it should probably be grayed out, or not there at all.

Summary

Based on what I've noticed in the heuristic analysis, I'd like to see some changes. I'd want the menu item to be called "Printer," and I'd want the dialog box to give me a list of currently available printer locations to choose from. The system should figure out what kind of printer it is. Also, I'd use an "OK" and a "Cancel" button instead of a window close box.

(Some discussion with the designers would probably raise the point that selecting a printer type effects how a document is formatted, even if a printer isn't connected. I'd have to argue that this really isn't "speaking the user's language." I think most users would expect to find formatting options under the format menu in the application.)

Credits and Pointers: Heuristic Analysis

The heuristic analysis technique was developed by Jacob Nielsen and Rolf Molich. Tests of the technique's effectiveness are described in:

More detailed descriptions of the nine heuristics are given in:

Copyright © 1993,1994 Lewis & Rieman

Contents | Foreword | Process | Users&Tasks | Design | Inspections | User-testing | Tools | Documentation | Legal | Managing | Exercises | Top

 


 

Icons

Een icon is een kleine afbeelding van een object op het scherm. De meest voorkomende icongrootte is 16x16 pixels. Voor grote icons wordt ook wel 32x32 gebruikt; hiernaast bestaan er ook wel afwijkende formaten.

Icons ondersteunen de begrijpelijkheid van de interface. Vaak worden ze metaforisch ingezet: Bijvoorbeeld gaat het MS-Windows platform uit van de kantoormetafoor zodat bestanden worden weergegeven als blaadjes papier (documenten), bestanden editen met een kladblok, directories als mappen zichtbaar zijn, wissen plaats vindt door objecten naar de prullebak te slepen, etc. en het beeldscherm een bureaublad is waarop deze icons te vinden zijn (zie figuur).


Figuur: Icons op de Windwos desktop

Voor de gebruiker is een icon meestal een interactief element. De icons op de desktop zijn te activeren door erop (dubbel) te klikken. Ook buttons bevatten vaak icons, bijvoorbeeld die op toolbars (zie figuur). Icons in de interface lokken daarom interactie uit: de gebruiker verwacht dat erop geklikt kan worden.


Figuur: Icons op de buttons van een toolbar

Directe manipulatie is sterk afhankelijk van icons. Directe manipulatie is het succes van de GUI (Graphical User Interface). Het is de interactiestijl waarbij objecten in de interface direct gemanipuleerd worden en het resultaat tegelijkertijd zichtbaar wordt. Je zou het kunnen vergelijken met fietsen of auto-rijden: als je het stuur verdraait merk je direct dat je een bocht maakt. Het 'verslepen' van een document icon in de prullebak icon (delete) is een voorbeeld van directe manupulatie. De scrollbar en de slider widget zijn andere voorbeelden van directe manipulatie. De scrollbar bevat 'pijltjes icons' om de richting aan te geven. De slider is een weergave van een schuifregelaar met een 'handle' voor het verslepen.


Figuur: Slider widget (uit Java bibliotheek)

Affordance

Het ontwerp van (interactieve) icons moet zo zijn dat de betreffende programmafunctie direct duidelijk is. Dit geven we aan het begrip affordance. Het printer icon in een toolbar heeft bijvoorbeeld een goede affordance: Het is direct duidelijk dat je, door op deze button te klikken, een afdruk gaat maken. (Ook de button zelf heeft een goede affordance: door de 3D simulatie (randjes, schaduw) lijkt het goed op de druktoets in de werkelijke wereld. Deze metafoor zorgt ervoor dat we intuitief kunnen handelen.)
De handle op de scrollbar heeft in eerste instantie een minder goede affordance: Dit object ziet eruit als een button, maar als je erop klikt gebeurt er niets (wel als je in de ruimte erboven klikt ...). Een beginnende gebruiker zal dus op de buttons klikken waar de pijltjes op staan. Vervolgens ziet de gebruiker dat de handle verspringt, en kan daaruit leren dat de gewenste verplaatsing ook met deze handles uitgevoerd kan worden, door deze te verslepen.
In dit voorbeeld wordt de affordance versterkt door de feedback die het systeem geeft. Naast affordance is feedback een belangrijk aspect van de user interface: het bevestigt de gebruiker in de juistheid van zijn/haar handelen. Dus laten buttons waarop geklikt wordt een beweging zien of blijven 'ingedrukt', of geeft de computer een korte beep bij een foutsituatie.

Typen van icons

Een icon kan bestaan uit concrete objecten, abstracte symbolen (lijnen, circels, pijlen e.d.) of een combinatie van beide. Bijvoorbeeld geven deze icons aan dat van document kan worden gewisseld: Dit icon gebruikt 'concrete' objecten (windows) en abstracte (pijl) en maakt d.m.v. het voor/achter perspectief gebruik van een 'ruimte' metafoor.
Of een programmafunctie goed begrepen wordt aan de hand van het icon is in hoofdzaak afhankelijk van de gebruikte analogie (mapping). Een printer icon heeft een directe analogie met de functie printen en wordt daarom direct begrepen.

In de literatuur (o.a. Preece) worden icons wel gecategoriseerd in vier types, gebaseerd op de mate van mapping tussen het icon en het concept waarvoor het wordt gebruikt. Deze types zijn 1. directe gelijkenis, 2. typisch object (bijv. mes+vork om de restauratie aan te duiden), 3. symbool (overdrachtelijke betekenis, bijvoorbeeld wijnglas op doos om breekbaar aan te geven) en 4. abstract (geen directe mapping, betekenis moet geleerd worden). Deze indeling is echter niet helemaal consistent, want vaak is het mogelijk om een icon twee types tegelijk toe te kennen. Bijvoorbeeld de printer is een directe gelijkenis maar ook een typisch object.

Op basis van onderzoek (Schijf, Verpoorten et al., 2006) stellen we een andere indeling voor (zie figuur):

Figuur: Representatie-types en een voorstel voor een mapping taxonomie, elk type verduidelijkt door enkele voorbeelden. Non-mapping representaties zijn La=language (label of annotatie) en Im=image (4 detailleringsgradaties: Im/++ tot Im/--; ++ betekent veel details, -- betekent dat een een label noodzakelijk is om het te kunnen begrijpen). Acht mapping types worden voorgesteld. (Uit Schijf, Verpoorten et al., 2006)

De figuur geeft alle mogelijke representaties weer. Voor wat betreft icons zijn alleen de types 3, 4, 7 en 8 relevant. Typen 3 en 4 zijn indirecte mappings. Type 3 (abstract) komt veel in de interface voor, maar alleen omdat in zo'n geval een toepassing van een van de andere types ontbreekt. Type 4 (concreet) is een concrete afbeelding die overdrachtelijk gebruikt wordt. Voorbeelden in de interface zijn het gebruik van de wereldbol om internet mee aan te geven.
Typen 7 en 8 zijn directe mappings. Type 8 (fysische analogie) zal niet vaak als icon in de interface voorkomen (wel als toepassing bijvoorbeeld bij de scrollbar en slider), maar type 7 (aspect, typisch voor het geheel) des te meer. Dit zijn dan ook de beste! Behalve de printer zijn van dit type ook de diskette en de icons om bold, italic en underline aan te geven. Horen hier nu ook bij? Ja, al gaan deze ook enigszins richting type 8 (fysische analogie); het groter/kleiner aspect is echter goed waar te nemen in het letterbeeld zelf, zodat type 7 domineert. De plus en min kunnen beschouwd worden als tekstlabels, om de bedoeling van de functie 'kleiner/groter maken' verder te ondersteunen. De schaar en het penseel zijn ook ietwat overdrachtelijk omdat niet feitelijk geknipt of gepenseeld wordt, maar hier is de object-handeling relatie zo prominent dat een directe mapping aangehouden wordt. Mede ondersteund omdat reeds in de software wordt gesproken over 'knippen'.

Samengevat onderscheiden we nu vier types, twee met een indirecte en twee met een directe mapping:
Indirect Abstract Een symbolische weergave waarvan de betekenis in de regel niet direct duidelijk is en geleerd moet worden.
Concreet Een bestaande afbeelding die op een overdrachtelijke wijze gebruikt wordt
Direct Typisch aspect Een deel dat kenmerkend is voor het geheel. Vooral objecten, horend bij de handeling, scoren hier hoog.
Fysische analogie Gebruik maken van de overeenkomst in beweging, richting of grootte

En welk type is dit: ? Geen enkel mapping type, het is een concrete weergave met weinig details, non-mapping type Im/- volgens de indeling in de figuur boven.

Zie ook onder naslag het artikel 'Designing Icons' over icon-ontwerp (uit de 'Java Look and Feel Design Guidelines').


Referenties:
Tabachneck-Schijf, H.J.M., Verpoorten, J.H., Van de Weg, R.L.W., Wieringa, R.J. 2006. The influence of conceptual user models on the creation and interpretation of diagrams representing reactive systems. Merida, InScit2006 Conference Proceedings.

 


 

Interactiestijl en dialoogmodel

Interactiestijl

Onder interactiestijl verstaan we de wijze waarop een gebruiker met de software interacteert en/of deze bestuurt. Bij de huidige computers vindt de interactie voornamelijk plaats met het toetsenbord en/of de muis. Een variant van de muis is de muispen (gecombineerd met een grafisch tablet), vooral in gebruik bij CAD (computer-aided design) systemen. Verwant aan de muis is het aanraakscherm, waar men met de vinger op het beeldscherm drukt. Dit is populair in geval van openbare opstelling (z.g. kiosk), bijvoorbeeld een informatiezuil of de nieuwere kaartjesautomaat van de NS. Oudere personal computers (tot eind 80-er jaren) waren muisloos en kenden alleen het toetsenbord. Hiermee is het overzicht trouwens niet compleet: De nog oudere main frames ontvingen hun instructies via ponskaarten (elke instructie op een aparte kaart), waarvan er stelselmatig een hele stapel (batch) moest worden ingevoerd. Na invoer van de ponskaarten (batch-verwerking) verwerkte de computer de instructies en werd het resultaat geprint. De ponskaartenstapel werd later vervangen door een reeks instructies in een file: de batch file (die ook onder MS-DOS op de pc een hoge populariteit had). Alhoewel batch-verwerking niet als interactief beschouwd wordt, is het nog steeds niet helemaal uitgestorven.
Volgens sommigen ligt de echte toekomst vooral bij de spraakinterface (ingesproken opdrachten). Deze interfaces bestaan al, maar de set opdrachten die verwerkt kan worden is stelselmatig nog beperkt. De laatste ontwikkelingen gaan richting driedimensionale (virtuele dimensies) interfaces, waarbij de muis dus een belangrijk hulpmiddel is om de 'objecten' in de virtuele ruimte te manipuleren (zie o.a. project Looking Glass van Sun Microsystems [http://wwws.sun.com/software/looking_glass/]).

Uitgaande van vooral het toetsenbord en de muis en de wijze waarop hiervan in de software gebruik gemaakt wordt, worden door HCI-auteurs meestal vier verschillende interactiestijlen onderscheiden: commandotaal, menustructuur, invulformulier en directe manipulatie.

Commandotaal

De eerste interactieve besturingswijze (vooral bij operating systems) gebeurde met commando's. Bijvoorbeeld bestanden kopieren d.m.v. intypen van het commando PIP (Periferal Interchange Program) in CPM, of het commando COPY in MS-DOS. In onderstaand voorbeeld zien we hoe zo'n interactieve sessie verloopt. Geheel links staat de prompt, een teken waarmee de software aangeeft klaar te zijn voor het commando (D:\> in het voorbeeld). Hierachter wordt het commando (ping in het voorbeeld) ingetypt, gevolgd door een (reeks) argument(en) waarmee het commando moet werken (solis.uu.nl in het voorbeeld). Na indrukken van Enter (ook wel Carriage Return genoemd, afgeleid van de type-machine waar het toetsenbord van afgeleid is) gaat het commando aan het werk. In het voorbeeld zie je eerst het commando bevestigen (Pinging solis..etc.) waarna het resultaat op het beeldscherm afgedrukt wordt (Reply from ..etc.). Daarna verschijnt de prompt weer, met erachter de cursor (_ in dit voorbeeld) die de actieve plaats op het scherm aangeeft.
Deze sessie is niet interactief maar dat is wel heel goed mogelijk. Bijvoorbeeld doordat de software om bevestiging vraagt (Are you sure? [Y/N]:), wat met intypen Y of N gegeven wordt, of doordat er om het intypen van een getal gevraagd wordt bijvoorbeeld om een keuze te maken uit een rijtje mogelijkheden.


Figuur: Voorbeeld van commandotaal in een besturingssysteem. Het commando 'ping' met argument 'solis.uu.nl' wordt gevolgd door uitvoer van het resultaat

Naast het intypen van commando's achter een prompt bestaat de besturing van oudere applicatie software vaak bijna geheel uit commando's waarbij een letter(reeks) wordt ingetoetst tegelijk met het ingedrukt houden van de Control-toets. De gebruikelijke notatie hiervoor is de Control-toets weer te geven met het ^-teken; bijv. ^A is control+A betekent eerst de Control-toets indrukken (om de speciale commado-functie aan te geven), de toets ingedrukt gehouden en vervolgens de A intoetsen. Voor de letter(combinatie)s worden z.g. mnemonics (spreek uit nimonics) gebruikt: letters en lettergroepen die op de een of andere wijze de betekenis kort weergeven en als geheugenhulpje dienen. Bijvoorbeeld ^P voor afdrukken (print), ^BS voor saven van een blok, etc. (programmeertalen maken hier veel gebruik van). Veel van deze control-toets combinaties zijn ook in moderne interfaces nog steeds werkzaam. Bijvoorbeeld kun je in Windows (en Unix/Linux) vrijwel altijd de printer activeren met ^P. In grafische user interfaces heten deze toetscombinaties Accelerators. Vrijwel ieder menu kent wel deze equivalenten voor keuzes, waarbij zowel de Alt- als de Control-toets gebruikt kan worden om de speciale commandofunctie aan te geven.

Het leren besturen van programma's alleen d.m.v. commando-opdrachten is voor veel mensen een moeilijke opgave. Aanvankelijk is geprobeerd dit op te lossen met speciale (programmeerbare) toetsen op het toetsenbord: de functietoetsen. In veel programma's kun je nog steeds hulp krijgen na het indrukken van F1 en in Windows kun je applicaties (en Windows zelf) afsluiten met Alt+F4. Het grote probleem bleek echter de programmeerbaargheid van deze functietoetsen: Voor hulp moet in het ene programma F1 en in het andere F3 gebruikt worden, voor afsluiten in het ene Alt+F4 en het andere F7, etc. Dit leidt dus tot inconsistentie in de interface. Ook functietoetsen zijn nog vaak actief in moderne software. Bijvoorbeeld betekent tegenwoordig F1 vrijwel altijd hulp.

Het meest voorkomende geval van commandotaal in de moderne interface is het opstellen van zoek queries, bijvoorbeeld in web search engines als Google, Alta Vista, AllTheWeb etc. Dergelijke commando's volgen een bepaalde syntax om de logische operatoren aan te geven. Bijvoorbeeld '+human +computer' of 'human AND computer' als gezocht moet worden naar documenten waar beide termen in voorkomen.

Ervaren gebruikers hebben vaak een voorkeur voor commando's vanwege de hogere snelheid. Bijkomend voordeel is een lager RSI-risico omdat er geen muis nodig is. Commando's moet je leren en omdat onthouden een grotere inspanning kost dan herkennen geven beginnende gebruikers de voorkeur aan het perpceptueel aanbieden van keuzes in de interface. Hiermee zijn we gekomen bij de volgende interactiestijl, de menustructuur.

Menustructuur

Bij deze interactiestijl wordt de software bestuurd door commando's op een gestructureerde wijze in lijsten en sublijsten, menu's genoemd, op te nemen. Menukeuzes leiden weer naar een volgend menu, etc.: Na de keuze van een menu item verschijnt een volgend menu onder/naast het vorige. Dit volgende menu heet een pull-down menu, of ook wel pop-down menu of (ietwat verwarrend, zie het interactie-element drop-down listbox) drop-down menu genoemd. Aanvankelijk werd veel software op deze wijze 'gebruikersvriendelijk' gemaakt. Inderdaad: als de gebruiker de weg weet in de menu-hierarchie kunnen snel commando's gegeven worden. Het zwakke punt zit in het "de weg weten", omdat alleen de keuzes op het bovenste niveau perceptueel aanwezig (zichtbaar) zijn. Vaak bestond de bediening van software uit complexe menu-structuren, en moest de gebruiker eindeloos zoeken in deze boomstructuur om het gewenste commando te vinden. Tegenwoordig wordt dit (deels) opgelost door de zg. toolbar: Een balk met buttons met iconen waaronder de meest voorkomende commando's direct zichtbaar opgesteld staan.


Figuur: Menubalk met een geopend submenu (pull-down menu).

De besturing d.m.v. een menustructuur is nog steeds in de interface aanwezig, bijvoorbeeld in de menubalk van alle windows applicaties (met als vaste elementen File, Edit, Help). Ook voor webpagina's wordt deze ingezet. In feite zijn er dan twee menustructuren: die van de browser en die van de webpresentatie (zie bijvoorbeeld deze presentatie). In de praktijk werkt dit alleen goed als de menu's niet meer dan 2 niveaus beslaan (hoofdmenu=menubalk en afhankelijk van de keuze een submenu).

Bij de meeste menu's is sprake van duidelijke lijsten met teksten (al dan niet vooraf gegaan door een icoontje) die je focus geeft (laat oplichten) door er de cursor op te zetten (muis op de tekst plaatsen of met de pijltjestoetsen naar de keuze 'bladeren'); de keuze wordt gemaakt met een muisklik of de Enter toets. Een andere wijze om keuzes te presenteren zijn de iconen op de desktop (bureaublad) (en in folders) van Windows. Gebruikers kunnen zelf iconen bijplaatsen die een shortcut (snelkoppeling) zijn naar een programma of een bestand. De keuze wordt gemaakt door op het icoon te dubbelklikken, waarna resp. het programma start of het bestand geopend wordt door aan het bestandstype geassocieerde programma. Shortcuts onderscheiden zich van andere iconen op de desktop door een pijltje in de linkeronder hoek (zie figuur). Het zijn verwijzingen (pointers) naar programma's of bestanden (wissen van de shortcut heeft geen effect op het programma of bestand).


Figuur: deel van de desktop met twee icons en twee shortcuts naar deze twee icons.

Invulformulier

Als een commando veel parameters heeft kunnen deze op een invulformulier worden ingevuld. Dit is een beeldscherm-afgeleide van de papieren formulieren. Zo'n 'formulier' is een interfacepaneel dat meestal als een aparte 'dialog' verschijnt en waarop veel verschillende soorten interactie-elementen kunnen staan (text fields, check boxes, list boxes (menu's), drop-down list boxes etc.). Een veel voorkomend voorbeeld is de dialog die verschijnt na (menukeuze van) het 'preferences', 'configuration', 'settings' etc. commando (zie figuur).


Directe manipulatie

Directe manipulatie is het succes van de GUI (Graphical User Interface). De klassieke definitie van deze interactiestijl (Shneidermann) is dat objecten in de interface direct gemanipuleerd worden, waarbij het resultaat direct (lees: gelijktijdig) zichtbaar wordt. Het is handelen in het gelijktijdig zichtbare resultaat. Je zou het kunnen vergelijken met fietsen of auto-rijden: als je het stuur verdraait merk je tegelijk dat je een bocht maakt. Je hoeft dus niet eerst aan te geven dat je een bocht wilt maken (commando), dan op te geven hoeveel graden (commandoparameters op invulformulier), waarna 'iets' het commando uitvoert.

Vrijwel alle huidige software werkt met directe manipulatie. Voorbeelden zijn games, spreadsheets, tekenprogramma's, tekstverwerkers etc. Bij tekstverwerkers bijvoorbeeld geeft het beeldscherm niet alleen een goede indruk van het op papier afgedrukte eindresultaat (lettertypes, letterstijl, kleur e.d.): ook is van elk gewist of toegevoegd karakter het resultaat direct zichtbaar. Dit wordt ook wel het wysiwyg (what you see is what you get) principe genoemd. Bij oudere z.g. 'line editors' was dat anders: dan moest eerst een commando gegeven worden om aan te geven dat een wijziging plaats ging vinden, vervolgens moest de cursor op een aparte regel op de juiste karakterpositie gezet worden, de wijziging worden ingetypt en tenslotte bevestigd. Pas daarna werd het resultaat getoond. Tekstopmaak werd nooit op het scherm gezet, maar stond zichtbaar in de tekst als commandotaal-uitdrukkingen.

In de huidige interface zijn er tal van elementen te vinden die op directe wijze gemanipuleerd kunnen worden: Bijv. spin controls en sliders om waarden in te stellen (met uiteraard direct zichtbaar gevolg) etc. Bestanden kunnen worden geopend door ze (in de windows explorer) naar het bijbehorende programma te 'slepen'. Windows op de interface kunnen direct gemanipuleerd worden: verplaatst (door ze met de muis te verslepen: 'drag and drop'), van afmeting veranderd d.m.v. de 'handles' in het window frame, 'minimized' d.m.v. de command button rechtsboeven, etc. Een ander voorbeeld is de interactieve presentatie waarbij je in een panorama-foto naar links of rechts kan bewegen, inzoomen e.d. door middel van het verslepen van de muis op de afbeelding.
De bovenaan deze pagina genoemde driedimensionele interface 'Looking Glass' berust vrijwel geheel op directe manipulatie. Bij buttons is alleen sprake van directe manipulatie in de control zelf, omdat deze de 'indruk'- en 'loslaat'beweging nabootsen. Voor de rest niet: pas na het indrukken van de button zie je het gevolg in de interface.

.

Dialoogmodel

Vrijwel elke schermpresentatie is een compositie van een of meerdere panelen, waarop interface-elementen (buttons, labels etc.) staan. Een dialoogmodel geeft het soort structuur aan waarin verschillende paneelcomposities elkaar opvolgen. Er bestaan vier basismodellen, in oplopende complexiteit: enkelvoudig, lineair, hierarchisch en netwerk.

Enkelvoudige dialoog

In dit geval is er maar één paneelcompositie. Veel search engines (Google, Alta Vista, alltheweb etc.) hanteren dit model: Er is een paneelcompositie met panelen waarop trefwoorden, zoekinstellingen e.d. staan plus een leeg paneel, dat na voltooing van de zoekopdracht gevuld is met een overzicht van links naar gevonden pagina's. In onderstaande figuur staan zulke (vrijwel) identieke paneelcomposities: Links het uitgangsscherm en rechts het resultaatscherm (www.alltheweb.com)

Figuur: Enkelvoudige dialoog (search engine alltheweb, www.alltheweb.com)

Lineaire dialoog

Hierbij is de dialoog een lineair uitgevoerde taak: Een reeks paneelcomposities komt in een (bijna) vaste volgorde langs gedurende de taak. Voorbeelden: de geldautomaat en 'wizards'. Wizards leiden een (vaak onervaren) gebruiker stap voor stap door een taak heen door bij elke stap vragen te stellen waarvan het antwoord bepalend is voor de volgende te presenteren stap. Bij wizards is het gebruikelijk terug te kunnen bladeren, om te kunnen herstellen.

Figuur: Boven: structuur lineaire dialoog. Onder: de 2 eerste schermen van een wizard (Nero brand software)

Hierarchische dialoog

Deze wordt gebruikt als een grote hoeveelheid informatie gestructureerd gepresenteerd moet worden. Elke paneelcompositie geeft toegang tot meerdere andere paneelcomposities, die elk weer .. etc. Een boomstructuur kortom.

Figuur: Hierarchische dialoog (www.boeing.com). Op de homepage wordt gekozen voor 'Product & Services', en hierin voor 'Phantom Works'. Het volgende scherm verschijnt, waar gekozen wordt voor 'research and development projects', waarna 5 keuzes ('Advanced Systems etc.) verschijnen.

Netwerkdialoog

Hierbij is een aantal paneelcomposities op verschillende manieren onderling verbonden. De gebruiker wisselt zelf tussen paneelcomposities. Waartussen je kan wisselen, hangt af van wat op de compositie aangeboden wordt. In Word bijvoorbeeld kun je een document in verschillende views geven: normaal, pagina lay out, overzichtsweergave en outline. Deze views hebben ook onderling iets afwijkende paneelcomposities. Vanuit sommige views kan de gebruiker een andere view kiezen op een klein navigatie-paneeltje (geheel onderaan het scherm).
Bij deze dialoogvorm is een goede navigatie voorziening belangrijk, om de gebruiker niet te laten verdwalen. Oudere hypertext presentaties hadden dit euvel nogal eens: Men volgde link na link en bleek dan de weg kwijt te zijn ('lost in hyperspace'). Op de browser is o.a. de Back en Forward button om deze reden opgenomen: terug te kunnen gaan op het eigen navigatiepad.


Figuur: Netwerkdialoog

 


 

 

 


 

Metaforen

Volgens Webster's dictionary uit 1913 is een matafoor "The transference of the relation between one set of objects to another set for the purpose of brief explanation". Dit drukt ook al redelijk nauwkeurig uit wat het doel van metaforen in de user interface is: Het gebruik maken van voorstellingen en begrippen uit de werkelijke wereld in de user interface, om de functies van een applicatie begrijpelijk te maken voor eindgebruikers. Iconen spelen hierbij een rol, reden waarom we beide aspecten van de user interface in het zelfde hoofdstuk bespreken.

Metaforen in de interface

Het is bekend dat de omgang met de computer al jaren voor veel mensen grote problemen oplevert. Dit geldt zowel voor het besturingssysteem als voor applicatie-software (veel mensen begrijpen niet eens het verschil tussen deze twee). Dit probleem kan benaderd worden vanuit het begrip mentaal model (zie het deel 'Theorie > User Models' over conceptuele gebruikersmodellen): De 'computer' (bedoeld wordt altijd de software die op de computer functioneert) lijkt niet op enig ander bestaand 'ding', dus zijn er geen bestaande aanknopingspunten en dat belemmert het ontwikkelen van een mentaal model erover. Daarbij komt dat de 'computer' zich op heel veel verschillende manieren kan presenteren. De computer is een universeel apparaat, waarvan de werking geheel wordt bepaald door het programma dat erin geladen wordt (het z.g. Von Neumann concept). Het ene moment is het een 'tekstverwerkingsmachine', het andere moment een 'rekenblad', 'woordenboek' etc. Gebruikers hebben dus te maken met een grote functionele verscheidenheid, die in alle andere bestaande gevallen in de werkelijke wereld alleen voorkomen als afzonderlijke apparaten (typemachine, calculator, tv etc.).

Veel beginnende computergebruikers kunnen na verloop van tijd enigszins uit de voeten met een enkele software applicatie. Als men vervolgens met het besturingssysteem in aanraking komt, bijvoorbeeld bestandsbeheer, is de kans op ongelukken groot (bestanden zoek, kwijt, niet opgeslagen etc.). De problemen beginnen opnieuw bij een andere applicatie. Geprobeerd wordt daarom om bij de presentatie van software aan gebruikers metaforen in te zetten die hen in staat te stellen een mentaal model te ontwikkelen. Metaforen komen zeer veel voor. Ze zijn, ongemerkt, al een vast bestanddeel van ons taalgebruik. Zeer frequent worden uitdrukkingen uit de ene context gebruikt om iets in een andere context duidelijk te maken. Bijvoorbeeld gebruiken we militaire taal om de elementen van een discussie te beschrijven: Iemand verdedigt een stelling, die door een ander aangevallen wordt. Men is in een aanvallende of verdedigende positie, en hanteert een bepaalde strategie of taktiek, verliest de discussie etc. Hierbij wordt stelselmatig niet van afzonderlijke termen gebruik gemaakt, maar juist van de samenhang ertussen in de oorspronkelijke context. Een ander (vaak voorkomend) voorbeeld is de context van het zien van objecten. Toegepast op ideeén en concepten: er licht op laten schijnen, helder voorstellen, van meerdere kanten bekijken, oppervlakkig behandelen, etc.

Ook bij software kunnen problemen (deels) opgelost worden door gebruik te maken van bepaalde taalmetaforen. Zo 'halen we mail op' uit onze 'mailbox'. Onzin natuurlijk, want we halen niets op: Er is ergens op een andere computer een file die kan worden gekopieerd naar onze computer, mits de juiste username/password combi wordt opgegeven, beide computers het juiste transportprotocol aanhouden en van het juiste poortnummer op de machines gebruik wordt gemaakt (daarna wist de andere computer de file). Gebruikers kunnen dit proces echter goed begrijpen (mentaal model/surrogaatmodel) als bestaande begrippen als 'mail' en 'mailbox' en 'ophalen' worden gebruikt.

Behalve taalmetaforen bevat de interface veel visuele metaforen. De principes van de Star interface (ontwikkeld in het onderzoekscentrum Xerox Parc) zijn op dit punt beroemd. Deze metafoor baseert zich op objecten uit de kantooromgeving om aspecten van de computer begrijpelijk te maken (zie figuur).

Figuur: Links de Xerox Star 8010 "Dandelion" computer, de eerste computer met een muis. Rechts een voorbeeld van de interface. (Bron: DigiBarn Computer Museum; http://www.digibarn.com/collections/systems/xerox-8010/)

De Apple en Windows interfaces zijn op de Xerox principes gebaseerd. Voor het gehele overzicht wordt de bureaublad metafoor (desktop) gebruikt, waarop diverse taken liggen. Hierop staat de prullebak (waarin we 'documenten' kunnen weggooien, maar ook weer terughalen). Documenten worden weergegeven als een papierblad met een ezelsoor, directories worden als hangmap weergegeven, en het hele bestandssysteem als een archiefkast. Documenten worden opgeborgen in hangmappen i.p.v. in 'directories'.

Documenten zijn natuurlijk files en cynisch genoeg zijn 'files' en 'directories' (folders) ook al metaforen, geleend van de boomstructuur. Feitelijk is er sprake van opslag op een disk, op tracks in bepaalde sectoren, vastgelegd in de FAT (=File Allocation Table) op de disk. Als gebruikers dus denken een document werkelijk verplaatst te hebben naar een andere folder hebben ze het mis als de folder op dezelfde disk staat: Het bestand staat dan nog steeds op dezelfde diskpositie(s), alleen de directory list in de FAT is aangepast.

De kantooromgeving-metafoor wordt in Windows nog steeds behoorlijk ver doorgevoerd: In veel applicaties kunnen we met een vergrootglas inzoomen op het object (tekst, plaatje). Bij de meeste editors wordt gebruikt gemaakt van de metafoor 'knippen en plakken' (Cut and Paste) meestal weergeven met een schaar, om een bepaald stuk (tekst, afbeelding etc.) te verplaatsen. Deze metafoor is overigens minder geschikt om de kleine variant Copy and Paste mee te verbeelden. Merk trouwens het inconsistente gebruik van de metafoor voor zoeken op: In veel applicaties met een vergrootglas aangegeven, in anderen met een verrekijker. Het vergrootglas wordt ook gebruikt voor inzoomen (bijv. in tekenprogramma's). Voor zoeken is dan ook de verrekijker iets geschikter...

Metaforen kunnen betrekking hebben op het geheel, en op afzonderlijke delen of functies. Het zal niet meevallen om een metafoor te vinden die alle aspecten van wat dan ook adequaat kan weergeven, ook niet omdat in software dingen mogelijk zijn die anders niet kunnen. Bijvoorbeeld een bestaand stuk tekst opnieuw opmaken (fonts, pagina-instellingen etc.), documenten comprimeren, kopiëren of attachen aan een mail. Een allesomvattende metafoor is in de regel ook niet nodig: Het is heel goed mogelijk om verschillende metaforen te combineren ('composite metaphor'). Een voorbeeld is de verrekijker voor de zoekfunctie bij editors e.d.: deze komt in de kantooromgeving niet voor maar dat is geen probleem.
Een ander voorbeeld van een 'composite metaphor' is de scrollbar bij documenten. Scrollbare documenten bestaan niet in de kantooromgeving. Dus wordt gebruik gemaakt van een andere analogie: dat van een opgerold document dat je naar boven of naar beneden afrolt om zo het gewenste documentdeel in beeld te krijgen. Overigens: sommige mensen raken hiervan in de war omdat de scrollbar de andere kant op beweegt dan de tekst: Blijkbaar wordt niet een rol afgewikkeld maar wordt het beeldscherm als een venster op een lange papierstrook verplaatst! Hoe dan ook, men kan heel goed verschillende metaforen combineren: De gebruiker beleefd geen contextconflicten en schakelt moeiteloos heen en weer omdat de metaforen niet concreet worden geinterpreteerd of waargenomen.

Verkeerd gekozen metaforen kunnen erg belemmerend werken. Bijvoorbeeld een winkel voorstellen als een concrete afbeelding van een winkel (deuren, schappen met artikelen e.d.), waarbij je telkens verder komt door op objecten te klikken. Hoe geef je de gebruiker orientatie mee? Wat doe je met schappen waar geen plaats is voor alle artikelen? Bij deze keuze loop je al snel vast (zie figuur). Dit probleem heb je al gauw als je teveel wilt realiseren met een enkele metafoor.


Figuur: Voorbeeld van een (muziek) webwinkel, weergegeven d.m.v. een concrete, enkelvoudige metafoor.
Waar staan de CD's? Wat voor winkelvoorwerp is 'Contact Custys'?
Bron: http://www.custysmusic.com/mall/CustysTraditionalMusicShop/index2.htm


Figuur: Voorbeeld van een 'composite metaphor'. Een hyperbolische boom wordt gebruikt om de structuur van een website weer te geven en dient tevens voor navigatie: De bol kan verdraaid worden zodat elk object en diens omgeving beter zichtbaar worden [niet actief image]. (http://www.inxight.com/map/).

 


 

Paper prototyping Bron: IBM Developerworks, http://www-106.ibm.com/developerworks/library/us-paper/?dwzone=usability (Overgenomen juli 2003)

 


IBM developerWorks > Web architecture
developerWorks
Paper prototyping
179 KBe-mail it!
Contents:
What paper prototyping is
How good should the prototype be?
What paper prototyping is (and isn't) good for
Key benefits for designers and developers
Common concerns
Conclusion
Resources
About the author
Rate this article
Related content:
Seven tricks that Web designers don't know
Subscribe to the developerWorks newsletter
developerWorks Toolbox subscription
More dW Web architecture resources
Sure, it's low-tech, but this usability testing method can help you sidestep problems before you write your code

Carolyn Snyder (csnyder@snyderconsulting.net)
President, Snyder Consulting
November 1, 2001

Wouldn't it be great to find out what users (and marketing) want before you start coding? Paper prototyping lets you do just that. While it may seem counterintuitive to test an interface without using a computer, paper prototyping lets you get maximum feedback for minimum effort. After a few usability tests with a paper prototype, you'll have confidence that you're implementing the right thing.

What paper prototyping is
Paper prototyping is a method of usability testing that is useful for Web sites, Web applications, and conventional software. Here's how it works: You first decide on the tasks that you'd like the user to accomplish. Next, you make screen shots and/or hand-sketched drafts of the windows, menus, dialog boxes, pages, popup messages, etc. that are needed to perform those tasks. Then you conduct a usability test by having one or two developers play the role of "computer," manipulating the pieces of paper to simulate how the interface would behave. Users are given realistic tasks to perform by interacting directly with the prototype -- they "click" by touching the prototype buttons or links and "type" by writing their data in the prototype's edit fields. (Using transparency or removable tape prevents the prototype from being written on directly.)

A facilitator (usually someone trained in usability) conducts the session while other members of the development team observe and take notes. The "computer" does not explain how the interface is supposed to work, but merely simulates what the interface would do. In this manner, you can identify which parts of the interface are self-explanatory and which parts are confusing. Because the prototype is all on paper, you can modify it very easily to fix the problems you find.

Figure 1. A paper prototype of the File Setup dialog from Microsoft Word
Figure 1. A paper prototype of the File Setup dialog from Microsoft Word

Figure 1 illustrates how various GUI widgets can be prototyped. This example shows the File Setup dialog from Microsoft Word. (In a usability test, this component would be placed on top of a prototype of the Word application rather than being shown by itself.) Each tab is on a separate piece of paper so it can be moved to the front if the user selects it. The drop-down list for paper size is written on a separate piece of paper and is shown if the user touches the drop-down arrow. The radio button is simulated using removable tape. The preview components (shown in red for purposes of this illustration) are tacked on with restickable glue so they can be changed if the user selects Landscape. (See Resources for more information on where to get removable tape and restickable glue.)

Figure 2. The shopping cart page from an e-commerce site
Figure 2. The shopping cart page from an e-commerce site

Figure 2 shows how removable tape allows users to place any combination of items in the shopping cart. The "computer" can update the shipping cost and total accordingly by wiping them off the transparency with a damp paper towel and rewriting them. (It's not considered cheating for the "computer" to use a calculator!)

How good should the prototype be?
You can use screen shots of an existing design if you happen to have them, but it's also fine to hand-sketch them, especially when you're in the early stages of design. And as Figure 3 shows, sometimes hand-drawn elements are actually more readable than screen shots that use a dark background color.

Figure 3. Hand-drawn versions of browser buttons compared to a grayscale screen shot
Figure 3. Hand-drawn versions of browser buttons compared to a grayscale screen shot

You can also mix and match screen shots and hand-drawn components. The prototype only needs to be good enough for you to get answers to the questions you're most concerned about. Thus, most paper prototypes don't need:

  • Straight lines or typed text. If the user can't read something, it's OK to tell them what it says. (But if the user doesn't understand a term, don't explain it -- change it.)
  • Images or icons. Use words instead. For example, for the company logo, you can just draw a box around the words "company logo." If images are part of the content (a product catalog, for example), you can paste them into your prototype using restickable glue, which allows you to rearrange the page later.
  • Color. As the saying goes, "You can put earrings on a pig, but it's still a pig." Color can't save an inherently flawed design -- do your initial testing with grayscale printouts of screen shots, or sketches using any dark-colored marker. Color can be added later once you're sure you aren't creating a pig.
  • Consistent sizing of components. Unless you've got a small or densely-packed display, don't worry about adhering exactly to a grid. It's OK if components are of varying sizes. For example, perhaps your menu bar and icons came from a screen shot and are relatively small compared to the hand-drawn parts of the screen. You can clarify by saying things like, "This is all one window," if the user seems confused.

It's fine if the prototype looks a bit messy. Very often, the first usability test will show you problems you'd never anticipated, and then you'll want to make changes. Don't spend time making the prototype look neat before you test it -- if it's legible, it's good enough. (For those of you who are thinking, "But I can easily mock up something that looks nice," see the sidebar.)

What paper prototyping is (and isn't) good for
Paper prototyping is especially useful for gathering data about the following kinds of problems:

  • Concepts and terminology. Do the target users understand the terms you've chosen? Are there key concepts they gloss over or misconstrue? (I've seen these types of usability issues in virtually every interface I've ever tested.)
  • Navigation/workflow. If there's a process or sequence of steps, does it match what users expect? Do they have to keep flipping back and forth between screens? Does the interface ask for inputs that users don't have, or don't want to enter?
  • Content. Does the interface provide the right information for users to make decisions? Does it have extra information that they don't need, or that annoys them?
  • Page layout. Although your scribbled screens may not be pretty, you'll still get a sense of whether users can find the information they need. Do you have the fields in the order that users expect? Is the amount of information overwhelming, not enough, or about right?
  • Functionality. You may discover missing functionality that users need, or functionality you'd planned but users don't care about.

On the other hand, paper prototyping isn't ideal if your biggest questions pertain to:

  • Technical feasibility. Paper prototypes don't demonstrate technical capability. It's possible to create a paper prototype that can't actually be implemented. To avoid this, I recommend that there always be at least one person involved who understands the technical constraints.
  • Download time or other response time. Because a person simulates the behavior of the computer, the "response time" is artificial.
  • Scrolling. I've seen some interesting and subtle problems with Web page designs that discourage the user from scrolling either down the page or back up to the top. I wouldn't have found these problems with a paper prototype.
  • Colors and fonts. If you really need to see how something looks on a computer screen, paper prototyping can't show you that. It's a good idea to involve the graphic designer in the paper prototype tests because he may find issues that influence the visual aspects of the final design.

Some development teams use paper prototypes in the early stages to smoke out the show-stoppers, and then do a couple of additional usability tests later with the real interface just to look for any additional surprises.

Key benefits for designers and developers
If you design and/or implement user interfaces, paper prototyping can provide several benefits:

1. Test your design with users before you code
Paper prototypes are ideal for finding out whether you're on the right track, before you write even a line of code. Sometimes the things you learn can have a significant impact on the interface or even the underlying architecture. For example, in testing a prototype of a travel Web site, we learned that users insisted on seeing some information that had to come from the airlines' databases. On one hand, this was bad news because it was technically difficult to get this information. On the other hand, the team learned about this need in time to address it in the first release, or else the site would have failed.

2. Make fast changes
With a paper prototype, you can revise the interface very quickly, even during a usability test. If a term is confusing, you can cross it out and try a different one. You can add an example next to a confusing edit field or a sentence of explanation. Simple changes like these can solve many usability problems. Even when you find the need for more substantial changes, you can often make them in a matter of hours. One team completely redesigned an e-commerce interface in one evening after learning from the first two tests that it had some fundamental flaws. The next day's tests confirmed that they'd fixed the problems.

3. Find out what marketing really wants
It's frustrating to implement something that wasn't quite what your marketing department had in mind. I call this the "Bud Light problem" after a funny series of Budweiser commercials in which someone says, "Bring me a light!" and is then presented with a lamp, flaming torch, fireworks -- anything but a light beer. It's not so funny when you've spent days or months developing the wrong thing. Interface specs -- even with screen shots -- don't solve the Bud Light problem because they don't show the behavior of the system, and they also don't show you what people (especially non-technical people) expect the interface to do. But when you put a paper prototype in front of someone and watch them use it, you'll quickly discover whether it meets their expectations. Invite marketing to your prototyping sessions, and make sure they attend the usability tests.

4. Eliminate technology variables from the usability testing equation
In eight years of usability testing, I've collected a number of "war stories" where technical glitches caused tests to be postponed or cancelled. This was disruptive to the development teams, which were relying on the tests to answer important questions about the interface. But I've never had to abort a usability test due to a problem with a paper prototype. I've even done paper prototyping during a power failure!

Paper prototypes give you complete control over how the interface behaves -- this is useful for short-notice demos as well as usability tests. Paper prototypes don't use databases, networks, servers, or any other form of technology, which eliminates most of the things that can go wrong. You don't have to worry about someone putting a change up on the development server that breaks the very thing you're trying to test (and this also means that development doesn't have to come to a complete stop every time you want to do a usability test).

You may be thinking, "But this is my application. I'm the one writing the code." Yes, but until you're well into the debugging stage, your code (or code written by others that yours depends on) may not be stable enough to allow users to do meaningful work without crashing. Bugs happen -- there's a big difference between the pleasant fantasy of "These ones and zeros obey my every whim" and the painful reality of "I'd be better off if I hadn't come in today." I hope I'm not the only software developer who's ever said that!

Why not just use Visual Basic, HTML, etc.?
There are some inherent advantages that paper prototyping offers over any computer-based prototype, no matter how proficient you are with the tool.

  1. Zero coding effort. While it's possible to mock up a decent-looking interface pretty quickly in VB, Dreamweaver, etc., writing the code to make the interface respond properly to the user's inputs can be time-consuming. With a paper prototype, the time spent coding is zero -- even if you're a real whiz, it's hard to be faster than that!
  2. Avoid nit-picky feedback. A polished-looking design can actually encourage the wrong kind of feedback. If you're trying to make sure you've got the right content and functionality, you may not want to hear comments like, "Hey, those fields don't line up," or "I don't like that shade of green." Paper prototypes avoid that kind of feedback because it's obvious to users that you haven't specified the look yet. This encourages users to focus on the concepts and functionality.
  3. Encourage creativity. Our brains respond more creatively to things that look somewhat unfinished. And users -- especially non-technical ones -- are often less intimidated by paper prototypes than by computers, so they'll feel more comfortable exploring your design.

Common concerns
Even people who recognize the benefits of paper prototyping may have some concerns about the technique. The questions I commonly hear fall into three categories: validity, professionalism, and resources.

1. Validity ("Does it find real problems?")
I'm often asked whether paper prototyping might have bad side effects, either in terms of missing important problems or finding false ones. The short answer is that paper prototyping does find most of the same problems that you'd find by testing the real thing.

To my knowledge, there is only one published scientific study (see Resources) of the validity of paper prototyping. Three researchers at Verizon (formerly GTE Labs) compared the type and number of problems found with a low-fidelity (i.e., paper) prototype as compared to a working prototype. They found that there was a significant degree of overlap between the problems found using the two different methods. Although the working prototypes did uncover a few more problems, they also took significantly longer to develop than the low-fidelity ones -- weeks instead of days. These results indicate that there are diminishing returns from taking the additional time to develop a polished prototype.

My own practical experience backs this up. I have conducted several hundred usability tests of software and Web sites, including more than 100 using paper prototypes. With only a few exceptions, I find the same kinds of problems with both.

2. Professionalism ("What will others think of it ... and us?")
The thought of showing an unfinished -- or even flawed -- design to outsiders makes some developers uncomfortable. Many of us are perfectionists by nature and/or training, and our jobs reward this trait. It's natural to be concerned that others will perceive our work as incomplete or sloppy.

Fortunately, that's not what happens. Users (and coworkers) respond positively to a paper prototype, provided that they've been briefed appropriately. When participants arrive for a usability test, I explain that we know the design has some rough edges (sometimes literally!) but that we want to get their feedback before we've invested a lot of effort to build the wrong thing. I've found that users understand this, and I've never heard a user make a disparaging remark about a paper prototype. On the contrary -- users appreciate knowing that their input is being requested while there's still time to incorporate it.

3. Development resources ("Do we really have time to do this? Is it just extra work?")
Those who have never done paper prototyping (or even usability testing) often overestimate the amount of time it will take. If you're already doing usability testing and only the paper prototype part is new, estimate no more than 1-2 days for prototype creation if you're working mostly from screen shots, and up to a week if it's a new interface or a complete redesign. Any more than a week and you're spending too much time polishing the design before getting user feedback. (The other activities associated with planning, preparing, and conducting a handful of usability tests typically take on the order of a week of hands-on time, spread out over 2-4 weeks.)

Sometimes paper prototyping will uncover planned functionality that doesn't need to be implemented. For example, I once tested a paper prototype of a distance learning Web application. The original design called for users to have avatars to navigate the virtual classroom, raise their virtual hands, etc. In prototype testing, we quickly learned that all this virtual 3D stuff got in the way of the real purpose of the application, which was to enable large companies to provide training to geographically dispersed employees. The designers realized that they were jeopardizing their whole product concept by trying to make the application feel like a video game. They dropped the 3D functionality, which actually shortened their development schedule. This was five years ago, and the product is still around, sans 3D.

Conclusion
It's normal for interfaces to undergo substantial changes between the initial concept and the actual release. No one enjoys writing code that ends up having to be overhauled or scrapped. Paper prototyping lets you find significant problems early in the design process, so you can experiment to find the best solution before investing the effort to implement it.

Resources

About the author
Carolyn Snyder Carolyn Snyder spent the first 10 years of her career as a developer of unusable software. Upon discovering users, she became a usability consultant, spending six years at user interface engineering before starting Snyder Consulting in 1999. She specializes in paper prototyping and usability testing. She's writing a book on paper prototyping and welcomes questions. E-mail her at csnyder@snyderconsulting.net.


179 KBe-mail it!
What do you think of this document?
Killer! (5)Good stuff (4)So-so; not bad (3)Needs work (2)Lame! (1)

Comments?



IBM developerWorks > Web architecture
developerWorks
  About IBM  |  Privacy  |  Legal  |  Contact

Bron: IBM Developerworks, http://www-106.ibm.com/developerworks/library/us-paper/?dwzone=usability (Overgenomen juli 2003)

 


 

Scenario's & Use Cases

Wat zijn scenario's?

Scenario's zijn heel korte beschrijvingen (bij voorkeur in een enkele zin) van potentiele praktijksituaties, vanuit een gebruiker bezien. Essentieel is het doel wat de gebruiker heeft. Scenario's worden gemaakt om de functionaliteit van het programma op een informele wijze te inventariseren. Het gaat bij scenario's om de toekomstige, gewenste, situatie: Op deze wijze wordt de variëteit van het toekomstige programma in beeld gebracht. Uiteraard kan hierbij ook de huidige situatie een rol spelen: Scenario's formuleer je op basis van de huidige situatie (bijvoorbeeld vastgelegd in taakanalyses), de gewenste situatie (omschreven in de opdracht) en gezond verstand. Als er voldoende scenario's zijn worden deze gegroepeerd in z.g. Use Cases. Ook kunnen dan de globaal verwoorde 'wensen en eisen' in de opdracht worden omgezet in nauwkeurig geformuleerde programmaspecificaties. Het door middel van scenario's vastleggen van de variëteit is dus een belangrijke stap in het ontwikkelproces.

De bestanddelen van elk scenario zijn 1. een gebruiker (welke?), 2. een doel dat de gebruiker heeft, en 3. vaak ook een soort omschrijving van de beginsituatie. Een scenario richt zich op het wat (doel) en niet op hoe dit bereikt moet worden: Het hoe en de probleem-situaties die de gebruiker daarbij kan tegenkomen worden in een later onywikkelstadium bekeken.
Onderstaand een voorbeeld van een reeks scenario's uit een project (Tide) m.b.t. een electronische studentagenda.

Student calendar is a calendar that can be used by a student to plan and manage her schedule.
  1. I have Linear Algebra I lectures on Thursdays 12-14 and I want to put them in my calendar for the whole semester.
  2. I usually wake up late in the morning so I donít usually need to see my whatís in my calendar before 10 am.
  3. I want to put Data Structures lectures, which are on Thursdays at the same time as Linear Algebra I lectures, in my calendar.
  4. I notice that there is something in my calendar next Tuesday early in the morning and Iíd like to see quickly what it is.
  5. My friend has found a new job and we want to go out and celebrate it so I need to see next three weeks in my calendar including weekends.
  6. My cousin has a birthday in two months. I wonder if I have put that in my calendar already.
  7. Next weeks User Interfaces lecture has been cancelled.
  8. This week User Interfaces lecture will last an hour longer because next weeks lecture was cancelled.
  9. My friend got married one month ago and I want to put the wedding day in my calendar so I will remember to congratulate her next year.
  10. We have been talking about going on a cruise with friends and I need to see if there are any weekends free during next couple of months.
  11. Meeting with the seminar group on Thursday 15.30 is very important.
  12. There is usually a lot of action on Thursdays so Iíd like it if there were more room for my markings on that day.
  13. I want to see three Wednesdays, which are not on sequential weeks because a meeting must be scheduled on one of them.
  14. I have a project meeting on 14th Tuesday and I need a lot of material with me so Iíd like to put the meeting and a list of the material as a reminder in my calendar.
  15. Itís Tuesday and I need to see the list of everything I need so I can be sure I have everything with me.
  16. Thursdayís seminar group meeting has been moved to Friday 14.00.
  17. I promised to go and visit my grandparents on Saturday afternoon.
  18. There is another seminar group meeting two weeks from now on Tuesday, but was it at 13.00 or 14.00?

Wat is een Use Case?

Use Cases hebben een centrale plaats in de huidige systeemontwikkeling. De diagramtechniek is opgenomen in UML (Unified Modeling Language). Scenario's en Use Cases zijn nauw gerelateerd: Scenario's worden al lang gebruikt om systeemvereisten te achterhalen en Use Cases zijn in zekere zin hier het vervolg op. Het schrijven van scenario's is een informele benadering, die niet in een methodologie verankerd ligt. Ivar Jacobson heeft hierin verandering gebracht. Zijn naam voor scenario is 'Use Case' en de definitie in zijn boek 'Object-Oriented Software Engineering' (1994) luidt:

A Use Case is a sequence of transactions in a system, whose task is to yield a measurable value to an individual actor of the system.

Fowler (1997) gebruikt een informelere beschrijving:

A Use Case is a typical interaction that a user has with the system in order to achieve some goal. Imagine the word processor that I am currently using. One Use Case would be 'make selected text bold'; another would be 'create an index for a document'.

Uit de bovenstaande termen 'transactions', 'measurable value', 'typical interaction' en 'some goal' is niet direct duidelijk wat de scope van een Use Case is. In de praktijk kunnen ze behoorlijk in grootte verschillen. De sleutel is dat een Use Case een afzonderlijke systeemfunctie is, gezien vanuit de gebruiker. Met systeemfunctie bedoelen we systeemgedrag, in relatie tot een gebruikersdoel. Cockburn (2001) zegt het zo:

A Use Case captures a contract between the stakeholders of a system about its behavior. The Use Case describes the system's behavior under various conditions as the system responds to a request from one of the stakeholders, called the primary actor. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, protecting the interests of all the stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the particular requests made and the conditions surrounding the requests. The Use Case gathers different scenarios together.

Hoe identificeer je Use Cases?

Sommige auteurs maken onderscheid tussen 'essential Use Cases' en 'system Use Cases'. Een essential Use Case (ook wel 'business Use Case' of 'abstract Use Case' geheten) is technologie- en implementatieneutraal en richt zich alleen op de gedragsaspecten. Een system Use Case (ook wel 'concrete Use Case' of 'detailed Use Case' genoemd) beschrijft ook in detail hoe gebruikers met het systeem interacteren, inclusief referenties naar aspecten van de user interface.
Wij richten ons uitsluitend op 'essential Use Cases'.

Use Cases kunnen op meerdere manieren verkregen worden, maar de methode die we in ons project gebruiken sluit aan bij de laatste zin in Cockburn's beschrijving: Een Use Case bundelt mogelijk meerdere scenario's. Eerst hebben we meerdere informele scenario's, geformulereerd. Uses Cases verkrijgen we door vervolgens de scenario's waar mogelijk te groeperen op overeenkomstige kenmerken (actor, doel, systeemgedrag etc.). Als een Use Case uit meerdere scenario's bestaat, is er sprake van een bepaalde variëteit. In zo'n geval bepaal je het belangrijkste scenario (het 'main success scenario') en beschouw je de rest als afwijkingen hiervan. In UML heet dit dat de Use Case meerdere 'realisaties' heeft; deze worden in de Use Case zelf met 'extensions' aangeduid.

Het is belangrijk te realiseren dat scenario's altijd positief geformuleerd zijn: er is een doel dat bereikt wil worden. In de praktijk ontstaat ook variëteit doordat doelen mislukken (bijv. een aankoop mislukt omdat het saldo op de creditcard ontoereikend is). Het is niet nodig, zelfs ongewenst, om in dit stadium allerlei soorten van mislukte uitkomsten als extra scenario's op te nemen. Dit gebeurt in latere ontwikkelstappen. Toch zijn er soms gevallen waarin dit toch relevant is. Alleen die worden opgenomen in een Use Case. In onderstaande stappenbeschrijving wordt hierop verder ingegaan.

Het groeperen van scenario's tot een Use Case op basis van overeenkomstige kenmerken wordt hieronder beschreven. In de eerste stap zijn dat de gebruikers, in de volgende stap de doelen, enzovoorts. Let er op dat het mogelijk is dat de verworven scenario's toch niet het gehele te ontwikkelen systeem beschrijven. Daarom moet bij onderstaande stappen ook het gezonde verstand gebruikt worden: welke algemene kennis over het systeem heb je, is logisch af te leiden of blijkt uit de opdracht?

  1. Begin bij de 'primary actors
    Een actor is iedereen of alles dat een actieve rol met het systemen heeft: mensen, machines en organisaties. Wie zal het systeem in die zin gebruiken? Probeer hierbij te generaliseren. Heb je 4 verschillende kopers? Dat heb je één actor: koper (hun rol is 'kopen'). Bedenk dat het woord 'actor' een actieve betekenis heeft. Een systeem dat bij een Use Case betrokken is omdat het iets registeert, of geraadpleegd wordt, is geen actor.
    Groepeer de scenario's op basis van de actoren (rollen). Ga na of er voor elke actor scenario's zijn. Mogelijk heb je deze al, maar zeker is dat nooit omdat scenario's niet systematisch worden geproduceerd. Dit geldt ook bij de volgende stappen: Ontbreken de scenario's, maak deze dan alsnog erbij.
  2. Identificeer duidelijk afgebakende doelen
    In deze stap vraag je jezelf af wat de actoren doen om hun rol te vervullen. Een student op de universiteit zal naast 'inschrijven op een cursus' ook het volgende willen doen: 'cursus afbreken', 'beurs aanvragen', 'cursusgeld betalen', 'inschrijven op tentamen', 'studievoortgangsoverzicht opvragen' e.d. Op deze wijze kom je op het spoor van de verschillende 'systeemfuncties' of 'services'. Dit zijn goede kandidaten voor een Use Case. Je kunt ook zeggen 'studeren aan de universiteit', maar dat is te globaal om een Use Case het zijn. Andersom moet je ook oppassen op veel te kleine services uit te komen. Hanteer hiervoor het volgende hulpmiddel:
    A Use Case describes something the designer can be proud of, and the customer is willing to pay for.
    (Uit Rubin (1998), p.24)
    Zoek uit welke doelen er zijn en groepeer de scenario's per actor per doel. Als voor een bepaald doel geen scenario's zijn gemaakt is het nuttig deze bij te maken om alsnog de mogelijke variëteit in beeld te krijgen.
  3. Zoek een startpunt: een trigger of een event
    Iets moet gebeuren om het systeem aan de gang te zetten, en dat iets wordt meestal uitgevoerd door de actor. De enige uitzondering die je zou kunnen maken zijn de 'time triggers', alhoewel hier ook een 'primary actor' is: het systeem dat de boel aan de gang zet. Bijvoorbeeld 'elke dag om 23:00 uur .. [backup maken]'. Wij hebben echter te maken met menselijke gebruikers. Verdeel de groepjes scenario's verder op basis van overeenkomstige startpunten.
  4. Bepaal stakeholders, hun belangen, precondities
  5. Bepaal het 'main success scenario'
    Op dit punt heb je alle bestaande scenario's gesorteerd in afzonderlijke Use Case kandidaten, elk uit één of meer scenario's bestaande. Heb je meer scenario's dan bepaal je welk scenario in de Use Case het belangrijkst is: Dit is het main success scenario. De andere scenario's zijn de variéteit hierop, de z.g.'extensions'.
    Het main success scenario moet nu worden uitgewerkt in afzonderlijke stappen (decompositie van het verloop). Dit wordt niet altijd eenvoudig gevonden. Goede aandachtspunten zijn: Uiteindelijke heeft elke Use Case twee aflopen: een 'fail' en een 'success'. Zoals hierboven gesteld is, werken we in principe alleen de goede afloop uit (het 'happy path'). Controleer de succes voorwaarde: of de belangen van alle stakeholders vervuld zijn.
  6. Verzamel de extensions
    Verwerk de overige scenario's in de extensions. Bepaal voor elke extension hoe de actors handelen. Zoek ook naar alternatieve succespaden en verwerk deze mede in de extensions. Een voorbeeld van een alternatief succespad is: 'koper heeft account, creditcard transactie kan overgeslagen worden'. De conditie plaats je aan het begin van de extension, gevolgd door de systeemstappen. Bijv. '3a. koper heeft account: zet bedrag op rekening en stuur bevestigingsnota'. Gebruik geen 'als ....' in het main success scenario.
  7. Let op sub Use Cases
    De mogelijkheid bestaat dat je op een Use Case stuit binnen de Use Case. Bijvoorbeeld omdat dit zich in meerdere Use Cases voordoet. Zo'n sub Use Case modeleer je er dan uit. Dit zie je in voorbeeld 1 in extension 5a1: ".. has the purchaser update questioned purchase".

Termen gebruikt in Use Cases

De betekenis van de termen die we in Use Cases gebruiken zijn:

Scope
Een aanduiding van het systeem dat we bespreken. Dit behandelen we als een 'black box'. Dit wil zeggen dat we niet geinteresseerd zijn hoe het binnenin functioneert. We interacteren ermee (geven het input) en dat heeft een bepaald resultaat (output).
Level
Zegt iets over het doel (hoog, laag). Dit is een globale aanduiding. Cockburn (2001) gebruikt twee levels: 'user goal' en 'summary level'. Het eerste is iets wat een enkele gebruiker nu nodig heeft. Bij het tweede zijn meerdere gebruikersdoelen aan de orde; de Use Case zal in de regel meer tijd in beslag nemen (uren, dagen etc.).
Stakeholder
Iets of iemand die met een belang betrokken is bij het systeem. In HCI denken we al snel aan personen, maar het kan ook een ander systeem zijn. Let erop dat je geen rangen of concrete personen e.d. opvoert ('generaal McArthur'). Het gaat om rollen (een rol bundelt een of meer taken / activiteiten) of instanties. Bijvoorbeeld: directie, inkoper, verkoper, klant, agentschap, overheid, controle-orgaan.
Actor
Een stakeholder (iets of iemand) die een actie kan uitvoeren.
Primary actor
De stakeholder die de interactie met het systeem start om een doel te bereiken. In HCI-termen: 'de persoon achter het beeldscherm'.
Een primary actor interacteert met het systeem. Hij/zij/het heeft een doel. Vanuit het systeem bezien komt het doel overeen met een enkele functie of een service.
Trigger
De 'event' die ervoor zorgt dat de Use Case start. Kan ook weergegeven worden als de eerste stap in het Use Case scenario.
Preconditions and postconditions (minimal / success guarantee [=measurable value])
Waaraan voldaan moet zijn resp. voor en na het verloop van de Use Case. Preconditions zijn niet vrijblijvend. Postconditions moeten met het doel stroken.
Main success scenario
Het 'happy path': het scenario waarin niets verkeerd gaat.
Extensions
De varieteit in het 'main success scenario'

Format van een Use Case

Een Use Case is primair een stuk tekst die je met de opdrachtgever communiceert. Er is verschil tussen het soort proza dat je in vrije beschrijvingen aantreft en de tekst in Use Cases. Deze laatste heeft een standaard indeling en opmaak en bevat uitsluitend korte uitdrukkingen. Alleen op deze wijze kan het gecontroleerd worden op consistentie en volledigheid. Bijvoorbeeld bevat het in stappen uitgewerkte scenario eenvoudige zinnen met telkens dezelfde structuur: Een actor die een stap in de actiereeks uitvoert (zie de voorbeelden hierna).

We gebruiken de volgende vaste template voor Use Cases:
Titel Enkele woorden of één zin. De bestanddelen zijn een werkwoord en het doel van de primaire actor. Bijvoorbeeld: een document index creeren
Samenvatting Kort! Een bruikbaar format is aan te geven wat de trigger, actie en het resultaat zijn.
  1. Deze Use Case begint met ....
  2. Deze Use Case doet ....
  3. Deze Use Case eindigt als/met ...
Primaire actor Een primaire actor vertoont gedrag en heeft een doel
Scope Het systeem dat je aangeeft bepaalt ook de grenzen van het werk: Niets wat erbuiten is, is onderwerp van bespreking.
Level Controleer een gebruikersdoel aan de 'coffee break test'. Kan de gebruiker een pauze nemen als het doel bereikt is?
Precondities Zijn de precondities dwingend? Spelen ze in de Use Case verder geen rol meer als conditie?
Stakeholders en hun belangen De genoemde belangen van de stakeholders moeten geheel en alleen te maken hebben met de Use Case.
Minimum uitkomst
(Minimal guarantee)
Met alle stakeholders belangen moet rekening gehouden zijn.
Succes voorwaarde
(Success guarantee)
Alle stakeholders belangen zijn vervuld.
Hoofdscenario
(Main success scenario)
Een scenario bestaat uit 3-9 stappen (liefst niet meer). Het loopt vanaf (inclusief/exclusief) de trigger tot en met de 'succes garantie'.
Voor elke stap in het scenario geldt:
  • het staat mogelijke variaties in opeenvolging toe;
  • het heeft een duidelijk doel;
  • het is duidelijk welke actor de doel-eigenaar is;
  • het doel is een subdoel van het doel van de Use Case;
  • de volgende stap is logisch vanuit het bereikte doel;
  • een stap beschrijft op geen enkele wijze het user interface ontwerp;
  • het is duidelijk welke informatie wordt uitgewisseld;
  • er wordt gevalideerd.
Subscenario's
(Extensions)
Extensions ontstaan doordat een bepaalde conditie 'waar' is. De conditie moet door het systeem gemeten en behandeld kunnen worden.
Nummer de extensions vanuit de stap (bijv. 3a, 3b of 3.1, 3.2). Niet alles wat mogelijk is hoeft ook. Ga na of een extension iets bijdraagt aan de werking van het systeem.

Dit format is niet dwingend. Afhankelijk van de aard van de Use Case voeg je aspecten toe, of laat je enkele weg. Uiteraard zijn 'primary actor', 'main success scenario' e.d. de harde kern die zelden gemuteerd zal worden.

Voorbeeld 1 (alleen bij wijze van voorbeeld inclusief falende aflopen!)

In onderstaande twee voorbeelden lijkt het of het main success scenario niet conform de aanwijzingen is uitgewerkt: de actor in de verschillende stappen is beurtelings de gebruiker en het systeem, terwijl aangegeven is de stappen vanuit de gebruiker te noteren. Soms is het echter ook goed om dingen die het systeem doet mee te nemen, bijvoorbeeld omdat het informatief is over een wijziging op het beeldscherm, of een aanwijzing is voor een foutconditie die later uitgewerkt moet worden. Belangrijk is wel in hoofdzaak vanuit de gebruiker te blijven denken m.b.t. de opeenvolgende stappen. Als het main success scenario later wordt uitgewerkt tot het storyboard (d.i. een reeks schetsen van beeldschermtoestanden) zal blijken dat in de regel alleen de gebruikersstappen relevant zijn.

Title: Buy Stocks over the Web
Summary:
  1. The Use Case begins when a Personal Advisor / Finance package (PAF) open
  2. The Use Case shows the user browsing and buying stocks
  3. The Use Case ends with an updated user's portfolio
Primary Actor: Purchaser
Scope: Personal Advisors / Financial package (PAF)
Level: User goal
Stakeholders and interests:
Purchaser - wants to buy stocks and get them added to the PAF portfolio automatically.
Stock agency - wants full purchase information.

Precondition: User already has PAF open.
Minimal guarantee: Sufficient logging information will exist so that PAF can detect that something went wrong and ask the user to provide details.
Success guarantee: Remote web site has acknowledged the purchase; the logs and the user's portfolio are updated.
Main success scenario:
1. Purchaser selects to buy stocks over the web.
2. Purchaser enters name of web site to use (E*Trade, Schwab, etc.).
3. PAF opens web connection to the site, retaining control.
4. Purchaser browses and buys stocks from the web site.
5. PAF intercepts responses from the web site and updates the purchaser's portfolio.
6. PAF shows the user the new portfolio standing.
Extensions:
2a. Purchaser wants a web site PAF does not support:
2a1. System gets new suggestion from purchaser, with option to cancel Use Case.

3a. Web failure of any sort during setup:
3a1. System reports failure to purchaser with advice, backs up to previous step.

3a2. Purchaser either backs out of this Use Case or tries again.

4a. Computer crashes or is switched off during purchase transaction:
4a1. (What do we do here?)

4b. Web site does not acknowledge purchase, but puts it on delay:
4b1. PAF logs the delay, sets a timer clock to ask the purchaser about the outcome.

5a. Web site does not return the needed information from the purchase:
5a1. PAF logs the lack of information, has the purchaser update questioned purchase.


(De onderlijning betekent een verwijzing naar een andere Use Case).
(Voorbeeld op basis van Cockburn, 2001, p.4)

Voorbeeld 2 (alleen bij wijze van voorbeeld inclusief falende aflopen!)

Title: Enroll in Seminar
Summary:
  1. The Use Case begins with a student who wants to enroll in a seminar
  2. The Use Case registers and verifies the student data
  3. The Use Case ends with an enrollment confirmation and a billed student
Primary Actor: student
Scope: University Course Catalog System
Level: Summary
Stakeholders and interests:
Student - who wants to enroll in a seminar

University - wants to validate the student is eligible to enroll in the seminar, the seminar fits into the students's existing schedule, and that the student is billed.
Precondition: The student is registered at the University and wants to enroll in a seminar.
Minimal guarantee: Student receives a confirmation.
Success guarantee: The student will be enrolled in the course she wants and is billed for.
Main success scenario:
  1. The student submits his name and student number.
  2. The system verifies the student is eligible to enroll in seminars at the university according to business rule 'BR129 Determine Eligibility to Enroll'.
  3. The student indicates the seminar in which she wants to enroll.
  4. The system verifies the student is eligible to enroll in the seminar according to business rule 'BR130 Determine Student Eligibility to Enroll in a seminar'.
  5. The system validates the seminar fits into the existing schedule of the student, according to the business rule 'BR143 Validate Student Seminar Schedule'.
  6. The system calculates the fees for the seminar, based on the fee published in the course catalog, applicable student fees, and applicable taxes. Apply business rules 'BR180 Calculate Student Fees' and 'BR45 Calculate Taxes for Seminar'.
  7. The system informs the student of the fees.
  8. The system verifies the student still wants to enroll in the seminar.
  9. The student indicates he wants to enroll in the seminar.
  10. The system enrolls the student in the seminar.
  11. The system adds the appropiate fees to the student's bill according to business rule 'BR100 Bill Student for Seminar'.
  12. The system provides the student with a confirmation that he is enrolled.
Extensions:
2a. The student is unknown to the system
2a1. The system informs the student

2a2. System backs up to the previous step

9a. The student indicates he wants not to enroll in the seminar
9a1. (etc.)


(Voorbeeld op basis van Ambler, 2001, p.54)

Use Case diagram

Alle geidentificeerde Use Cases worden in een Use Case diagram weergegeven. Dit diagram geeft de samenhang tussen de verschillende Use Cases weer. Het diagram is een onderdeel van UML (Unified Modeling Language). Dit diagram toont de externe actoren, de systeemgrens (-omvang), de verschillende Use Cases (als een ellips) en bevat 'communicatie' lijnen die actoren aan ellipsen, of ellipsen onderling verbinden. Het nut van het Use Case diagram is om in een enkele afbeelding de gehele behandelde context zichtbaar te maken.
Zie hiervoor verder in de officiele OMG specificatie (Use Case diagrams onder 'Theorie').

 


 

User Interface componenten

User Interface-componenten zijn panels (ned: paneel) en de interface-elementen hierop. Panels zijn vlakken op het beeldscherm. Een window kan een enkel panel bevatten, maar kan ook opgebouwd zijn uit afzonderlijke panels. Tesamen noemen we dit de paneelcompositie. Interface-elementen zijn interactie-elementen (widgets) en niet-interactieve elementen (cues). De Microsoft benaming voor een widget is control.

Interface Panels

Van der Harst en Maijers (1999) onderscheiden vijf soorten interface panels:

Overzichts-paneel

Dit is een primair paneel waarin de gebruiker objecten ziet waarmee een bepaalde actie kan worden begonnen. In het voorbeeld hieronder zijn dat de diverse objecten in het 'control panel' van Windows. Ook de folders en disks in het linker paneel van de 'Windows Explorer' is een voorbeeld. Bekijk je dit document in pdf format in de acrobat viewer, dan zie je links een overzichtspaneel waarop je kunt klikken op een hoofdstuk of paragraaf. Een overzichtspaneel is dus meer dan de weergave van een lijst o.i.d.: Er kan een actie worden gestart (het z.g. 'select-then-operate') mechanisme.

Detail-paneel

Dit zijn panelen die van een aspect van de pagina gedetailleerd weergeven, zoals alle gegevens (meer dan in het overzichtspaneel staan) van een geselecteerd artikel. Kiest men bijvoorbeeld in de bibliotheekcatalogus op het 'verkorte titelscherm' (10 titels met alleen auteur en verkorte titel) er een uit, dan verschijnen op het detailpaneel alle boekgegevens zoals auteur, volledige titel, jaar van uitgave etc. In onderstaand voorbeeld van een mailprogramma zijn er twee overzichtspanelen en een detailpaneel (dat de inhoud van een mail bevat).

Commando-paneel

Dit zijn panelen waarop commando's gegeven worden en (wanneer relevant) de bijbehorende parameters ingesteld worden. Bijvoorbeeld 'zoek en vervang' met de parameters 'alle voorkomens ja/nee', 'zoekterm', 'vervangterm', 'case-gevoelig ja/nee', etc. Een ander voorbeeld vinden we  aan het eind van het belastingformulier: twee buttons met resp. 'aangifte opslaan' en 'aangifte verzenden'. Onderstaand paneel komt uit de settings van Windows, waar het getalformaat aan de eigen 'locale' aangepast wordt:

Boodschap-paneel

Dit zijn de waarschuwingen, foutmeldingen en dergelijke. 'Bestand wissen?' OK / Cancel.

Navigatie-paneel

Dit type paneel geeft de gebruiker de nodige bewegingsvrijheid tussen interface-panelen en/of paneelcomposities. Bijvoorbeeld de tabs bovenaan een 'stapeltje' panels.

Interface elementen: controls (widgets) en cues

Van der Harst en Maijers onderscheiden in hun 'platformonafhankelijk referentiemodel' 24 soorten interface-elementen (controls en cues). Afhankelijk van de doelapplicatie (windows applicatie of browser) krijgen die een bepaalde specifieke uitwerking. Een 'text box' bijvoorbeeld kennen we in de browser alleen als 'text field' (enkele invoerregel van toetsenbord karakters ). In een windowsapplicatie zijn meerdere varianten mogelijk, bijvoorbeeld voor invoer van europees en arabisch gemengd (Bidi).
Groep Interface-elementen
Overzichtscontrols List view
Tree view
Cell view
Canvas
Tekstinvoercontrols Text box
Multiple-line text box
Numerieke invoercontrols Spin box
Slider
Meervoudige selectiecontrols Multiple-selection list box
Check box
Enkelvoudige selectiecontrols List box
Drop-down list box
Radio button
Image map
Multimedia cues Image
Sound
Movie
Cues Label
Formatted text
Separator
Group box
Progress indicator
Navigatiecontrols Tab control
Command button
Figuur: Overzicht interface-elementen
Uit: Computable 40, 8 oct 1999.

Controls (widgets)

Een control stelt een gebruiker in staat een commando (user action) te geven. De meeste interface-elementen zijn controls. Van der Harst en Maijers onderscheiden 24 verschillende soorten, die representatief zijn voor de meeste windows- en browserapplicaties. In de praktijk bestaan nog veel meer controls. Met name in hoog-interactieve leersystemen komen nog tal van andere types voor; deze laten we hier verder buiten beschouwing.

Naast dit overzicht zijn voorbeelden van controls en cues in overvloed te vinden in de Windows/Apple/Java Interface Guidelines, waarvan de links op de websites pagina staan.
Short-term memory
Bij controls hebben we te maken met het kortetermijngeheugen (STM, short term memory). Hierbij wordt vaak gerefereerd aan Miller's Law, c.q. het "magische getal" 7 plus of min 2. Volgens Miller is het STM bij kortdurende presentatie van informatie niet in staat om meer dan 7 (± 2) items vast te houden. Overigens is dit een paar jaar geleden door de cognitieve psycholoog Nelson Cowan weerlegd: Hij heeft aangetoond dat het kortetermijngeheugen doorgaans niet verder komt dan 4. Is het meer, dan is vrijwel altijd sprake van 'chunking'. De definitie voor 'item' is een chunk (brok) (zie ook de theorie-aanvulling 'cognitie'). Of het nu 7 is, of 4 of iets er tussen in: Het STM is relevant bij alle vormen van informatie-presentatie, dus ook bij de presentatie van keuzes in een aantal van onderstaande controls.

Groep: overzichts controls

Interface-element: list view
Gebruik: Lijst gestructureerde gegevens (elke regel dezelfde attribuut structuur).
Geordend op basis van een van de attributen
Voorbeeld: Tabel. Gebruikelijk is de keuze voor sortering per kolom.

Interface-element: tree view
Gebruik: Hierarchische weergave. Tree nodes weergegeven d.m.v. tekst en/of icon.
Een niveau in de hierarchie <= 8 delen. Tree diepte <= 4 niveaus diep. Gebruiken bij > 16 keuze-opties
Voorbeeld: File explorer Windows

Interface-element: cell view
Gebruik: Spreadsheet
Voorbeeld: Een cel van een spreadsheet (bijv. Excell)

Interface-element: canvas
Gebruik: Vrij object; bevat image, diagram, tekst etc.
Maximum aantallen voor codering:
Voorbeeld:

Groep: Tekstinvoer controls

Interface-element: text box
(HTML/Java: text field)
Gebruik: Single line text invoer met 'on the spot' editing (wissen, backspace, cursor/caret verplaatsing e.d.).

Gebruik een label links van de box, zelfde hoogte als invoer.
Indien meerdere text fields onder elkaar staan: rechte linker kantlijn.
Gebruiken voor relatief korte invoer (enkele woorden, getallen e.d.)

Voorbeeld:
Auteur

Interface-element: Multiple-line text box
(HTML/Java text area)&
Gebruik: Multiple-line text invoer met 'on the spot' editing (wissen, backspace, cursor/caret verplaatsing e.d.).
Scroll bars wanneer invoer de box afmeting overschrijdt.

Gebruik een label boven de box, links uitgelijnd.

Voorbeeld: Constitution

Groep: Numerieke invoercontrols

Interface-element: spin box
Gebruik: Stapgrootte afstemmen op benodigde precisie.
Gebruik een label
Voorbeeld:

Interface-element: Slider
Gebruik: Horizontaal of vertikaal.
Aan uiteinden minimum en maximum waarden tonen.
Voorbeeld:

Groep: Meervoudige selectie controls

Interface-element: multiple-selection list box
Gebruik: Hoogte: min 5 items zichtbaar; max.: denk aan 7(+/-2). 
Breedte is breedste item (erg brede items afkorten): voorkom horizontale scrollbar.

Identiek aan single-selection listbox, behalve dat de gebruiker d.m.v. Ctrl+<click> om meerdere list items (html: 'options') selecteert.

Voorbeeld:

Interface-element: check box
Gebruik: Maximum 6-7 keuzes. 
Zg. OR-selectie.: 0..6 keuzes uit 1..6 opties

Opties onder elkaar zetten en links uitlijnen.

Voorbeeld:

Groep: Enkelvoudige selectie controls

Interface-element: list box
Gebruik: Een (soms nul)  keuze uit 5..16 opties

Dit voorbeeld is een pop-up listbox in MS-Windows (context gevoelig menu d.m.v. rechter muisklik). Dit heeft nooit een scrollbar. 
Zie verder multiple-selection listbox.

Voorbeeld:

Interface-element: drop-down list box
Gebruik: Gebruiken wanneer er 3-100 items gekozen kunnen worden.
In ingeklapte toestand even breed als uitgeklapt.
Voorbeeld:
(ingeklapt)
(uitgeklapt)

Interface-element: radio button
Gebruik: OF/OF (XOR)-selectie: 1 keuze uit 2..6 opties.
Voorbeeld:

Interface-element: combo box
Gebruik: Combinatie van tekstinvoer en listbox. Invoer voor opgeven nieuwe waarde of springen naar waarde in lijst.
Voorbeeld:

Interface-element: image map
Gebruik: Klikken op een bepaald punt ('hot spot') op een afbeelding (bijv. plattegrond).
In HTML ook 'regions' met een bepaalde shape (rect, circle, e.d.). De gebruiker moet door oplichten of een 'handje' weten dat de muis zich op een hot spot bevindt.

Groep: Navigatie controls

Interface-element: tab control
Gebruik: Zet tabs bij voorkeur op max. 1 regel.
Max. aantal tabs: 'in principe' 8
Maak alle tabbladen even breed. De breedtes van de tab controls zelf varieren in de regel door het opschrift. Heb je meerdere tab-regels, dan ontstaat een warrige layout m.b.t. de vertikale uitlijning.
Zet de command buttons (OK, Cancel) altijd onder de tabbladen, en nooit erop: anders is onduidelijk of de actie ook betrekking heeft op de instellingen die op andere tabbladen zijn doorgevoerd, of de dialog afsluit of niet, etc.
Voorbeeld:

Interface-element: command button
Gebruik: Voor navigatie en commando's.
Zet i.g.v. een commando het werkwoord in onbepaalde wijs op de button. Bijv. 'Afsluiten', 'Afdrukken' (niet 'druk af').
Gebruikelijk is met twee puntjes.. achter het werkwoord aan te geven dat er nog een dialoog (in een commadopaneel) volgt.
Voorbeeld:

Cues

Cues zijn interface elementen zonder interactie.
Interface-element: label
Gebruik: Alle labels identiek lettertype en -grootte. Bij voorkeur schreefloze letter (zoals Arial).
Voorbeeld:
Zie label in group box

Interface-element: formatted text
Gebruik: div.
Voorbeeld:
Bijvoorbeeld woorden in bold of een 'pretty print' met inspringende linkerkantlijn (zoals hier)

Interface-element: separator
Gebruik: visuale scheider 
(HTML: Horizontal Ruler)
Voorbeeld:

Interface-element: group box
Gebruik: Kader voor het groeperen van elementen. Per interface panel max. 4 group boxes.
Voorbeeld:

Interface-element: progress indicator
Gebruik: Laat gebruiker d.m.v. 'verplaatsing op schaal' weten dat er 'iets gebeurt'. De indicatie hoeft niet nauwkeurig te zijn.
Voorbeeld:

Groep: Multimedia cues

Cues ter ondersteuning van de interface.

Interface-element: image
Gebruik: Eenheid van kleurgebruik en stijl indien meerdere cues aanwezig. Herkenbare plaatjes.
Voorbeeld:

Interface-element: sound
Gebruik: Geluid ter verduidelijking van de interface.
Alleen gebruiken als het nodig/nuttig is.
Voorbeeld:
Error beep, window close e.d.

Interface-element: movie, animatie
Gebruik: Zorg voor controls e.d. om movie te stoppen.
Voorbeeld: Hulp agent

 


 

Conceptuele modellen bij gebruikers

Inleiding

Gebruikers die omgaan met apparatuur, situaties e.d. ontwikkelen daaraan een conceptueel model: Al doende leert men. In de literatuur vinden we conceptuele modellen aangeduid als mentaal model en als user model. Hierna wordt verder de term user model gebruikt en beperkt de bespreking zich tot user models in relatie tot apparaten (m.n. software-applicaties).

Een user model bevat in meerdere mate kennis over hoe iets functioneert, en in mindere mate hoe het structureel in elkaar zit. Zo'n model ontstaat op vier manieren:

Mensen gebruiken user models automatisch. Op het moment dat je begrijpt hoe een waterkraan werkt ('je er een user model aan ontwikkeld hebt'), handel je als vanzelfsprekend in vergelijkbare situaties: de volumeregelaar van je versterker open draaien, de knop op het gasfornuis etc. Deze werken allemaal identiek: hoe verder je naar rechts draait hoe meer gevolg dat heeft. User models hoeven echter geen getrouwe weergave te zijn van de werking van een systeem. Zelfs gebrekkige voorstellingen zijn goed mogelijk – zelfs veel voorkomend. Zo gebruikt de meerderheid van de mensen slechts een minderheid van de mogelijkheden van tekstverwerkers. De meerderheid denkt ook dat het hoog draaien van de kamerthermostaat de kamer sneller warmer maakt ('kraan model': meer draaien is meer krijgen. Onjuist: het verwarmen gaat even snel, alleen houdt de kachel slechts op met branden bij een hogere temparatuur).

Voor HCI zijn user models op twee manieren van belang:

  1. Of een gebruiker aan een systeem een user model kan ontwikkelen hangt mede af van hoe dat systeem zich aan de gebruiker presenteert.
  2. Gebruikers nemen bestaande user models automatisch mee. Als een systeempresentatie daar tegen ingaat, bijvoorbeeld omdat het anders werkt dan een gebruiker verwacht, creëer je een interactie-probleem (de gebruiker heeft altijd gelijk).

Bij het ontwikkelen van een goede interface heb je met beiden te maken. Een voorbeeld van een begrip dat met het eerste te maken heeft is de affordance die iets heeft. Dit duidt aan hoeveel een object of applicatie zelf 'vertelt' over hoe het gebruikt moet worden. Een handvat op een trekdeur bijvoorbeeld: Je zal daar als eerste aan willen trekken. Heeft zo'n deur aan beide kanten handvaten, dan gaat het dus de helft van de keren mis. Veel metaforen in de user interface (prullebak, buttons etc.) hebben een goede affordance omdat ze aansluiten bij bestaande user models. Een consequentie van affordances is dat je, als je je gebruikers iets nieuws wilt laten doen, ook een nieuw soort interactie widget moet ontwerpen.
Met betrekking tot het tweede punt zul je voor een interface ontwerp beginnen met het in kaart brengen van je gebruikers, om er achter te komen wat deze allemaal meenemen uit hun ervaringsverleden. Bouw je bijvoorbeeld een nieuw spreadsheet programma, en je toekomstige gebruikers hebben al veel ervaring met een ander spreadsheetprogramma, dan moet je opletten voor conflicten tussen de beide interfaces. Ook kan het verstandig zijn niet een heel andere omgang te willen introduceren (lees: tegen het bestaande user model in te willen gaan). Als bijvoorbeeld gebruikers gewend zijn geraakt aan een popup menu onder de rechter muisknop, of icons kunnen verslepen, zullen ze het als een interface-probleem ervaren als dat in een applicatie niet meer kan omdat dan de feitelijke werking tegen de verwachte werking (user model) ingaat.

Dergelijke punten neem je mee in het basisontwerp, wat alleen nog maar een conceptueel ontwerp is. Het doel hiervan in het basisontwerp is:

Een van de grote problemen voor de ontwerper is dat eigen kennis niet uit te schakelen is: Een ontwerper, die per definitie veel van het nieuwe systeem afweet, zal zich moeilijk kunnen verplaatsen in een onwetende gebruiker. In andere woorden: het conceptuele model dat een ontwerper van een systeem heeft, en het conceptuele model dat de ontwerper denkt dat de user heeft, zijn niet synoniem met het feitelijke user model. Ook is er niet een simpele test voor het meten van het user model. Mede daarom is het derde doel het lastigst, terwijl het ook het belangrijkst is. De literatuur geeft dit aan als “het ontwikkelen van een (beoogd) user model”.

Op de belangrijke punten van user models m.b.t. het basisontwerp wordt nu wat dieper ingegaan.

User models

Er zijn twee user model vormen: statisch en dynamisch. In de minderheid ontwikkelen gebruikers statische modellen, die betrekking hebben op de structuur van systemen. Kennis van de structuur van bijvoorbeeld een tekstverwerker of een televisietoestel hoort bij expertgedrag. Vrijwel iedereen kan overweg met een televisietoestel en ontwikkelt daarbij enig idee hoe zo'n ding in elkaar zit (antenne, antennesignaal, beeldbuis, kanalen, luidsprekers) maar dit heeft een grote afstand tot hoe het feitelijk geconstrueerd is. Zo'n conceptueel model van hoe iets geconstrueerd is wordt in de literatuur een surrogaat model genoemd.
In meerderheid worden dynamische modellen ontwikkeld. Dynamische modellen zijn z.g. runnable modellen: modellen van processen die men voor het ‘geestesoog’ kan laten afdraaien. Hierbij ontwikkelt de gebruiker een theorie over de werking van een systeem. Hij/zij gebruikt het model om een inschatting te maken tussen oorzaak ('als ik dat doe ..') en gevolg ('.. heeft dat een zus of zo'n effect'). Vandaar dat mensen denken dat de kamer sneller warmer wordt als ze thermostaat 'kraan' meer open draaien. Een runnable model is dus een causaliteiten model: relaties tussen oorzaak en gevolg.

Structurele en procedurele kennis kunnen uiteraard verweven zijn. Als iemand weet dat de iconen op de desktop van Windows slechts snelkoppelingen zijn naar het programma, dan begrijpt hij/zij ook dat het wissen van dat icoon niet ook het wissen van het programma tot gevolg heeft. Bij de meeste gebruikers ligt het accent sterk op de procedurele aspecten. Zij hebben weinig kennis van hoe het systeem structureel in elkaar zit, maar hebben wel modellen over het gebruik van het systeem (denk aan kennis van motor : autorijden). Bij experts ligt dat anders: Zij hebben een goede structurele kennis van een systeem. Dit maakt hun procedurele kennis veel flexibeler, en dat is nuttig bijvoorbeeld in probleemsituaties. Doordat experts een goede mentale analogie van een systeem hebben kunnen ze vrij nauwkeurig systeemgedrag voorspellen onder tal van omstandigheden. Zij 'runnen' in zichzelf een simulatie van het systeem. Het wordt verondersteld dat gebruikers eerst een simpel functioneel user model creëren, vaak een theorie, vanwaar procedurele modellen worden ontwikkeld. De functionele en procedurele modellen worden over het algemeen pas aangepast als verwachtingen op basis van de bestaande modellen niet worden beantwoord (wat kan het mij schelen hoe die motor precies werkt zolang de auto goed rijdt) maar zelfs dat hoeft niet (ik breng ‘m gewoon naar de garage als hij stuk is; of: ik haal mijn info wel ergens anders op als deze site niet werkt).

Belangrijk is het om zich te realiseren dat 'gewone' gebruikers hun modellen niet ontwikkelen op basis van structurele kennis: User models worden ontwikkeld doordat men theorieën vormt over de interne werking op basis van de externe uitkomsten. Het externe gedrag is onderdeel van wat Norman (1986) het 'System Image' noemt (zie figuur 1).


Figuur 1: User models en system image volgens Norman

Wellicht is het nu ook beter te begrijpen waarom een systeemontwerper de slechtste persoon is om de user interface te ontwerpen: Ten eerste heeft hij/zij als expert veel structurele kennis over het systeem, en eigen kennis kun je niet uitschakelen. En ten tweede zal de gebruiker w.s. een andere taakuitvoering hebben dan de expert (die nu eenmaal een ander beroep heeft dan de gebruiker). Een gebruiker hoeft niet geheel te begrijpen hoe een tv toestel werkt om er prettig mee om te kunnen gaan. Een systeem moet zich dusdanig aan de gebruiker presenteren dat deze er op een 'intuitieve' wijze mee om kan gaan: als het gedrag van het systeem overeenkomt met de verwachtingen van de gebruiker.

Er zijn vier vormen van (dynamische) user models:

Een gebruiker die met een systeem in de weer is, vraagt zich voortdurend af wat hij/zij ziet, welk effect een handeling heeft gehad en dus wat het systeem gedaan heeft en vraagt zich af wat de beste volgende stap is in termen van wat..als.. In andere woorden, zo'n gebruiker 'runt' zijn conceptuele model en, als de uitkomsten niet kloppen met de werkelijkheid, probeert hij dit bij te stellen. Elk van de vier vormen kan hierbij actief zijn. Als een gebruiker geen verklaring kan vinden voor een bepaald (ongewenst of onverwacht) gevolg heeft deze een probleem met de interface: Zijn conceptuele model schiet dan tekort en het systeem biedt onvoldoende handreikingen om een verbeterd model te vormen. Observatie en analyse van dergelijke situaties bij gebruikers kan dan ook leiden tot ontwerpverbeteringen. Aan de basis van dergelijke analyses ligt het ontwerp van een (beoogd) user model.

Mismatches tussen computerapplicaties en user models

Gebruikers hebben traditioneel in eerste instantie veel moeite met het hanteren van computers. Begrijpelijk, want er zijn in de gemiddelde huishouding geen apparaten die er qua bediening op lijken. Helaas lijken besturingsystemen van computers in eerste instantie weinig ontworpen voor naïve gebruikers. Niet alleen heeft de gebruiker m.b.t. de computer geen voor de hand liggende analogieën voor het creëren van een user model, veel aspecten zijn ook strijdig met de bestaande user models. Enkele voorbeelden:

Deze mismatches worden door ervaren gebruikers niet meer als hinderlijk ervaren (d.w.z. als feit geaccepteerd maar niet-technische mensen ontwikkelen er geen user model aan), maar dat betekent niet dat er geen mismatches meer mogelijk zijn. Toen in het midden van de 90er jaren van de vorige eeuw men massaal overschakelde van de tekstverwerker WordPerfect naar MS-Word waren er niet voor niets specifieke cursussen MS-Word voor WP gebruikers. Men zou kunnen denken dat het gebruik van WP een soort user model over tekstverwerken teweeg gebracht zou hebben, maar dat is onjuist: WP-gebruikers hebben leren saven, afsluiten, printen, documenten te laden etc. d.m.v. functietoetsen, die op deze manier niet meer in MS-Word functioneerden.

Veel van de vroegere mismatches zijn opgeheven door het gebruik van standaarden in de user interface. Een windowsgebruiker die met een bepaalde applicatie heeft leren werken, kan in een andere applicatie direct bestanden openen, opslaan, printen e.d. Mismatches kunnen wel nog ontstaan door onjuist gekozen metaforen, die een gebruiker op het verkeerde been zetten.

Hoe meet je een user model

Sasse (1992) heeft onderzocht hoe je user models het beste kunt meten. Ze heeft vijf methoden uitgeprobeerd:

  1. Het interactief observeren van gebruikers die met een systeem werken
    In dit geval gebruikten de testpersonen in principe ongestoord het systeem. Als het fout ging en de testpersoon had dat niet in de gaten, werd op de fout attent gemaakt. Als er vragen kwamen over de werking werd in eerste instantie geprobeerd de persoon door het stellen van vragen op het goede spoor te brengen; lukte dat niet dan werd de vraag beantwoord.
    Bij deze methode worden wel dingen waargenomen, maar vooral als het fout gaat zodat een eenzijdig beeld wordt verkregen. Bovendien raken testpersonen van hun stuk omdat ze onderbroken worden. Er wordt bovendien geen (of slechts incidenteel een) beeld verkregen van functionele kennis, alleen van procedurele kennis.
  2. Gebruikers een systeem laten uitleggen
    In deze opzet moest een groep personen (de ‘instructors’) aan iemand anders (de 'leerder') de werking van een programma uitleggen, nadat de instructors zelf de weken ervoor over het programma instructie hadden gehad. De leerder, die in feite een medewerker is van de experimentator, zit achter het systeem en past het geleerde direct toe. De experimentator observeert de sessie vanuit een andere ruimte maar is bij problemen wel oproepbaar.
    Deze methode blijkt de beste te zijn: Omdat de leerder (met opzet) regelmatig om zowel functionele als procedurele uitleg vraagt moeten de 'instructors' hun kennis verwoorden. Dit geeft veel weer van de interne modellen bij de instructors, die uiteindelijk ook maar kort geleden instructie hebben gehad.
  3. Gebruikers het gedrag van een systeem laten voorspellen
    In dit geval werd gebruik gemaakt van een prolog programma bestaande uit een knowledge base en een regel. De testpersoon moet een query intypen en het antwoord voorspellen. Vervolgens moet de testpersoon een vraag gesteld in natuurlijke taal vertalen in een query en tenslotte hiervan de uitkomst voorspellen.
    Deze methode is bruikbaar voor het meten van statische modellen. Vooral als de testpersoon bij de eerste taak fouten maakt kan door het stellen van vragen veel informatie verkregen worden over het begrip van het systeem. Bij de eerste taak ligt het accent op het begrijpen van het (prolog) systeem, bij de tweede en derde op probleem-oplos gedrag waardoor deze geschikter zijn bij ervaren gebruikers. In het algemeen geeft deze methode veel inzicht over de interne representatie van de testpersoon, m.n. de statische aspecten (surrogaatmodel).
  4. Gebruikers eerst een systeem laten beschrijven en het vervolgens laten gebruiken
    In dit experiment wordt een relatie gelegd tussen de functionele kennis over een systeem van een gebruiker en de procedurele vaardigheid er mee om te kunnen gaan. Eerst werd de kennis getest en vervolgens werden enkele taken gegeven die uitgevoerd moesten worden.
    Deze methode geeft geen informatie over het (dynamische) user model. Uit dit experiment kwam o.a. naar voren dat het niet nodig is om kennis over een systeem te hebben (een 'surrogaat model' te hebben) om er mee om te kunnen gaan. Deze methode is dus alleen bruikbaar om na te gaan in welke mate er een mapping is tussen de conceptuele kennis en de vaardigheid m.b.t. het systeem.
  5. Gebruikers observeren die een systeem aan het leren zijn
    In dit experiment werden gebruikers in paren voor een uur achter een voor hen nieuwe applicatie gezet met de opdracht de werking ervan te exploreren. Deze groep testpersonen had wel al enige algemene computerervaring. De ene testpersoon zat achter de computer en de andere ernaast met het manual, om dit te raadplegen als de ene testpersoon daaraan behoefte had. De 'manualhouder' was een medewerker van de experimentator, geinstrueerd om niet al te behulpzaam te zijn om het ontdekkend leren van de ander niet te storen. Ook moesten antwoorden wat vaag zijn en alleen de juiste richting aangeven, niet de concrete oplossing.
    Deze methode is een variant van de tweede methode en komt op de 2e plaats wat betreft doeltreffendheid. Het nadeel ten opzichte van de tweede methode is dat de taak minder gestructureerd is en daarom ook de informatie die verkregen wordt meer 'toevallig' is. Bij een gestructureerde taak kun je nauwkeuriger bepaalde hypothese over een user model testen.

In alle methodes wordt de meeste informatie verkregen als gebruikers fouten maken en deze proberen te herstellen. Specifieke informatie verkrijg je door de testtaak te structureren.

Belangrijk is dat gebruikers aan een systeem een user model kunnen ontwikkelen. In dat opzicht is het voor HCI ook niet zo erg als meer ervaren gebruikers geen fouten maken, zodat je hun user model niet kan meten: Er is alleen een interface-probleem als gebruikers fouten maken en deze niet kunnen herstellen. Je weet dan dat aan het ontwerp problemen kleven en op welke punten dat is.

Hoe ontwikkel je een (beoogd) user model

Een goed ontwerp houdt rekening met bestaande user models. Daarom inventariseert men de soort kennis en ervaring die er is zodat conflicten hiermee in de nieuwe interface vermeden kunnen worden. Daarnaast worden maatregelen getroffen die er voor moeten zorgen dat gebruikers ook aan het nieuwe systeem een user model kunnen ontwikkelen. Dit wordt in de literatuur het 'ontwerpen van een user model' genoemd. Hierbij gaat het dus om een beoogd model. Dit model representeert wat de gebruiker in een situatie waarschijnlijk zal denken, en hoe hij/zij waarschijnlijk zal reageren. Het ontwerpen van een beoogd user model kun je realiseren als je rekening houdt met de volgende aandachtspunten:

Het weergeven van een user model in het ontwerp

Een user model kan je niet in een enkel diagram of een enkele tabel weergeven. In dit studie-onderdeel wordt het weergegeven in een z.g. State Transition Diagram en verder komt het tot uitdrukking in de ontwerpaspecten zoals metaforen en andere visuele elementen in de interface, en in de manier waarop de gebruiker met het systeem interacteert. Concreet, uitgaande van de vier vormen van dynamische modellen:

Samengevat: Het user model wordt het meest concreet vastgelegd in een State Transition Model. Voor de rest bestaat de weergave uit opmerkingen bij gemaakte ontwerpkeuzes, met name m.b.t. visuele elementen.

Literatuur:
Mayhew, D.J., Principles and Guidelines in Software User Interface Design, Prentice Hall, 1992, chapter 3.
Newman, W.M. & Lamming, M.G., Interactive System Design. Addison-Wesley, 1995, pp.323-343.
Norman, D.A., Cognitive engineering. In: Norman, D.A. & Draper, W. [editors], User Centered System Design: New Perspectives on Human-Computer Interaction, Lawrence Erlbaum Associates, 1986, pp.31-65.
Sasse, M.A., User's models of computer systems. In: Rogers, Y. et al., Models in the Mind - Theory, Perspective & Applications. Academic Press, 1992, pp.225-239.
Sasse, M.A., Eliciting and Describing Users’ Models of Computer Systems [Thesis], University of Birmingham, http://www.cs.ucl.ac.uk/staff/A.Sasse/thesis, 1997.

 


 

Gebruikersprofielen en consequenties

Een interface moet geschikt moet zijn voor een gebruiker en moet passen bij diens taakuitvoering. In dit hoofdstuk richten we ons op deze aspecten in relatie tot het interface-ontwerp.

Idealiter is een interface geschikt voor elke gebruiker, maar dat is in de praktijk niet haalbaar. Een met applicatie software zeer ervaren gebruiker bijvoorbeeld heeft geen moeite met een interface waarop een grote verscheidenheid aan gegevens en interactie-soorten (checkboxes, list boxes, drop down menu's e.d.) te vinden is. Een beginnende gebruiker daarentegen kan beter geconfronteerd worden met een interface waarop weinig gegevensrubrieken en keuze-elementen te vinden zijn. De ervaren gebruiker voelt zich waarschijnlijk belemmerd door zo'n interface.

Wat is een gebruiker?

Het probleem is dat er niet zoiets als 'een' gebruiker is. Er zijn een heleboel gebruikersaspecten die elk een effect (kunnen) hebben op de interface, maar geen enkele gebruiker is een 'verzameling' van dezelfde gebruikersaspecten met dezelfde waarden. Er moet dus op de een of andere wijze uitgegaan worden van doorsneden: de interface moet geschikt gemaakt worden voor een bepaalde populatie.

Gebruikers-eigenschappen worden in kaart gebracht door een gebruikersonderzoek uit te voeren. Bijvoorbeeld door interviews af te nemen of aan de hand van een vragenlijst. Dit onderzoek vindt plaats onder de toekomstige gebruikers van de applicatie. Op basis van deze gegevens worden een of meer doorsneden (gebruikerscategorieën) bepaald en is/zijn de toekomstige 'gebruiker(s)' bepaald.

Soms zijn populaties al direct zichtbaar. Gaat een applicatie bijvoorbeeld gebruikt worden door zowel baliemedewerkers als directieleden, dan is het waarschijnlijk dat dit gebruik (de taakuitvoering) zal verschillen. In dit geval is het waarschijnlijk mogelijk om direct van twee gebruikersgroepen uit te gaan (het gebruikersonderzoek richt zich direct op beide groepen afzonderlijk en ook de interface zal voor beiden afzonderlijk ontworpen gaan worden). Er wordt dus mede uitgegaan van aspecten die voor de taak van belang zijn. Bijvoorbeeld de gebruiksfrequentie: Een applicatie die dagelijks veel gebruikt wordt (bijv. baliemedewerkers) zal moeten scoren op snelheid van kunnen werken. Daarentegen moet een applicatie die incidenteel gebruikt wordt (bijv. directieleden) eenvoudig te leren (intuitief toegankelijk) zijn. Natuurlijk wil je allebei realiseren maar dat is niet (altijd) mogelijk.

Bij web applicaties is een gebruikersonderzoek in de regel niet mogelijk. Hoe kom je dus aan de kenmerken van de toekomstige 'gebruiker'? Hier moet je je beperken tot de veronderstelde kenmerken van de beoogde doelgroep. Deze kenmerken kun je later proberen te valideren bijv. door mini-enquetes op te nemen. Het probleem blijft echter bestaan: Iedereen kan een website bezoeken en dus kun je te maken krijgen met heel verschillende kenmerken van gebruikers. Het enige wat erop zit is uit te gaan van wat je denkt te weten over de beoogde doelgroep.

Mayhew's checklist

Deborah Mayhew (1992) presenteert een lijst met kenmerken, aan de hand waarvan een gebruikersprofiel (van de populatie) kan worden beschreven. Dat doe je door van alle afzonderlijke gebruikers de kenmerken te verzamelen en dan deze data te analyseren op frequentie e.d. Is een profiel eenmaal bepaald, dan zijn er bepaalde consequenties af te lezen m.b.t. het interface-ontwerp.
Niet alle kenmerken hoeven van toepassing te zijn, en ook is de checklist reeds enigszins gedateerd: Inmiddels zijn veel meer mensen gewend geraakt aan de omgang met computers dan ruim 10 jaar geleden het geval was. Ondanks dat zijn de meeste consequenties nog steeds relevant en heeft het veel zin de lijst in te vullen en de consequenties ervan in het ontwerp mee te nemen (zie volgende paragraaf).

Mayhew's 'User Profile Checklist' ziet er als volgt uit:

Psychological Characteristics
  • Cognitive Style
Verbal/analytic - Spatial/intuitive
  • Attitude
Positive – Neutral – Negative
  • Motivation
High – Moderate - Low
Knowledge & Experience
  • Reading level
Less than fifth grade – Fifth to twelfth grade – Above twelfth grade
  • Typing skill
Low – Medium - High
  • Education
High school degree – College degree – Advanced degree
  • System experience
Expert – Moderate - Novice
  • Task experience
Novice in field- Moderate – Expert in field
  • Application experience
No similar systems – One similar system – Some similar systems
  • Native language
English - Other
  • Use of other systems
Little or none - Frequent
  • Computer literacy
High – Moderate - Low
Job & Task Characteristics
  • Frequency of use
Low – Medium - High
  • Primary training

None – Manual only – Elective formal- Mandatory formal

  • System use
Mandatory – Discretionary
  • Job categories
Executive – Manager – Engineer – Secretary - Clerk
  • Turnover rate
High – Moderate - Low
  • Other tools
Telephone – Calculator - Adding machine - Other
  • Task importance
High - Low
  • Task structure
High – Moderate - Low
Physical Characteristics
  • Color blind
Yes - No
  • Handedness
Right – Left - Ambidextrous
  • Gender
Female - Male

Enkele aspecten van de lijst behoeven enige uitleg.

Consequenties van ingevulde waarden voor het ontwerp

Psychological Characteristics

  • Cognitive Style

Zie de opmerking in de vorige paragraaf. Door de grote individuele verschillen lijkt de directe praktische waarde (toepasbaarheid) van dit item dan ook gering. Wel is het nuttig te weten dat er zulke grote verschillen zijn en dat wat voor de ene gebruiker prettig is, voor de andere een probleem kan zijn. Dit kan leiden tot het ontwikkelen van 'meerdere wegen naar Rome' in de interface.

  • Attitude

Motivatie en attitude zijn van invloed op taakuitvoering.
Het UI ontwerp kan negatieve reacties (angst, verveling, desinteresse) vermijden door de taak interessanter te maken (leuker, aantrekkelijker, uitdagender, meer mogelijkheden).

Belangrijke vraag: wat is de meerwaarde van de applicatie?

  • Motivation

Motivatie en attitude zijn van invloed op taakuitvoering.
Motivatie kan laag zijn zijn door een gevoel van bedreiging, maar ook hoog door angst. Motivatie heeft ook te maken met vrijwillig/verplicht gebruik. Dit beinvloedt de ontwerpdoelen:

User characteristics

Design goal

Low motivation, discretionary use Ease of learning
Low motivation, mandatory use Control, power (must feel benefit immediately)
High motivation, due to fear Ease of learning, robustness, control, power
High motivation, due to interest Power, ease of use
Knowledge & Experience
  • Reading level
Bij een "talige" interface moeten woordgebruik ('moeilijke woorden') en grammaticale structuur afgestemd worden op het leesniveau van de gebruiker.
Zie ook Education
  • Typing skill
Is minder van belang, alhoewel het voorkomt dat mensen niet met het toetsenbord overweg kunnen.
  • Education
Het opleidingsniveau beinvloedt het leesniveau.
Een 'talige' interface past het best bij hogere opleidingsniveaus (zie ook 'reading level').

Opleidingsniveau heeft ook invloed op de mogelijke complexiteit en abstractie van de interface.
Idem: interactiestijl (bijv. direct manipulation versus besturingstaal).

  • System experience
  • Task experience
System experience (bekendheid met functietoetsen, commando's e.d. ;"syntactische bekendheid") en Task experience ('achtergrond kennis' taakdomein; "semantische bekendheid") hangen samen:
  Task experience LOW Task experience HIGH
System experience LOW Veel hulp en messages zowel van syntactische (toetsen e.d.) als semantische (taak) aard.
Effective error recovering procedures
Veel syntactische hulpmogelijkheden en -messages
System experience HIGH Veel semantische hulpmogelijkheden en -messages.
Snelle (efficiente) besturings-mogelijkheden.
Snelle (efficiente) besturings-mogelijkheden.
Korte (non 'verbose') syntactische error messages.
  • Application experience
Ervaring met identieke applicaties als welke ontwikkeld wordt vereenvoudigt het gebruik van de nieuwe applicatie, mits er geen strijdige elementen in de user interfaces zijn (zie het hoofdstuk over user models).
  • Native language
Als de gebruikers meerdere nationaliteiten hebben moet een meertalige interface overwogen worden (taalkeuze).
In dit geval is het belangrijk om tussen applicaties onderling een consistent gebruik van termen te handhaven.
  • Use of other systems
Als de gebruiker regelmatig ook andere systemen gebruikt neemt hij daarvan kennis, ervaring en gewoontes (zie het hoofdstuk over user models) mee.
In dat geval is het belangrijk de user interfaces van de systemen op elkaar aan te laten sluiten, voor een minimum aan leerlast en wisselingsfouten.

In het algemeen kan gesteld worden dat de interface voor ervaren computergebruikers 'drukker' (meer zichtbare elementen) uitgevoerd kan worden dan voor beginnende gebruikers.

  • Computer literacy
Gebruikers kunnen enige "computer literacy" hebben. Ook doen ze in de omgang met verschillende applicaties enige "computer literacy" op.
Dit kunnen andere applicaties zijn dan in deze situatie ontwikkeld wordt. In dat geval betekent "computer literacy" niet ook "application experience" of "system experience".
Job & Task Characteristics
  • Frequency of use
De 'Ease of use' - 'ease of learning' trade-off wordt bepaald door 'frequency of use', 'system use' en 'task importance'.
  • High-frequency users zullen de interface leren en herinneren ook als dit niet eenvoudig is. Zij zijn meer gebaat bij ''ease of use'.
  • Low-frequency users zullen de interface niet kunnen leren en herinneren, tenzij deze er voor ontworpen is. Dit heeft prioriteit op 'ease of use'.
Frequency of use = high Ease of use
Frequency of use = low Ease of learning and remembering
  • Primary training
Bij training speelt 'verplicht' of vrijwillig' een rol. Zie hiervoor verder bij 'system use'.
  • System use
De 'Ease of use' - 'ease of learning' trade-off wordt bepaald door 'frequency of use', 'system use' en 'task importance'.
  • Bij verplicht gebruik krijgen gebruikers meestal training. 'Ease of use' geeft hen een gevoel van "power and control", wat de motivatie gunstig beinvloedt.
  • Bij vrijwillig gebruik zijn de eerste indrukken belangrijk voor een goede motivatie. Daarom heeft 'ease of learning' een hogere prioriteit.
System use = mandatory Ease of use
System use = discretionary Ease of learning and remembering
  • Job categories

Een mogelijk probleem bij het hanteren van de lijst is de vraag 'voor welke gebruiker wordt het ingevuld?' Er kan geen rekening gehouden worden met elke individuele gebruiker, zodat in de regel een gemiddelde aangehouden wordt. Dit kan uiteraard onverstandig zijn. Als een toekomstige applicatie gebruikt gaat worden door zowel leden van de directie als receptie-medewerkers is zo'n gemiddelde niet erg voor de hand liggend: Het is te verwachten dat beide groepen een verschillende taakuitvoering, opleiding e.d. hebben. In dit geval lijkt het redelijk voor beide groepen verschillende interfaces te ontwikkelen. Vanwege de hogere kosten zal de echte noodzaak hiervoor wel onderzocht moeten worden. Men gaat dus uit van een gemiddelde gebruiker, mits deze voldoende representatief is voor de gebruikersgroep (c.q. de spreiding niet te groot is).
  • Turnover rate
Turnover rate is de frequentie van wisselen van baan (werkplek).
We bekijken het vanuit de taak.
  • Hoge 'turnover rate'
    Een systeem dat veel training vergt en moeilijk te leren is, is niet geschikt in een taak met een sterk wisselende bezetting (bijv. uitzendkrachten). De leerinvestering weegt niet op tegen het nut van het systeem. 'Ease of learning' staat voorop.
  • Lage 'turnover rate'
    Wanneer een persoon langer de taak uitvoert, is een grotere leerlast is mogelijk c.q. wordt als een reële investering gezien. 'Ease of use' staat nu voorop.
Turnover rate = high Ease of learning and remembering
Turnover rate = low Ease of use
  • Other tools

Als samen met de software nog andere tools gebruikt worden, moet de UI van de software hier op afgestemd worden c.q. niet van verschillen, wanneer mogelijk (zie hoofdstuk user models). Een bekend voorbeeld is het verschil in inrichting van het toetsenblok van rekenmachines c.q. het numerieke deel van het keyboard versus dat vande telefoon.
Wanneer bestaande tools door software vervangen worden, is het geschikt de bestaande oude tools als metafoor te kiezen (reductie leercurve; zie hoofdstuk user models).
  • Task importance
De 'Ease of use' - 'ease of learning' trade-off wordt bepaald door 'frequency of use', 'system use' en 'task importance'.

Taakbelang heeft effect op de motivatie. Taakbelang bepaalt mede de (bereidheid tot) investering in "primary training" (m.n. bij vrijwillig gebruik). Vrijwel elke initiele leercurve veroorzaakt  een dip in de productiviteit (afweging tussen investering en effect).

  • Als het belang hoog is, is de motivatie hoog en heeft 'ease of use' een hogere prioriteit dan 'ease of learning'.
  • Als het belang laag is, is de motivatie laag en tolereren gebruikers geen 'leerkosten'.

'Ease of learning' moet compatible zijn met 'primary training' en 'turnover rate'.
Taakbelang en 'frequency of use' kunnen onafhankelijk zijn.

Task importance = high Ease of use
Task importance =low

Ease of learning and remembering

  • Task structure
De flexibiliteit van de interface moet in overeenstemming zijn met complexiteit van de taakstructuur. De taakstructuur is mede bepalend voor de primaire interactiestijl.

Volgens Miller en Thomas (1977, in Mayhew) zijn er twee dimensies: 'control' ('user' of 'system') en 'choice '('free' of 'forced'). Dit levert tesamen vier “basistypen” van user interfaces op:

  1. System controlled - forced choice
  2. System controlled - free choice
  3. User controlled - forced choice
  4. User controlled - free choice
  • Input mode
    • input only (bijv. data entry)
    • input to get output (bijv. belastingaangifte)
  • Output mode
    • receive structured outputs (bijv. management report systems)
    • obtain desired output by selection (bijv. database query system)
Vuistregel:

Geschikt voor gestructureerde taak

  • System-controlled interactions
  • Forced-choice interactions
    (menu's)
  • Free-choice interactions
    (dialogs)
  • Processing mode
    • limited data manipulation (bijv. statische software)
    • extensive data manipulation (bijv. programmeer-omgeving)
Vuistregel:

Geschikt voor minder gestructureerde taak

  • User-controlled interactions
  • Free-choice interactions
    (dialogs, command languages, booleans
    )

Physical Characteristics
  • Color blind
Uitgaande van een gemiddelde gebruiker veroorzaken deze drie items geen bijzondere gevolgen voor het ontwerp. In het algemeen moet men er wel rekening mee houden dat ca. 8% van de mannen (bij vrouwen slechts ca. 0.5%) 'kleurenzwak' is. Dit betekent dat bepaalde kleuren (vaak rood en groen) niet onderscheiden worden (rood als groen gezien wordt).
  • Handedness
  • Gender

Literatuur
Mayhew, Deborah J., Principles and Guidelines in Software User Interface Design, Prentice Hall, 1992, chapter 2.

 


 

Naslag

  • Designing Icons
  • Handleiding BSCW
  • Literatuurlijst
  • Web bronnen


     

    Designing Icons

    in chapter 5 van de Java Look and Feel Design Guidelines
    Bron: http://java.sun.com/products/jlf/ed1/dg/high.htm#71577

    java.sun.com and JLF home page   Previous Next Contents/Index/Search

    5: Application Graphics

    This chapter provides details on:

    • The use of cross-platform color
    • The design of application graphics, such as button graphics, icons, and symbols
    • The use of graphics to enhance your product and corporate identity

    Because the quality of your graphics can affect user confidence and even the perceived stability of your application, it is wise to seek the advice of a professional visual designer.

     

    Working With Cross-Platform Color

    In a cross-platform delivery environment, you need to ensure that the visual components of your application reproduce legibly and aesthetically on all your target systems. In many cases, you might not know which platforms will be used to run your software or what display capabilities they might have.

    Online graphics consist of the visual representations of JFC components in the Java look and feel, which are drawn for you by the toolkit, and application graphics such as icons and splash screens, which you supply.

    The Java look and feel components use a simple color model that reproduces well even on displays with a relatively small number of available colors. You can use the theme mechanism to change the colors of the components. For details, see Themes.

    Use themes to control the colors of Java look and feel components--for instance, to provide support for display devices with minimal available colors (fewer than 16 colors).

    You need to supply icons, button graphics, pictures and logos for splash screens, and About boxes. Since these graphics might be displayed on a number of different platforms and configurations, you must develop a strategy for ensuring a high quality of reproduction.

    Use color only as a secondary means of representing important information. Make use of other characteristics (shape, texture, size, or intensity contrast) that do not require color vision or a color monitor.

    The colors available on your users' systems, along with graphic file formats, determine how accurately the colors you choose are displayed on screen. Judging color availability is difficult, especially when you are designing applications to be delivered on multiple configurations or platforms.

     
    Working With Available Colors

    The number of colors available on a system is determined by the bit depth, which is the number of bits of information used to represent a single pixel on the monitor. The lowest number of bits used for modern desktop color monitors is usually 8 bits (256 colors); 16 bits provide for thousands of colors (65,536, to be exact); and 24 bits, common on newer systems, provide for millions of colors (16,777,216). The specific colors available on a system are determined by the way in which the target platform allocates colors. Available colors might differ from application to application.

    Designers sometimes use predefined color palettes when producing images. For example, some web designers work within a set of 216 "web-safe" colors. These colors reproduce in many web browsers without dithering (as long as the system is capable of displaying at least 256 colors). Dithering occurs when a system or application attempts to simulate an unavailable color by using a pattern of two or more colors or shades from the system palette.

    Outside web browsers, available colors are not so predictable. Individual platforms have different standard colors or deal with palettes in a dynamic way. The web-safe colors might dither when running in a standalone application, or even in an applet within a browser that usually does not dither these colors. Since the colors available to a Java application can differ each time it is run, especially across platforms, you cannot always avoid dithering in your images.

    Identify and understand the way that your target platforms handle colors at different bit depths. To achieve your desired effect, test your graphics on all target platforms at depths less than 16 bits.

     
    Choosing Graphic File Formats

    You can use two graphic file formats for images on the Java platform: GIF (Graphics Interchange Format) and JPEG (named after its developers, the Joint Photographic Experts Group).

    GIF is the common format for application graphics in the Java look and feel. GIF files tend to be smaller on disk and in memory than JPEG files. Each GIF image is limited to 256 colors, or 8 bits of color information per pixel. A GIF file includes a list (or palette) of the colors (256 or fewer) used in the image. The number of colors in the palette and the complexity of the image are two factors that affect the size of the graphic file.

    On 8-bit systems, some of the colors specified in a GIF file will be unavailable if they are not part of the system's current color palette. These unavailable colors will be dithered by the system. On 16-bit and 24-bit systems, more colors are available and different sets of colors can be used in different GIF files. Each GIF image, however, is still restricted to a set of 256 colors.

    JPEG graphics are generally better suited for photographs than for the more symbolic style of icons, button graphics, and corporate type and logos. JPEG graphics use a compression algorithm that yields varying image quality depending on the compression setting, whereas GIF graphics use lossless compression that preserves the appearance of the original 8-bit image.

     
    Choosing Colors

    At monitor depths greater than 8 bits, most concerns about how any particular color reproduces become less significant. Any system capable of displaying thousands (16 bits) or millions (24 bits) of colors can find a color very close to, or exactly the same as, each value defined in a given image. Newer systems typically display a minimum of thousands of colors. Different monitors and different platforms might display the same color differently, however. For instance, a given color in one GIF file might look different to the eye from one system to another.

    Many monitors or systems still display only 256 colors. For users with these systems, it might be advantageous to use colors known to exist in the system palette of the target platforms. Most platforms include a small set of "reserved" colors that are always available. Unfortunately, these reserved colors are often not useful for visual design purposes or for interface elements because they are highly saturated (the overpowering hues one might expect to find in a basic box of magic markers). Furthermore, there is little overlap between the reserved color sets of different platforms, so reserved colors are not guaranteed to reproduce without dithering across platforms.

    Select colors that do not overwhelm the content of your application or distract users from their tasks. Stay away from saturated hues. For the sake of visual appeal and ease of use, choose groups of muted tones for your interface elements.

    Since there is no lowest-common-denominator solution for choosing common colors across platforms (or even colors that are guaranteed to reproduce on a single platform), some of the colors in your application graphics will dither when running in 8-bit color. The best strategy is to design images that dither gracefully, as described in the following section.

     
    Maximizing Color Quality

    Images with fine color detail often reproduce better on 8-bit systems than those images that are mapped to a predefined palette (such as the web-safe palette) and use large areas of solid colors. Dithering in small areas is less noticeable than it is over larger areas, and, for isolated pixels of a given color, dithering simply becomes color substitution. Often colors in the system palette can provide a fair-to-good match with those specified in a GIF file. The overall effect of color substitution in small areas can be preferable to the dithering patterns produced for single colors, or to the limited number of colors resulting from pre-mapping to a given color palette.

    The following table shows a graphic with a blur effect that contains a large number of grays. Remapping this graphic to the web-safe palette reduces the number of grays to two and results in an unpleasing approximation of the original graphic. However, the original GIF file displays acceptably in a Java application running in 8-bit color on various operating systems, even though the systems might not have available the exact colors in the image.

    Table  4 Remappings of a Blurred Graphic 

    Original Graphic
    Microsoft Windows
    Macintosh
    CDE
    Original colors




    Remapped to web-safe palette




    There are no absolutely safe cross-platform colors. Areas of solid color often dither, producing distracting patterns. One effective way to avoid coarse dithering patterns is to "pre-dither" your artwork intentionally. This approach minimizes obvious patterned dithering on 8-bit systems while still permitting very pleasing effects on systems capable of displaying more than 256 colors.

    To achieve this effect, overlay a semitransparent checkerboard pattern on your graphics. The following figure shows how to build a graphic using this technique.

    Figure 34 Adding a Pattern to Avoid Coarse Dithering Patterns

    To build the graphic:

    1. Use a graphics application with layers.
    2. Apply the pattern only to areas that might dither badly. Leave borders and other detail lines as solid colors.
    3. Play with the transparency setting for the pattern layer until the pattern is dark enough to mix with the color detail without overwhelming it visually. A 25% transparency with the default secondary 2 color (RGB 153-153-153) produces a good result for most graphics.
    4. Test your results on your target 8-bit platforms.

    The following table shows the variable results of graphic reproduction in 8-bit color, using different styles for various operating systems.

    Table  5 Variations in Reproduction of 8-Bit Color 
    Styles
    Original Graphic
    Windows 95
    (8 bits)
    Mac OS 8.5
    (8 bits)
    CDE
    (8 bits)
    Plain
    Dithering added
    Gradient
    Dithering added to gradient

    The plain graphic in the preceding table, which uses a large area of a single web-safe color, dithers badly on Windows 95 and CDE. Adding a pattern to the plain color improves the appearance only slightly. A gradient effect is added to the graphic to add some visual interest; this produces a banding effect on Mac OS 8.5. Adding the dithered pattern produces good results on all three platforms with 8-bit color. In 16-bit and 24-bit color, the graphic reproduction is very close to, or exactly the same as, the originals.

     

    Designing Graphics in the Java Look and Feel Style

    Application graphics that you design fall into three broad categories:

    • Icons, which represent objects that users can select, open, or drag
    • Button graphics, which identify actions, settings, and tools (modes of the application)
    • Symbols, which are used for general identification and labeling (for instance, as indicators of conditions or states)


    Table  6 Examples of Application Graphics
    Graphic Type
    Examples
    Basic 3D Style
    Pre-Dithered
    Icons
    Button graphics


    Symbols

    Use the GIF file format for iconic and symbolic graphics. It usually results in a smaller file size than the JPEG format and uses lossless compression.

    Put all application graphics in resource bundles.

    Where possible, use globally understood icons, button graphics, and symbols. Where none exist, create them with input from international sources. If you can't create a single symbol that works in all cultures, define appropriate graphics for different locales (but try to minimize this task).

     

    Designing Icons

    Icons typically represent containers, documents, network objects, or other data that users can open or manipulate within an application. An icon usually appears with identifying text.

    The two standard sizes for icons are 16 x 16 pixels and 32 x 32 pixels. The smaller size is more common and is used in JFC components such as the internal frame (to identify the contents of the window or minimized internal frame) and tree view (for container and leaf nodes). You can use 32 x 32 icons for applications designed for users with visual impairments or for objects in a diagram, such as a network topology.

    Design icons to identify clearly the objects or concepts they represent. Keep the drawing style symbolic, as opposed to photo-realistic. Too much detail can make it more difficult for users to recognize what the icon represents.

    When designing large and small icons that represent the same object, make sure that they have similar shape, color, and detail.

    Specify values for the accessibleDescription and accessibleName properties for each icon so that assistive technologies can find out what it is and how to use it.

     
    Working With Icon Styles

    The following figure shows sample 32 x 32 and 16 x 16 icons for files and folders drawn in two different styles. Note that many objects are difficult to draw in a flush 3D style, particularly at the smaller 16 x 16 size. Three visual elements appear in the sample icons: an interior highlight (to preserve the flush style used throughout the Java look and feel), a pattern to minimize dithering (described in Working With Available Colors), and a dark border.

    Figure 35 Two Families of Icons

    Use a single style to create a "family" of icons that utilize common visual elements to reflect similar concepts, roles, and identity. Icons in families might use a similar palette, size, and style.

    Don't mix two- and three-dimensional styles in the same icon family.

    For satisfactory display on a wide range of background colors and textures, use a clear, dark exterior border and ensure that there is no anti-aliasing or other detail around the perimeter of the graphic.

     
    Drawing Icons

    The following section uses a simple folder as an example of how to draw an icon. Before you start, decide on a general design for the object. In this example, a hanging file folder is used to represent a directory.


    1. Draw a basic outline shape first.

    Icons can use as much of the available space as possible, since they are displayed without borders. Icons should usually be centered horizontally in the available space. For vertical spacing, consider aligning to the baseline of other icons in the set, or aligning with text (for instance, in a tree).

    If both sizes are required, work on them at the same time rather than trying to scale down a detailed 32 x 32 icon later; both sizes then can evolve into designs that are recognizable as the same object.


    2. Add some basic color (green is used here).


    3. Draw a highlight on the inside top and left.

    This practice creates the flush 3D style of the Java look and feel.


    4. Add some detail to the icon.

    In this case, the crease or "fold" mark in the hanging folder is drawn.


    5. Try a gradient that produces a "shining" effect instead of the flat green.

    Here a dark green has replaced the black border on the right and bottom; black is not a requirement as long as there is a well-defined border.


    6. Add a pattern to prevent coarse dithering. This technique minimizes banding and dithering on displays with 256 or fewer colors (see Maximizing Color Quality).

    The first graphic is an exploded view of an icon that shows how the pattern is added.

     

    The next graphic shows an icon in which a pattern has been added to the color detail.


    7. Define the empty area around the icon graphic (in which you have not drawn anything) as transparent pixels in the GIF file.

    This practice ensures that the background color shows through; if the icon is dragged to or displayed on a different background, the area surrounding it matches the color or pattern of the rest of the background.

     

    Designing Button Graphics

    Button graphics appear inside buttons--most often in toolbar buttons. Such graphics identify the action, setting, mode, or other function represented by the button. For instance, clicking the button might carry out an action (creating a new file) or set a state (boldfaced text).

    The two standard sizes for button graphics are 16 x 16 pixels and 24 x 24 pixels. Either size (but not both at the same time) can be used in toolbars or tool palettes, depending on the amount of space available. For details on toolbars, see Toolbars. For more on palette windows, see Palettes.

    If you include both text and graphics in a button, the size of the button will exceed 16 x 16 or 24 x 24 pixels. If the button size is an issue, consider using tool tips instead.

    Do not include text as part of your button graphics (GIF files). Use button text instead. Keep the button text in a resource bundle to facilitate localization.

    Note, however, that toolbar buttons can display text instead of graphics, particularly if your usability testing establishes that the action, state, or mode represented by the button graphic is difficult for users to comprehend. Tool tips for toolbar buttons can help clarify the meaning of a button. For details, see Tool Tips for Toolbar Buttons.

    When designing your button graphics, clearly show the action, state, or mode that the button initiates.

    Keep the drawing style symbolic; too much detail can make it more difficult for users to understand what a button does.

    Use a flush 3D border to indicate that a button is clickable.

    Draw a clear, dark border without anti-aliasing or other exterior detail (except the flush 3D highlight) around the outside of a button graphic.

     
    Using Button Graphic Styles

    The following figure shows sample button graphics designed for toolbars and for the contents of a tool palette.

    Figure 36 Button Graphics for a Toolbar and a Tool Palette

    Use a single style to create a "family" of button graphics with common visual elements. You might use a similar palette, size, and style for different button groups, such as toolbar buttons, toggle buttons, or command buttons. Review the graphics in context before finalizing them.

     
    Producing the Flush 3D Effect

    To produce the flush 3D effect, add an exterior white highlight on the outside right and bottom of the graphic and an interior highlight on the inside left and top.

    Figure 37 Flush 3D Effect in a Button Graphic

     
    Working With Button Borders

    The size of a button graphic includes all the pixels within the border. As shown in the following illustration, horizontal and vertical dimensions are both either 24 or 16 pixels. The border abuts the button graphic (that is, there are no pixels between the border and the graphic).

    Figure 38 Button Graphics With Borders

     
    Determining the Primary Drawing Area

    Because the white pixels in both the button border and the button graphic are less visually significant than the darker borders, the area used for most of the drawing is offset within the 16 x 16 or 24 x 24 space. The following illustration shows the standard drawing area for both button sizes. Note that the white highlight used to produce the flush 3D style in the button graphic might fall outside this area.

    Figure 39 Primary Drawing Area in Buttons

    The following illustrations show 16 x 16 and 24 x 24 button graphics that use the maximum recommended drawing area. Notice that on all sides there are 2 pixels between the dark border of the button graphic and the dark portion of the button border.

    Figure 40 Maximum-Size Button Graphics

     
    Drawing the Button Graphic

    When drawing a button graphic, first decide on a general design that represents the action or setting activated by the button. In the following examples, a clipboard suggests the Paste command.

    1. Decide which size you want to use for the button or toolbar graphic.

    2. Draw a basic outline shape, taking care to remain within the primary drawing area.

    3. Add some basic color.

    4. Add the flush 3D effect by drawing highlights on the inside left and top, and on the outside bottom and right of the outline.

    This is a good basic design, but because of the large area using a single color, the graphic lacks visual interest and might not reproduce well on some systems.

    5. Try a gradient instead of the flat color.

    6. Add a pattern. This technique minimizes banding and dithering on displays with 256 or fewer colors (see Maximizing Color Quality).

    The first figure shows an exploded view of the button graphic without flush 3D highlights. The next figure shows the effect of the pattern on the color detail of the button graphic.

    7. Define the empty area around your button graphic (in which you have not drawn anything) as transparent pixels in the GIF file.

    This practice ensures that the background color shows through; if the theme changes, the area around the button graphic will match the rest of the background canvas in the interface.


     

    Designing Symbols

    Symbols include any small graphic (typically 48 x 48 pixels or smaller) that stands for a state or a concept but has no directly associated action or object. Symbols might appear within dialog boxes, system status alert boxes, and event logs. Saturated colors might be useful for status or warning symbols.

    The examples in the following figure show the graphic from an Info alert box and a caution symbol superimposed on a folder icon to indicate a hypothetical state. The style for symbols is not as narrowly defined as that for icons and button graphics. The examples in the following figure use a flush or etched effect for interior detail but not for the border of the graphic.

    Figure 41 Symbols

    Ensure adequate contrast between a warning symbol and the icon or background it appears against.

     

    Designing Graphics for Corporate and Product Identity

    Application graphics present an excellent opportunity for you to enhance your corporate or product identity. This section presents information about installation screens, splash screens, About boxes, and login splash screens.

    Note - The examples presented in this section use the sample text-editing and mail applications, MetalEdit and MetalMail. They are not appropriate for third-party use.

    Use the JPEG file format for any photographic elements in your installation screens, splash screens, and About boxes.

     
    Designing Installation Screens

    An installation screen is a window containing images that are displayed in an application installer. Often the first glimpse users have of your application is the installer. Consequently, an installation screen introduces and reinforces your corporate and product identity. The number of screens in an installer can vary.

    Use a plain window for installation screens, and draw any desired border inside the window.

    Provide a clearcut way for your users to move through the steps required to perform the installation, and enable them to cancel or stop the installation at any point.

    The JWindow component is typically used to implement plain windows.

    See Layout and Visual Alignment for general guidelines on how to arrange and align items.

     
    Designing Splash Screens

    A splash screen is a plain window that appears briefly in the time between the launch of a program and the appearance of its main application window. Nothing other than a blank space is included with a JFC-supplied plain window; you must provide the border and the contents of the splash screen. For instance, the black border on the window in the following figure is part of the GIF file supplied by the splash screen designer.

    Figure 42 Splash Screen for MetalEdit

    Although not required, splash screens are included in most commercial products. Splash screens typically have the following elements:

    • Company logo
    • Product name (trademarked, if appropriate)
    • Visual identifier of the product or product logo

    Check with your legal adviser about requirements for placing copyright notices or other legal information in your splash screens.

    To get the black border that is recommended for splash screens, you must include a 1-pixel black border as part of the image you create.

    The JWindow component, not the JFrame component, is typically used to implement the plain window that provides the basis for splash screens.

     
    Designing Login Splash Screens

    If your application requires users to log in, you might consider replacing the traditional splash screen with a login splash screen.

    Figure 43 Login Splash Screen for MetalMail

    The elements of this screen might include:

    • Label and text field for a login user name
    • Label and password field
    • Label and editable combo box for any other information required by the system
    • Buttons for logging in and canceling the login splash screen

    To save time and to increase the chance of users viewing a splash screen, it is a good idea to combine your login screen and your splash screen.

    Provide a way for users to exit the login splash screen without first logging in.

    The JDialog component, not the JWindow component, is typically used to implement a login splash screen.

     
    Designing About Boxes

    An About box is a dialog box that contains basic information about your application.

    Figure 44 About Box for MetalEdit

    An About box might contain the following elements:

    • Product name (trademarked, if appropriate)
    • Version number
    • Company logo
    • Product logo or a visual reminder of the product logo
    • Copyright, trademarks, and other legal notices
    • Names of contributors to the product

    Because users typically display About boxes by choosing the About Application item from the Help menu, be sure that the About box is accessible while your application is running.

    Because the dialog box title bar might not include a Close button on all platforms, include a Close button in your About boxes so that users can dismiss them after reading them. Follow the guidelines for button placement described in Spacing in Dialog Boxes.


    java.sun.com  :  Design Guidelines Previous  |  Next  |  Contents  |  Index  |  Search

    Copyright 1999 Sun Microsystems, Inc. All Rights Reserved.

     


     

    Handleiding BSCW

    Wat en waarvoor is BSCW?

    BSCW valt onder de categorie 'groupware' en biedt een z.g. 'shared workspace' aan. Om deze redenen gebruiken we het voor het delen van informatie en voor communicatie buiten de team sessies. In onze onderwijssituatie betreft dat het studenten team en begeleidende docenten

    Studenten team

    Docenten

    Belangrijke gedragsregels m.b.t. BSCW

    BSCW is oorspronkelijk ontworpen voor research groepen. Professionals die documenten delen en er gezamenlijk aan werken. Professionals ook die verantwoordelijkheid nemen m.b.t. gezamenlijke producten. Dit is exact de attitude die ook van iedereen verwacht wordt.

    Wie thuis in het wilde weg bestanden wist, bezorgt zichzelf problemen. Wie in BSCW dergelijke handelingen uitvoert, bezorgt de gehele groep problemen. BSCW verhindert dit niet, net zo min als je hard disk je tegen houdt bij wissen, verplaatsen ed. van bestanden. Met andere woorden: er is op BSCW geen 'speelkwartier'. Dit heeft ook betrekking op het veranderen van de z.g. 'Access Rights'. Blijf eraf, zelfs als je denkt te begrijpen wat je doet.

    BSCW is alleen bedoeld voor de zakelijke communicatie m.b.t. het teamwerk. Het is niet die handige schijf waar je even wat MP3 bestanden op zet. Het is ook niet die handige mailing list om collega's uit te nodigen voor een avondje stappen.

    Mail die je naar de hele groep stuurt, komt ook bij de docenten en de systeembeheerder aan. Deze zijn ook 'members'. Dat wordt wel erg veel mail de komende tijd. Let er dus op aan wie je mail verstuurt (zie verder).

    Inloggen

    BSCW is gekoppeld aan een web server en is toegankelijk via internet; dus ook van buiten de universiteit. De BSCW server houdt voor iedereen persoonlijk bij welke items nieuw zijn e.d. Je gebruikt een browser zoals Netscape of Internet Explorer (een recente versie a.u.b.).

    Beginners mode / expert mode

    Wie voor het eerst inlogt in BSCW, werkt in de 'beginners'-mode. Dat betekent dat je niet alles ziet en ook niet over versiebeheer beschikt. Wijzig jezelf daarom in ieder geval in expert door onder Options voor Preferences te kiezen en op de verschijnende schermpagina het User Profile op 'Expert' te zetten.

    Events

    Elke scherm bestaat uit een tabel. Op de regels staan folders, bestanden e.d. De kolommen geven informatie over de eigenaar, datum etc. plus events, aangegeven met enkele verschillende icons. Klikken op de 'bril' icon geeft je een overzicht van wat door de teamgenoten allemaal gelezen is. Zo weet je bijvoorbeeld of persoon x al naar je bijdrage heeft gekeken. Klikken op de 'voetafdruk' icon geeft je overzicht van alle wijzigingen: documenten die zijn gepost, folders die gemaakt of gewist zijn en door wie dat gebeurt is. Op deze wijze blijf je op de hoogte van het handelen van je teamgenoten.

    Events kun je verwijderen door op de 'Catch Up' button te drukken. Vanaf dat moment zie je alleen de nieuwe events. Dat gebeurt alleen voor jezelf: voor iedereen worden de events persoonlijk bijgehouden.

    Actions : versiebeheer

    Helemaal aan het eind van elke regel staat een kleine 'actions' button, die afhankelijk van het type regel (folder, document etc.) een aantal actions te zien geeft. Bij documenten kun je voor Version. Hiermee zet je een document onder versiebeheer. Dat betekent dat bij nieuwe postings de bestaande versie niei overschreven wordt, maar bewaard onder een versienummer. Deze optie moet je gebruiken voor documenten waaraan gezamenlijk gewerkt wordt. Iemand die een mutatie gaat plegen zal het document eerst van BSCW douwnloaden en dan onder actions voor Set Lock kiezen (zodat het gelocked is en niet anderen ondertussen ook aan het wijzigen gaan slaan). Het terugplaatsen van het document gaat in omgekeerde volgorde: Remove Lock en vervolgens uploaden.

    Folders en eigenaars

    Bovenaan het scherm, in het kader dat aangegeven is met 'Your location' zie je waar je je in de folderstructuur bevindt. Bij elke folder staan een groeps icoontje (twee gezichtjes). Klik je hierop dan zie je alle leden van de betreffende folder. Op dit scherm kun je ook eenvoudig een mailtje sturen naar alle personen, of degenen die je aangevinkt hebt. Het laatste is aan te bevelen omdat w.s. ook de docenten en de systeembeheerder (automatisch) tot de folderleden behoren, en zij willen niet graag alle mailtjes ontvangen.

    De folderstructuur kan heel complex kan lijken, vanwege de systematiek van toekennen van 'access rights'. Ben je zelf de owner van een folder of bestand, dan kun je ook een heleboel access rights aanpassen. Doe dit echter niet! Zelfs als je denkt te begrijpen wat je doet. Dit heeft in het verleden voor veel problemen gezorgd. In het kader van het onderwijsgebruik is het helemaal niet nodig dit te doen.  

    Nuttige browser instellingen

    Als je met een browser op BSCW staat, vervolgens een pagina buiten BSCW bezoekt en daarna met de Back button terugkeert, zal de BSCW server niet opnieuw om het username en password vragen. Prettig, maar dat geldt ook voor gebruikers die na jou op de pc (bijv. in het practicum) aan het werk gaan! Dit effect heeft alles te maken met de cache instellingen van je browser c.q. de opgebouwde history.
    Het is in ieder geval verstandig om in het practicum bij vertrek de sessie de history van de browser en de cache te wissen.

    Verder zijn m.b.t. de cache een aantal instellingen van belang voor een correcte werking van BSCW. Als je van de BSCW administrator een email krijgt ter bevestiging van je aanmelding bevat deze de betreffende aanwijzingen, waarvan we hier de laatste drie opnemen:

    3. Before using the BSCW server, please check that your Web browser is
    configured correctly: The browser should always contact the BSCW server
    before using pages from the cache:

        In Netscape 4.x:
            "Edit" --> "Preferences" --> "Advanced" -->
                "Cache" --> "Every time"

        In MS Internet Explorer 5:
            "Tools" --> "Internet Options" --> "General" -->
                "Temporary Internet files" --> "Settings" -->
                    "Every visit to the page"

    Note: Depending on your browser version the procedure to set these
    option may be a bit different.

    4. When using MS Internet Explorer 5 you should disable the Feature

            "Tools" --> "Internet Options" --> "Advanced" -->
                "Browsing" --> "Show friendly HTTP error messages"

    since IE5 may otherwise display meaningless error messages.

    5. Make sure that the clock on your computer is set correctly.
    Otherwise synchronisation between the BSCW server and pages in
    your local cache does not work.

    Voor de rest

    Er zijn nog veel meer instellingen, die je zelf moet exploreren of via de Help moet verkennen. Veel van deze instellingen kunnen de gebruikswaarde van BSCW verhogen.

    Systeembeheer maakt regelmatig backups. Dat wil niet zeggen dat alles ook echt veilig is. Regelmatig is bijvoorbeeld eens per week, op per dag - afhankelijk van de instellingen (die weer te maken hebben met het soort gebruik van de workspace).
    Systeembeheer houdt ook een uitvoerige logging bij: elke activiteit in BSCW wordt in principe vastgelegd. Dit is nodig om bij problemen naar de oorzaak te kunnen zoeken. Zolang je zelf niet de oorzaak van problemen bent hoef je je daar geen zorgen over te maken.

     


     

    Literatuurlijst

    Baecker, R.M. et al. (1995). Readings in Human-Computer Interaction : Toward the Year 2000. San Francisco : Morgan Kaufmann. Reader. Goed overzicht over evaluatiemethodes.
    Cato, John (2001). User-Centered Web Design. Addison-Wesley 'Kookboek' voor websites.
    Chen, Qiyang (2001). Human Computer Interaction : Issues and Challenges. Idea Group Publishing.  
    Cooper, A. & Reimann, R.M. (2003). About Face 2.0: The Essentials of Interaction Design. John Wiley & Sons.
    Dix, A.J. et al. (1998). Human-Computer Interaction. Englewood Cliffs : Prentice Hall. Standaardboek m.b.t. HCI
    Fowler, M. & Scott, K. (2000). UML Distilled (Second Edition) : A Brief Guide to the Standard Object Modeling Language. Reading Mass. : Addison-Wesley. Behandelt de UML schematechnieken voor software-ontwikkeling. De huidige UML versie (1.5) is verder dan die in het boek behandeld wordt (1.3). Sommige symbolen zijn daardoor niet meer geheel up to date. Verder een goed leesbare inleiding.
    Galitz, W.O. (2002).The Essential Guide to User Interface Design. John Wiley & Sons.
    Hackos, J.T. & Redish, J.C. (1998).User and Task Analysis for Interface Design. John Wiley & Sons.
    Harst, G. van der & Maijers, R. (1999). Effectief GUI-ontwerp : Een praktische ontwerpaanpak voor browser- e Windows-interfaces. Schoonhoven : Academic Service. Redelijk volledig boek met een praktische inslag. Goed leesbaar.
    Helander, M.G. et al. (1997). Handbook of Human-Computer Interaction. Amsterdam : North-Holland.  Dik (1500 pag.; prijzig!) boek met hoofdstukken van (vele) gerenommeerde auteurs.
    Hix, D. & Hartson, H.R. (1993). Developing User Interfaces : Ensuring Usability Through Product & Process. New York : John Wiley & Sons.  
    Isaacs, E. & Walendowski, A. (2002). Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology. New Riders Publishing.  
    Johnson, Jeff (2000). GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers. San Diego : Academic Press.
    Laurel, B. (1990). The Art of HCI Design. Reading Mass. : Addison-Wesley.
    Mayhew, D.J. (1992). Principles and Guidelines in Software User Interface Design. Englewood Cliffs: Prentice-Hall
    Mayhew, D.J. (1998). The Usability Engineering Lifecycle. San Diego, Acadamic Press (Morgan Kauffman) 'Kookboek' o.b.v. veel praktijkervaring. Bevat weinig tot geen theorie.
    Newman, W.M. & Lamming, M.G. (1995). Interactive System Design. Reading Mass. : Addison-Wesley.
    Nielsen, J. (2002). Homepage Usability: 50 Websites Deconstructed. New Riders Publishing.
    Preece, J. et al. (1994). Human-Computer Interaction. Reading Mass. : Addison-Wesley. Breed opgezet boek met onderwijskundige opzet (samenvattingen, vragen, oefeningen). Veel illustraties. Z.g. 'boxes' met mini-artikelen. Interviews met vooraanstaande personen. Opzettelijke herhalingen in de tekst. Ietwat gedateerd. Bruikbaar als inleiding op HCI, mist soms diepgang.
    Preece, J. et al. (2002). Interaction Design. John Wiley & Sons Dit boek lijkt de opvolger te zijn van de uitgave uit 1994. De opzet is breed en komt overeen met de vorige uitgave.
    Nielsen, J. (1994). Usability engineering. San Francisco : Morgan Kaufmann. Standaard werk op het gebied van usability engineering. Voor een inhoud van dit boek, een hoofdstuk en links naar andere artikelen: zie http://www.useit.com/jakob/useengbook.html
    Norman, D.A. (1988).The Psychology of Everyday Things. Basic Books. Klassieker. Fools Can Be So Ingenious!
    Rees, Michael [et al.](2001). Web Interfaces : Interactive Workbook. Prentice Hall 'Kookboek' voor websites, dat enige HCI-theorie bevat.
    Sanders,M.S. & McCormick, E.J. (1992). Human Factors In Engineering and Design. McGraw Hill (7e druk). Ever since the first edition was published in 1957, this landmark book (then titled Human Engineering) has been considered as a Bible in the area of Human Factors in engineering and design. This is a course book and a good reference for Industrial Engineers, Designers, Architects, etc. Any person who is involved in any way with humans and their interaction with their workplace will have a great deal of understanding about his task, once he reads this book.
    Shneiderman, B. (1998). Designing the User Interface : Strategies for effective human-computer interaction. Reading Mass. : Addison-Wesley. Standaardboek m.b.t. HCI. Het accent ligt enigzins op de C in HCI.

     


     

    Webbronnen

    Alle links openen in een nieuw venster
    ACM
    http://www.acm.org/sigchi/
    The ACM Special Interest Group on Computer-Human Interaction. The scope of SIGCHI consists of the study of the human-computer interaction process and includes research and development efforts leading to the design and evaluation of user interfaces. The focus of the SIG is on how people communicate and interact with computer systems. SIGCHI serves as a forum for the exchange of ideas among computer scientists, human factors scientists, psychologists, social scientists, systems designers and end users. SIGCHI offers its members the "Member Plus" package and co-sponsors a number of conferences and workshops each year, including the annual CHI conference. The SIGCHI Bulletin is published quarterly.

     

    W3Schools  www.w3schools.com/ Goede intro's, voorbeelden en naslag voor html, css, script etc.

     

    http://www.m-w.com/netdict.htm Websterís Collegiate woordenboek en thesaurus
    Uitleg van termen in het Engels.
    Op http://www.yourdictionary.com/diction3.html#english vind je andere on-line bronnen (i.h. engels)

     

    http://www.techweb.com/encyclopedia/ Tech Encyclopedia
    Uitleg van (14.000+) termen op computergebied

     

    http://www.britannica.com/ Britannica online encyclopedie

     

    http://www.filespecs.com/index.jsp Informatie over bestandsformaten

     

    Apple Macintosh : Interface Guidelines
    http://developer.apple.com/techpubs/macos8/mac8.html

     

     

    Microsoft : Design Guidelines for Windows XP
    http://www.microsoft.com/hwdev/windowsxp/downloads/
    Zie ook: Windows 98/2000 UI Design Guidelines op http://msdn.microsoft.com/library/default.asp?
    URL=/library/books/winguide/ch00a.htm

     
    Het is mogelijk dat deze site problemen oplevert als je arriveert met een niet-Microsoft browser (!= Internet Explorer).

     

    Welcome to Java Software Platform Human Interface
    Here find information on the JavaTM look and feel (including the Java Look and Feel Graphics Repository.), related papers, guidelines, how to participate in our Usability Studies and other related Human Interface topics.
     
    Guidelines van de cross platform taal Java (Sun Microsystems)
    NIMA : HCI Guidelines 
    http://164.214.2.59/TAT/hci_pages/hci_guidelines.html

     

     

    Perlman, G. HCI Bibliography.
    http://www.hcibib.org
    Zéér uitgebreide website op het gebied van HCI (geeft aan 20.000 records te hebben)

     

    Porteous, M.A. et al. (1993). SUMI Questionnaire. SUMI Home: http://www.ucc.ie/hfrg/questionnaires/sumi/index.html. De SUMI Questionnaire bevat 50 vragen (op een 3-puntsschaal) t.b.v. gebruikersevaluatie. Internationale standaard.

     

    Smith, S.L & Mosier, J.N. (1986). Guidelines for Designing User Interface Software
    http://www.hcibib.org/sam/ of Smith & Mosier [PDF, 641KB]
     

     

    Usability FirstTM
    http://www.usabilityfirst.com
     
    Your online guide to usability resources.

     

    Usable web
    http://usableweb.com
    Thematisch geordend links naar artikelen.

     

    Useit.com (Nielsen, Jakob)
    http://www.useit.com/
    Usability engineering

     

    Tognazzini, Bruce
    http://www.asktog.com/tog.html
    "Contact me or read my new webzine, AskTog"
    Zie ook de kopie van het hoofdstuk 'Case Study : One-Or-More Buttons' uit het boek Tog on Interface

     

    http://www.usabilityweb.nl/
     
    Nederlandstalige kennisbank voor gebruikersvriendelijke websites
     
    Peterned http://www.xs4all.nl/~peterned/ Een opmerkelijke site (voor technici) over web development waar o.a. het onderste uit de kan gehaald wordt m.b.t. client scripting, css e.d.
     
    W3C http://www.w3c.nl/Vertalingen/2000/WAI-WEBCONTENT/WAI-WEBCONTENT-NL.html W3C richtlijnen voor de toegankelijkheid van Web Content 1.0
     
    Color Wheel Pro Color Wheel Pro is a program that allows you to see color theory in action: you can create harmonious color schemes and preview them on real-world examples.