I. Introduction▲
L'ergonomie logicielle est une chose que beaucoup de développeurs, amateurs ou professionnels, ont tendance à ignorer. Il en résulte des logiciels difficiles à appréhender et dont la logique de fonctionnement échappe totalement aux utilisateurs.
Le ressenti qui en résulte peut suffire à faire la réputation d'un logiciel et de son succès ou de son échec.
Aussi, nous est-il indispensable d'en maîtriser les bases ! Reposant sur l'intuitif, la logique et le respect de nos habitudes, je vous invite à découvrir ces bases.
II. Nos habitudes▲
II-A. Visualisation▲
Notre éducation a un impact dans notre vie de tous les jours. Cela inclut la visualisation d'une page informatique, et donc l'utilisation d'un logiciel.
Par extension, cela aura également un impact sur l'ergonomie que doit adopter un logiciel.
Nous avons l'habitude de lire une page de gauche à droite et de haut en bas :
![Image non disponible](./images/10000201000001C7000001000844A1B6.png)
Tout logiciel se doit donc d'adopter cette même logique.
Imaginez un logiciel disposant de sa zone de travail en haut, son menu à droite, sa barre de statut à gauche. Vous seriez bien désorienté, du moins dans un premier temps. C'est précisément cette situation qu'il faut éviter de produire.
II-B. Organisation▲
Toute IHMInterface Homme Machine, GUIGraphical User Interface en anglais, se doit d'être bien organisée afin de garantir une utilisation agréable et optimale.
Dans ce but, tout type d'éléments, quel qu'il soit (barre d'outils, menu…), doit être classé.
Différentes options peuvent alors s'offrir, selon les besoins ou souhaits des utilisateurs :
- alphabétique ;
- logique ;
- importance/priorité ;
- …
On affichera les éléments, selon l'option choisie de gauche à droite ou de haut en bas.
II-C. Champ de vision▲
Le champ de vision de l'être humain est un champ de type rectangulaire.
Notre vision se focalise sur un point central, puis sur la périphérie. Plus on s'écarte du point central, moins l'être humain remarque de détails.
Ce principe doit être pris en compte dans la conception d'IHM.
L'illustration suivante est une représentation de la vue humaine, adaptée à un écran rectangulaire type 16:9. Ce sont actuellement les écrans les plus répandus :
![Image non disponible](./images/10000201000001C7000001007A01E40B.png)
Sur cette illustration, le point central est vert. Il représente ce que l'on regarde en direct, sur quoi se focalise notre vue et en rouge, ce que notre vision occulte.
On remarque bien que plus on s'écarte du centre du rectangle, moins on visualise le vert. On remarque également que nous sommes plus attentifs aux bordures haute et basse qu'aux bordures gauche et droite.
L'ensemble de ces constats permet de donner des lignes directrices pour une bonne organisation de nos IHM :
![Image non disponible](./images/10000201000001C70000010069C95290.png)
La zone de travail principale peut ne concerner qu'une partie ou la totalité de l'espace situé entre les menus et la barre de statut.
Depuis l'apparition des écrans 16:9, certains développeurs ont pris l'habitude d'utiliser l'espace à gauche et droite de la zone de travail :
- de déplacer la barre d'outils sur la gauche, permettant ainsi de gagner en hauteur de zone de travail ;
- d'ajouter des fonctionnalités en accès direct sur les côtés.
III. Règles basiques▲
Une bonne IHM répond positivement aux points suivants :
- Utilisabilité/simplicité : est-il facile d'utiliser le logiciel ?
- Explicité : le logiciel peut-il être utilisé sans notice ?
- Convivialité : le logiciel est-il agréable à utiliser ?
- Fonctionnalité : le logiciel répond-il aux besoins ?
- Erreurs maîtrisées : les messages d'erreurs sont-ils explicites ?
III-A. Éléments principaux▲
III-A-1. Fenêtre principale▲
L'IHM de la fenêtre principale doit être la plus précise possible. La fenêtre doit posséder un titre. En général, ce titre est composé de la façon suivante :
<nom du logiciel> - <nom du fichier>
Il faut limiter l'affichage dans la fenêtre à une ou deux tâches à la fois.
III-A-2. Fenêtre secondaire▲
Lors de l'affichage d'un message d'information, d'erreur…, à l'utilisateur, il faut utiliser une icône standard afin d'indiquer le type de message.
Type de message |
Représentation usuelle |
Exemple d'images
|
Information |
La lettre i |
|
Idée/astuce |
Une ampoule |
|
Avertissement |
Un panneau routier attention danger |
|
Erreur |
Une croix rouge ou une croix blanche sur fond rouge |
|
De plus, le texte du message devra être court, explicite et pertinent, pour tout utilisateur, y compris les novices. On évitera donc de donner trop d'informations à l'utilisateur, car trop d'informations tue l'information.
En cas de message d'erreur, un numéro pourra être fourni, à destination des informaticiens. Ce numéro servira alors à localiser plus précisément le type d'anomalie constatée et/ou le code étant tombé en erreur.
Enfin, on pourra, de manière plus générique, codifier l'ensemble des types de messages par une lettre d'identification.
Type de message |
Exemple de codification |
Information |
I000 |
Idée/astuce |
A000 |
Avertissement |
W000 |
Erreur |
E000 |
III-A-3. Menu▲
La création d'un menu doit s'inspirer de l'environnement, en extrayant des mots-clés.
Outre cela, il faut également utiliser des mots-clés standards (Fichier, Édition…).
Au sein des menus, un tri sera effectué afin de présenter les divers éléments à l'utilisateur en respectant une logique (alphabétique, importance…).
Pour des questions de lisibilité et de clarté, on se limitera à deux sous-menus. En effet, au-delà, un effet cascade risque à la fois de perdre l'utilisateur et d'encombrer l'écran durant la navigation :
III-A-4. Icônes▲
Les icônes utilisées au sein de l'application ne doivent pas être choisies au hasard.
Le mauvais choix d'une icône peut engendrer des incompréhensions, voire des erreurs d'utilisation par un utilisateur :
![Image non disponible](./images/100002010000008000000080918E668A.png)
Cette icône, représentant une loupe, peut avoir plusieurs significations tels « chercher » ou encore « zoomer ». Maintenant, mettons-nous dans un contexte où ces deux fonctionnalités sont disponibles dans le logiciel, mais seule une d'entre elles est accessible dans la barre d'outils. En voyant juste cette icône, de prime abord, l'utilisateur se demandera sans doute s'il s'agit de la fonction « recherche » ou de la fonction « zoom ».
Une icône doit s'inspirer de l'action qu'elle vise à déclencher. Toute icône doit pouvoir se passer de texte descriptif. C'est à cette seule condition qu'une icône peut être considérée comme judicieusement sélectionnée.
Les icônes doivent être à la bonne taille, ni trop petites, ni trop grandes, et si possible être issues de l'environnement.
Voici quelques liens utiles afin de trouver aisément des icônes. N'oubliez pas de bien respecter les termes des licences associées.
III-A-5. Barre d'outils▲
Les barres d'outils peuvent se présenter sous forme verticale ou horizontale. Comme vu sur le chapitre concernant le champ de vision, il est préférable d'utiliser le modèle horizontal, qui sera plus visible.
Comme pour les menus, on tâchera de trier les éléments en respectant une certaine logique. Ainsi ne commencerons-nous pas directement par l'icône « À propos de… ».
III-A-6. Barre de statut▲
Les barres de statut devront impérativement être placées en bas de l'écran.
Les informations qui y seront affichées devront être pertinentes et explicites. Cela signifie par exemple ne pas réafficher une information déjà disponible ailleurs dans l'OS, comme l'heure.
III-A-7. Texte▲
Concernant le texte au sein de l'application, on privilégiera les polices standards et libres de droits. Cela permettra ainsi une liberté d'un point de vue licence. Cependant attention, car :
Dans tous les cas, il faudra bien vous assurer que cette police est disponible sur l'OS.
Si la police est absente, elle sera substituée, mais l'expérience de l'utilisateur pourrait en pâtir.
Le cas échéant, vous pouvez installer vous-même la police, ou bien l'embarquer en tant que dépendance et vous en servir directement.
Équivalence |
||
Police non libre |
Police libre 1 |
Police libre 2 |
Arial |
Liberation Sans |
FreeSans |
Times New Roman |
Liberation Serif |
FreeSerif |
Courier New |
Liberation Mono |
FreeMono |
On se limitera également à deux, voire trois polices maximum, pour des raisons de clarté.
On n'oubliera pas d'aérer le texte et de contraster au maximum (texte de couleur sombre sur fond clair par exemple) afin d'optimiser la lisibilité du texte.
Enfin, on évitera toute police fantaisiste qui rendra difficile la lecture.
Si les polices citées ci-dessus ne vous conviennent pas, il existe des sites, comme DAFONT, qui vous permettent de trier les polices par type de licence. Pensez-y !
Le Serif correspond à l'empattement présent sur les lettres dans certaines polices d'écriture.
III-A-8. Boutons▲
Afin d'être efficaces, les boutons doivent être clairement compréhensibles.
Les boutons peuvent contenir du texte seul, une icône seule ou une icône accompagnée d'un texte.
Une variante consiste à utiliser l'icône seule, avec le texte en bulle d'aide. C'est cette dernière solution qui doit être privilégiée.
Le texte du bouton devra, encore une fois, être court et explicite :
III-B. Le vocabulaire▲
Lorsque l'on conçoit un logiciel dédié à un environnement spécifique (mécanique, médical, scientifique…), il est important de porter attention au vocabulaire utilisé.
En effet, chaque milieu spécifique utilise son propre langage. Ne pas tenir compte de ce langage propre reviendrait à condamner d'avance un logiciel à péricliter.
Si l'équipe de développement n'est pas du milieu visé par le logiciel, il est donc primordial de se documenter sur le vocabulaire adéquat, et de le tracer dans une documentation qui sera à disposition de l'ensemble des développeurs et utilisateurs du logiciel final.
Dans la mesure du possible, il faut également éviter d'utiliser des abréviations, et standardiser et uniformiser le vocable du logiciel.
III-C. Homogénéité▲
Il faut respecter un certain formalisme au sein de l'application afin d'éviter de perdre l'utilisateur.
Pour cela, il faut éviter d'utiliser différents termes pour la même action (ex. : quitter et sortir).
De même, en cas de jeux de couleurs, on tâchera de rester cohérent dans leur utilisation.
Il faut que, quel que soit l'endroit du logiciel où se trouve l'utilisateur, ce dernier n'ait jamais à remettre en question l'interprétation à faire de l'IHM.
III-D. Clarté▲
Toute IHM réussie doit être agréable à utiliser. Cela passe par une clarté de l'écran.
Il ne faut donc pas hésiter à regrouper des actions communes par thème par exemple ou encore d'ajouter des onglets au besoin.
De même, il faut penser à aérer l'IHM et à bien aligner les divers éléments afin d'obtenir quelque chose d'agréable à l'œil.
En effet, même si cela relève d'un pur esthétisme, cela peut suffire à rebuter un utilisateur.
III-E. Temps de réponse▲
Lorsqu'on conçoit un logiciel, il n'est pas rare de tomber sur des fonctionnalités qui mettent un peu de temps à s'exécuter.
Si on peut se permettre de laisser l'utilisateur attendre une ou deux secondes, au-delà, il faut penser à l'attente qu'il devra subir.
Pour cela, il faut mettre en place, idéalement, une barre de progression accompagnée ou non d'explications textuelles, permettant à l'utilisateur de connaître le niveau d'avancement de la tâche. Au pire, une barre de tâches effectuant un aller/retour permettra de savoir qu'une action est en cours et qu'il ne s'agit pas d'un plantage.
III-F. Jeux de couleurs▲
Les jeux de couleurs permettent de mettre en évidence des données ou des informations liées à des données.
Par exemple, le rouge est habituellement associé à tout ce qui est critique, important ou élevé. De même, le vert est associé généralement à un traitement qui s'est bien déroulé, à une variable dans la bonne plage…
Le choix de jeux de couleurs peut s'avérer judicieux à condition de ne pas rentrer en conflit avec des jeux de couleurs utilisées dans l'environnement (carte météo par exemple).
Il faut alors faire attention au contraste, afin de ne pas agresser les yeux et limiter ces jeux. En effet, choisir des jeux disposant de trop de possibilités va amener l'utilisateur à se perdre. Tâchez de vous limiter au strict minimum.
Il existe des sites spécialisés afin de vous aider dans le choix de couleurs complémentaires. En voici quelques-uns :
III-G. Procédure▲
Dans certains environnements, un « process » consiste en un enchaînement de traitements.
Lors de la retranscription de ces process dans un logiciel, il faut respecter la chronologie afin de rester cohérent vis-à-vis des utilisateurs :
III-H. Erreurs▲
Une des règles de base (PEP) en PYTHON est « Une erreur ne devrait jamais passer silencieusement ».
Cette règle résume bien ce genre de situation. Tout développeur sait parfaitement qu'une des plus grandes sources d'erreurs est l'interface chaise/clavier, c'est-à-dire l'utilisateur lui-même.
Pour éviter tout problème, il faut anticiper les erreurs potentielles en essayant de se mettre à la place des utilisateurs. Les erreurs doivent alors être indiquées aux utilisateurs en les accompagnant de numéros uniques permettant de localiser l'erreur au sein du code.
III-I. Assistance utilisateur▲
Il existe différentes façons de guider un utilisateur. Les points suivants peuvent être fournis au format PDF.
La première est de fournir une notice fonctionnelle avec le logiciel :
- afin d'être efficace, la notice doit être concise. Il ne faut pas s'y perdre en explications interminables qui auront pour effet de donner envie à l'utilisateur d'arrêter de la lire. Préférez ainsi une documentation basique de 50 pages à une documentation archive complète de 500 pages ;
- chaque exemple/chapitre, devra être agrémenté de captures d'écran, afin de casser la monotonie du texte ;
- afin de rester cohérente, cette notice devra utiliser les mêmes termes que l'application. De même, on respectera également la logique des différents « process ».
La seconde méthode consiste à insérer directement les informations dans le logiciel. Différentes options :
- annoter les champs de saisie d'un texte explicatif qui sera effacé à la saisie ;
- préciser une unité ;
- utiliser une zone label affichant un texte pour expliquer ce qu'on attend dans un champ de saisie par exemple ;
- utiliser des infobulles. Pour savoir comment renseigner ou utiliser une partie du logiciel, l'utilisateur aura simplement à positionner sa souris sur l'élément concerné.
Outre cela, pour un logiciel open source, on tâchera autant que possible de fournir une documentation technique pour les développeurs et les intégrateurs.
III-J. Retour utilisateur▲
Un point important dans le développement d'un logiciel est le retour utilisateur, encore appelé « feedback ».
À l'exception du logiciel dédié à un usage exclusivement personnel, un logiciel est censé servir à un minimum d'utilisateurs.
Aussi, afin d'assurer la pérennité du logiciel développé, les retours utilisateur ont une importance non négligeable.
Les utilisateurs sont ceux qui vont permettre de faire vivre un logiciel. Les écouter et tenir compte/appliquer leurs demandes/recommandations jouera en faveur du logiciel. Se sentant écoutés, ils continueront d'utiliser un logiciel et le recommanderont autour d'eux.
Sur le principe du donnant/donnant, le feedback est une base importante dans le développement logiciel.
IV. Processus de conception▲
IV-A. Idée de base▲
Tout comme n'importe quel projet, la création d'un logiciel part d'un besoin (personnel ou professionnel) ou bien d'une idée.
Afin d'éviter toute mauvaise surprise, il est important de détailler au maximum le besoin/l'idée.
Une fois tout cela effectué, il faut passer à la partie IHM afin de savoir comment organiser le logiciel : c'est ce qu'on appelle les maquettes.
IV-B. Maquettes▲
Une maquette est un aperçu visuel (un simple dessin par exemple) qui permet de représenter grossièrement ou finement au choix, le rendu final que devra posséder le logiciel à développer.
Afin de créer votre maquette, la première chose à faire va être de lister les éléments que vous voulez en accès direct, ceux des menus… Ensuite seulement, vous êtes capable d'attaquer la partie graphique.
Les maquettes présentent un intérêt dans le sens où avant même de coder votre logiciel, elles vous aideront à concevoir l'IHM et à valider cette dernière auprès des utilisateurs finals.
De plus, une fois les maquettes validées, ces dernières vont vous simplifier le codage, car vous pourrez alors facilement coder l'IHM.
IV-B-1. Exemple▲
Pour illustrer cette histoire de maquette, nous allons prendre un exemple tout simple. Disons que le logiciel que nous devons concevoir doit permettre d'aller chercher une cotation boursière en ligne.
Les requis sont les suivants :
- pouvoir choisir parmi une liste d'actions prédéfinies ;
- pouvoir demander un code donné ;
- doit afficher la valeur à la clôture ;
- doit indiquer si l'action était en hausse ou non à la clôture ;
- quelle est la valeur la plus haute et la plus basse du jour.
Nous possédons assez d'éléments pour proposer une IHM. Bien entendu, il n'existe pas qu'une seule réponse, je vous rassure. Mais voici à quoi cela pourrait ressembler.
Développeur Python, j'utilise généralement GLADE pour mes maquettes d'IHM. C'est un outil que beaucoup d'entre vous pourraient trouver fort pratique, pour peu que vous codiez en GTK.
![Image non disponible](./images/10000201000001B3000000CD77942FD5.png)
Maintenant, si nous analysons un peu cette IHM, voici les points que nous pourrons noter :
- premièrement, nous répondons à l'intégralité des demandes du client ;
- nous respectons la logique de haut en bas et de gauche à droite ;
- au centre, nous retrouvons bien notre info principale ;
- tout est aligné et donc agréable à l'œil ;
- les outils de recherche sont regroupés au sein d'un cadre commun ;
- concernant l'historique min/max, nous allons du plus petit (gauche) au plus grand (droite), selon une logique croissante.
Voici pour les points principaux. Il en résulte une IHM répondant aux attentes du client : fonctionnelle, intuitive et ergonomique.
IV-C. Confrontation au monde réel▲
Un développeur est quelqu'un plongé dans son monde et ayant sa propre vision de la façon dont doit être développé le logiciel.
Malheureusement, cette vision, principalement technique, peut ne pas aboutir au résultat escompté par l'utilisateur final.
L'utilisateur final a également sa propre vision des choses. Pour lui, peu importe la manière dont est construit un logiciel (du moins en général). Seul le côté fonctionnel de ce dernier l'intéresse.
Le logiciel est-il simple d'emploi ? Remplit-il bien ses besoins ? Enfin, est-il ergonomique ?
Bref, une vision à l'opposé du développeur.
IV-D. Qualification▲
La qualification vise à déterminer si le logiciel créé répond bien aux attentes, aussi bien en termes de fonctionnalité que d'ergonomie. C'est ce dernier point qui nous intéresse naturellement ici.
Pour cela, de nombreuses méthodes existent. Pour la plupart, elles consistent en une série de questions, bien plus ciblées et étayées que celles posées au tout début de ce tutoriel.
Ces questionnaires sont remplis, en général, par une équipe dédiée, indépendante des développeurs, afin d'éviter toute influence.
On peut également imaginer un questionnaire à destination des utilisateurs finals.
Enfin, afin de pouvoir comparer efficacement l'ensemble des réponses, il faut utiliser une méthode adaptée, telle l'utilisation des diagrammes de Kiviat.
Pour rappel, les diagrammes de Kiviat, aussi appelés diagrammes étoiles permettent de comparer rapidement et visuellement des produits sur un ensemble de paramètres donnés.
Dans notre cas, les points basiques sont en général les questions standards :
- Utilisabilité/simplicité : est-il facile d'utiliser le logiciel ?
- Explicité : le logiciel peut-il être utilisé sans notice ?
- Convivialité : le logiciel est-il agréable à utiliser ?
- Fonctionnalité : e logiciel répond-il aux besoins ? Répond-il au cahier des charges ?
- Erreurs maîtrisées : les messages d'erreurs sont-ils explicites ?
Par la suite, chaque point est évalué, sur une échelle donnée, en essayant d'être le plus objectif possible. Ou en faisant appel aux utilisateurs, à travers le feedback.
Si nous appliquons cela à notre logiciel de données boursières. Voici ce que cela pourrait donner (ici, nous ne noterons pas la maîtrise des erreurs). L'échelle utilisée va de 0 à 5 :
V. Conclusion▲
Comme nous venons de le voir à travers cet article, les bases de l'ergonomie logicielle reposent sur de la logique et un fonctionnement intuitif.
Il suffit en effet de réfléchir à nos habitudes et à l'ordre des choses pour se rendre compte que certaines interfaces sont loin d'être ergonomiques.
Même si cet article ne vise qu'à en introduire les bases, j'espère qu'il vous permettra néanmoins de mieux maîtriser l'ergonomie de vos interfaces et vous permettra de proposer à l'avenir une meilleure expérience à vos utilisateurs.