Interaction Homme-Machine : Support de cours

Son champ de vision est d’environ 180° ; cela signifie par exemple qu’outre son écran, un utilisateur perçoit aussi (quoique moins bien) sur les cotés. On en déduit aussi que l’utilisateur ne perçoit pas ce qui est derrière lui. Cela peut avoir son importance suivant l'environnement dans lequel se trouve l’interface : outre la réalité virtuelle, cela concerne par exemple les interfaces qui sont dans la rue (distributeurs, …​) ou dont la nature est dépendante du lieu ou elles se trouvent (machines outils, …​).

Son acuité donne la taille minimale des objets observables. En particulier, un seul pixel peut être très facilement vu. L’utilisateur d’une interface percevra souvent des artefacts graphiques ou des décalages d’objets les uns par rapport aux autres.

Sa sensibilité aux couleurs : la théorie des couleurs est complexe et parfois subjective. Sans entrer dans les détails pour l’instant, on retiendra que chaque couleur est porteuse d’une sémantique subjective, et que la perception de chaque couleur est influencée par les couleurs qui l’environnent.

Sa perception de la profondeur, grâce à la vision stéréoscopique : nous avons deux yeux qui voient chacun une image légèrement différente ; notre cerveau déduit la notion de profondeur de ces deux images. Cependant, d’autres informations secondaires peuvent aussi donner une impression de profondeur : on peut citer par exemple la taille des objets les uns par rapport aux autres, les ombres, la luminosité, …​ Ce sont ces informations qui nous permettent de « percevoir » la profondeur d’une scène en trois dimensions affichée sur un écran, par nature en deux dimensions seulement.

Sa sensibilité aux mouvements. Dans une interface graphique, le mouvement peut être utilisé au bénéfice de l’utilisateur, par exemple pour attirer son attention sur un objet clignotant, ou lui indiquer l’avancement d’une tâche grâce à une barre de progression. Cependant, trop d’éléments en mouvement à l’écran le font souvent au détriment de la compréhension de l’utilisateur.

Sa capacité à reconnaître et à différencier, grâce à la vision active, apte entre autres à isoler un élément particulier reconnaissable par une ou plusieurs caractéristiques différentes de celles des éléments environnants.

Notre vue, notre toucher et notre proprioception sont en interaction constante. Par exemple, pour saisir un objet, notre vue nous permet d’amorcer notre mouvement, de corriger la trajectoire de notre main, et de réajuster spécifiquement nos mouvements, tandis que notre toucher nous sert à confirmer que notre geste est correctement exécuté, ainsi qu’à affermir notre prise.

De manière générale, notre main dominante exécute l'action, tandis que notre main non-dominante nous permet de situer le contexte de cette action. Cette collaboration entre nos deux mains nous permet d’entreprendre des manipulations complexes.

Cependant, cette interaction entre les deux mains de l’utilisateur reste relativement peu exploitée dans le domaine des IHM. Citons comme exceptions certaines applications de réalité virtuelle et certains contrôleurs à reconnaissance de mouvements majoritairement utilisés dans le domaine des jeux vidéos.

L’informatique enseigne que tout problème peut être décomposé en sous-problèmes ; ces sous-problèmes pouvant à leur tour être décomposés, jusqu’à atteindre une série de problèmes triviaux à résoudre. La résolution dans l’ordre de tous ces problèmes triviaux permet d’atteindre le but final.

La théorie de l’action de Don Norman énonce que tout utilisateur franchit les étapes suivantes lorsqu’il manipule une interface dans un but précis :

La théorie ne donne qu’une vision partielle de la manière dont un humain tente d’accomplir ses buts à l’aide d’une IHM.

En pratique, il est nécessaire de garder en tête que :

En conséquence, il peut y avoir autant, voir davantage, de méthodes de résolution d’un même problème que d’utilisateurs.

Le type de périphérique de sortie prévalent dans le domaine des IHM est bien évidemment l'écran. Les écrans sont aujourd’hui de plusieurs types : écrans LED, LCD, vieux écrans CRT, écrans amoled, retina, etc.

Leurs caractéristiques principales sont leur résolution, la définition de l’image qu’ils offrent, leur persistance ou rémanence, et leur vitesse de rafraîchissement.

Le nombre de périphériques d’entrée disponible aujourd’hui est impressionnant : clavier, souris, molette, trackball, tablette (graphique), touchpad, joystick, joypad, …​ difficile d’être exhaustif. Un des périphériques d’entrée les plus utilisés, l’écran tactile (qu’il soit capacitif ou résistif), est à la fois un périphérique d’entrée et de sortie.

Tous ces périphériques d’entrée offrent chacun des sensations différentes, et sont donc réservés à des usages différents.

Il est possible de classer les périphériques d’entrée de différentes manières :

Une notion utile est aussi la notion d'écho. Il s’agit de la représentation graphique des actions de l’utilisateur. Par exemple lorque l’utilisateur utilise une souris, le curseur (en temps normal) ou le rectangle élastique (lors d’un redimensionnement) forment l’écho de cette souris.

Cette catégorie d’interface graphique regroupe elle-même trois sous-catégories : les interactions de type « console », celles de type « formulaire » et enfin les interfaces de navigation.

Un des fondateurs et défenseur des IHM par manipulation directe est Ben Shneiderman (The future of interactive systems and the emergence of direct manipulation, Behaviour & Information Technology, 1982).

L’idée sous-jacente à ce style d’interface est que les objets informatiques peuvent être manipulés de manière similaire à des objets physiques, et que l’utilisateur peut faire des actions sur eux à l’aide de son périphérique d’entrée.

Dans sa forme la plus « pure », une IHM par manipulation directe respecte quatre grands principes :

Cette catégorie d’IHM est rendue possible par le fait de détecter certaines données particulières issues d’un périphérique d’entrée considéré. Ces données sont ensuite comparées à un vocabulaire afin de leur donner une sémantique précise. Cette sémantique est ensuite traduite en opération(s) à effectuer par l’application.

Toutes les fonctionnalités de l’interface sont décomposées en tâches élémentaires. Chacune de ces tâches correspond à l’implémentation d’un automate à états finis. Cet automate est enrichi d’actions associées :

Ce paradigme de programmation est caractérisé par sa non-linéarité. Pour chaque objet O de l’interface : si l’événement E se produit sur l’objet O, alors le traitement T est exécuté.

Plutôt que d’implémenter directement une interface graphique en utilisant un langage de programmation, il est possible d’utiliser un langage de balisage d’interface graphique (ou User Interface Markup Language).

Les fichiers créés sont alors destinés :

Il est enfin possible d’utiliser un constructeur (builder) d’interface graphique. Il s’agit d’un logiciel WYSIWYG de création d’interface graphique.

L’utilisateur, ou plutôt les utilisateurs, sont d’un intérêt crucial, puisque ce sont eux qui décideront au cours de leur usage si le système créé est convivial ou pas. Il est donc incontournable de bien cerner qui utilisera l’interface, de bien identifier ses utilisateurs cibles. Cela peut se faire à travers certaines questions précises, dont une liste figure ci-dessous à titre d’exemple.

Répondre à ces questions n’est ni facile ni rapide, mais c’est vital, et les résultats de concevoir une IHM sans y répondre sont en général …​ décevants.

La meilleure manière de répondre à ces questions sur les utilisateurs est de leur parler. Éventuellement en parlant à leur management. L’utilisateur doit être associé au design de l’interface qu’il utilisera. Il n’est ni un objet abstrait, ni un simple sujet d’étude.

Une autre maxime du design d’interfaces utilisateur est qu’un système ne doit être conçu ni pour les utilisateurs, ni par eux, mais avec eux. Ce qu’il faut en comprendre est qu’un designer n’est pas réellement capable de penser à la place des utilisateurs, mais que ceux-ci sont le plus souvent incapable de créer leurs propres outils. Le mieux est que tous travaillent ensemble.

Les tâches de chaque utilisateur doivent être accomplies à cause d’un certain contexte. Ce contexte dépend de beaucoup de facteurs :

De la même manière qu’il est crucial de bien cerner les utilisateurs d’un système grâce à des questions pertinentes, cerner la nature exacte des tâches qu’ils ont à réaliser l’est tout autant :

Le système que vous concevez (ou achetez) n’est pas le centre de l’univers. Le contexte est important. Et la technologie seule ne résout pas tous les problèmes.

Avant d’envisager à quoi ressemblera l’interface, il est plus profitable de l’envisager à travers les concepts qu’elle permettra de manier. Ses concepts doivent être correctement définis. Un bon concept doit être adapté à l’utilisateur et à la tâche. Il faut notamment faire attention aux traditions ou habitudes qu’on manie sans réfléchir.

Lors de la conception d’une interface il est important de clairement définir chaque terme qu’on emploie. Il faut savoir de quoi on parle. En effet, si la définition même des termes utilisés par l’interface est floue et/ou changeante dès la conception, comment demander à l’utilisateur de s’y retrouver ?

Il est de plus nécessaire d’employer toujours le même terme dans une situation donnée. Utiliser des synonymes ou inventer de nouveaux termes (par exemple pour « éviter les répétitions ») est à éviter. L’utilisateur doit être en terrain connu : une IHM n’est pas un roman ou une rédaction.

Enfin, il faut rester conscient que le vocabulaire utilisé par l’application (ou par le designer de l’application), n’est pas toujours celui de l’utilisateur.

Décrire les différentes fonctionnalités de l’interface ne doit pas se faire dès le début en se reférant à des éléments graphiques. En phase de design, on étudie les différentes opérations supportées par une interface afin d’en maximiser l’ergonomie, mais on ne s’intéresse pas encore, en pratique, à quoi ressembleront graphiquement ces opérations.

Il est utile d’exploiter les connaissances que l’utilisateur possède déjà et qui concernent des interfaces similaires, que ce soit dans leur apparence ou dans leurs buts. Cela peut se traduire, par exemple, par :

L’utilisateur ne doit jamais être perdu ou livré à lui-même. Il doit pouvoir, en permanence :

Correctement guider l’utilisateur facilite son apprentissage du système et sa facilité à s’y repérer. De même, cela contribue à prévenir d’éventuelles erreurs d’utilisation dues à une mauvaise compréhension de l’état du système ou d’une opération particulière.

Il existe deux types de guidage complémentaires :

Les outils informatiques cultivent et entretiennent les habitudes de leurs utilisateurs. Les utilisateurs recherchent eux-même cela : ils veulent pouvoir au plus vite tomber dans une sorte d’utilisation inconsciente de leurs outils, afin de pouvoir les « oublier » et se concentrer sur les tâches qu’ils ont à accomplir. Plus un système informatique est homogène, mieux ils y arriveront.

Un système est homogène si, par exemple :

Ces qualités rendent le système plus prévisible, plus facilement exploitable, plus compréhensible. Tout ceci contribue à rendre les détails propres au système « oubliables », afin que l’utilisateur puisse se concentrer sur ce qu’il a à faire, au lieu de comment le faire.

Un système souple s’adapte à l’utilisateur, à sa tâche et au support sur lequel elle tourne. Il peut, par exemple :

L’utilisateur doit toujours garder le contrôle sur le système. De même, il doit comprendre de quelle manière ce contrôle s’exerce.

Un système ergonomique offrira un feedback immédiat aux actions de l’utilisateur, afin que celui-ci puisse se rendre compte de l’effet de ses actions. Ce retour offert à l’utilisateur doit être présent même si la commande est longue. Cela peut se faire via des messages de confirmation, des barres de progression, des voyants de statut, et ainsi de suite. À l’inverse, un freeze de l’IHM pendant la durée d’une opération longue est à proscrire.

Tout cela contribue à rendre les opérations permises par un système prédictible. Outre faciliter l’apprentissage, cela prévient les erreurs d’utilisation dues à une mauvaise compréhension de ses actions par l’utilisateur, ou à la simple impatience.

Lorsqu’un erreur survient, l’utilisateur doit pouvoir la percevoir et l’identifier comme une erreur. S’il est nécessaire que l’utilisateur fasse une opération explicite pour corriger une erreur, il doit être guidé afin de pouvoir faire des choix éclairés, et non livré à lui-même. Enfin, lorsqu’une erreur survient, le système doit être suffisamment robuste (ie. fiable) pour que cette erreur n’impacte pas la suite du fonctionnement du système.

Il faut garder à l’esprit que toute erreur n’est pas bloquante. Il est possible de notifier l’utilisateur de manière non-bloquante, c’est à dire sans que celui-ci doive interrompre ce qu’il est en train de faire, afin qu’il puisse identifier ce qui s’est mal passé plus tard, quand il le jugera utile.

Un système tolérant aux erreurs qui surviennent et qui offre les outils pour analyser et corriger précisément tout type d’erreur, met son utilisateur en confiance.

Les informations fournies à l’utilisateur doivent être concises et précises. Attention, le langage utilisé pour fournir ses information, ainsi que leur niveau de précision doivent être adapté à l’utilisateur. En effet, un message exposant le fonctionnement interne du système, bien que compréhensible par un développeur, n’est pas adapté à un utilisateur !

Cette concision s’applique aussi à la facilité d’exploitation du système. Il est important de minimiser le nombre et la durée des actions à réaliser par l’utilisateur pour accomplir une opération particulière.

De trop nombreuses IHMs imposent arbitrairement des restrictions à leurs utilisateurs. Par exemple :

Parfois, ces limitations ont une raison d’être due aux limitations techniques d’un système donné. Cependant, elles sont toujours perçues par l’utilisateur comme arbitraires, frustrantes, et faciles à oublier.

En conséquence, il est préférable de limiter à tout prix ces restrictions, que ce soit dans leur nombre ou leur impact.

La conception d’un système devrait prendre comme point de départ l’utilisateur et les tâches qu’il a à accomplir (voir approche anthropocentriste). Il est nécessaire, afin de maximiser l’efficience avec laquelle l’utilisateur accomplit ses tâches, qu’il puisse se concentrer sur elle, sans avoir à se préoccuper de détails d’implémentation de l’interface.

De plus, les concepts qu’utilise ce système doivent être clairement définis. Clairement définir ses concepts implique de savoir lesquels sont réellement utiles à l’utilisateur, et lesquels sont, à l’inverse, utiles au seul concepteur/développeur de l’interface.

En conséquence, les concepts et le vocabulaire propres à un système, mais non utiles à l’exécution d’une tâche, doivent être toujours invisibles pour l’utilisateur. En d’autres termes, il faut garder les mécanismes internes du système …​ à l’intérieur.

Lorsqu’un système offre toujours plus de fonctionnalités ou d’options, il promet davantage de puissance à son utilisateur. Cependant, ces améliorations fonctionnelles doivent nécessairement se retrouver dans l’IHM, au risque de rendre celle-ci toujours plus complexe. Il faut donc éviter que, pour l’utilisateur, de grands pouvoirs impliquent …​ une grande confusion !

Une IHM offrant pléthore de fonctionnalités peut être intimidante. Surtout pour un utilisateur qui n’utilise vraiment qu’une portion, parfois minime, de ces fonctionnalités.

Il vaut mieux ne pas s’aliéner les utilisateurs débutants, en cours de formation ou occasionnels. De plus, il ne faut pas freiner l’utilisateur, même expert, dans ses opérations les plus courantes en le forçant à considérer d’autres opérations offertes par le système.

En conséquence, seules les fonctionnalités les plus importantes doivent être aisément accessibles et visibles. À l’inverse, les fonctionnalités moins couramment utilisées doivent pouvoir être ignorées.

Un designer ne doit pas partir du principe que l’utilisateur connait le fonctionnement du programme, et tout spécialement pas son fonctionnement interne. L’utilisateur ne connait ni le langage, ni surtout les intentions du designer, et n’a en général pas connaissance du contexte nécessaire pour comprendre les messages d’erreur.

À titre d’exercice, avant de cliquer sur chacun des liens suivant (chacun mène vers un article de presse), lisez-en l’intitulé relativement loufoque, et essayez de vous imaginer la situation qu’ils décrivent. Ensuite seulement, cliquez et lisez l’article. Est-ce que les faits décrits correspondaient tous exactement à ce que vous aviez imaginé ?

Pour les simples utilisateurs d’un système, la situation est semblable. Il ne sont probablement pas plus idiots que le designer ou le développeur. Ils en savent même probablement davantage sur la réalité des tâches que le logiciel permet d’accomplir. Mais ils ne connaissent pas vraiment le logiciel lui-même dans le détail, et ce contexte qui leur fait défaut leur empêche par exemple de comprendre un message d’erreur qui détaille le fonctionnement interne du logiciel.

Typiquement, un développeur ou un designer pensent « inside-out » : il connaissent les détails internes du système, et s’en servent, même inconsciemment, pour évaluer l’ergonomie de l’interface externe. À l’inverse, un utilisateur lambda pense « outside-in » : il ne connaît que le logiciel de l’extérieur, et doit se servir de cette connaissance partielle pour comprendre ce qui se passe vraiment.

C’est ce biais cognitif, intrisèque aux fonctions de designer ou de développeur, qui doit être évité pour maximiser entre autres la facilité d’apprentissage et d’exploitation d’un logiciel par son utilisateur réel.

L’informatique est la traitement automatique de l’information. L’utilisateur à besoin que le système qu’il utilise lui fournisse des informations utiles, pas qu’il se contente de lui afficher des données sans traitement. Les meilleures IHMs n’embrouillent pas l’utilisateur avec des données dont il n’a pas besoin à ce moment, mais lui présentent les informations réellement nécessaires, compilées à partir de ces données.

En particulier :

De manière générale, la convivialité des données présentées réside dans l’attention portée par le concepteur aux détails.

Une maxime qui est pour beaucoup dans le fait que l’utilisateur s’approprie une interface et la trouve intuitive peut être traduite par « l’écran appartient à l’utilisateur ». Elle signifie que quand un changement survient à l’écran, l’utilisateur doit le percevoir, s’y attendre, et le maîtriser.

En pratique, cela veut dire :

Dans le domaine des IHM, les couleurs sont utilisées pour :

Il est important pour l’attrait d’une interface d’utiliser une palette de couleurs bien choisie. C’est là le travail des artistes, mais il est possible d’isoler certaines règles de base :

Ethan Marcotte a défini la notion de Responsive Design en 2010 dans un article pour le magazine A List Apart.

Cette conception implique un design unique qui s’adapte automatiquement pour tous les écrans (c’est à dire pour toutes les tailles de viewport) grâce à une mise en page fluide. Peu importe l’appareil sur lequel est affichée l’interface graphique, seule la taille de l’écran compte.

Par exemple, des éléments d’un menu disposés horizontalement sur un écran large « flottent » verticalement lorsque la largeur de l’écran se réduit. Une grille de 4×1 éléments pourra ainsi se voir successivement redimensionnée en 2×2, puis 4×1.

Le terme d’adaptive design a été utilisé pour la première fois par Aaron Gustafson dans son ouvrage Adaptive Web Design.

Il implique de concevoir un design adapté, optimal pour chaque appareil sur lequel doit s’afficher une IHM. Cela entend une stratégie de contenu propre à chaque support et ce, dès la conception. L’adaptive design est centré sur l’expérience utilisateur ; d’où la nécessité de comprendre les besoin et habitudes de navigation (potentiellement différentes) des utilisateurs de chaque appareil. Puisque l’accent est mis sur les phases d’analyse du besoin et de conception, une grande rigueur est nécessaire.

Voici un aperçu rapide des techniques de base qui rendent possible un design multi-support.

Dans tous les cas, une bonne pratique est de prévoir une ou plusieurs polices de remplacement (fallbacks). C’est pourquoi on parle plutôt aujourd’hui de familles de polices (font families) affectées à un contenu particulier.

La notion d’égalité devant le contenu (content parity, ou *One Web*(W3C)) consiste à rendre disponible les mêmes informations et services à tous les utilisateurs. Et cela, quel que soit l’appareil qu’ils utilisent pour accéder à ces contenus. Cela ne signifie cependant pas que les contenus seront affichés exactement de la même manière quel que soit l’appareil. Au contraire, les contenus devraient être présentés de la manière la plus appropriée à chaque appareil.

Ces buts sont évidemment à poursuivre dans la limite du raisonnable. En particulier, des points comme les capacités techniques ou d’input des appareils ou, dans un contexte mobile, les considérations de réseau peuvent affecter la présentation du contenu.

L’accessibilité numérique est la mise d’un à la disposition de tous les individus, quels que soient leur matériel ou logiciel, leur infrastructure réseau, leur langue maternelle, leur culture, leur localisation géographique, ou leurs aptitudes physiques ou mentales, des ressources numériques.

L’accessibilité est généralement associée à la notion de handicap. En effet, le handicap de l’utilisateur d’un logiciel influe directement sur sa capacité à l’utiliser.

Il existe en fait bien des types de handicaps différents, temporaires ou permanents, qui ont pour la majorité différents dégrés ou formes spécifiques :

Cependant, les personnes en situation de handicap ne sont pas les seules concernées par l’accessibilité d’une interface. On peut citer par exemple le cas d’une personne distraite par autre chose qui aura ses capacités de réaction et d’opération décrues, celui d’une personne opérant dans un environnement bruyant, dont la carte son est cassée ou qui a tout simplement ses enceintes éteintes qui bénéficiera de contraintes semblables à celles d’une personne sourde, le cas évident d’une personne ne maîtrisant pas la langue de l’interface, et ainsi de suite. L’accessibilité d’un logiciel concerne donc tout le monde.

Les enjeux de l’accessibilité sont nombreux :

Les situations dans lesquelles les utilisateurs ont besoin d’une interface accessible sont diverses et variées. De plus, des stratégies, produits ou aides spécifiques existent déjà pour adresser certains problèmes. Parmi eux, on peut citer entre autres :

Il parait donc difficile de répondre de manière exhaustive et appropriée à chacun de ces usages. La solution est de respecter certains standards :

Toutes ces sources ne sont bien souvent pas centrées sur l’accessibilité, mais comportent soit une partie qui lui est dédiée, soit un tas de bonnes pratiques qui permettent naturellement l’accessibilité.

L’internationalisation consiste à préparer son adaptation à des langues et des cultures différentes. C’est un travail essentiellement technique, de conception et d’implémentation. Pour qu’un logiciel puisse être considéré comme étant internationalisé

Il existe différentes manières complémentaires pour valider l’accessibilité d’un logiciel :

Il existe différentes manières de tester l’ergonomie d’un système :

Une règle à respecter absolument dans tous les cas est que le designer/développeur ne doit jamais intervenir, ne jamais guider l’utilisateur, même pour « essayer de l’aider ». Par contre, il faut toujours observer l’utilisateur, prendre des notes sur ce qu’il fait, observer ses réactions, car on apprend toujours quelque chose d’un tel test sur la qualité du système.

Il est aussi utile de s’assurer que l’utilisateur est conscient que ça n’est pas lui qui est testé, mais le système, afin de s’assurer de la sincérité de ses actions et de ses réponses.

On peut tester à toutes les étapes du développement, mais pas de la même manière ni avec les mêmes enjeux.