Pourquoi Apple demandait aux développeurs de renoncer à certaines améliorations
La couverture du guide de 1987 : une main sur la souris, devant le menu Édition ouvert sur « Copier ».
En 1987, Apple publie un guide destiné aux développeurs de logiciels pour ses ordinateurs. Dans le chapitre consacré à la conception des interfaces, une recommandation surprend : une solution nouvelle, parfaitement adaptée à une situation, doit parfois être abandonnée au profit d’une solution un peu moins efficace, mais plus répandue.
Le bureau du Macintosh tel que le guide le décrit en 1987 : barre de menus, fenêtres, icônes, corbeille.
Le guide reconnaît donc que le développeur peut avoir trouvé mieux. Il lui demande pourtant d’envisager de conserver l’existant.
Pour comprendre cette consigne, il faut regarder ce que le développeur cherche à améliorer, puis ce que l’utilisateur devra apprendre pour en profiter. Les pages qui entourent ce passage expliquent cet arbitrage. Elles permettent aussi d’en cerner la limite : à quel moment une nouveauté mérite-t-elle qu’on change ses habitudes ?
Le développeur travaille sur un logiciel. Son client en utilise plusieurs.
La préface du guide prend un exemple familier : Commande-X pour couper, Commande-V pour coller. Ces commandes conservent le même sens dans les applications qui respectent les conventions d’Apple.
Le passage de la préface : Commande-X et Commande-V veulent dire Couper et Coller dans toutes les applications standard.
Une personne qui apprend à couper et coller dans un traitement de texte peut réutiliser ce savoir ailleurs. Elle n’aborde donc pas chaque logiciel comme une débutante. Une partie de l’apprentissage est déjà faite.
Les menus Fichier et Édition que chaque application devait reprendre, avec les mêmes raccourcis : Commande-X, Commande-C, Commande-V, Commande-S.
Pour le développeur, ces habitudes constituent une contrainte. Il doit employer des commandes et des éléments d’interface qu’il n’a pas choisis. Une autre organisation conviendrait peut-être mieux à son application.
C’est précisément le cas qu’envisage le guide. Il reconnaît qu’une solution peut être plus efficace dans une situation particulière, puis demande de considérer les autres logiciels dont la personne se sert.
La section « Consistency » : la solution nouvelle du programmeur doit parfois céder la place à une solution un peu moins efficace, mais plus répandue.
Imaginons qu’une nouvelle commande permette d’effectuer une opération en un seul geste au lieu de deux. Une fois apprise, elle fait gagner du temps. Mais l’utilisateur doit d’abord la découvrir, comprendre son fonctionnement et se souvenir que, dans cette application, l’opération se fait autrement.
Une amélioration qu’Apple ajoute sans changer le geste : Couper et Coller remettent eux-mêmes les espaces au bon endroit.
Lorsqu’il revient à son ancien logiciel, il retrouve l’autre manière de faire. S’il alterne souvent entre les deux, il doit aussi alterner entre deux habitudes.
Le nombre de gestes nécessaires ne suffit donc plus à comparer les solutions. Il faut compter l’apprentissage, les hésitations et les erreurs provoquées par ce changement.
Le développeur voit le gain obtenu dans son application. Le guide lui demande d’élargir son évaluation à la journée de la personne qui l’utilise.
Une habitude permet d’aller vite. Elle peut aussi conduire à l’erreur.
La préface explique que la cohérence entre applications facilite l’apprentissage et réduit les risques lorsqu’une personne reproduit un geste appris ailleurs.
Pour montrer le danger, elle invente un cas volontairement extrême : une application dans laquelle Commande-S, habituellement associé à l’enregistrement, provoquerait l’arrêt sans sauvegarde.
La préface imagine Commande-S qui, au lieu d’enregistrer, éteindrait la machine sans sauvegarder.
Aucun utilisateur n’aurait de raison de s’attendre à ce résultat. Son expérience le conduirait même à faire exactement ce qu’il faut pour perdre son travail.
Le problème tient au fait qu’une commande familière invite à agir sans vérifier. C’est ce qui la rend pratique. Une fois son fonctionnement appris, on peut consacrer son attention au document, au dessin ou au calcul en cours.
Réemployer cette commande avec un autre sens transforme cet acquis en risque.
La boîte « Enregistrer avant de fermer ? » : le guide exige la même partout, car un clic sur Non par habitude fait perdre le travail.
Il faut donc distinguer deux difficultés. Une fonction inconnue demande un apprentissage. Une fonction qui paraît connue, mais se comporte autrement, peut provoquer une erreur avant même que l’utilisateur ait compris qu’il devait apprendre quelque chose.
Cette distinction aide à examiner une refonte. Si l’on déplace une commande, la personne devra la chercher. Si l’on conserve sa place et son apparence tout en changeant son effet, elle risque de l’utiliser avec son ancienne intention.
Les deux changements ne lui imposent pas le même effort. Ils ne réclament pas les mêmes précautions non plus.
Apple prévoit pourtant que ses propres règles seront remplacées.
On pourrait tirer de ces recommandations une conclusion commode : mieux vaut conserver ce que les gens connaissent.
La préface ferme cette possibilité. Elle précise que le guide ne constitue pas le dernier mot sur le sujet. De nouvelles fonctions rendront les interfaces plus efficaces, et de nouvelles interfaces apparaîtront. Elle reconnaît aussi l’existence de très bonnes applications qui s’écartent sensiblement de ses recommandations.
Apple écrit que son guide n’est pas le dernier mot et que de nouvelles interfaces apparaîtront.
Le développeur peut donc déroger aux conventions. Apple lui demande une raison et une attention particulière aux personnes qui arriveront avec les habitudes des applications standard.
Le guide ne fournit pas de seuil chiffré pour décider qu’un gain justifie un nouvel apprentissage. Il présente toutefois des choix qui permettent de comprendre ce qu’on peut chercher à gagner.
Dans la partie consacrée au WYSIWYG, « ce que vous voyez est ce que vous obtenez », il décrit le problème de la mise en page. Sur certains systèmes, l’utilisateur donne des commandes à l’ordinateur et attend l’impression pour voir le résultat. Il doit imaginer comment ce qu’il saisit deviendra une page.
Apple demande que le résultat des choix de présentation soit directement visible à l’écran. La personne peut modifier son document en voyant ce qu’elle fait, sans attendre une impression ni calculer mentalement sa disposition.
La section WYSIWYG : l’écran doit montrer la page telle qu’elle sortira de l’imprimante.
Le bénéfice recherché est identifiable : réduire les allers-retours et l’incertitude pendant la préparation du document.
On peut alors formuler la question laissée ouverte par le guide : l’effort demandé pour apprendre le nouveau fonctionnement est-il justifié par ce qu’il permettra ensuite d’accomplir ?
Une opération effectuée occasionnellement et une tâche répétée toute la journée ne donneront pas nécessairement la même réponse. C’est une conséquence de cet arbitrage, pas une règle supplémentaire formulée par Apple.
Pour le savoir, il faut sortir de la démonstration du concepteur.
La personne qui a développé une fonction sait où elle se trouve, pourquoi elle existe et comment l’utiliser. Lorsqu’elle la montre, elle enchaîne les bonnes actions. Elle peut ainsi démontrer le gain promis sans rencontrer les difficultés d’apprentissage qui accompagnent sa découverte.
Le guide consacre une section aux tests avec des utilisateurs. Il recommande d’y recourir assez tôt pour pouvoir encore modifier le principe du produit. Attendre un prototype fonctionnel laisse, selon lui, trop peu de place aux utilisateurs pour influencer la conception.
Des dessins sur papier ou des suites d’écrans peuvent déjà servir à examiner les premières propositions.
La section « User testing » : tester tôt, sur papier s’il le faut, avec des gens qui connaissent la tâche mais pas l’outil.
Le choix des participants est précis : des personnes qui connaissent la tâche à accomplir, mais pas la technologie employée. Elles comprennent ce qu’elles cherchent à obtenir sans connaître d’avance le chemin prévu par le développeur.
Pour un logiciel de mise en page, on peut donc observer quelqu’un qui sait préparer un document, mais découvre cette interface. Lorsqu’il hésite, on peut examiner ce qu’il cherchait, ce qu’il avait compris et ce qu’il s’attendait à voir apparaître.
Apple recommande notamment de faire parler les participants pendant qu’ils travaillent. Le guide propose aussi de relever les durées, les erreurs et les actions effectuées, puis de corriger la conception et de recommencer.
Le guide demande de mesurer les durées et les erreurs, et de faire parler la personne pendant qu’elle travaille.
Cette démarche permet de préciser le désaccord autour d’une nouveauté. Une personne ne trouve pas la commande : il faut travailler sa découverte. Elle la trouve, mais prévoit un autre résultat : son apparence ou son intitulé induit une mauvaise interprétation. Elle la comprend et réussit la tâche : on peut commencer à examiner le gain apporté.
Un premier essai ne permet cependant pas de savoir ce qui se passera après plusieurs jours d’usage. Une nouveauté peut demander un effort initial puis devenir avantageuse. La comparaison devrait alors porter aussi sur les utilisations suivantes. Le guide ne fournit pas ce protocole ; c’est une limite à garder lorsqu’on applique son raisonnement.
La raison de changer doit pouvoir être observée.
Dans ces pages, Apple demande parfois de conserver une solution moins efficace parce qu’elle est déjà connue. La consigne prend sens lorsqu’on inclut dans l’évaluation tout ce que l’utilisateur doit apprendre et se rappeler pour effectuer son travail.
Elle oblige aussi à préciser ce qu’on attend d’une nouveauté. « Plus moderne », « plus original » ou « plus élégant » ne dit pas encore quelle difficulté disparaîtra pour la personne qui s’en sert.
Pour défendre un changement, une équipe devrait pouvoir décrire l’opération facilitée, l’effort nouveau demandé et la manière dont elle examinera les deux. Elle peut alors découvrir que le gain mérite l’apprentissage, qu’une transition est nécessaire, ou que l’ancienne solution rend encore mieux service.
Le guide de 1987 ne permet pas de trancher ces décisions à sa place. Il donne en revanche une raison de se méfier d’une démonstration dans laquelle tout devient plus simple une fois que l’on sait déjà se servir du produit.
Source : Apple Computer, Human Interface Guidelines: The Apple Desktop Interface, Addison-Wesley, 1987. Préface, pages xi–xii ; chapitre 1, sections « Consistency », « WYSIWYG » et « User testing ». Les exemples de refonte et les prolongements sur l’apprentissage dans la durée sont notre lecture du document.
