Ergonomie logicielle

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 :

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.

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.

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 :

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 :

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.

III-A-1. Fenêtre principale▲

<nom du logiciel> - <nom du fichier>

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 (source iconfinder, gratuite, sans feedback)
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 :

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.

• https://www.iconfinder.com/
• http://www.icon-king.com/projects/nuvola/
• http://sourceforge.net/projects/openiconlibrary/

III-A-5. Barre d'outils▲

III-A-6. Barre de statut▲

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 :

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.

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.

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.

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.

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.

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 :

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.

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.

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.

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.

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.

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.

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.

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.

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 :