Principes et conseils : Interface utilisateur (Général)
Rubriques
Principes fondamentaux pour les fenêtres : situer le contexte
Cette section offre une vue d'ensemble de l'anatomie d'une interface utilisateur utilisant des fenêtres. Cette vue d'ensemble est nécessaire à la compréhension du reste de ces principes et conseils.
Une interface utilisateur à fenêtres est divisée en fenêtres. Ces fenêtres peuvent être déplacées sur l'écran, empilées les unes sur les autres ou encore iconisées. Un système est généralement composé d'une fenêtre principale, à laquelle s'ajoutent un certain nombre de fenêtres secondaires. La fenêtre principale gère l'interaction majeure avec l'utilisateur et contient souvent un nombre arbitraire d'objets. Les fenêtres secondaires servent à appuyer les interactions avec les fenêtres principales en fournissant des détails sur leurs objets, ainsi que sur les opérations qui sont réalisées sur ces objets.
Fenêtres principales
La fenêtre principale contient souvent un nombre arbitraire d'objets avec lesquels interagit l'utilisateur. Celui-ci interagit habituellement avec le système en sélectionnant d'abord un ou plusieurs objets, par exemple en cliquant dessus, puis en choisissant une opération (par exemple en utilisant un menu) qui est alors exécutée sur tous les objets sélectionnés.
Les opérations usuelles sont Couper, Copier, Coller,
Supprimer et Afficher les propriétés.
La fenêtre principale contient normalement une barre de menus, à partir de laquelle les utilisateurs peuvent choisir des opérations. Ces dernières peuvent également être choisies au moyen de menus contextuels (en faisant un clic droit sur l'objet lui-même) ou bien par manipulation directe (en déplaçant l'objet après avoir cliqué dessus). Etant donné que le nombre total d'objets peut s'avérer trop important pour la fenêtre principale,
les utilisateurs peuvent souvent faire défiler les objets à l'aide d'une barre de défilement, ou encore redimensionner la fenêtre. De plus, la fenêtre principale peut souvent être divisée en volets (qui définissent des sous-zones au sein de la fenêtre) que les utilisateurs ont également la possibilité de redimensionner.

Une fenêtre principale dans Microsoft Word, présentant un document.
Elle contient des objets tels que des paragraphes et des caractères (Bien que les exemples présentés ici soient tirés de la plate-forme Microsoft, ces principes et conseils ne sont en aucune façon conçus pour être spécifiques à cette plate-forme particulière).

Une fenêtre principale dans Microsoft Outlook, présentant une boîte de réception. Elle contient des objets tels que des courriers électroniques.
Composites
Un objet composite dans une interface utilisateur est un objet qui est visuellement composé d'autres objets. Par exemple, un paragraphe est un composite de caractères,
et un objet de dessin complexe est un composite formé d'un certain nombre d'objets de dessin primitifs.
Fenêtres secondaires
Les fenêtres secondaires assistent les fenêtres principales en fournissant des détails (comme les propriétés) sur leurs objets, ainsi que sur les opérations réalisées sur ces objets. Seules quelques-unes des propriétés des objets sont normalement affichées dans la fenêtre principale. Les propriétés d'un objet peuvent être consultées en ouvrant une fenêtre de propriétés (qui est une fenêtre secondaire), laquelle affiche toutes les propriétés d'un objet. L'utilisateur peut souvent modifier les attributs au moyen de contrôles tels que des touches à bascule, des boutons radio, des échelles, des boîtes de dialogue ou encore des zones de texte.

Une fenêtre secondaire dans Microsoft Word, qui est une fenêtre de propriétés affichant les propriétés d'un paragraphe.

Une fenêtre de propriétés dans Microsoft Outlook, affichant les propriétés d'un e-mail.
Notez que la frontière est ténue, et parfois même artificielle, entre fenêtres principales et secondaires ; il arrive qu'elles présentent le même niveau de complexité. Par exemple, comparez la fenêtre de document présentée plus haut et la fenêtre de courrier : la première est considérée comme principale, alors que la seconde est vue comme secondaire.
Toutefois, il existe deux différences essentielles entre fenêtres principales et secondaires :
- Les fenêtres principales sont souvent considérées comme étant plus importantes pour l'application du fait qu'elles doivent fournir une convivialité étendue. C'est la raison pour laquelle les efforts en matière de développement ont tendance à être plus centrés sur les fenêtres principales.
- Les fenêtres secondaires apparaissent souvent au cours de la navigation dans les fenêtres principales, mais l'inverse n'est pas vrai.
Outre les fenêtres de propriétés, il existe d'autres types de fenêtres secondaires,
telles que des boîtes de dialogue, de message, des palettes ou encore des fenêtres contextuelles.

Une boîte de dialogue dans Microsoft Word, fournissant une opération de recherche dans les paragraphes et caractères.
De nombreuses applications sont directement attachées à des fichiers. Les utilisateurs peuvent lancer ces applications en réalisant l'opération Ouvrir sur un objet fichier (par exemple en double-cliquant sur l'icône d'un fichier dans un dossier). Leur fenêtre principale affiche les objets contenus dans ce fichier.
Les opération usuelles sur les fichiers sont Enregistrer, Enregistrer sous, Ouvrir,
et Nouveau ; elles peuvent en général être choisies dans le menu Fichier de la fenêtre principale. Celle-ci peut également afficher des fichiers multiples (Interface à Documents Multiples, ou MDI), permettant ainsi à l'utilisateur d'aller et venir entre différents fichiers.

Une fenêtre de gestion de fichiers sur une plate-forme Microsoft Windows, montrant des fichiers et des dossiers.
Dimensions visuelles -
La clé, pour obtenir des fenêtres principales qui soient pratiques, est d'utiliser les dimensions visuelles lorsqu'il s'agit de visualiser les objets contenus et leurs attributs. Les avantages qu'il y a à présenter plus d'attributs que ne le nécessite l'identification sont que :
- L'utilisateur évite d'aller et venir sans arrêt entre les fenêtres, puisque le nombre de fenêtres à afficher se trouve réduit (lorsque l'utilisateur a besoin de voir un attribut qui est présenté dans la fenêtre principale).
- L'utilisateur peut voir les différents aspects (ou différents objets) au même moment, ce qui est souvent utile pour comparer ou pour déceler des modèles récurrents. Une bonne utilisation des dimensions visuelles peut encourager les utilisateurs à développer une touche entièrement nouvelle.
Les dimensions visuelles sont :
Ces dimensions sont présentées ci-dessous. Toutefois, tenez compte de la zone d'écran disponible lorsque vous concevez la visualisation des objets. Essayez de réduire la surcharge au maximum lorsque vous exploitez la zone d'écran, et demandez-vous si l'utilisation de plusieurs dimensions visuelles vaut la peine d'allouer une plus grande zone d'écran. Peut-être l'utilisateur est-il mieux servi par une simple liste de noms, étant donné que ce dont l'utilisateur a vraiment besoin, c'est de voir autant d'objets que possible.
Notez qu'il est important d'utiliser ces dimensions visuelles, ou de les étendre, afin d'être en mesure d'identifier les objets de façon individuelle. Nous abordons ce sujet plus bas (voir la section "Identification"
ci-après).
Notez également que les dimensions visuelles peuvent être utilisées en corrélation avec la dimension temporelle, par exemple en déplaçant les objets (leur position change au fil du temps), ou en modifiant la forme ou la couleur des objets (leur état change au fil du temps) ; ce dernier cas est abordé dans la section "Forme"
ci-après.
Position
Les aspects les plus intuitifs que la position peut présenter sont les positions du monde réel.
Nous citerons les exemples suivants :
- Les Systèmes d'Information Géographique (SIG) qui présentent une carte sur laquelle les objets apparaissent sur les mêmes longitude et latitude que celles qui sont les leurs dans la réalité.
- Les programmes de Conception Assistée par Ordinateur (CAO) qui présentent exactement les objets et leur environnement selon leurs coordonnées réelles.
- Les éditeurs What You See Is What You Get (WYSIWYG) qui affichent les objets (caractères) sur l'écran à l'endroit même où ceux-ci apparaîtront sur une impression papier.
Parfois il est pertinent d'afficher en taille réelle (comme pour les exemples du programme de CAO et du WYSIWYG), et parfois ce n'est pas le cas ; par exemple, quand la taille des objets est très inférieure à la distance entre les objets.
A titre d'exemple, imaginons que nous ayons un système de réservation aérienne dans lequel l'utilisateur doive entrer des destinations. Une présentation possible consisterait à présenter une carte affichant les différents aéroports (un aéroport est alors un objet). Naturellement,
puisque les tailles réelles des aéroports n'ont ici aucune importance (et qu'elles sont trop petites pour apparaître), tous les aéroports seront présentés sous forme d'icônes de la même taille.
Cet exemple montre également que les positions réelles peuvent être utilisées même si elles ne sont pas pertinentes, tant qu'elles aident l'utilisateur à identifier les objets. Dans l'exemple, l'utilisateur n'a pas besoin de connaître la localisation d'un aéroport. Mais s'il a des connaissances en géographie, il peut lui être plus facile de trouver des destinations sur une carte plutôt que sur une liste.
Vous pouvez également utiliser une position pour représenter des positions réelles "virtuelles". Par exemple, imaginez un système de télé-achat dans lequel les utilisateurs pourraient acheter des articles venant de différents magasins. Une représentation possible consiste en un schéma de grande surface (virtuelle) sur lequel sont positionnés les différents magasins (un magasin est alors un objet). Ce schéma n'a rien à voir avec la position véritable de ces magasins ; il exploite simplement la mémoire spatiale de l'utilisateur : il est plus aisé de se rappeler une position x-y qu'un article sur une liste ou dans une hiérarchie.
Il existe une autre utilisation de la position, qui consiste à faire apparaître les associations entre les objets : tous les objets qui ont la même position verticale sont associés d'une manière, et tous ceux qui partagent une même position horizontale le sont d'une autre. Les tableurs en sont un exemple.
Une alternative similaire revient à laisser un axe représenter la gamme de valeurs d'un certain attribut. Par exemple, dans un système de réservation de voyages, les vols réservés (un vol étant alors un objet) pourraient être représentés le long d'un axe temporel horizontal faisant état de leur position dans le temps, du temps qu'ils vont durer ainsi que du temps que va passer l'utilisateur à chaque destination. Ce sont là des choses que l'utilisateur n'est pas tenu de savoir, mais il est agréable de les consulter si leur présentation n'est pas dérangeante.
Si vous ne souhaitez pas utiliser tant de zone d'écran en présentant la gamme de valeurs dans toute son étendue, vous pouvez réduire les distances entre les objets. Dans l'exemple de la réservation de voyages, cela signifierait que tous les vols réservés soient présentés horizontalement sans espace entre eux, avec le premier vol tout à gauche, le second immédiatement à droite du premier, et ainsi de suite. Les utilisateurs ne verraient pas combien de temps ils resteraient à chaque destination, mais ils pourraient être informés de la durée des vols.
Taille
Dans bien des cas, la "taille" doit représenter la même chose que la position. Dans un système de CAO, par exemple, la taille doit naturellement représenter la dimension réelle.
Parfois, pourtant, nous sommes libres de choisir quelle taille devra représenter, par exemple, les aéroports, sur la carte servant au choix de la destination.
Le cas échéant, la taille devra représenter ce qui est le plus intuitivement perçu comme étant la taille réelle de l'objet. Pour un fichier, la taille de l'objet devra représenter l'espace disque occupé. Pour un compte bancaire, la taille de l'objet devra représenter le solde. Pour la plupart des tailles, une échelle logarithmique est préférable à une échelle proportionnelle, car cette dernière consomme en général trop de zone d'écran.
La taille est tellement intuitive que vous pouvez envisager de la faire apparaître même si ce n'est a priori pas pertinent. Après tout, dans la réalité, différentes choses (objets) occupent différentes portions de notre champ visuel du fait de leurs différentes tailles respectives. Et ce n'est pas gênant ; cela nous permet simplement de délimiter les choses.
De la même façon, le fait d'utiliser différentes tailles dans l'interface utilisateur permettra souvent aux utilisateurs de différencier les objets.
La taille ne devrait normalement être utilisée que pour la présentation d'un attribut, même s'il est possible de laisser les plans vertical et horizontal en présenter chacun un (ce qui n'est pas trop naturel, et pourrait en conséquence perturber l'utilisateur).
L'un ou l'autre des plans (horizontal ou vertical) devra être logarithmiquement proportionnel à l'attribut dont il s'agit d'illustrer la taille ; l'autre plan devra être fixe (ou dépendre de la longueur du nom, par exemple). Si les plans horizontal et vertical sont tous deux proportionnels au même attribut, cela ne présente que rarement de l'intérêt : c'est simplement encombrant et plus gourmand en termes de zone d'écran.
Forme
Les formes, dans une interface utilisateur graphique, sont généralement représentées par des icônes ; la forme est plutôt utilisée pour représenter le type car il est plus intuitif de définir une différence d'apparence que cela ne l'est de définir une différence de type. Dans la réalité, différents objets de même type ont généralement la même apparence, alors que des objets de différents types paraissent dissemblables. Par exemple, différents objets "chaise" semblent identiques (ils ont tous quatre pieds, une assise et un dossier), alors qu'une voiture semble très différente d'une chaise.
Dès lors, quels sont les critères pour les cas où différents objets sont de différents types ?
Par exemple, on devra certainement considérer des classes différentes comme étant des types différents. De même,
certains attributs sont des "quasi-types." Ces attributs doivent compter un ensemble limité de valeurs possibles, leur valeur déterminant généralement ce qu'il est possible de faire avec les objets (en termes d'opérations et de valeurs possibles d'autres attributs).
C'est la même chose que dans la réalité ; la différence fondamentale entre une chaise et une voiture est la façon dont elles sont utilisées : une chaise sert à se reposer, une voiture à se déplacer.
Cependant, lorsque vous analyserez ce qu'il faudra considérer comme des types différents, souvenez-vous que le plus important est : quel attribut l'utilisateur percevra-t-il le plus probablement comme un type ?
Si vous n'avez pas de classes multiples ni aucun attribut quasi-"type",
vous pouvez utiliser des icônes pour représenter les différentes valeurs de quelque autre attribut à valeur limitée, mais seulement si cet attribut présente un intérêt central pour l'utilisateur.
Les icones servent souvent à indiquer différents états de l'objet (en plus d'en indiquer le type). Quand vous sélectionnez un objet, celui-ci présente généralement l'un des deux aspects suivants : sa couleur vire au noir, ou un rectangle apparaît autour de lui. Un autre des états possibles est celui dans lequel vous avez ouvert une fenêtre de propriétés pour l'objet. Normalement, d'autres états d'application peuvent être affichés, comme par exemple l'indication selon laquelle un e-mail a été lu ou non. Assurez-vous simplement que la présentation de l'état ne rend pas la perception du type plus difficile pour l'utilisateur, et vice-versa.
Couleur
La couleur peut être divisée en trois composantes, basées sur la perception visuelle. La teinte (c'est-à-dire, rouge, bleu, marron, et ainsi de suite), la saturation et la luminosité.
Vous ne devrez toutefois pas utiliser différentes composantes pour représenter différents attributs,
car cela serait trop difficile à percevoir pour l'utilisateur.
La teinte pourra servir à représenter le type ou les attributs dont l'ensemble de valeurs possibles est limité. Cependant, il est préférable d'utiliser une icône pour cela, car celle-ci peut être conçue de telle façon que l'utilisateur comprenne quelle valeur elle représente, alors que la mise en correspondance du contenu des couleurs et (de la plupart) des types de valeur est loin d'être si intuitive.
La teinte peut ainsi être utilisée en lieu et place des icônes, si on ne trouve pas d'icônes intuitives. Si vous disposez de nombreux types d'icônes, vous pouvez également vous servir de la teinte pour catégoriser les types d'icônes (de manière à ce que certaines icônes à la signification proche soient rouges, d'autres bleues pour dénoter un autre groupe de significations, et ainsi de suite).
La saturation pourra être utilisée pour représenter un attribut à gamme de valeurs, mais cela mènera à une interface utilisateur assez laide et trop compliquée ; l'utilisation de différentes saturations est perturbante pour l'oeil et celle d'une saturation haute est assez agaçante.
La luminosité est la composante la plus pratique de la couleur. On peut l'utiliser pour représenter un attribut à gamme de valeurs, et c'est si discret qu'il est possible d'en faire également usage pour des attributs d'importance secondaire. Pour que la luminosité reste discrète,
il convient d'éviter d'aller de l'absence totale d'obscurité (blanc) à l'obscurité totale (noir), mais seulement d'une faible obscurité (gris clair) à une obscurité profonde (gris foncé). Pour de nombreux systèmes dans lesquels l'utilisateur crée l'essentiel des objets, il est très utile de présenter les objets en fonction de leur âge ; par exemple, le temps écoulé depuis la dernière modification. Cela aide les utilisateurs à identifier l'objet avec lequel ils veulent travailler (qui est souvent l'objet pour lequel le "temps écoulé depuis la dernière modification" est le plus court). Aussi, s'il n'y a pas d'attribut à gamme de valeurs que vous devez impérativement présenter à l'utilisateur, envisagez de faire ressortir l'âge.
La couleur sert souvent à faire les icônes plus attractives, esthétiquement parlant, et permet également à l'utilisateur de faire rapidement la différence entre elles. Si vous faites le choix d'icônes multicolores, il serait préférable que vous n'utilisiez pas la couleur à d'autres fins.
Compte tenu du fait que certaines personnes sont daltoniennes, et que tous les écrans ne traitent pas la couleur,
vous devrez éviter d'utiliser la couleur comme seul moyen de transmettre certaines informations vitales. D'un autre côté, une utilisation des couleurs discrète et bien pensée rend l'interface utilisateur esthétiquement plus attractive.
Identification
L'utilisateur doit être en mesure d'identifier chaque objet individuellement. Parfois, les autres dimensions visuelles suffisent à l'identification, mais la plupart du temps, ce n'est pas le cas.
Faire apparaître un nom dans une icône ou à côté de celle-ci est la technique la plus usitée pour faciliter l'identification. L'avantage des noms est qu'une zone d'écran très réduite peut présenter un grand nombre de noms distincts.
Il est préférable qu'un nom puisse être généré à partir d'une valeur d'attribut (généralement textuelle). L'alternative est de laisser les utilisateurs spécifier les noms lorsqu'ils créent les objets, mais cela prend un certain temps, et réduit la convivialité en conséquence.
Il est parfois possible de donner à l'icône une forme qui permette d'y insérer le nom. Cela économise de la zone d'écran et fournit une indication plus forte de la relation entre l'icône et le nom. Toutefois, cela peut donner lieu aux problèmes suivants :
- L'icône doit être vide en son milieu (où le nom apparaît).
- Les noms ont des longueurs variables, ce qui signifie que soit la largeur de l'icône doit dépendre de la longueur du nom, soit certains noms devront être tronqués.
- L'icône doit être bien plus large que haute, étant donné que tout texte de longueur raisonnable est plus large que haut.
En conséquence, vous devez souvent afficher le nom sous l'icône ou à la droite de celle-ci, ce qui présente l'avantage d'occuper moins de zone d'écran, mais également l'inconvénient que l'objet (icône + nom) devient encore plus large qu'il n'est haut.
Si vous n'avez pas d'espace du tout pour afficher le nom (ce qui est possible,
car on peut en général identifier une icône sans la nommer), vous pouvez afficher le nom par l'intermédiaire de fenêtres contextuelles qui apparaissent quand le curseur est sur l'icône.
La police du nom peut servir à indiquer un attribut à choix limité, si vous parvenez à trouver une correspondance intuitive entre police et valeurs d'attribut ; par exemple, vous pourriez utiliser du gras ou des italiques pour distinguer l'objet ou souligner son importance.
Dans la plupart des cas, cependant, il n'est pas judicieux de jouer avec la police, car c'est assez déplaisant à l'oeil et rarement intuitif.
Si vous affichez le nom (ou, de la même façon, tout autre texte que l'utilisateur peut modifier), il est préférable que la création/modification du nom se fasse dans la fenêtre principale. L'alternative consisterait, pour l'utilisateur, à appeler une opération Renommer puis à entrer le nouveau nom, ou à ouvrir la fenêtre de propriétés et à y saisir le nouveau nom.
Non seulement il est plus rapide de saisir le nom directement dans la fenêtre principale, mais cela vient par ailleurs conforter le principe "where you see it is where you change it" (les objets peuvent être modifiés directement là où ils apparaissent).
Outils avancés de recherche et de sélection 
Si le groupe des objets qui doivent être modifiés ou sujets à une opération est composé de telle façon que l'utilisateur peut exprimer des critères de sélection les identifiant, l'outil de recherche de la fenêtre principale peut solutionner le problème en sélectionnant toujours l'ensemble des occurrences correspondant aux critères.
Il y a deux façons possibles de conduire la recherche :
- Tous les objets auxquels les critères de recherche s'appliquent sont sélectionnés dans la fenêtre principale. Si vous ne pouvez pas garantir que tous les objets ainsi trouvés apparaissent simultanément dans cette même fenêtre (car ils peuvent être trop éloignés les uns des autres),
vous avez également la possibilité d'afficher une liste d'occurrences dans la fenêtre de recherche. A l'issue d'une recherche, soit l'utilisateur spécifie des critères de recherche supplémentaires, soit il réalise une opération sur les objets sélectionnés. Cette approche présente l'avantage de permettre à l'utilisateur d'exécuter une opération sur tous les objets conformes aux critères de recherche.
- Vous fournissez un bouton Rechercher dans la fenêtre de recherche qui sélectionne le prochain objet correspondant aux critères et fait défiler le contenu de la fenêtre principale afin que cet objet soit visible. Après une recherche, l'utilisateur peut effectuer une opération sur l'objet sélectionné puis poursuivre une recherche séquentielle sur les objets correspondant aux critères de recherche. L'avantage de cette approche réside dans le fait que l'utilisateur peut visualiser chaque objet trouvé dans son environnement (dans la fenêtre principale plutôt que dans une liste d'occurrences séparée).
Dans bien des cas, vous combinerez les deux possibilités, en incluant par exemple un bouton Sélectionner tout dans la fenêtre de recherche séquentielle ou un bouton Voir suivant
dans la fenêtre de recherche parallèle.
Tri

Comme exemple de tri, on pourrait imaginer que le système organise tous les objets verticalement, par ordre alphabétique par nom ou bien selon la valeur d'un attribut. L'utilisateur ferait alors défiler les objets devant lui. C'est là le mode de navigation le plus simple, tant en termes d'implémentation que d'exploitation par l'utilisateur.
Le tri fonctionne mieux lorsque l'utilisateur connaît toujours le nom (ou l'attribut en fonction duquel on a trié) de l'objet voulu. L'annuaire téléphonique est un bon exemple de système qui devra être implémenté de cette manière. La fenêtre principale devra si possible proposer une opération de modification de l'ordre et/ou des critères de tri.
Héritage contrôlé par l'utilisateur 
On trouve un bon exemple d'héritage contrôlé par l'utilisateur dans les éditeurs WYSIWYG, où il vous est possible de définir le "style" auquel chaque paragraphe appartient avant de définir comment ce style (c'est-à-dire : chaque caractère appartenant à ce style) devra être mis en page.
L'inconvénient par rapport à un outil de recherche réside dans le fait qu'un héritage contrôlé par l'utilisateur traite les changements d'attributs (et éventuellement d'associations) pour des objets multiples, mais pas la réalisation d'opérations. Cela ajoute donc de la surcharge en ce sens que l'utilisateur doit explicitement définir et gérer les groupes (c'est-à-dire les styles disponibles). C'est également un concept plus compliqué.
Cependant, si des critères de recherche ne peuvent pas être spécifiés pour les objets, ou si l'utilisateur doit effectuer des modifications relatives sur les valeurs d'attribut (par exemple une augmentation de deux), proposer un héritage contrôlé par l'utilisateur peut alors être une solution.
Pour que celui-ci soit utile, la nature de la classe doit être telle que les objets puissent être répartis en groupes (qui aient un sens logique pour l'utilisateur) dans lesquels l'essentiel des valeurs d'attribut soient les mêmes.
Par rapport à un outil de recherche, l'avantage d'un héritage contrôlé par l'utilisateur est qu'il
gère la substitution ; il peut par exemple ne modifier la valeur d'attribut que si celle-ci n'a pas été explicitement définie dans l'objet. Il peut également permettre à l'utilisateur de définir des valeurs d'attribut plus génériques (et par conséquent plus puissantes) ; par exemple, hériter la police du style, mais la faire deux pixels plus grand. L'héritage contrôlé par l'utilisateur est particulièrement utile lorsque les groupes n'ont pas de critères de recherche faciles à définir.
La classe pour laquelle vous prendrez en charge l'héritage contrôlé par l'utilisateur peut hériter d'elle-même, ou bien vous pouvez créer une nouvelle classe dont le but est d'être héritée.
Faire hériter la classe d'elle-même est légèrement plus efficace, étant donné que le même objet peut être utilisé à la fois pour hériter de l'objet et pour faire les choses qui étaient à l'origine dévolues à cet objet, comme être une facture, être un compte, et ainsi de suite. Cela permet à l'utilisateur (et au système) d'avoir moins de classes à gérer. D'un autre côté, créer une nouvelle classe à partir de laquelle hériter présente l'avantage d'être plus facile à
comprendre du fait que l'héritage est clairement séparé de l'opération normale de la classe. La création d'une nouvelle classe est la meilleure solution dans la plupart des cas, en particulier si les utilisateurs n'ont pas une grande expérience des ordinateurs et des modèles orientés objet.
Il est préférable que la classe que vous créerez hérite d'elle-même afin de supporter des niveaux d'héritage multiples.
Dans la plupart des systèmes, l'utilisateur doit souvent changer le groupe d'héritage d'objets particuliers compte tenu du fait qu'il ne sait pas à l'avance et avec exactitude de quelle façon les groupes d'héritage devront être structurés. Proposez donc une opération à cet effet.
Si vous décidez de prendre en charge, dans votre système, un héritage contrôlé par l'utilisateur, analysez quelles sont les choses (attributs, associations, classe) qui doivent être héritées et ne prenez alors en charge que l'héritage qui les concerne. Cela rendra la gestion de la fonctionnalité moins générique mais plus aisée (pour les utilisateurs comme pour les développeurs). Modélisez les choses qui devront être héritées dans votre nouvelle classe. De nombreux attributs seront alors modélisés à la fois dans la classe qui hérite et dans la classe héritée. Souvenez-vous que l'héritage contrôlé par l'utilisateur est conçu pour faire gagner du temps à l'utilisateur, pas à vous. Si la classe hérite d'elle-même, cela implique que tout est héritable.
Déterminez si l'utilisateur a réellement besoin de créer de nouveaux objets au sein de la classe héritée, ou si le système peut fournir un nombre d'objets satisfaisant une bonne fois pour toutes.
Empêcher l'utilisateur de créer de nouveaux objets réduira grandement la flexibilité de l'héritage, mais d'un autre côté, celui-ci n'en sera que plus simple à manier.
Déterminez également si les modifications opérées sur les attributs numériques des objets qui héritent devront être interprétées comme étant fonction de la valeur héritée ou bien comme étant fixes. Mettons, par exemple, qu'un objet hérite de la taille de police 12 et que l'utilisateur amène celle-ci à 14. Par interprétation relative, le système mémorisera la taille de police de l'objet comme valeur héritée +2 ; c'est-à-dire que si la taille de police de l'objet hérité modifie la taille de police, l'objet qui hérite modifiera également la taille de police. Si vous appliquez l'interprétation relative, il faudra le préciser sur l'attribut de l'objet hérité (car c'est là que vous regardez quand vous souhaitez examiner l'héritage). Il est important que l'interprétation relative soit présentée à l'utilisateur (par ex., "taille de police : 12+2=14," plutôt que simplement "taille de police : 14"). Si vous testez plusieurs scénarios, vous rencontrerez des situations qui plaideront les unes pour l'interprétation relative, les autres pour l'interprétation fixe. Il est sûrement préférable d'appliquer les deux.
Etant donné que l'héritage contrôlé par l'utilisateur est réservé aux utilisateurs de niveau intermédiaire et avancé, vous devez le concevoir de telle façon qu'il n'interfère pas avec une utilisation normale (par exemple lorsque l'utilisateur n'utilise pas l'héritage) ; sinon, les utilisateurs novices s'en trouveront intimidés.
Souvenez-vous que l'héritage que vous construisez a pour but de simplifier la vie de l'utilisateur ; il n'a pas forcément besoin d'être générique ou pur, mais il doit être utilisable.
Une hiérarchie de navigation permet à l'utilisateur (et éventuellement au système) de catégoriser les objets dans les fenêtres principales ou les composites, qui sont hiérarchisés. Les hiérarchies de navigation font en sorte que l'utilisateur n'ait à chercher que dans une catégorie (ou quelques unes, à la limite). Cela réduit le nombre d'objets à afficher à un moment donné. L'utilisateur doit toutefois (généralement) gérer la catégorisation, ce qui est un inconvénient. Les navigateurs de fichiers fournissent un bon exemple de cette technique : les répertoires et les dossiers ont pour but d'aider l'utilisateur à trouver les fichiers qu'il recherche.
Gestion des fenêtres
La taille et la position des fenêtres sont généralement sous le contrôle total de l'utilisateur. Vous pouvez toutefois envisager de réduire la surcharge engendrée par le fenêtrage en laissant le système influencer la taille et la position des fenêtres.
Plus une fenêtre principale est grande, plus on peut y montrer d'objets, mais plus aussi on consomme de zone d'écran. Une fenêtre principale devra normalement présenter autant d'objets que possible, mais sans consommer plus de zone d'écran que nécessaire.
- Faites chaque fenêtre principale assez grande pour que tous les objets puissent y être affichés, mais pas plus grande que l'écran. Faites-la assez grande pour montrer l'ensemble des objets mais évitez les zones qui ne présentent rien d'utile, comme les marges dans un éditeur de bureau. Même si vous avez suffisamment d'espace pour faire apparaître ces zones vides, celles-ci pourraient dissimuler d'autres applications .
- Souvenez-vous qu'un utilisateur opère des redimensionnements entre les sessions. Si le nombre d'objets croît, augmentez la taille de la fenêtre de manière à ce que tous les objets soient visibles, à moins que cette fenêtre n'occupe déjà toute la hauteur de l'écran ou que l'utilisateur ait choisi une taille inférieure à celle proposée par défaut. Si le nombre d'objets décroît, réduisez la taille, à moins que l'utilisateur n'ait choisi une taille supérieure à celle proposée par défaut. Cette règle vous permet de vous assurer que vous respectez l'intention de l'utilisateur dans ses manoeuvres de redimensionnement.
Une limitation supplémentaire de la taille de la fenêtre principale peut être nécessaire si vous avez souvent besoin d'utiliser l'application parallèlement à d'autres applications. Dans ce cas, vous pourriez fixer la taille maximum de la fenêtre principale à la moitié de l'écran (et non à la totalité de l'écran).
Règlez la position par défaut de la fenêtre principale de façon à ce qu'elle masque aussi peu que possible d'autres applications éventuelles. Si vous devez masquer certaines fenêtres, choisissez celles qui sont inactives depuis le plus longtemps, et essayez d'en garder visible au moins une petite partie afin que l'utilisateur puisse facilement les activer.
L'inconvénient qu'il y a à appliquer les règles ci-dessus réside dans le fait qu'elles retireront une partie du contrôle des mains de l'utilisateur (le système redimensionnera une fenêtre sans qu'on le lui ait demandé, et ne mémorisera pas les repositionnements de l'utilisateur entre les sessions). C'est pourquoi vous devez, si vous appliquez ces règles, permettre à l'utilisateur de les désactiver (à l'aide d'une commande).
Pour ce qui est des fenêtres secondaires, leurs taille et position devront être telles qu'elles ne masquent pas la fenêtre d'où elles ont été appelées ni, si possible, d'autres fenêtres secondaires. Si elles doivent masquer la fenêtre d'où elles ont été appelées, essayez de vous assurer qu'elles ne dissimulent pas les objets sélectionnés. Le fait de masquer des éléments vitaux, comme des objets sélectionnés, est une faille de convivialité que l'on observe couramment dans les fenêtres secondaires.
Pour les fenêtres principales autres que la fenêtre principale majeure, vous devrez également appliquer les règles de dimensionnement du dernier paragraphe.
Les boîtes de dialogue, en revanche, devront être placées de manière à masquer la fenêtre active. Etant donné qu'elles sont normalement temporaires et de taille réduite, l'utilisateur n'a en général pas besoin de voir la fenêtre active pendant que la boîte de dialogue est ouverte. Le fait de placer les boîtes de dialogue par-dessus la fenêtre active permet de s'assurer que l'utilisateur en prend connaissance, et cela réduit les mouvements de souris nécessaires puisque le curseur est normalement déjà sur la fenêtre active.
En ce qui concerne les fenêtres de propriétés, le nombre d'attributs détermine la taille. Si la taille est trop importante (approximativement 1/4 de l'écran), vous devrez utiliser des onglets supplémentaires.
Informations de session
Toutes les configurations d'application devront être sauvegardées entre les sessions (sans que l'utilisateur ait besoin de le spécifier). La taille et la position des fenêtres, la vue sélectionnée, de même que la position des barres de défilement, devront également être sauvegardées. Lorsque l'utilisateur redémarre une application, celle-ci doit avoir exactement le même aspect que lorsqu'il l'a quittée. La raison à cela est qu'habituellement, la première chose que feront les utilisateurs en démarrant une session sera de se remettre au travail là où ils se seront arrêtés à la fin de la session précédente.
Aide en ligne
L'aide en ligne est une part très importante du système. Un système d'aide bien conçu devrait même pouvoir remplacer le manuel d'utilisation pour la plupart des systèmes. La plupart des projets consacrent des efforts considérables à l'écriture et à la production de manuels alors qu'il est connu que la majeure partie des utilisateurs ne les utilisent pas. Vous devriez plutôt envisager de consacrer ces efforts à un bon système d'aide.
Il existe de nombreux outils d'aide que vous pouvez envisager :
- L'aide sur un sujet est l'outil d'aide le plus important. Il propose à l'utilisateur d'entrer un sujet ou de naviguer dans un sujet existant et fournit de l'aide sur ces sujets. Le principe est de proposer un volumineux index d'aide fort de nombreux synonymes. Souvenez-vous : l'utilisateur ne connaît pas toujours le terme exact servant à nommer ce qui lui pose problème.
- L'aide sur un objet est une aide contextuelle. Elle affiche un texte explicitant le fonctionnement d'une partie spécifique (objet) de l'interface utilisateur. L'utilisateur fait appel à l'aide contextuelle puis y sélectionne la partie de l'interface pour laquelle il a besoin d'aide.
Ce type d'aide devra, pour être exploitable, traiter de chaque partie de l'interface utilisateur. Il est également possible de fournir une aide implicite au moyen de fenêtres contextuelles ; une forme condensée d'aide contextuelle que le système propose juste à côté du curseur lorsque l'utilisateur s'attarde quelques secondes. L'utilisation d'aide implicite dans des fenêtres contextuelles présente l'avantage de ne pas interférer avec le fonctionnement normal de l'interface utilisateur.
- La zone de message est une zone (généralement située dans la fenêtre principale)
dans laquelle le système affiche des "commentaires" non-sollicités sur les actions de l'utilisateur. Si vous la proposez, il faudra que ce soit de façon optionnelle.
- Les assistants sont une technique populaire que vous devez envisager de proposer
lorsque l'utilisateur demande de l'aide sur la manière de faire quelque chose. Un assistant guide l'utilisateur
tout au long d'une tâche (suffisamment importante) à l'aide d'une technique de "cheminement main dans la main". Il fait apparaître des textes descriptifs conjointement à des opérations (boutons) qui permettent à l'utilisateur d'effectuer pas à pas les différentes phases de la tâche qui est expliquée dans le texte. Il arrivera également que l'assistant pose des questions et que, selon les réponses de l'utilisateur, il effectue automatiquement la tâche. Les assistants se révèlent excellents pour les tâches complexes et inhabituelles.
La nécessité de recourir à une aide contextuelle et à des assistants peut être identifiée à l'occasion de tests d'utilisation. Si, durant ces tests, les utilisateurs ne comprennent pas ce que sont les différentes portions de l'interface, c'est là une indication de la nécessité d'une aide contextuelle. S'ils rencontrent des difficultés dans l'exécution d'une tâche donnée, c'est cette fois le signe que des assistants seraient les bienvenus.
Le problème de nombreux systèmes d'aide est qu'ils sont soit écrits pour des novices (et consacrent en conséquence énormément de temps à l'explication d'évidences), soit pour des experts (il s'agit alors de manuels de référence qui supposent que l'utilisateur en sait pratiquement autant que le programmeur qui a réalisé l'application). Face à la plupart des systèmes, les utilisateurs sont dans leur grande majorité des
"intermédiaires qui progressent". Ecrivez donc le texte d'aide pour eux.
Annulation

L'annulation est une fonction très utile, même s'il est en général difficile de la mettre en place. Elle permet aux utilisateurs d'apprendre plus vite, étant donné qu'ils n'ont pas à craindre de détruire des choses. Elle réduit également le risque de perdre des informations. Une autre solution pour éviter les pertes d'informations consiste à demander à l'utilisateur de confirmer toute opération qui pourrait donner lieu à une perte d'informations. C'est toutefois là une mauvaise solution, en général, car cela ajoute une surcharge considérable d'interactions, et les utilisateurs prennent rapidement l'habitude de confirmer sans réfléchir, ce qui rend cette solution finalement inadéquate.
Les ambitieux peuvent faire le choix de proposer une fonction de répétition et même, éventuellement, de multiplier les niveaux d'annulation et de répétition. Néanmoins, le premier niveau d'annulation fournit l'essentiel de l'amélioration en termes de convivialité.
Agent macro 
Si vous proposez des macros, il peut être très utile d'utiliser un agent qui surveille continuellement les actions de l'utilisateur, à la recherche de séquences d'interactions répétées. Dès qu'une séquence d'interaction est répétée, l'agent crée une macro (après en avoir demandé la permission à l'utilisateur). Disons que l'utilisateur a ordonné de "Souligner" deux paragraphes de texte et qu'il a chaque fois mis le texte en bleu immédiatement après. L'agent devra alors lui demander s'il souhaite une macro qui effectue à la fois les commandes "Souligner" et "Mettre en bleu" sur le paragraphe de texte sélectionné. Si oui, l'agent devra créer une telle macro ainsi qu'un bouton (ou un élément de menu) qui permette d'exécuter cette macro.
Si l'utilisateur sélectionne un objet durant l'enregistrement, cela devra normalement être interprété comme une spécification "delta", c'est-à-dire quel objet a été sélectionné en relation avec la sélection précédente (comme "sélectionner le suivant", "sélectionner le premier enfant", et ainsi de suite).
Savoir si vous devrez interpréter la modification des attributs d'un objet comme relevant d'une spécification delta (interpréter, par exemple, la modification d'une valeur d'attribut de 12 à 14 comme une augmentation de 2 plutôt que comme un réglage à 14) n'est pas si évident. L'interpréter de la sorte est généralement plus efficace, puisque la modification d'un attribut pour lui donner une valeur fixe face à des objets multiples peut souvent être effectuée en sélectionnant ces objets multiples puis en leur ouvrant une fenêtre d'attributs, dans laquelle vous fixerez l'attribut (à 14) une bonne fois pour toutes.
Mise en relief dynamique 
Bien souvent, les associations entre classes sont bidirectionnelles, ce qui signifie que dans l'interface utilisateur réelle, l'association apparaît sur les deux objets. Si un utilisateur se focalisant sur un objet A, peut voir que A est associé à un objet B, alors l'inverse, normalement, présente également un intérêt pour l'utilisateur (c'est-à-dire qu'en se focalisant sur un objet B, celui-ci peut voir que B est associé à A).
L'association apparaît en principe dans la fenêtre de propriétés des objets,
identifiant l'objet associé par son nom.
En général, il vaut mieux éviter de visualiser les associations entre objets dans une fenêtre principale. Leur représentation en flèches et lignes prend en effet souvent l'apparence, plutôt confuse et déplaisante à l'oeil, d'une "fosse aux serpents". Il est ainsi plus agréable de mettre en relief tous les objets associés lorsque le curseur est sur l'un d'entre eux. On peut citer à titre d'exemple le cas où des notes de bas de page sont associées à des caractères dans un éditeur de document, et que ces notes sont mises en relief lorsque le curseur se trouve sur le caractère associé.
|