samedi 31 août 2013

L'erreur d' Engelbart : privilégier l'efficacité au détriment de l'utilisabilité

J'avais promis un retour sur la vision de Doug Engelbart qui a guidé toute sa vie de chercheur (cf. article précédent de ce blog).
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.
La phrase d'Alan Kay est très juste, j'emploierais plutôt la métaphore du piano car Engelbart pensait que l'utilisateur apprendrait tous les accords possibles (31 au total) du chorded keyboard pour saisir du texte et apprendrait à combiner un accord sur ce clavier avec un appui sur les boutons de la souris pour entrer une commande dans le système NLS. Dans les faits, seul Engelbart a dû faire cet effort d'apprentissage pour contrôler son système.

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)
Sur ce point Alan Kay, encore lui, fait figure d'exception, en proposant Dynabook en 1972 dans un article intitulé "A Personal Computer For Children Of All Ages". Kay avait déjà le souci de l'utilisabilité, mais Dynabook n'était qu'un concept, il n'est donc pas possible de juger réellement son utilisabilité. Dynabbok reste néanmoins l'ancêtre des tablettes, en quelque sorte l'inspirateur du Newton, sorti 20 ans plus tard, ou encore de l'iPad, sorti presque 40 ans après (encore une fois Apple doit beaucoup à Xerox).

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)


Aucun commentaire: