Instructions: Interface utilisateur (Généralités)
Cette instruction fournit des règles générales pour le développement des interfaces utilisateur basées sur des fenêtres
Relations
Description principale

Notions fondamentales sur les fenêtres : Définition du contexte

Cette section donne un aperçu de l'anatomie d'une interface utilisateur basée sur des fenêtres. Cette présentation est nécessaire pour bien comprendre le reste de ces instructions.

Une interface utilisateur basée sur des fenêtres est divisée en fenêtres. Les fenêtres peuvent être déplacées sur l'écran, empilées les unes sur les autres et présentées sous forme d'icônes. Un système est composé en général d'une fenêtre principale et un certain nombre de fenêtres secondaires. La fenêtre principale gère l'interaction majeure avec l'utilisateur et contient souvent un nombre d'objets arbitraire. Les fenêtres secondaires sont utilisées pour prendre en charge les interactions avec les fenêtres principales en fournissant des détails sur leurs objets et les opérations sur ces objets.

Fenêtres principales

La fenêtre principale contient souvent un nombre d'objets arbitraire avec lesquels l'utilisateur agit. L'utilisateur agit en général 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 exécutée sur tous les objets sélectionnés. Les opérations courantes comprennent Couper, Copier, Coller, Supprimer et Afficher les propriétés.

La fenêtre principale contient normalement une barre de menu, à partir de laquelle les utilisateurs peuvent choisir des opérations. Les utilisateurs peuvent également choisir des opérations par les menus déroulants (par un clic droit sur l'objet lui-même) et par manipulation directe (en cliquant et en faisant glisser l'objet). Etant donné que le nombre total d'objets peut ne pas être adapté à la fenêtre principale, les utilisateurs peuvent souvent faire défiler les objets à l'aide d'une barre de défilement, ou redimensionner la fenêtre. De plus, la fenêtre principale peut souvent être divisée en sous-fenêtres (qui définissent des sous-domaines de la fenêtre), que l'utilisateur peut également redimensionner.

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, ou un objet de croquis complexe est un composite de plusieurs objets de croquis primitifs.

Fenêtres secondaires

Les fenêtres secondaires prennent en charge les fenêtres principales en fournissant des détails (tels que les propriétés) sur leurs objets et les opérations de ces objets. Seule une partie des propriétés des objets sont normalement affichées dans la fenêtre principale. Les propriétés d'un objet peuvent être visualisées en ouvrant une fenêtre de propriétés (une fenêtre secondaire) qui affiche tous les attributs d'un objet. L'utilisateur peut souvent modifier les attributs par des commandes telles que les boutons à bascule ou radio, les échelles, les zones de liste déroulante et les zones de texte.

Notez qu'il y a une différence légère et parfois assez artificielle entre les fenêtres principales et les fenêtres secondaires - il se peut qu'elles affichent les mêmes niveaux de complexité. Cependant, il existe deux différences majeures entre les fenêtres principales et secondaires :

  • Les fenêtres principales sont souvent considérées comme étant plus importantes pour l'application car elles doivent offrir une grande convivialité. Par conséquent, les efforts de développement tendent à se concentrer plutôt sur les fenêtres principales.
  • Les fenêtres secondaires s'affichent souvent en naviguant dans les fenêtres principales, et non le contraire.

En plus des fenêtres de propriétés, il y a d'autres types de fenêtres secondaires, tels que les boîtes de dialogue, les zones de message, les palettes et les fenêtres en incrustation.

De nombreuses applications sont basées sur des fichiers. Les utilisateurs peuvent lancer ces applications avec l'opération Ouvrir sur un objet de fichier (par exemple, en double-cliquant sur une icône de fichier dans un dossier). Leur fenêtre principale affiche les objets stockés dans ce fichier. Les opérations courantes sur les fichiers sont Enregistrer, Enregistrer sous, Ouvrir et Nouveau, qui peuvent en général être sélectionnées par un menu fichier dans la fenêtre principale. La fenêtre principale peut également afficher plusieurs fichiers (également appelé l'interface documents multiples, ou MDI), ce qui permet à l'utilisateur de passer entre différents fichiers.

Visual Dimensions

La clé pour des fenêtres principales ergonomiques est d'utiliser les dimensions écran lorsque l'on affiche les objets contenus et leurs attributs. Les avantages de la présentation de plus d'attributs que nécessaire pour l'identification sont que :

  • L'utilisateur éviter la navigation entre fenêtres en plus, en réduisant le nombre de fenêtres qui doivent s'afficher (lorsque l'utilisateur souhaite voir un attribut qui est présenté dans la fenêtre principale).
  • L'utilisateur peut voir les différents aspects (de différents objets) en même temps, ce qui est souvent utile pour faire des comparaisons et pour lancer des patterns reconnus. Une bonne utilisation des dimensions visuelles peut encourager les utilisateurs à développer une approche totalement nouvelle de leur travail.

Les dimensions visuelles sont :

Ces dimensions sont présentées ci-dessous. Cependant, veillez à la zone de l'écran disponible lors de la conception de la visualisation des objets. Essayez de respecter le temps fonction lorsque vous exploitez la zone d'écran aussi petite que possible et voyez si l'utilisation de plusieurs dimensions visuelles vaut l'utilisation supplémentaire de zone d'écran. L'utilisateur est peut-être mieux servi simplement par une liste de noms, car ce dont il a réellement besoin est de voir autant d'objets que possible.

Notez qu'il est important d'utiliser ces dimensions visuelles, ou de les agrandir, afin de pouvoir identifier uniquement des objets. Nous incluons également une discussion à ce sujet ci-dessous (voir la section"Identification" ci-dessous).

Notez également que les dimensions visuelles peuvent être utilisées en corrélation avec la dimension temporelle, par exemple en déplaçant des 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-dessous.

Position

Les aspects les plus intuitifs que la position peut présenter sont des positions dans le monde réel. Nous citerons les exemples suivants :

  • Les Systèmes d'Informations Géographiques (SIG) qui affichent un plan sur lequel vous présentez les objets aux mêmes longitude et latitude que dans le monde réel.
  • Les programmes de Conception Assistée par Ordinateur (CAO) qui présentent les objets et leur environnement exactement selon leurs coordonnées dans le monde réel.
  • Les éditeurs tel écran - tel écrit (WYSIWYG) qui affichent les objets (caractères) au même emplacement sur la fenêtre qu'ils apparaîtront sur une impression papier.

Il est parfois pertinent d'afficher la taille réelle (exemples des programmes de CAO et d'éditeurs tel écran - tel écrit), et d'autres fois ce n'est pas le cas ; par exemple, lorsque la taille des objets est beaucoup plus petite que la distance entre les objets.

Par exemple, imaginez un système de réservation de vols dans lequel l'utilisateur doit entrer les destinations. Une présentation possible serait d'afficher un plan indiquant les différents aéroports (où un aéroport est un objet). Naturellement, puisque les tailles réelles des aéroports ne sont pas pertinentes (et trop petites pour être vues), tous les aéroports sont affichés sous forme d'icônes de la même taille.

Cet exemple illustre également le fait que les positions réelles peuvent être utilisées même si elles ne sont pas pertinentes, du moment qu'elles aident l'utilisateur à identifier les objets. Dans cet exemple, l'utilisateur n'a pas besoin de connaître l'emplacement d'un aéroport. Mais si l'utilisateur connaît sa géographie, il peut être plus facile pour trouver des destinations sur un plan plutôt que dans une liste.

Vous pouvez également utiliser la position pour représenter des positions réelles "virtuelles". Imaginez par exemple un système de shopping à domicile grâce auquel les utilisateurs peuvent acheter des articles dans différents magasins. Une présentation possible serait d'afficher une image schématique d'un centre commercial (virtuel) dans lequel les différents magasins se trouvent (où un magasin est un objet). Cette image schématique n'a rien à voir avec les emplacements réels de ces magasins - elle exploite uniquement la mémoire de l'espace de l'utilisateur : il est plus facile de se rappeler une position x-y qu'un article dans une liste ou une hiérarchie.

Une autre utilisation alternative de la position est d'afficher des associations entre les objets : tous les objets qui ont la même position verticale sont associés d'une façon et tous les objets qui ont la même position horizontale sont associés d'une façon différente. Les feuilles de calcul en sont un exemple.

Une alternative similaire consiste à laisser un axe représenter la gamme de valeurs d'un attribut. Par exemple, dans un système de réservation de séjours, les vols réservés (où un vol est un objet) pourrait être présenté sur un axe temporel horizontal, affichant leurs relation dans le temps, leur durée et la durée du séjour de l'utilisateur dans chaque destination. L'utilisateur n'a pas besoin de savoir toutes ces choses, mais il peut être bien de les voir si elles sont présentées discrètement.

Si vous ne souhaitez pas utiliser autant de zone d'écran en présentant toute la gamme de valeurs, vous pouvez réduire les distances entre les objets. Dans l'exemple de la réservation de séjours, ceci signifierait que tous les vols réservés sont présentés horizontalement, sans espace entre eux, mais le premier vol est à gauche, le second à sa droite, etc. Les utilisateurs ne verront pas la durée qu'ils pourraient rester dans chaque destination, mais ils pourraient voir la durée des vols.

Taille

Dans de nombreux 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 portée réelle. Parfois, cependant, nous sommes libres de choisir quelle taille doit représenter, par exemple, les aéroports sur le plan qui prend en charge la sélection des destinations.

Dans ces cas-là, la taille doit représenter ce qui est le plus intuitivement perçu comme la taille réelle de l'objet. Pour un fichier, la taille de l'objet doit représenter la quantité d'espace disque occupé. Pour un compte bancaire, la taille de l'objet doit représenter le solde. Pour la plupart des tailles, une échelle logarithmique est mieux qu'une échelle proportionnelle, car une échelle proportionnelle consomme en général trop de zone d'écran.

La taille est en fait si intuitive que vous pouvez envisager l'afficher même si elle n'est pas pertinente. Après tout, dans la réalité, différentes choses (objets) occupent différentes proportions de notre champ visuel à cause de leur taille différente. Et ceci n'est pas indiscret ; cela nous aide simplement à distinguer les choses. De même, l'utilisation de différentes tailles dans l'interface utilisateur aidera souvent les utilisateurs à distinguer différents objets.

La taille doit normalement être utilisée pour présenter un seul attribut, même s'il serait possible de laisser la mesure horizontale présenter un attribut et la mesure verticale en présenter un autre (ce qui n'est pas très intuitif, et pourrait désorienter l'utilisateur).

La mesure horizontale ou la verticale doit être (logarithmiquement) proportionnelle à l'attribut dont la taille sert à illustrer - l'autre mesure doit être fixe (ou dépendre de la longueur du nom, par exemple). Si les deux mesures horizontale et verticale sont proportionnelles au même attribut, cela ajoute rarement de la valeur : cela semble indiscret et ne fait que consommer plus de zone d'écran.

Forme

Les formes sont normalement représentées par des icônes dans une interface utilisateur graphique ; la forme sert le mieux à représenter le type, car elle est plus intuitive pour indiquer une différence d'apparence qu'une différence de type. Dans la réalité, différents objets du même type d'élément ont normalement une apparence similaire, alors que des objets de types différents ont une apparence différente. Par exemple, différents objets d'une chaise ont une apparence similaire (ils ont tous quatre pieds, un siège et un dossier), alors qu'une voiture a une apparence très différente de celle d'une chaise.

Ainsi, quels sont les critères lorsque différents objets sont de types différents? Eh bien, différentes classes doivent certainement être considérées comme des types différents. Certains attributs ressemblent également à des types. Ces attributs doivent avoir un ensemble limité de valeurs possibles et leur valeur détermine normalement ce qui peut être fait avec l'objet (en termes d'opérations et de valeurs possibles d'autres attributs). Il en est de même dans la réalité - la différence la plus importante entre une chaise et une voiture est leur utilisation : une chaise sert à se reposer et une voiture est un moyen de transport.

Cependant, lorsque vous analysez ce qui doit être considéré comme des types différents, n'oubliez pas que le plus important est : quel attribut l'utilisateur est le plus susceptible de considérer comme un type.

Si vous n'avez pas plusieurs classes ni aucun attribut ressemblant à un type, vous pouvez utiliser des icônes pour représenter les différentes valeurs pour un autre attribut à valeurs limitées, mais uniquement si cet attribut représente un intérêt central pour l'utilisateur.

Les icônes sont également souvent utilisées pour afficher différents états de l'objet (en plus d'indiquer le type). Lorsque vous sélectionnez un objet, il est généralement affiché de l'une des façons suivantes : la couleur passe au noir, ou un rectangle s'affiche autour. Un autre état possible est que vous avez ouvert une fenêtre de propriétés pour l'objet. En général, d'autres états spécifiques à l'application pourraient également s'afficher, comme par exemple, pour savoir si un e-mail a été lu. Assurez-vous simplement que la présentation de l'état ne gêne pas l'utilisateur pour percevoir le type et vice versa.

Couleur

La couleur peut être divisée en trois composants, selon la perception visuelle. Ces composants sont : la nuance (c'est-à-dire rouge, bleu, marron, etc), la saturation et la clarté. Cependant, vous ne devez pas utiliser différents composants pour représenter différents attributs, car ceci sera trop difficile à percevoir pour l'utilisateur.

La nuance pourrait être utilisée pour représenter le type ou les attributs qui ont un ensemble limité de valeurs possibles. Cependant, il est préférable d'utiliser une icône pour cela, car l'icône peut être conçue de façon à ce que l'utilisateur comprenne quelle valeur elle représente, alors qu'il y a pas de distinction si intuitive entre le contenu de la couleur et les valeurs (de la plupart des types. La nuance peut donc être utilisée à la place des icônes, si l'on ne trouve aucune icône intuitive. Une alternative si vous avez de nombreuses icônes de types consiste à utiliser la nuance pour classer les icônes de type (de façon à ce que certaines icônes de signification similaire soient rouges, d'autres signifiant autre chose soient bleues, etc).

La saturation pourrait être utilisée pour représenter un attribut avec une gamme de valeurs, mais ceci rendrait l'interface utilisateur assez laide et indiscrète - l'utilisation d'une saturation différente est déconcertante et l'utilisation d'une saturation élevée est plutôt indiscrète.

La clarté est le composant de la couleur le plus convivial. Elle peut être utilisée pour représenter un attribut avec une gamme de valeurs, et elle est tellement discrète qu'elle peut être utilisée également pour des attributs d'importance secondaire. Pour que la clarté soit discrète, nous devez éviter de passer de la clarté totale (blanc) à l'obscurité totale (noir), mais uniquement passer d'une faible clarté (gris clair) à une forte obscurité (gris foncé). Dans le cas de nombreux systèmes dans lesquels les utilisateurs créent la plupart des objets, il est très utile de présenter les objets selon l'âge ; par exemple, la durée depuis la dernière modification. Ceci aide les utilisateurs à identifier l'objet avec lequel ils souhaitent travailler (qui est souvent l'objet qui présente la "durée depuis la dernière modification" la plus courte). Par conséquent, si vous n'avez pas d'attribut à gamme de valeurs que vous devez absolument présenter à l'utilisateur, envisagez de présenter l'âge.

La couleur est souvent utilisée pour rendre les icônes plus esthétiques et elle aide également l'utilisateur à faire une distinction rapide entre les icônes. Si vous fournissez des icônes multicolores, vous ne devriez probablement pas utiliser la couleur à d'autres fins.

Etant donné que certaines personnes sont daltoniens, et étant donné que les écrans ne prennent pas tous la couleur en charge, vous ne devez pas utiliser la couleur comme seul moyen d'afficher des informations vitales. D'autre part, une utilisation bien planifiée et discrète des couleurs rend l'interface utilisateur plus esthétique.

Identification

L'utilisateur doit être en mesure d'identifier de façon unique chaque objet. Parfois, les autres dimensions visuelles sont suffisantes pour l'identification, mais la plupart du temps elles ne le sont pas. L'affichage d'un nom dans ou près d'une icône est la technique d'identification la plus populaire. L'avantage des noms est qu'une toute petite zone d'écran peut afficher un grand nombre de noms différents et distincts.

Il est préférable qu'un nom soit généré à partir d'une valeur d'attribut (qui est en général textuel). L'alternative consiste à laisser les utilisateurs spécifier les noms lorsqu'ils créent les objets, mais ceci prend du temps, et donc réduit la convivialité.

Vous pouvez parfois donner une forme à l'icône, de façon à ce que le nom soit contenu dans l'icône. Ceci économise de la zone d'écran et indique plus clairement la relation entre l'icône et le nom. Cependant, ceci peut engendrer les problèmes suivants :

  • L'icône doit être vide au milieu (là où le nom apparaît).
  • Les noms ont des longueurs variables, ce qui signifie que la mesure horizontale de l'icône doit dépendre de la longueur du nom, ou que certains noms doivent être tronqués.
  • L'icône doit être beaucoup plus large que haute, étant donné que tout texte de longueur raisonnable est plus long que large.

Par conséquent, vous devez souvent afficher le nom au-dessous ou à droite de l'icône, ce qui a l'avantage de consommer moins de zone d'écran, mais qui présente l'inconvénient que l'objet (icône + nom) devient plus large que haut. Si vous n'avez pas assez d'espace pour afficher le nom (ce qui est possible, car vous pouvez en général identifier une icône sans la nommer), vous pouvez afficher le nom sous forme de fenêtres en incrustation qui s'affichent lorsque le curseur se trouve au-dessus de l'icône.

La police du nom peut être utilisée pour afficher un attribut à choix limités, si vous pouvez trouver une distinction intuitive entre la police et les valeurs d'attribut ; par exemple, vous pourriez utiliser le gras ou l'italique pour distinguer les objets, ou en souligner l'importance. Dans la plupart des cas, cependant, l'utilisation de la police n'est pas appropriée, étant donné qu'elle est plutôt indiscrète et rarement intuitive.

Si vous afficher le nom (ou, pour cela, tout autre texte que l'utilisateur est autorisé à modifier), vous devez prendre en charge la modification du nom directement dans la fenêtre principale. L'alternative consisterait à ce que l'utilisateur demande une opération Renommer puis saisisse le nouveau nom, ou bien ouvre la fenêtre de propriétés et y modifie le nom. Il n'est pas seulement plus rapide de modifier le nom directement dans la fenêtre principale, mais cela respecte également le principe "on effectue des modifications là où on le voit".

Rechercher et sélectionner

Si le groupe d'objets qui doit être modifié ou subir des opérations est composé de façon à ce que l'utilisateur puisse exprimer des critères de sélection en les identifiant, l'outil de recherche de la fenêtre principale peut résoudre le problème en sélectionnant toujours le cas où tous les critères sont satisfaits.

Il y a deux façons possibles de gérer 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 trouvés s'affichent simultanément dans la fenêtre principale (car ils peuvent être trop distants les uns des autres), vous pouvez également afficher une liste de résultats de recherche dans la fenêtre de recherche. Après une recherche, l'utilisateur spécifie des critères de recherche supplémentaires ou bien effectue une opération sur les objets sélectionnés. L'avantage de cette approche est qu'elle permet à l'utilisateur de donner l'ordre d'une opération sur tous les objets qui satisfont les critères de recherche.
  • Vous fournissez un bouton Rechercher dans la fenêtre de recherche qui sélectionne le prochain objet conforme aux critères de recherche et qui fait défiler le contenu de la fenêtre principale de façon à ce que cet objet soit visible. Après une recherche, l'utilisateur peut effectuer une opération sur les objets sélectionnés, puis continuer la recherche par séquences parmi les objets conformes aux critères de recherche. L'avantage de cette approche est que l'utilisateur peut voir chaque objet trouvé dans son environnement (dans la fenêtre principale plutôt que dans une liste de résultats de recherche séparée).

Le plus souvent, vous voudrez combiner les deux cas, par exemple en incluant un bouton Sélectionner tout dans la fenêtre de recherche par séquences ou un bouton Afficher suivant dans la fenêtre de recherche parallèle.

Tri

Un exemple de tri : le système peut disposer tous les objets verticalement, en ordre alphabétique par nom ou selon la valeur d'un attribut. L'utilisateur navigue alors parmi les objets en les faisant défiler. Il s'agit de la prise en charge de la navigation la plus simple possible en termes de mise en place et d'opération de l'utilisateur. Le tri fonctionne au mieux lorsque l'utilisateur connaît toujours le nom (ou l'attribut que nous avons trié en fonction) de l'objet désiré. Un exemple d'un système qui doit être mis en place de cette façon : un annuaire téléphonique. La fenêtre principale doit souvent subir une opération pour modifier l'ordre et/ou les critères de tri.

Héritage contrôlé par l'utilisateur

Un exemple d'héritage contrôlé par l'utilisateur : les éditeurs WYSIWYG où vous définissez à quel "style" chaque paragraphe appartient, puis définissez comment ce style (c'est-à-dire chaque caractère appartenant à ce style) doit être présenté.

Un inconvénient par rapport à un outil de recherche est que l'héritage contrôlé par l'utilisateur prend en charge uniquement les modifications d'attributs (et éventuellement des associations) pour plusieurs objets, et pas l'exécution des opérations. L'héritage contrôlé par l'utilisateur implique également que l'utilisateur définisse explicitement et conserve les groupes (c'est-à-dire les styles disponibles). Il s'agit également d'un concept plus compliqué.

Cependant, si les critères de recherche ne peuvent pas être spécifiés pour les objets, ou si l'utilisateur doit effectuer des modifications relatives aux valeurs d'attributs (comme les augmenter de deux), alors l'héritage contrôlé par l'utilisateur peut être une solution.

Pour que l'héritage contrôlé par l'utilisateur soit utile, la nature de la classe doit être telle que les objets puissent être classés en groupes (qui ont une certaine signification logique pour l'utilisateur) dans lesquels la plupart des valeurs d'attributs sont les mêmes.

Un avantage par rapport à un outil de recherche : l'héritage contrôlé par l'utilisateur prend en charge l'écrasement ; par exemple, changez la valeur d'attribut mais uniquement si elle n'a pas été définie explicitement dans l'objet. L'héritage contrôlé par l'utilisateur permet également à l'utilisateur de fournir des définitions de valeurs d'attributs plus génériques (et donc plus puissantes) ; par exemple, utilisez la police de ce style, mais augmentez-la de deux pixels. L'héritage contrôlé par l'utilisateur est particulièrement utile lorsque les groupes n'ont pas de critères de recherche faciles à spécifier.

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 l'objectif est d'être héritée. Faire hériter la classe d'elle même est un peu plus puissant, car le même objet peut être utilisé pour hériter de et pour effectuer les choses prévues à l'origine pour l'objet, comme étant une facture, un compte, etc. Ceci conduit à moins de classes pour l'utilisateur (et le système) à gérer. D'autre part, créer une autre classe de laquelle hériter a l'avantage d'être plus facile à comprendre, car 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 beaucoup d'expérience en informatique et en modèles tournés vers les objets. La nouvelle classe créée doit de préférence hériter d'elle-même pour prendre en charge plusieurs niveaux d'héritage.

Pour la plupart des systèmes, l'utilisateur doit souvent modifier le groupe d'héritage pour des objets particuliers, car l'utilisateur ne connaît pas à l'avance la structure exacte des groupes d'héritage. Fournissez une opération pour ce faire.

Si vous décidez de prendre en charge l'héritage contrôlé par l'utilisateur dans votre système, analysez les éléments (attributs, associations, classe) qui doivent être héritées, et prenez l'héritage en charge uniquement pour ces éléments. Ceci conduira à une manière moins générique mais plus facile (pour les utilisateurs et les développeurs) de gérer les fonctions. Modélisez les éléments qui doivent être hérités dans votre nouvelle classe. De nombreux attributs seront alors modélisés dans la classe héritant et dans la classe héritée. N'oubliez pas que l'héritage contrôlé par l'utilisateur sert à faire gagner du temps à l'utilisateur, et non pas à vous. Si la classe hérite d'elle-même, ceci implique que tout peut être hérité.

Déterminez si l'utilisateur doit vraiment créer de nouveaux objets de la classe héritée ou si le système peut fournir un nombre d'objets suffisant une bonne fois pour toutes. Interdire à l'utilisateur de créer de nouveaux objets réduira considérablement la flexibilité de l'héritage, mais le rendra d'autre part plus facile à opérer.

Déterminez également si des modifications aux attributs numériques des objets héritant doivent être interprétés comme étant relatifs à la valeur héritée ou comme étant fixes. Disons par exemple qu'un objet hérite d'une taille de police égale à 12, et que l'utilisateur la fasse passer à 14. Dans une interprétation relative, le système se rappellera la taille de la police de l'objet comme d'une valeur héritée +2 ; ainsi, si la taille de la police de l'objet hérité change la taille de la police, l'objet héritant changera également de taille de police. En cas d'interprétation relative, cela doit être noté sur l'attribut de l'objet hérité (car c'est là qu'on regarde si l'on souhaite examiner l'héritage). Il est important que l'interprétation relative soit présentée à l'utilisateur (par ex., "taille de la police : 12+2=14," plutôt que simplement "taille de la police : 14"). Vous pouvez explorer des scénarios pour trouver des situations en faveur de l'interprétation relative ou fixe. Vous pouvez être amené à prendre les deux en charge.

Etant donné que l'héritage contrôlé par l'utilisateur est destiné uniquement aux utilisateurs intermédiaires et puissants, vous devez le concevoir de façon à ce qu'il n'interfère pas avec l'utilisation normale (par exemple, lorsque l'utilisateur n'utilise pas l'héritage) ; sinon, les utilisateurs débutants seront intimidés.

N'oubliez pas que l'héritage contrôlé par l'utilisateur que vous construisez est fait pour faciliter la vie de l'utilisateur ; il n'a pas besoin d'être générique ni pur, mais il doit être convivial.

Une hiérarchie de navigation permet à l'utilisateur (ou éventuellement au système) de classer les objets en fenêtres principales ou composites, qui sont organisés de façon hiérarchique. Les hiérarchies de navigation assurent que l'utilisateur n'ait à rechercher qu'une (ou quelques) catégories. Ceci réduit le nombre d'objets qui doivent être affichés à un point donné dans le temps. Un inconvénient cependant : l'utilisateur (en général) doit gérer la classification. Un exemple de cette technique : les navigateurs de fichiers ; les répertoires et les dossiers servent à aider l'utilisateur à trouver des fichiers.

Gestion des fenêtres

La taille et la position des fenêtres sont en général entièrement contrôlées par l'utilisateur. Cependant, vous pouvez envisager de réduire 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 le nombre d'objets affichés est important, mais plus il y a de zone d'écran de consommée également. Une fenêtre principale doit normalement afficher autant d'objets que possible, mais sans consommation inutile de la zone d'écran.

  • Veillez à ce chaque fenêtre principale soit assez grande pour que tous les objets puissent s'afficher, mais qu'elle reste plus petite que l'écran. Veillez à ce que chaque fenêtre principale soit assez grande pour afficher les objets en entier, mais évitez les zones qui n'affichent rien d'utile, comme les marges dans un diffuseur de publications. Même si vous avez de l'espace pour afficher ces zones vides, elles peuvent gêner d'autres applications.
  • N'oubliez pas qu'un utilisateur est redimensionné entre les sessions. Si le nombre d'objets augmente, augmentez la taille de la fenêtre pour que tous les objets soient visibles, à moins qu'elle soit déjà à la hauteur de l'écran total, ou si l'utilisateur a choisi une taille inférieure à la taille par défaut. Si le nombre d'objets diminue, diminuez la taille, à moins que l'utilisateur ait choisi une taille supérieure à la taille par défaut. Cette règle assure que vous suiviez l'intention des opérations de redimensionnement de l'utilisateur.

Une autre limitation possible au niveau de la taille d'une fenêtre principale se présente si vous devez souvent utiliser l'application en parallèle avec d'autres applications. Vous pouvez alors maximiser la taille par défaut de la fenêtre à la moitié de l'écran (contrairement à la totalité de l'écran).

Veillez à ce que la position par défaut d'une fenêtre principale soit telle qu'elle gêne le moins possible d'autres applications. Si vous devez cacher certaines fenêtres, choisissez celles qui n'ont pas été utilisées depuis longtemps et essayez de laisser au moins une petite partie de la fenêtre visible pour que l'utilisateur puisse les activer facilement.

Un inconvénient de l'application des règles ci-dessus : cela enlève une part de contrôle à l'utilisateur (le système redimensionnera une fenêtre sans qu'on lui demande, et oubliera le redimensionnement de l'utilisateur entre les sessions). Par conséquent, si vous appliquez ces règles, vous devez permettre à l'utilisateur de les désactiver (à l'aide d'une commande).

En ce qui concerne les fenêtres secondaires, leur taille et leur position doivent être telles qu'elles ne cachent pas la fenêtre de laquelle elles ont été appelées, et éventuellement de façon à ce qu'elles ne cachent pas d'autres fenêtres secondaires. Si elles cachent la fenêtre de laquelle elles ont été appelées, essayez de vous assurer qu'elles ne cachent pas d'objets sélectionnés. Cacher des éléments vitaux, comme des objets sélectionnés, constitue un défaut courant en termes de convivialité pour les fenêtres secondaires.

Pour les fenêtres principales autres que la fenêtre principale la plus importante, vous devez également appliquer la règle concernant les tailles du dernier paragraphe.

Des boîtes de dialogue doivent cependant être placées de façon à ce qu'elles cachent la fenêtre active. Etant donné qu'elles sont temporaires et petites, l'utilisateur n'a en général pas besoin de voir la fenêtre active lorsque la boîte de dialogue est ouverte. Placer des boîtes de dialogue sur la fenêtre active assure que l'utilisateur en prend connaissance, et réduit les mouvements de souris nécessaires, car le curseur est normalement déjà sur la fenêtre active.

Pour les fenêtres de propriétés, le nombre d'attributs détermine la taille. Si la taille est trop importante (environ 1/4 de l'écran), vous devez utiliser plus de tabulations.

Informations relatives aux sessions

Toutes les configurations d'applications doivent être sauvegardées entre les sessions (sans que l'utilisateur ait besoin de l'indiquer). La taille et la position des fenêtres, la vue sélectionnée et les positions des barres de défilement doivent également être sauvegardées. Lorsque les utilisateurs redémarrent une application, celle-ci doit avoir exactement la même apparence que lorsqu'ils l'ont quittée la dernière fois. La raison à cela est qu'en général, la première chose que font les utilisateurs lorsqu'ils démarrent une session est de reprendre là où ils étaient lorsqu'ils ont quitté la dernière session.

Aide en ligne

L'aide en ligne est une partie très importante du système. Un système d'aide bien conçu doit même être en mesure de remplacer les manuels pour l'utilisateur pour la plupart des systèmes. La plupart des projets demandent des efforts considérables pour construire et produire des manuels, alors que tout le monde sait que les utilisateurs ne les utilisent jamais. Vous devriez penser à investir ces efforts dans un bon système d'aide à la place.

Il existe un certain nombre d'outils d'aide possibles à étudier :

  • Aide sur un sujet est l'outil d'aide le plus important. Il permet à l'utilisateur de saisir un sujet ou de parcourir un sujet existant et fournit de l'aide sur ces sujets. La clé est de fournir un index d'aide important avec de nombreux synonymes. N'oubliez pas : l'utilisateur peut ne pas connaître le terme correct lorsqu'il a besoin d'aide.
  • Aide sur un objet est une aide contextuelle. Elle affiche du texte qui explique une partie spécifique (un objet) de l'interface utilisateur. L'utilisateur demande une aide contextuelle, puis sélectionne la partie de l'interface utilisateur pour laquelle il a besoin d'aide. Ce type d'aide doit être disponible pour chaque partie de l'interface utilisateur, si elle doit être conviviale. Une autre alternative consiste à fournir une aide implicite sous formes de fenêtres en incrustation - une forme condensée d'aide contextuelle que le système présente à côté du curseur lorsque l'utilisateur attend quelques instants. L'utilisation d'aide implicite sous forme de fenêtres en incrustation a l'avantage de ne pas interférer avec le fonctionnement normal de l'interface utilisateur.
  • Zone de message est une zone (en général la fenêtre principale) où le système imprime des "commentaires" non sollicités sur les actions de l'utilisateur. Elle doit être facultative si elle est fournie.
  • Assistants : une technique populaire que vous devez envisager de fournir lorsque l'utilisateur demande de l'aide quant au mode d'opération. Un assistant guide l'utilisateur dans une activité (non banale) à l'aide d'une technique de "prise par la main". Il affiche du texte descriptif en conjonction avec les opérations (boutons) qui permettent à l'utilisateur d'effectuer les parties de l'activité expliquées dans le texte. Un assistant posera également des questions, et, selon les réponses de l'utilisateur, effectuera automatiquement l'activité. Les assistants sont excellents pour les activités non banales et rarement utilisées.

Le besoin d'aide contextuelle et d'assistants sera probablement identifié lors du test d'utilisation. Si, lors du test d'utilisation, les utilisateurs ne comprennent pas les différentes parties de l'interface utilisateur, ceci indique un besoin d'aide contextuelle. S'ils ont des difficultés à effectuer une certaine tâche, ceci indique un besoin d'assistants.

Le problème avec de nombreux systèmes d'aide est qu'ils sont rédigés pour des débutants (avec une grande partie du texte qui explique ce qui est évident) ou pour des experts (des manuels de référence qui considèrent que l'utilisateur en sait presque autant que le programmeur qui a créé l'application). Pour la plupart des systèmes, la plupart des utilisateurs sont au niveau "intermédiaire - en évolution". Rédigez le texte d'aide pour eux.

Annuler

Annuler est une fonction très utile, bien qu'elle soit difficile à réussir (à mettre en place) en général. Elle permet aux utilisateurs d'apprendre plus rapidement, car ils n'auront pas à avoir peur de détruire quoi que ce soit. Elle réduit également le risque de perte d'informations. Une solution alternative pour éviter la perte d'informations consiste à exiger que l'utilisateur confirme toutes les opérations qui peuvent entraîner une perte d'informations. C'est en général une mauvaise solution, cependant, car cela ajoute une interaction considérable et les utilisateurs apprennent vite à confirmer automatiquement, ce qui rend cette solution inadéquate.

Une option ambitieuse consiste à également fournir Rétablir, et éventuellement plusieurs niveaux d'annulation et de rétablissement. Cependant, le premier niveau d'annulation atteint la plus grande partie de convivialité en plus.

Agent de macros

Si vous fournissez des macros, il peut être très utile d'utiliser un agent qui contrôle en permanence les actions de l'utilisateur, à la recherche de séquences d'interactions répétées. Dès qu'une séquence d'interactions répétées est trouvée, l'agent crée une macro (après avoir demandé l'autorisation à l'utilisateur). Disons que l'utilisateur a demandé "Souligner" pour deux paragraphes de texte, et que les deux fois, l'utilisateur a également changé la couleur du texte, passant au bleu, immédiatement après avoir demandé "Souligner". Alors l'agent doit demander à l'utilisateur si celui-ci souhaite une macro qui fasse les deux, "Souligner" et "Mettre en bleu" pour le paragraphe de texte sélectionné. Si c'est le cas, l'agent doit créer cette macro et un bouton de commande (ou une commande de menu) qui exécute la macro.

Si l'utilisateur sélectionne un objet lors de l'enregistrement, ceci sera normalement interprété comme une spécification "delta", c'est-à-dire quel objet a été sélectionné en rapport avec la sélection précédente (comme "sélectionner suivant", "sélectionner premier enfant", etc.).

Le fait de savoir si vous devez interpréter la modification des attributs d'un objet en spécification delta (par exemple, en interprétant le passage d'une valeur d'attribut de 12 à 14 comme une augmentation de 2 plutôt que comme une définition de 14) n'est pas si évident. L'interpréter comme une spécification delta est en général plus puissant, car le passage d'un attribut à une valeur fixe pour plusieurs objets peut souvent être accompli en sélectionnant plusieurs objets, puis en ouvrant une fenêtre d'attributs pour ceux-ci, dans lesquelles vous définissez l'attribut (à 14) une bonne fois pour toutes.

Surbrillance dynamique

Assez souvent, les associations entre les classes sont bi-directionnelles, ce qui signifie que dans l'interface utilisateur réelle, l'association est affichée sur les deux objets. Si un utilisateur, examinant l'objet A, peut voir que A est associé à l'objet B, l'inverse est alors normalement également intéressant pour l'utilisateur (lorsqu'il examine l'objet B, l'utilisateur peut voir que B est associé à A). L'association s'affiche en général dans les fenêtres de propriétés des objets, identifiant l'objet associé par un nom.

En général, visualiser des associations entre des objets dans une fenêtre principale est trompeur. Visualiser les associations sous forme de flèches ou de lignes mène souvent à une source de problèmes peu attrayante et peu discrète. Une bonne façon de visualiser les associations est de mettre en surbrillance tous les objets associés lorsque le curseur se trouve sur un objet d'association. Par exemple, lorsque des notes de bas de page sont associées à des caractères dans un éditeur de document, et que les notes sont mises en surbrillance lorsque le curseur est sur le caractère associé.