IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Ergonomie logicielle

Les bases

Quel que soit le type d'interface que vous ayez à créer, client lourd ou léger, un minimum d'ergonomie est indispensable à vos applications.

À elle seule, elle peut en effet faire la différence, et par là assurer le succès ou non d'un logiciel ou d'un système d'exploitation.

À travers l'article suivant, je vous invite à découvrir les bases de l'ergonomie logicielle.

12 commentaires Donner une note à l´article (5)

Article lu   fois.

L'auteur

Profil ProSite personnel

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

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

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

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

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 :

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

Information

La lettre i

Image non disponible

Idée/astuce

Une ampoule

Image non disponible

Avertissement

Un panneau routier attention danger

Image non disponible

Erreur

Une croix rouge ou une croix blanche sur fond rouge

Image non disponible Image non disponible

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.

Image non disponible

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 :

Image non disponible

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

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.

Image non disponible

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 :

Image non disponible

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 :

Image non disponible

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

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 :

Image non disponible

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.

VI. Remerciements

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

Licence Creative Commons
Le contenu de cet article est rédigé par GALODE Alexandre et est mis à disposition selon les termes de la Licence Creative Commons Attribution - Pas d'Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 non transposé.
Les logos Developpez.com, en-tête, pied de page, css, et look & feel de l'article sont Copyright © 2015 Developpez.com.