Algemeen Jacques Ellul Günther Anders Lewis Mumford Herbert Marcuse Andrew Feenberg Wiebe Bijker Algemeen Luddieten Wapentuig als voorbeeld Transport Radio en televisie Internet Artificiële intelligentie Algemeen Hypermedia en hypertext Informatieovervloed Privacy Spionage, inlichtingendiensten Cyberoorlog Hackers Algemeen Het schrift Boeken en tijdschriftenCooper is een Amerikaans programmeur die al in de zeventiger jaren bedrijfsapplicaties programmeerde en ook aan de wieg stond van Visual Basic.
Hij richtte uiteindelijk een bedrijf op dat zich gewijd heeft aan 'interaction design', aan het ontwerpen dus van software en toepassingen die rekening houden met de manier waarop mensen werken.
Alan COOPER"The point of this book is uncomplicated: We can create powerful and pleasurable software-based products by the simple expedient of designing our computer-based products before we build them."(xvii)
[De benadering is dus gelijk aan die van Donald A. Norman.]
Dit hoofdstuk begint met een vliegtuigongeluk door een menselijke fout van een piloot. Die fout kon echter gemaakt worden door het slechte design van de boordcomputers. [Norman heeft vergelijkbare voorbeelden.] Andere voorbeelden van slecht design volgen.
"... a fundamental truth about computers: They may tell us facts, but they don't inform us. They may guide us with precision, but they fon't guide us where we want to go."(4)
Cooper wijst er [ook weer als Norman] op dat wat logisch en goed is voor techneuten nog niet goed is voor gewone gebruikers.
"Although computer operating systems need hierarchical file systems, the people who use them don't. It's not surprising that computer programmers like to see the underlying hierarchical file systems, but it is equally unremarkable that normal users like Jane [uit een eerder gegeven voorbeeld] don't. Unremarkable to everyone, that is, except the programmers who create the software that we all use. They create the behavior and information presentation that they like best, which is very different from the behavior and information presentation that is best for Jane. Jane's frustration and inefficiency is blamed on Jane, and not on the programmers who torpedoed her."(11)
"The high-tech industry is in denial of a simple fact that every person with a cell phone or a word processor can clearly see: Our computerized tools are too hard to use. (...) The high-tech industry has inadvertently put programmers and engineers in charge, so their hard-to-use engineering culture dominates. Despite appearances, business executives are simply not the ones in control of the high-tech industry. It is the engineers who are running the show. In our rush to accept the many benefits of the silicon chip, we have abdicated our responsibilities. We have let the inmates run the asylum. When the inmates run the asylum, it is hard for them to see clearly the nature of the problems that bedevil them."(15)
"To be a good programmer, one must be sympathetic to the nature and needs of the computer. But the nature and needs of the computer are utterly alien from the nature and needs of the human being who will eventually use it."(16)
De oplossing: interaction design.
Cognitieve frictie is de weerstand die een mens ontmoet wanneer hij / zij aan de slag wil met een ingewikkeld systeem van regels die veranderen wanneer het probleem verandert. Interactie met software kent een heel hoge graad van cognitieve frictie in tegenstelling tot interactie met fysieke apparaten. Daarom is interaction design van software noodzakelijk die die frictie omlaagt brengt. En dat kan er niet pas op het eind even aan toegevoegd worden, het moet het beginpunt zijn van het hele ontwikkelproces.
"Almost all interaction design refers to the selection of behavior, function, and information and their presentation to users. "(22)
Cooper spreekt liever niet van 'interface design'. Dat roept het beeld op van iets wat er op het eind aan toegevoegd kan worden, los van de rest van het proces. Het idee achter 'interaction design' gaat veel verder. En het moet maken dat gebruikers van producten zich niet stom voelen.
"Cognitive friction doesn't come from technology, but from the people who control technology."(27)
En de grootste fout die er gemaakt wordt is: het eindeloos toevoegen van functies en 'features' zodat de interface en het gebruik ervan steeds complexer worden:
"the difficulty of operation increases more rapidly than the usefulness increases."(29)
"You can predict which features in any new technology will get used and which won't. The usage of a feature is inversely proportional to the amount of interaction needed to control it."(33)
Op het moment wordt van iedereen verwacht dat hij of zij met zeer complexe technologie kan omgaan ('computer literacy'). Vroeger werd dat overgelaten aan getrainde professionals, nu wordt elke amateur geacht alles van een apparaat te snappen.
"Thus the term 'computer literacy' becomes a euphemism for social and economic apartheid. Computer literacy is a key phrase that brutally bifurcates our society."(38)
Een kritiek op de haast en de deadline-cultuur bij het ontwikkelen van software, waardoor gebruikers slechte producten voorgeschoteld krijgen. Het ontbreekt managers aan een visie op wat een afgerond product is. Je hebt daarvoor een preciese beschrijving nodig, fysiek zowel als qua gebruik.
"Unfortunately most software products never have a description. Instead all they have is a shopping list of features."(42)
"Without blueprints, the software builders don't really have a firm grasp on what makes the product 'done', so they pick a likely date for completion, and when that day arrives they declare it done."(43)
"I've seen Product Managers sacrifice not only design, but testing, function, features, integration, documentation, and reality. Most Product Managers that I have worked with would rather ship a failure on time than risk going late."(44)
Dat betekent een voortdurende onderhandeling over 'features' waarin de programmeurs een grote invloed hebben en gemakkelijk hun vooroordelen en persoonlijke voorkeuren kunnen volgen. Maar gebruikers zijn helemaal niet zo uit op 'features', gebruikers willen simpelweg hun doelen kunnen bereiken. Soms zijn daarvoor bepaalde 'features' nodig, maar vaak helemaal niet. De kostbare gevolgen van slechte software zijn vaak verborgen (mensen die die software niet meer zullen gebruiken, mensen die een hekel aan hun baan krijgen waar ze die software moeten gebruiken en daardoor fouten maken, en zo verder).
Wanneer er tevoren geen design gemaakt is, zitten programmeurs maar wat uit te proberen en kunnen ze niet loskomen van hun eigen ideetjes en code. Daarom heeft 'design achteraf' geen enkele zin.
Wat, dus, is slechte software? Vanuit de metafoor 'dancing bearware' die Cooper gebruikt voor slechte software (wanneer je een beer ziet dansen ben je meer onder de indruk van dat een beer kan dansen dan van het dansen als zodanig):
"So few software-based products have exhibited any real dancing ability that most people are honestly unaware that things could be better - a lot better. "(59)
Voorbeelden: emailprogramma's, agenda- en projectplanningssoftware, webbrowsers. Wat is er verkeerd aan?
Goede software maakt dat gebruikers loyaal worden aan die software. Dat is voor een bedrijf van groot belang. Daarvoor is een goede balans nodig tussen wat technisch kan ('capability'), verkoopbaar is ('viability'), en wat klanten willen van een product ('desirability'). En het beste is om uit te gaan van het laatste. [Dit is het 'tripod'-model van Keeley dat ook Norman beschrijft.]
Voorbeelden van gebrek aan balans: Novell's Netware, Microsoft, Apple.
Programmeurs zijn niet getraind voor 'interaction design'.
"Despite all the marketing rhetoric, the form of our products is really determined by those people least equipped to do so."(81)
Voorbeelden daarvan en de mislukkingen die daarvan het gevolg waren.
"Software is more like a bridge than an edifice. Although it runs on high-technology microprocessors, it must be operated and used by mere mortals. Amid all the attention and excitement about new technology, we overlook the incredible differences between computers and the humans who have to use them."(87)
"Clearly, one side of software - the inside - must be written with technical expertise and sensitivity to the needs of computers. But equally clearly, the other side of software - the outside - must be written with social expertise and sensitivity to the needs of people. It is my contention that programmers can do the former, but it takes interaction designers to do the latter."(88)
Zo noemt Cooper programmeurs in dit hoofdstuk. Dit gaat over de manier waarop programmeurs zaken benaderen en zich gedragen: de psychologie van de computerprogrammeur.
"Homo logicus desires to have control over things that interest them, and the things that interest them are complex, deterministic systems. People are complex, but they don't behave in a logical and predictable way, like machinery. (...) Controlling humans is less appealing from the programmer's point of view."(96)
Programmeurs houden van complexiteit, hebben er heel veel voor over om te begrijpen hoe iets dat complex is in elkaar steekt en om daar controle op te krijgen. Gewone mensen willen eenvoud en resultaat / succes bij wat ze doen. en daarvoor willen ze wel de controle overlaten aan anderen.
"Normal humans are quite content not to know how something works, even though they use it and depend on it in their everyday lives. They see implementation model interfaces [dicht bij de machine, zoals programmeurs dat gewend zijn] as imposing an unnecessary burden of understanding on them. Programmers find such attitudes inscrutable."(99)
Bij het programmeren kan een afwijkend iets, een uitzondering, fataal zijn. Programmeurs zijn dus gespitst op mogelijke uitzonderingen en doen er alles voor om die voor te zijn en te vermijden of te controleren. Vandaar dat ze de neiging hebben om interfaces vol te proppen met opties. In het normale leven van normale mensen zijn uitzonderingen juist iets waarvan je moet uitgaan en richt je je op de grote lijnen. Een interface hoeft dus alleen de belangrijke opties te hebben.
Daarnaast hebben veel programmeurs een heel onvolwassen attitude, ook als ze ouder zijn geworden: ze lachen om mensen die niet met computers kunnen wat zij kunnen en minachten ze. Ook dat levert geen producten op die gemakkelijk zijn te gebruiken voor die normale mensen.
Programmeurs letten meer op de slimmigheden in (hun) code dan op de behoeften van gebruikers. Daarom zullen ze snel code hergebruiken die goed is. Vanuit het perspectief van 'interaction design' kan dat echter helemaal verkeerd uitwerken.
"... programmers believe that their own imperatives of construction simplicity and ease of acquisition of pre-written source code take precedence over any suggestions [zo worden specificaties door hun dan gezien] made by others."(107)
"As you can see, there is a clear conflict of interest between what the user needs and what the programmer needs. (...) We never let basketball players referee their own basketball games. The conflicting interests are clearly visible, yet we consistently let programmers make design decisions based on personal implementation considerations."(108)
"They [de programmeurs] take our precisely rendered screen shots and treat them as vague suggestions for the interface. They take our list of functions and features and cherry-pick those items from it that they personally agree with or that are particularly easy for them to build."(109)
Programmeurs hebben door alle genoemde zaken een nerd cultuur die wereldwijd hetzelfde is. Respect voor technische vaardigheden / deskundigheid staat centraal. Hun bazen - die zelf meestal ook programmeurs zijn geweest - hebben dezelfde instelling. Voorbeeld: Microsoft. N.a.v. Fred Moody's boek (I sing the body electronic van 1995) over de programmeercultuur bij dit bedrijf:
"The book is a remarkable chronicle of how arbitrary, demoralizing, and unprofessional Microsoft's development methods often are."(111)
"Software engineers respect others in their own areas, but when a non-programmer ventures into the world of programming, as Moody described, programmers become condescending or even elitist."(117)
"It doesn't require sophisticated tools to dehumanize your fellow human - a glance or a kick does it as well. It is not technology that is dehumanizing. It is the technologists, or rather the processes that technologists use, that create dehumanizing products."(120)
Vanaf dit hoofdstuk gaat Cooper de methode ('Goal-Directed Design') uitleggen die tot goede software leidt. Drie van de meest krachtige 'tools' zullen worden besproken.
[Voor mij is dat meteen wat minder interessant. Ik zoek zelf geen praktische oplossingen, ben meer uit op het begrijpen van het probleem..]
"The most obvious approach, to find the actual user and ask him, doesn't work for a number of reasons, but the main one is that merely being the victim of a particular problem doesn't automatically bestow on one the power to see its solution. The actual user is still a valuable resource, and we devote considerable attention to him or her, but we never let the user directly affect the solution."(123)
In plaats daarvan wordt er met hypothetische archetypes van gebruikers gewerkt, aangeduid met de term 'personas'. Er wordt ontworpen voor een persona, niet voor hele grote groepen mensen met heel verschillende wensen die je toch nooit allemaal blij kunt maken. Het is belangrijk die ene 'persona' helemaal blij te maken.
Een ander principe: niet de gebruiker moet 'elastisch' zijn, maar de software. Die moet zich op allerlei manieren kunnen aanpassen aan wat de gebruiker wil doen.
"A fully realized, thoroughly defined user persona is a powerful tool. Until the user is precisely defined, the programmer can always imagine that he is the user. A completely pronounced user persona is key to the suppression of any tendency for the developer to usurp or distort the user persona's role. Long before a single line of code is written, a well-defined user persona becomes a remarkably effective tool for interaction design."(128-129)
Bijvoorbeeld ook omdat de vaardigheden van een persona heel precies vastgesteld moeten worden.
Wanneer je 'persona', zeg je 'doelen' ('goals' als 'end conditions'). Over dat laatste handelt dit hoofdstuk. Doelen zijn niet hetzelfde als taken, taken vormen het process waarmee die doelen bereikt worden.
"There is an easy way to tell the difference between tasks and goals. Tasks change as technology changes, but goals have the pleasant property of remaining very stable."(150)
Programmeurs zijn over het algemeen gericht op taken (procedureel). Interaction design is gericht op doelen. Helder voorbeeld van de verschillen op p.151-152. Software moet zich als een aangenaam mens gedragen en dus beleefd, respectvol, geïnteresseerd zijn, en zo verder (zie lijst p162 en de uitwerking ervan).
De dere 'tool' is die voor het uitwerken van de taken, door Cooper 'scenarios' genoemd.
"A scenario is a concise description of a persona using a software-based product to achieve a goal."(179)
Weer verdere uitwerking en een 'case study'.
"A better waiter makes fewer trips, and a better designer always creates lots less interface."(201)
Hier wordt gekeken naar andere manieren om software beter te laten aansluiten bij de gebruiker. Maar ze zullen nooit voldoen wanneer de standaard ontwikkelcyclus van programmeurs (programmeren - testen - bijstellen) als uitgangspunt geaccepteerd wordt. Zoals hgezegd moet design vooraf gaan aan heel dat proces.
"Putting design before programming means fundamental change in the software development process. Programmers, who are naturally affected by this, see it in vaguely threatening terms. They have heretofore been first and, by implication, most important. If some other discipline comes first, does that mean the other practitioners are more important? This is not true, and I will discuss it in more detail in the next chapter."(207)
'Usability testing' is een voorbeeld van het blijven accepteren van de programmeercyclus. Cooper gelooft er niet in, tenzij het opgenomen wordt in Goal-Directed Design als een fase. Hij gelooft ook niet in multidisciplinaire teams, programmeurs die design doen, Style Guides die voor alle situaties toepasbaar zouden zijn, focus groups voor software (vooral niet als die innovatief is), en 'visual design' als dogma.
"We often see products that look really good - whose aesthetics are superb - but whose functionality or whose interactivity isn't adequate. That is not because the product wasn't designed, but because it was designed by an aesthetic, visual designer, rather than by an interaction designer with the tools to master cognitive friction."(214)
Industriële vormgeving is ook niet hetzelfde als 'interaction design' en ook allerlei mogelijke nieuwe technologie zoals spraakherkenning of handschriftherkenning is niet vanuit zichzelf de oplossing.
"So much of our communication is based on nuance, gesture, and inflection that although it might be a year or two before computers recognize our words, it might be decades - if ever - before computers can effectively interpret our meaning."(215)
Dit hoofdstuk gaat over de rol van de (technische) manager in het ontwikkelproces van software en hoe design die manager kan helpen bij het bereiken van zijn of haar doelen. Managers krijgen wensen te horen van alle kanten en 'zitten al gauw op de rug van de tijger'.
"There is a big difference between listening to and following your customers. Listening is good. It implies applying your own filter to what you have heard. Following is bad. It implies merely doing what your customers tell you to do. This lets the tiger decide where you will go."(220)
"When customers bring requests for features in one hand and a check in the other, technical managers find the combination irresistible. This is one more contributing reason why so many product development organizations use feature-list negotiation to manage themselves. They are riding the tiger, and deadline management assures that they will ride at a dizzying pace."(221)
Klantgestuurde producten hebben geen samenhangend design en missen conceptuele integriteit en een lange-termijn-visie.
Het design moet dus vooraf gaan aan het programmeren. Daarom wordt alles van dat design in een document vervat waarop alle betrokkenen zich kunnen baseren. Desondanks zouden programmeurs geneigd kunnen zijn dat 'design document' te negeren, bijvoorbeeld omdat ze het slechts willen zien als een suggestie.
Het topmanagement moet daarom vierkant achter het idee staan dat het design allesbepalend is, het designteam verantwoordelijk en dus de baas is voor de uiteindelijke kwaliteit voor de gebruiker, en dat iedereen zich aan het bereikte design moet houden, dus ook de programmeurs. Dit vraagt in de meeste gevallen een enorme omwenteling van de bedrijfscultuur.