Samenvatting

Het ongeluk bij Ueberlingen op 1 juli 2002 is het tragische resultaat van een ongelukkige samenloop van omstandigheden waarbij 71 mensen om het leven kwamen. Het is een ongeluk waarbij de technologie werkte zoals bedoeld, en de mens de zwakste schakel bleek. De gemaakte mensenlijke fouten zijn stuk voor stuk wellicht voorstelbaar, maar leiden desondanks tot de desastreuze gevolgen. Om deze reden dienen uit dit ongeluk lessen getrokken te worden waarmee een nieuw soortgelijk ongeluk kan worden voorkomen.

Inleiding

Op 1 juli 2002 zijn twee vliegtuigen op elkaar gebotst. Bij het ongeval kwamen 71 mensen om het leven, voornamelijk schoolkinderen. Het incident vond ‘s avonds laat plaats in de buurt van de Zuid-Duitse plaats Ueberlingen. Een Tupolev was onderweg van Moskou naar Barcelona, een Boeing van Bergamo naar Brussel. Hoe hebben twee vliegtuigen tijdens een heldere nacht zonder druk vliegverkeer elkaar zo exact kunnen raken? Op het eerste gezicht lijkt dit een freak-accident. Nadere analyse brengt feiten aan het licht waar lering uit getrokken kan worden. Dat deze lessen nodig zijn blijkt uit het feit dat een jaar eerder een soortgelijke situatie heeft plaatsgevonden, waarbij meer dan 700 mensen betrokken waren.

Analyse van de gebeurtenissen

De twee vliegtuigen vlogen op dezelfde hoogte en hadden een koers en snelheid waarbij het onvermijdelijk was dat ze elkaar zouden raken. De beide vliegtuigen waren echter uitgerust met een TCAS. Dit is een apparaat aan boord van een vliegtuig dat andere vliegtuigen in de buurt kan detecteren en zodoende botsingen kan voorspellen. Wanneer de TCAS een botsing ziet aankomen, zal het de bemanning van beide vliegtuigen een advies geven en zo een daadwerkelijke botsing voorkomen. Het ene vliegtuig krijgt het advies te stijgen (in dit geval de Tupolev), het andere om te dalen (de Boeing).

Het apparaat functioneerde in beide vliegtuigen goed. De goed werkende techniek heeft desondanks dit ongeval niet kunnen voorkomen. Zoals vele ongelukken was ook dit ongeluk een samenloop van omstandigheden. De Boeing volgende het advies van de TCAS om te dalen. De Tupolev daalde tegelijktertijd ook. Niet op advies van de TCAS, die adviseerde te stijgen, maar op advies van de luchtverkeersleiding. De luchtverkeersleiding gaf dit advies zonder te weten dat de TCAS adviseerde te stijgen. Al is het cru, men kan stellen dat zonder tussenkomst van de luchtverkeersleiding het ongeluk niet zou hebben plaatsgevonden.

Het is duidelijk dat zowel de luchtverkeersleiding als de bemanning van de beide vliegtuigen geen compleet overzicht hadden van de situatie. De enige die wel een botsing zag aankomen was de algehele luchtverkeersleiding in Karlsruhe. Deze probeerde contact te leggen met de lokale luchtverkeersleiding in Zurich, maar kon wegens problemen met de telefoon geen contact krijgen.

De lokale luchtverkeersleiding in Zurich was op het moment van het ongeluk bemand door slechts één persoon. Dit was een langstaande traditie binnen het luchtverkeersleidingscentrum. De tweede persoon had pauze en bevond zich enkele kamers verderop. De persoon die dienst had, had juist een vliegtuiglanding begeleid. Voor deze landing had hij zowel zijn eigen scherm, als het scherm van zijn collega nodig. Hij kon beide schermen alleen overzien door met zijn burostoel tussen beide scherm heen-en-weer te rijden. Het begeleiden van de landing en het heen-en-weer pendelen tussen twee schermen vormde een afleiding voor de luchtverkeersleider.

Wellicht even tragisch als het ongeluk zelf is de gebeurtenis van een jaar later. De luchtverkeersleider die tijdens het ongeluk in Zurich dienst had is door messteken vermoord. Of er een rechtstreeks verband is met het ongeluk is niet met 100% zekerheid te zeggen. Het is wel duidelijk dat een vliegtuigongeluk een beladen onderwerp is waarbij de emoties hoog oplopen, zowel op persoonlijk, economisch als op politiek nivo. Er wordt snel gezocht naar één schuldige terwijl iedereen in de hele vliegtuigindustrie een aandeel heeft in de veiligheid van alle betrokkenen.

Aanbevelingen

• Piloten dienen het advies van de TCAS te volgen, ook als ze een tegenstrijdig advies krijgen van de luchtverkeersleiding. Zij dienen dit tegenstrijdige advies te melden aan de luchtverkeersleiding.
• De luchtverkeersleiding dient altijd door minimaal twee personen bemand te worden.
• De werksituatie in Zurich dient aangepast te worden zodat luchtverkeersleiders makkelijker op elkaars schermen kunnen kijken.
• Ongelukken dienen onpartijdig onderzocht te worden en tijdens rapportages dient naar alle partijen, van nabestaanden tot vliegtuigbouwers, duidelijk te worden gemaakt dat er vrijwel nooit één schuldige valt aan te wijzen.

Dat metaforen nut hebben wordt ondersteund door de studie van Hsu et al (Hsu, 2002). Zij lieten proefpersonen zoeken in een grote tekst die middels drie verschillende user-interfaces doorzoekbaar was. In de eerste interface kon alleen via hyperlinks van artikel naar artikel worden genavigeerd. De tweede interface was daarnaast opgebouwd als boek en via de inhoudsopgave doorzoekbaar. De derde interface ondersteunde ook het zoeken via een folder systeem waarbij de hoofdstukken als tabbladen zichtbaar waren. Des te meer metaforen werden gebruikt, des te sneller en beter konden de proefpersonen, op de tekst betrekking hebbende, vragen beantwoorden.

Uit het voorbeeld van de orientatiemetafoor blijkt dat bij het gebruik van metaforen sterk rekening moet worden gehouden met cultuurverschillen. In oosterse culturen wordt van rechts naar links gelezen waardoor de metafoor rechts is verder geen (of minder) betekenis heeft (Barr, 2005). In het algemeen kan gesteld worden dat metaforen afgestemd dienen te worden op het kennisnivo van de gebruiker. Wanneer de gebruiker niet bekend is het brondomein, dan heeft de metafoor geen nut.

Hetzelfde kan gesteld worden wanneer de mapping van bron- naar doeldomein niet aansluit (Erickson, 1990). Wanneer een metafoor in het doeldomein niet volledig wordt gebruikt, dan kan dit verwachtingen scheppen die bij de gebruiker niet worden ingevuld. Zo kan een bestand wel in een map geplaatst worden, maar een map kan niet in een archiefkast. Ook kunnen in een computer mappen een eindeloze hiërarchie vormen. Deze mismatch tussen bron- en doeldomein kan bij gebruikers veel verwarring schepping waardoor het gebruik van de metafoor wordt ontkracht.

Erickson geeft een aantal concrete aanbeveling ten aanzien van het gebruik van metaforen (Erickson, 1990):

• Een metafoor moet structuur en houvast geven aan de gebruiker. Des te concreter het brondomein is, des te beter.
• Het brondomein moet bekend zijn bij de gebruiker. Des te meer de gebruiker weet over het brondomein, des te levendiger beeld hij zich kan vormen.
• Het brondomein moet relevant zijn en nauw aansluiten op het doeldomein.
• Het gebruik van de metafoor moet in de toekomst uitbreidbaar zijn. Wanneer nieuwe functionaliteit in de software beschikbaar komt, dan moet de aanpassing in de user-interface voort kunnen bouwen op de eerder gekozen metafoor.

Literaatuurlijst

Barr, P, Biddle R & Noble J (2005), A taxonomy of user-interface metaphors

Erickson T.D. (1990), Working with interface metaphors

Hsu, Y & Schwen, T. M (2002). The effects of structural cues from multiple metaphors on computer user’s information search performance

Metaforen zijn in te delen in een taxonomy. Deze bestaat uit orientatiemetaforen, ontologische metaforen, structuurmetaforen en metonymische metaforen (Barr, 2005).

Een orientatiemetafoor maakt onder andere gebruik van richting om betekenis te geven. Zo is in de westerse cultuur de betekenis van rechts: verder of volgende. Van deze metafoor kan gebruik gemaakt worden door in een user-interface een pijltje naar rechts te gebruiken om naar een volgende pagina te navigeren. Een pijltje naar links betekend terug en naar boven betekend naar een bovenliggend nivo.

Een ontologische metafoor gebruikt een concreet object om iets abstracts te duiden. In het volgende fragment wordt tijd als object gebruikt: “Ik heb niet genoeg tijd.” Ontologische metaforen zijn in eerste instantie lastig voor te stellen in een user-interface. Tegelijkertijd zijn ze overal. Denk hierbij aan fouten die iets kunnen veroorzaken. Let wel dat de fout een voor de gebruiker abstract concept is, terwijl dit voor de programmeur niet abstract hoeft te zijn.

Structuurmetaforen helpen bijvoorbeeld om het werken met data eenvoudiger te maken. Data wordt in de user-interface getoond als bestanden, die in mappen kunnen worden geplaatst. Een bestand en een map zijn elementen, het verplaatsen is een proces. De gebruiker denkt hierdoor in bekende termen en hoeft niet te begrijpen wat er daadwerkelijk in de computer gebeurt.

Wanneer in een user-interface een kleine foto van een persoon wordt getoond om de gehele persoon aan te duiden, dan is sprake van een metonymy. Bij een metonymy wordt een deel van iets gebruikt om iets groters aan te duiden. Dit hoeft geen concreet element te zijn, maar kan ook verwijzen naar een proces. Een voorbeeld hiervan is het gebruik van icoontjes waarmee een actie kan worden gestart. Het icoontje stelt de actie voor.

Literaatuurlijst

Barr, P, Biddle R & Noble J (2005), A taxonomy of user-interface metaphors

Erickson T.D. (1990), Working with interface metaphors

Hsu, Y & Schwen, T. M (2002). The effects of structural cues from multiple metaphors on computer user’s information search performance

Bij het ontwerpen van user-interfaces wordt al sinds de jaren 80 gebruik gemaakt van metaforen (Hsu et al, 2002). In het dagelijks leven gebruiken we iedere dag metaforen, los van de computer en user-interfaces. Metaforen zijn een integraal deel van ons leven, terwijl we dat vaak niet beseffen (Erickson, 1990). Ter illustratie geven Lakoff en Johnson in hun boek, Methaphors We Live By, een beschrijving hoe een discussie kan worden beschreven in termen van oorlog (in: Erickson, 1990). Een discussie heeft partijen die hun posities verdedigen en zwakke stellingen van de andere partij aanvallen. Door een discussie in termen van oorlog te beschrijven wordt het duidelijker wat een discussie is. Bij de concrete term oorlog kunnen mensen zich een beter beeld vormen dan bij de abstracte term discussie.

Een metafoor wordt gebruikt om iets wat nieuw of abstract is te begrijpen door termen te gebruiken uit een geheel ander domein. Een domein wat wel bekend of concreet is. Een metafoor heeft daarmee twee componenten: het brondomein en het doeldomein (Barr, 2005). Het brondomein is het bekende (in het vorige voorbeeld de oorlog). Het doeldomein is het domein waarop het brondomein wordt toegepast (de discussie). Het doeldomein wordt beschreven in termen van het brondomein.

Literaatuurlijst

Barr, P, Biddle R & Noble J (2005), A taxonomy of user-interface metaphors

Erickson T.D. (1990), Working with interface metaphors

Hsu, Y & Schwen, T. M (2002). The effects of structural cues from multiple metaphors on computer user’s information search performance

De mens heeft al veel ontdekt. De tijd waarin de grote oceanen bevaren werden om nieuwe werelden te ontdekken ligt ver achter ons. Toch leren we iedere dag nog bij. De afgelopen eeuwen hebben we zelfs ontdekt dat er zoveel te ontdekken valt dat het handig is om kennis en ervaring te delen en van generatie op generatie over te dragen. Zo voorkom je dat iets wat al ontdekt is, niet nog een keer ontdekt hoeft te worden. Boeken, scholing en wetenschap zijn geboren.

Hoewel ontdekken leuk is (of op z’n minst ‘kan zijn’), zijn er redenen waarom je niet alles zelf wilt uitvogelen. Velen zijn je voor gegaan en het is nuttig om van die ervaring gebruik te maken. Dat scheelt een hoop moeite en frustratie. En niet te vergeten tijd. Ontdekken kost soms zoveel tijd dat je de moed opgeeft voordat je iets ontdekt hebt. Iets van een ander leren maakt het leven dus leuker en makkelijker. Je leert dingen die je zelf nooit had kunnen ontdekken.

De ontdekbaarheid van dingen (in het Engels aangeduid met de term discoverability) is een belangrijk concept. Iets is goed ontdekbaar als je het in korte tijd kunt ontdekken, zonder aanwijzingen van anderen of gebruik van een boekje. De letterlijke betekenis dus. Kun je bij een pinautomaat snel ontdekken hoe je er geld uitkrijgt? Kun je van een onbekende auto snel ontdekken hoe je moet starten en wegrijden? Een nieuw softwareprogramma of website: hoe snel ontdek je de belangrijkste functionaliteiten? Dat is ontdekbaarheid.

Niet alles in de wereld is van zichzelf makkelijk ontdekbaar of ontdekbaar te maken. Sommige dingen zijn gewoon inherent lastig. Denk aan Einstein’s relativiteitstheorie. Daarvan is het handig als iemand het uitlegt. De magnetron, om een geheel ander voorbeeld te noemen, moet je kunnen gebruiken zonder cursus of handleiding. En een nieuw computerprogramma? Nieuwe software zó eenvoudig maken dat alle functies makkelijk ontdekbaar zijn is op zich goed te doen. Je doet dit door alle knoppen en teksten zo te plaatsen dat het voor de nieuwe gebruiker logisch is. Hiep, hoi, ontdekbare software!

Houdt er echter rekening mee dat software die voor nieuwe gebruikers ontdekbaar is, voor meer ervaren gebruikers onwerkbaar kan zijn. Denk hierbij aan een geluidstechnicus die op een My First Sony de nieuwste kneiter van Frans Bauer in elkaar mixed. Het verbeteren van de ontdekbaarheid van software heeft duidelijk een keerzijde. Professionele software die bedoeld is om door ervaren gebruikers gebruikt te worden zal per definitie niet optimaal ontdekbaar zijn. Lekker productief werken met sneltoest-combinaties is voor de ervaren doelgroep bijvoorbeeld belangrijker dan de ontdekbaarheid daarvan.

De ontdekbaarheid van software (of andere complexe systemen en apparaten) is niet altijd het hoogste doel. Aan ontdekbaarheid moeten soms concessies worden gedaan, ten behoeve van de fase die na de ontdekking komt: het productief gebruik. Dit heeft twee belangrijke consequenties. Ten eerste werkt, in de verkoop en promotie van software en websites, het verstrekken van proeflicenties niet. De toekomstige gebruiker zal de software beoordelen op wat hij er in de eerste 30 minuten mee kan. En dat is by design dus vrij weinig. Onervaren gebruikers zullen de software daarmee als onwerkbaar beschouwen. Onterecht, maar zeer begrijpelijk.

Ten tweede: iets wat lastig is om zelf te ontdekken, kun je het beste eerst een keertje bij een ander afkijken. Voor software waarbij concessies zijn gedaan aan de ontdekbaarheid heeft training een extreem grote waarde. Doen dus! Of lees op zijn minst een goed boek. Ben je als gebruiker de eerste fase van ontdekken doorgekomen, dan heeft training zijn waarde verloren; de functionaliteiten zijn ontdekt. Een boek of verdiepingstraining heeft dan hooguit nog waarde als naslagwerk of om nieuwe foefjes te leren.