J’ai pas mal l’occasion ces temps-ci de travailler sur des problématiques d’ergonomie. C’est complètement passionnant, et en même temps très difficile, car vous avez d’un côté une interface, une logique logicielle, et de l’autre une infinité (potentielle 😀 ) d’utilisateurs, avec chacun leur sensibilité différente, leur façon de raisonner et d’interpréter l’interface qui s’offre à eux. Cette perspective finalement très “humaine” que l’on se doit d’apporter à nos projets est vraiment intéressante, et amène parfois à bousculer de vieilles habitudes. Un exemple…

Les règles du jeu

Un exemple qui m’a frappé est celui, classique, des écrans de configuration de “règles de messages” : lorsque vous utilisez un client mail classique (Outlook, Mail, Eudora, Thunderbird….), tous fonctionnent d’une manière similaire : on peut définir des règles, des automates, qui vont permettre de classer automatiquement tel ou tel message.

Un écran de définition d’une règle ressemble toujours plus ou moins à ceci :

Ici, une copie d’écran de l’appli “Mail”, sous Mac, mais les concurrents sont très similaires.

Je ne sais pas pour vous, mais moi, en tant que développeur, je “vois”, au travers de cette interface, une traduction directe d’un code métier, manipulant des objets conçus directement à partir du cahier des charges. Un truc style :

Regle r=new Regle();

r.setName(“Regle No 1”);

r.set…..

listeregles.ajout(r);

r.appliquer();

Quoi de plus normal diriez vous (enfin si vous êtes développeurs…) : l’interface utilisateur doit permettre de manipuler les fonctionnalités métiers d’une application, et je passe mes formations a expliquer comment monter ce genre d’architecture “multi-couches”.

Mais, en prenant du recul… est ce que cette vision très “cartésienne” des choses est la bonne ?

Une histoire de Monopoly

Souvenez vous, lorsqu’on vous explique les règles d’un jeu, style monopoly ou jeu de cartes. Classiquement, votre interlocuteurs va commencer par vous reprendre les règles complètes, d’un point de vue un peu “théorique”. Au début, ça va. Puis, les détails s’accumulant, vous allez perdre petit à petit pied, jusqu’à décrocher complètement, jusqu’au moment clef où l’interlocuteur va prononcer la phrase magique : “Par exemple…”. Et là, votre esprit va s’éveiller d’un coup, et se raccrocher à cette vision hyper partielle, mais concrète et assimilable, de l’exemple qu’on va vous donner. “Là, si machin met un 8 de coeur, tu vas pouvoir mettre un 9 de trèfle”.

Ce n’est qu’une pièce du puzzle, mais cet exemple va être comme le bout de bois flottant en pleine mer auquel vous allez vous raccrocher, pour ensuite reprendre pied petit à petit et avoir une vision plus claire du jeu. Et, seulement ensuite, vous allez pouvoir relire sereinement les règles, y repérer les exemples que vous avez assimilé, et vous faire vous même votre vision du jeu.

Bien sûr, ce raisonnement n’est pas valable pour tout le monde : certains esprit préféreront ingurgiter d’un bloc les règles du jeu, et n’utiliseront les exemples qu’en fin de cycle d’apprentissage, simplement pour valider quelques zones floues ; mais la grande majorité des êtres humains fonctionnent par l’exemple.

Regarder par l’autre bout de la lorgnette

Pour définir les régles de tri de votre mail, c’est la même chose : on vous demande de définir des règles “théoriques” d’emblée de jeu. Alors que vous, humanum vulgaris, vous êtes “programmé” pour fonctionner avec des exemples !

Les concepteurs de cette interface n’ont pas voulu mal faire. Ils ont simplement cherché à faire de leur IHM un moyen de manipuler leurs objets métiers, et donc de fournir une interface au cahier des charges qu’on leur a demandé de remplir. Point. Et on peut pas en vouloir à un “barbu”, comme je les appelle (on se demande pourquoi 😉 ) de raisonner comme un barbu, avec des instances de classes et des appels polymorphes !

Simplement, dans ce cas précis, il aurait été utile de voir un peu le problème avec un autre angle de vision : celui de l’humain, de l’utilisateur, qui a son mode de raisonnement propre, et qui n’est pas toujours relié à la simple traduction IHM d’un paradigme objet !

On efface tout et on recommence

Donc, l’utilisateur aime raisonner par l’exemple : qu’on lui en donne la possibilité ! Ca donnerait à peu près ceci :

Imaginons que l’utilisateur veuille déplacer automatiquement les mails Facebook qu’il reçoit dans un dossier qu’il a créé pour l’occasion.

1) Il prend un mail Facebook, et le glisse, comme il l’a déjà fait plein de fois, sur le dossier approprié

2) Une boîte de dialogue apparaît alors, lui demandant “Quelle caractéristique de ce mail vous amène à le déplacer ici ?”

3) Parmi les choix proposés : “Le nom de domaine de l’expéditeur“. Il clique là dessus

Et c’est terminé ! Pas besoin de préciser “déplacer vers”, ni un nom du dossier, puisque l’exemple aura permis au programme de le deviner. Par la suite, lorsqu’il voudra affiner ses règles, il pourra ensuite accéder à des écrans similaires à celui du début de cet article. Mais seulement à ce moment là, lorsqu’il aura bien maitrisé “les règles du jeu” et qu’il voudra simplement en préciser certains comportements.

Au boulot !

Cet exemple n’est sans doute pas parfait. Et il ne parlera sans doute pas à tout le monde. Mais on touche ici à ce qui fait le fondamental de l’ergonomie : trouver un juste équilibre entre les besoins “métiers” (les fonctions), et les réflexes, les intuitions de l’utilisateur. Dur boulot !