Doug Engelbart est incontestablement une figure majeure de l'histoire de l'informatique, mais, il faut le reconnaître, s'il a été un inventeur de génie, s'il a su tirer le meilleur de la technologie, il s'est totalement trompé sur les capacités et les motivations humaines.
Alan Kay, autre acteur exceptionnel de l'informatique, a expliqué l'erreur d'Engelbart en une phrase : "Engelbart, for better or for worse, was trying to make a violin…most people don’t want to learn the violin" ("Engelbart, pour le meilleur ou pour le pire, essayait de fabriquer un violon ... la plupart des gens ne veulent pas apprendre le violon").
Comme je l'écrivais dans l'article précédent, "Toute sa vie, Engelbart a cherché à concevoir des outils améliorant la communication et la collaboration humaine pour permettre à l'humanité de résoudre des problèmes toujours de plus en plus complexes". Engelbart pensait que l'utilisateur, pour tirer au mieux profit de ces nouveaux systèmes informatiques, serait prêt à passer de longue heures à apprendre à les utiliser de façon performante. C'est là qu'il s'est trompé.
 |
| Chorded keyboard, clavier et souris du système NLS. |
Pour Engelbart, comme d'ailleurs pour ses contemporains, dans les années 60 et 70, la priorité était d'avoir une interaction performante, efficace, ce n'est qu'à partir des années 80 que l'utilisabilité est devenue la priorité des concepteurs d'interaction.
 |
| Dynabook (Alan Kay, Xerox PARC, 1972) |
Engelbart avait bien compris que les ordinateurs, excessivement rare et incroyablement volumineux dans les années 60, allaient se multiplier, se miniaturiser et se populariser, mais il n'avait pas compris que ce ne serait possible qu'au prix d'une simplification de l'interaction. En passant d'un marché de grands comptes (jusqu'aux années 70) à un marché de masse (à partir des années 80), inévitablement l'interaction homme-machine devait devenir toujours plus simple pour satisfaire un utilisateur de moins en moins disposé à apprendre comment fonctionne son système.
L'erreur d'Engelbart a été de croire que l'accroissement de la complexité des tâches réalisables par les machines allait de paire avec une augmentation de la performance des utilisateurs et une interaction plus experte.
Je terminerai en citant un commentaire brillant de Gene Golovchinsky du FXPAL, disparu en août 2013 qui écrivait en juillet 2013 :
"I think one problem with Engelbart’s argument is the confusion between interface complexity and task complexity. I would argue that the more complex, cognitively demanding the *task* is (running a power plant, landing an airplane, etc.) the more the *interface* has to stay out of the way. One can tolerate interface idiosyncrasies in MS Word much more than in an airplane because the tasks are less demanding and the consequences of malfunction are less severe. This does not argue against the need for skilled operators nor against the need for competent interface design. Appropriate interface design is orthogonal to the complexity of the task, to the sophistication of the user, or to the need to foster learning. While differences in task and operator skill call for differences in interfaces, it does not follow that interfaces should be difficult to use once the user’s skills and task are taken into consideration".
(Je pense qu'un problème avec l'argument d'Engelbart est la confusion entre la complexité de l'interface et la complexité de la tâche. Je dirais que plus la tâche est complexe et exigeante cognitivement (gestion d'une centrale électrique, l'atterrissage d'un avion, etc) plus l'interface doit rester à l'écart. On peut tolérer les particularités de l'interface dans MS Word bien plus que dans un avion parce que les tâches sont moins exigeantes et les conséquences de dysfonctionnements moins sévères. Cela ne s'oppose pas à la nécessité d'avoir des opérateurs qualifiés, ni à la nécessité d'une bonne conception de l'interface. La conception d'une interface appropriée est orthogonale à la complexité de la tâche, à la sophistication de l'utilisateur, ou à la nécessité de favoriser l'apprentissage. Si des tâches ou des opérateurs différents appellent des interfaces différentes, ça n'implique pas que les interfaces doivent être difficiles à utiliser une fois les compétences et les tâches de l'utilisateur prises en considération)
Articles
