Joel on Software

Joel on Software Joël à propos de logiciel

 

La Conception d'Interface Utilisateur pour les Programmeurs
Chapitre 1
Chapitre 2
Chapitre 3
Chapitre 4
Chapitre 5
Chapitre 6
Chapitre 7
Chapitre 8
Chapitre 9

D'autres articles de "Joel on Software" en Français

D'autres articles de "Joel on Software" en Anglais

Contacter l'auteur (En Anglais uniquement)

 

La Conception d'Interface Utilisateur pour les Programmeurs
Chapitre 2: Découvrir ce à quoi ils s'attendent


Par Joël Spolsky
Traduit par Jean-Marc Dubois
Vérifié par Ziad Wakim
11 Avril 2000

Quand un nouvel utilisateur s'assoit pour utiliser un programme, il n'est pas comme un enfant qui vient de naître. Il a quelques idées sur la façon dont, pense-t-il, le programme va fonctionner. S'il a utilisé un logiciel similaire auparavant, il pensera qu'il va fonctionner de la même manière. S'il a utilisé n'importe quel logiciel auparavant, il pensera que votre programme suit certaines règles générales. Il aura peut-être des a priori intelligents sur le fonctionnement de l'IU. C'est ce que l'on appelle le modèle de l'utilisateur : leur représentation mentale de ce que le programme fait pour eux.

Le programme a, lui aussi, un "modèle mental," seulement il est binaire et est exécuté fidèlement par le processeur. On l'appelle le modèle du programme, et c'est La Loi. Comme vous l'avez appris au Chapitre Un, si le modèle du programme correspond au modèle de l'utilisateur, vous avez une interface utilisateur réussie.

Prenons un exemple. Dans Microsoft Word (comme dans la majorité des éditeurs de texte), quand vous placez une image dans votre document, l'image est en fait incorporée dans le fichier même du document. Vous pouvez créer l'image, la glisser dans le document, puis effacer le fichier originel de l'image, mais l'image va rester dans le document.

Le langage HTML, lui, ne vous permet pas de faire ça. Les documents HTML doivent stocker leurs images dans un fichier séparé. Si vous prenez un utilisateur qui a l'habitude des éditeurs de texte, et ne connaît rien au HTML, que vous l'asseyez devant un éditeur HTML wysiwyg, comme FrontPage, il va sûrement penser que l'image sera stockée dans le fichier. Appelez cela inertie du modèle de l'utilisateur, si ça vous chante.

Nous avons donc un malheureux conflit entre le modèle de l'utilisateur (l'image va être incorporée) et le modèle du programme (l'image doit être dans un fichier séparé), donc l'IU va forcément poser problème.

Si vous êtes en train de concevoir un programme comme FrontPage, vous venez juste de débusquer votre premier problème d'IU. Vous ne pouvez pas vraiment changer le langage HTML. Il faut trouver quelque chose pour mettre le modèle du programme en phase avec le modèle de l'utilisateur.

Vous avez deux possibilités. Vous pouvez essayer de changer le modèle de l'utilisateur. Ce qui est en fait particulièrement difficile à faire. Vous pourriez expliquer les choses dans le manuel, mais tout le monde sait que les utilisateurs ne lisent pas les manuels, d'ailleurs cela ne devrait pas être nécessaire. Vous pouvez faire apparaître une petite boîte de dialogue qui explique que l'image n'est pas incorporée au document, mais cela pose deux problèmes : ça va déranger les utilisateurs avancés, et les utilisateurs ne lisent pas les boîtes de dialogues non plus (nous reparlerons de cela dans le chapitre six)

Si la montagne ne vient pas à Mahomet... le meilleur choix est presque toujours de changer le modèle du programme, pas le modèle de l'utilisateur. Quand l'utilisateur insère l'image, vous pouvez peut-être faire une copie de l'image dans un sous-répertoire sous le fichier du document, ainsi vous respectez au moins l'idée de l'utilisateur : l'image est copiée (et l'originale peut être effacée sans risque).

Comment puis-je connaître le modèle de l'utilisateur ?

En fait c'est relativement facile. Il suffit de leur demander ! Prenez, au hasard, cinq personnes de votre entreprise, ou parmi vos amis, ou votre famille, et dites leur en gros ce que fait votre programme ("c'est un programme pour faire des pages web"). Puis décrivez la situation : "tu as la page web sur laquelle tu travailles, et un fichier image nommé Image.JPG. Tu insères l'image dans ta page web." Puis posez leur quelques questions pour imaginer et tester leur modèle de l'utilisateur. "Où va l'image ? Si tu supprimes Image.JPG, est-ce que la page web pourra toujours afficher l'image ?"

L'un de mes amis travaille actuellement sur un album photo électronique. Après que vous ayez inséré vos photos, l'application affiche un paquet de miniatures : de toutes petites copies de chacune des images. Bien-sûr, la création de ces miniatures met longtemps, surtout si vous avez beaucoup de photos. Aussi veut-il enregistrer les miniatures quelque part sur le disque dur, comme ça elles ne seront créées qu'une seule fois. Il y a plein de manière de faire ça. Elles pourraient être enregistrées dans un seul et même gros fichier appelé Miniatures. Elles pourraient être enregistrées dans des fichiers distincts placés dans un sous-répertoire appelé Miniatures. Elles peuvent avoir l'attribut caché du système d'exploitation afin que les utilisateurs ne sachent même pas qu'elles existent. Mon ami a utilisé la méthode qui était le meilleur compromis d'après lui : il enregistre la miniature de chaque image image.JPG dans un nouveau fichier appelé image_m.JPG placé dans le même répertoire. Si vous faîtes un album de 30 photos, une fois terminé, il y a 60 fichiers dans le répertoire, y compris les miniatures.

On peut débattre pendant des semaines des avantages et des inconvénients de chaque façon d'enregistrer les miniatures, mais il est évident qu'il y a une manière scientifique de le faire. Il suffit de demander à quelques utilisateurs où ils pensent que les miniatures vont être enregistrées. Bien-sûr, la plupart ne saura pas ou s'en moquera, ou ils n'auront jamais pensé à ce problème, mais si vous demandez à beaucoup de gens, vous allez commencer à percevoir quelque chose comme un consensus. La voix du peuple est le meilleur modèle de l'utilisateur, et c'est à vous de lui faire correspondre le modèle du programme.

Ensuite, il faut tester vos théories. Construisez une maquette ou un prototype de votre interface, et demandez à quelques personnes d'accomplir certaines tâches. Pendant qu'elles réalisent ces tâches, demandez leur ce qui se passe d'après elles. Votre but est de découvrir ce à quoi elles s'attendent. Si la tâche est "insérer une image" et que vous les voyez essayer de faire glisser l'image dans votre application, vous saurez que vous devez gérer le glisser-déposer. Si elles ouvrent le menu Insérer, vous saurez que vous avez intérêt à mettre une option Image dans le menu Insérer. Si elles sélectionnent les mots "Times New Roman" dans la barre de polices et les remplacent par "Insérer Image", vous avez découvert une espèce arriérée qui n'a jamais vu d'interface graphique et ne connaît que les interfaces du type ligne de commande.

Combien d'utilisateurs faut-il pour tester votre interface ? Votre instinct doit vous dire "plus il y en a, mieux c'est", ce qui est exact pour des expérimentations scientifiques. Mais cet instinct est faux. Presque tous les gens qui font leur métier de ces tests d'utilisabilité semblent penser que cinq ou six utilisateurs suffisent. Au-delà, vous revoyez, encore et encore, les mêmes résultats, et chaque nouvel utilisateur n'est qu'une perte de temps.

Vous n'avez pas besoin d'un véritable laboratoire d'utilisabilité, et vous n'avez pas vraiment besoin de recruter des utilisateurs anonymes - Vous pouvez réaliser des "tests à dix balles", tout simplement en demandant à la prochaine personne que vous croisez de faire un rapide test d'utilisabilité. Attention à ne pas tout ficher en l'air en expliquant comment faire les choses. Demandez leur de penser tout haut, et interviewez les en leur posant des questions ouvertes pour essayer de découvrir leur modèle mental.

Si votre programme n'est pas trivial, ce n'est probablement pas le modèle de l'utilisateur.

Quand j'avais six ans, mon père a rapporté à la maison un des premiers ordinateurs de poche, un HP-35, et il a tenté de me convaincre qu'il y avait un ordinateur dedans. Je pensais que c'était impossible. Tous les ordinateurs de Star Trek étaient de la taille d'une pièce, et avaient d'énormes bandes magnétiques. Je pensais qu'il y avait juste une sorte de connexion intelligente entre les touches du clavier et les LED de l'affichage, qui donnait ces résultats justes (Hé, j'avais six ans).

Il est important de retenir que les modèles de l'utilisateur ne sont pas très complexes. Quand des gens doivent imaginer comment un programme fonctionne, ils ont tendance à imaginer des choses simples plutôt que des choses tarabiscotées.

Asseyez-vous devant un Mac. Ouvrez deux feuilles Excel et un document Word. N'importe quel néophyte parierait que les fenêtres sont indépendantes. Elles semblent indépendantes :

Le modèle de l'utilisateur dit qu'en cliquant sur la feuille 1 cette fenêtre reviendra au premier plan. Ce qui se passe en vrai, c'est que la feuille 2 passe au premier plan, une surprise très frustrante pour tout le monde :

Il est évident que le modèle du programme de Microsoft Excel dit "vous avez ces feuilles invisibles, une pour chaque application, et les fenêtres sont collées à ces feuilles invisibles. Quand vous mettez Excel au premier plan, toutes les autres fenêtres d'Excel vont passer au premier plan elles aussi."

D'aaaaa-cord. Des feuilles invisibles. Quelles sont les chances qu'un modèle utilisateur utilise ce concept de feuilles invisibles ? Aucune, c'est sûr. Donc les nouveaux utilisateurs seront surpris de ce comportement.

Un autre exemple du monde de Microsoft Windows est la combinaison de touches Alt+Tab, qui permet de basculer à l'application suivante. La majorité des utilisateurs imagineraient qu'elle permet une simple rotation des fenêtres ouvertes. Si vous avez les fenêtres A, B et C ouvertes, avec A la fenêtre active, Alt+Tab vous fait passer à B. Encore une fois Alt+Tab et vous passez à C. En fait, le second Alt+Tab vous ramène à A. Le seul moyen d'aller à C est de garder la touche Alt enfoncée et d'appuyer deux fois sur Tab. C'est une bonne manière de basculer entre deux applications, mais presque personne ne la devine, parce que c'est un modèle un peu plus compliqué que celui où Alt+Tab fait tourner le premier plan entre toutes les fenêtres ouvertes.

Il est déjà difficile de faire correspondre le modèle du programme au modèle de l'utilisateur quand les modèles sont simples. Mais quand les modèles deviennent complexes, c'est encore plus dur. Alors choisissez le modèle le plus simple.



> Chapitre 3

Cet article est paru en version originale anglaise sous le titre User Interface Design for Programmers Chapter 2: Figuring Out What They Expected  

Joël Spolsky est le fondateur de Fog Creek Software, une petite société éditrice de logiciel située à New York. Il est diplômé de l'Université de Yale et a travaillé comme programmeur et manager chez Microsoft, Viacom et Juno.


Le contenu de ces pages représentent l'opinion d'une personne.
Contenu protégé par le copyright ©1999-2005 par Joël Spolsky. Tous droits réservés.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky