Interfaces graphiques

Type WIMP
par Marc NANARD
Conservatoire national des arts et métiers (CNAM)
Laboratoire d’informatique, de robotique et de microélectronique de Montpellier (LIRMM),
UMR CNRS/université de Montpellier-II
et Jocelyne NANARD
Université de Montpellier-II, LIRMM

1. Constituants .............................................................................................. H 7 216 – 2

1.1 Action de pointer.......................................................................................... — 2
1.2 Regrouper et séparer l’information : les fenêtres ..................................... — 3
1.3 Raccourcis symboliques : les icônes .......................................................... — 7
1.4 Organiser les commandes : les menus ...................................................... — 8
2. Dialogue ...................................................................................................... — 9
2.1 Principe ......................................................................................................... — 9
2.2 Principaux interacteurs ................................................................................ — 10
2.3 Structuration syntaxique ............................................................................. — 11
2.4 Structuration visuelle................................................................................... — 12
3. Principales métaphores .......................................................................... — 15
3.1 Bureau ........................................................................................................... — 15
3.2 Dialogue et conventions .............................................................................. — 16
3.3 « Copier-coller » ........................................................................................... — 16
3.4 « Glisser-déposer » ...................................................................................... — 17
3.5 Poubelle ........................................................................................................ — 17
3.6 Arbre développable ..................................................................................... — 17
Pour en savoir plus ........................................................................................... Doc. H 7218

es habitudes d’interaction qui se sont développées du fait de l’emploi

L d’écrans ont forgé le « look and feel » des interfaces graphiques usuelles.
Petit à petit, les comportements et les conventions de représentation se sont
homogénéisés et ne diffèrent d’un système à l’autre que par de très petits
détails. Ces interfaces graphiques portent le nom générique d’interfaces WIMP
(« window, icon, menu, pointer ») en raison des interacteurs graphiques macros-
copiques que l’on y rencontre le plus fréquemment. Mais il existe des interfaces
à désignation directe, non WIMP, par exemple celles des jeux vidéo.
En pratique, les divers objets graphiques et les conventions d’usage associées
sont actuellement bien au point et sont directement disponibles sous des formes
fonctionnellement et visuellement très voisines dans les différentes boîtes à
outils qui permettent de développer des interfaces graphiques. Citons Delphi
pour Lisp, Motif pour X-Windows, Mac App et PowerPlant pour le MacIntosh, et
les bibliothèques Java pour ce dernier langage. On y trouve en particulier les
classes permettant de construire aisément des spécialisations des interacteurs
de base dont on peut avoir besoin. Toutefois, un concepteur d’interfaces doit
aussi connaître et comprendre les principes ainsi que les raisons des longues
évolutions qui ont conduit aux interacteurs actuels, car il peut être amené à
développer de nouveaux interacteurs pour des besoins spécifiques.
Après l’exposition des fondements cognitifs des interfaces graphiques [H 7 215],
cet article adopte le point de vue des objets et des techniques de l’interaction pour
l’utilisateur. L’article suivant [H 7 217] explique les principes d’architecture logicielle
pour les interfaces graphiques et les spécificités des différentes plates-formes.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 7 216 − 1
INTERFACES GRAPHIQUES _______________________________________________________________________________________________________________
1. Constituants
Les interfaces graphiques WIMP (window, icon, menu, pointer)
usuelles font intervenir deux caractéristiques principales :
— elles nécessitent de pouvoir désigner la représentation d’un
objet, d’une commande, d’une valeur. Cette action se nomme
« pointer » ;
— elles organisent le dialogue macroscopique avec les classes
d’objets graphiques suivantes :
• des fenêtres,
• des icônes,
• des menus.
Elles sont donc considérées comme des interfaces à désignation
directe. Dans l’organisation détaillée du dialogue, elles utilisent une
grande variété d’interacteurs qui mettent en œuvre le pointage. De
façon générale, le dialogue est régi par un langage dont les éléments
sont les interacteurs, aussi bien les fenêtres, les icônes, les menus
que des interacteurs comme les boutons, les boîtes de dialogue, etc.
1.1 Action de pointer
1.1.1 Principe
Toutes les interfaces à désignation directe, en particulier WIMP,
demandent à l’usager de désigner ce qu’il souhaite en le « mon-
trant » et en confirmant son choix.
■ Pointer
Le terme « pointer » désigne l’action qu’effectue l’usager qui désigne
une partie identifiée de l’écran. Deux entités interviennent :
— le moyen utilisé pour pointer ;
— l’objet qui est pointé.
■ Pointeur
Le terme « pointeur » désigne le moyen utilisé pour réaliser
l’action de pointer. Il permet de montrer l’objet d’intérêt en pointant
sur sa représentation à l’écran et en le sélectionnant.
Un pointeur est constitué de deux dispositifs :
— un « dispositif matériel de pointage » dont l’utilisateur modifie
la position dans l’espace ;
— un « dispositif logique de pointage » : le curseur.
La désignation met en jeu la boucle de Norman [H 7 215]. L’usa-
ger agit avec le dispositif de pointage (souris, touches, joystick,
tablette…) et évalue l’effet de son action en observant sur l’écran la
position d’un « curseur » qui représente le point d’intérêt de l’utilisa-
teur. C’est ce curseur qui est déplacé à l’aide du dispositif de poin-
tage. Il s’agit typiquement d’un transfert métaphorique : en
déplaçant un objet matériel, l’utilisateur agit sur un objet abstrait, un
point à l’écran. Ce point à l’écran, pour des raisons de lisibilité, est
représenté graphiquement par une croix, une flèche, etc.
■ Objet pointé
De fait, la désignation repose techniquement au niveau le plus
bas sur l’analyse de la position effective du curseur, mais elle est
très vite transformée en une désignation fonctionnelle de zones
cibles qui correspondent à la représentation graphique de l’objet sur
lequel porte l’interaction de l’utilisateur. Ainsi, c’est tel « bouton »
ou tel « item de menu », en tant que tel, qui a été « désigné » et non
telle coordonnée qui est concernée.
■ Zone cible pour la sélection d’un objet
Une zone cible désigne une zone géométrique de l’écran qui, si
elle contient le curseur et si l’utilisateur valide sa désignation, pro-
voque la sélection de l’objet associé à cette zone cible.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 7 216 − 2 © Techniques de l’Ingénieur, traité Informatique
Exemple : les zones d’un écran d’une borne interactive de vente de
billets sont très grandes et peu nombreuses pour pouvoir être dési-
gnées (pointées) du doigt, même par une personne peu habile. Un
thème très important dans la conception d’interfaces est désormais
l’accessibilité pour tous, c’est-à-dire la prise en compte des handicaps
( auditifs, visuels, moteurs…), et de façon plus générale, l’adaptation à
l’usager non expert, trop longtemps négligé par les informaticiens. La
facilité de désignation est un facteur important à prendre en compte.
Quel que soit le dispositif matériel utilisé (molettes – figure 1 –,
souris, etc.), l’interprétation des actions réalisées avec ces disposi-
tifs est transposée en désignation fonctionnelle. Elle n’est pas tou-
jours « géométrique ». Le choix de ces dispositifs repose sur
l’analyse des comportements spontanés des usagers.
Exemple : ainsi, certaines bornes SNCF utilisent une molette pour
faire défiler un pointeur horizontal désignant globalement une ligne. En
effet, il semble que les usagers novices soient plus prompts à tourner
un bouton qu’a toucher un écran. Cela s’appelle le déterminisme lin-
guistique. Il consiste à agir et penser avec le vocabulaire dont on dis-
pose déjà et ce, en termes des actions dont on a l’habitude. L’usager
ne touche pas l’écran de sa télé ; par contre, il tourne les boutons de
son poste de radio. Il peut inférer facilement qu’il peut tourner le bou-
ton qu’il voit sur la borne, alors qu’il n’inférera pas spontanément qu’il
peut toucher l’écran s’il ne voit personne le faire. Aujourd’hui, presque
tout le monde a utilisé un écran tactile, le problème est donc moins cru-
cial.
La désignation peut ne faire appel à aucune notion géométrique,
mais seulement à un parcours abstrait d’éléments. Dans ce cas, les
organes de pointage peuvent être les flèches du clavier.
Exemple : les icônes des éléments d’un dossier sur Mac ou PC
peuvent être désignées (pointées) sans utiliser la souris, directement
au moyen des flèches du clavier. Il s’agit bien d’une désignation et non
d’une nomination textuelle. On parcourt l’ensemble des icônes par
ordre alphabétique à l’aide des flèches droite et gauche. C’est une
autre façon de pointer. Elle est fréquemment utilisée pour la désigna-
tion dans les listes et les menus, comme alternative à la désignation
par souris.
1.1.2 Utilisabilité et pointage
Les problèmes d’utilisabilité concernant le pointage correspon-
dent aux difficultés de réalisation de l’opération.
1.1.2.1 Précision du pointage
Le pointage utilisé dans la désignation directe est le plus souvent
un pointage fonctionnel servant uniquement à désigner, et non un
pointage géométrique exact comme vers une cible. La précision
graphique de la visée est donc souvent secondaire, le pointage dési-
gnant une entité de taille importante (par exemple, un bouton, une
icône, un item de menu, un mot).
La précision ne prend sens que lorsque les objets à désigner sont
eux-mêmes très petits, en particulier dans les constructions graphi-
ques, retouches d’image, etc. Par contre, dans de très nombreuses
applications, une précision de l’ordre de la cinquantaine de pixels
est souvent tout à fait suffisante.
1.1.2.2 Précision et sensibilité du pointage
Le pointage implique le changement de position dans l’espace du
dispositif matériel. Il n’y a pas nécessairement de proportionnalité
entre les comportements de déplacement du dispositif physique et du
curseur. Par exemple, les souris offrent en général une sensibilité non
linéaire qui est plus grande lorsqu’on déplace moins vite la souris. Il
est ainsi possible de pointer la cible avec plus de précision lorsque l’on
amène le curseur au voisinage de la région d’intérêt.
______________________________________________________________________________________________________________
Figure 1 – Pointeur à rouleau
Figure 2 – Tablette
à numériser
Exemple : dans les débuts, ainsi que maintenant encore sur les
tablettes, il y avait proportionnalité entre les déplacements matériels et
leur effet. Cela s’est avéré peu pratique et inadapté d’un point de vue
cognitif. Les souris actuelles ont un déplacement “non linéaire” : la dis-
tance parcourue par le curseur sur l’écran est proportionnelle à la
vitesse de la souris et non à son déplacement. De ce fait, la boucle de
réaction intègre directement l’effet de la loi de Fitts (relative à la rela-
tion entre la vitesse, la précision et la distance). Quand l’usager va vite,
c’est qu’il n’a pas besoin de précision. Quand il va lentement, c’est qu’il
a besoin d’une grande précision. Cette transformation est si bien fon-
dée que l’usager ne constate même pas cette non-linéarité et la trouve
naturelle.
Les tablettes à numériser (figure 2) permettent de connaître de
façon précise la position d'un point sur une surface. Les procédés de
mesure sont divers. L'un d'eux consiste à mesurer le temps de pro-
pagation d'une onde sonore depuis plusieurs points jusqu'au stylet.
Les tablettes ont été utilisées au début principalement pour la
numérisation de cartes. On constate alors que le contrôle en posi-
tion est en général assez peu naturel. Il n’a de sens que pour le poin-
tage direct sur un document posé sur la tablette. Sur certaines
tablettes, équipées indifféremment d’un crayon et d’une souris,
celle-ci peut être contrôlée en position ou en vitesse.
La souris n’est pas le seul moyen de pointage. Elle est considérée
comme peu précise. Certains dispositifs permettent une grande pré-
cision géométrique.
Exemple : sur les premiers écrans graphiques, utilisés, par exemple,
en conception assistée par ordinateur, on utilisait pour pointer un
« réticule », c’est-à-dire deux lignes qui se croisent, comme dans un
viseur. Chacune d’elles était déplacée par une molette. C’est en couplant
le mouvement de ces deux molettes que Douglas Engelbart a inventé la
souris. Les réticules sont très précis. Ils sont encore utilisés pour les
relevés géographiques ou encore pour réaliser les cartes à partir de pho-
tos aériennes.
D’autres dispositifs permettent de capter plus de deux coordon-
nées, en particulier pour les applications 3D. Il existe des capteurs
destinés à la désignation en trois dimensions. Ils peuvent avoir
jusqu’à six degrés de liberté (trois mouvements, trois angles). Le
plus simple est la « boule » (figure 3). On tient une boule en main.
Elle est reliée à un support par un capteur d’effort. On peut la soule-
ver, la pousser en avant ou en arrière, à droite ou à gauche, et en
même temps la tourner selon les trois axes. Ce dispositif est d’un
emploi assez surprenant car les déplacements effectifs de la main
sont nuls, seul l’effort est pris en compte.
Les dispositifs ayant le plus de naturel consistent en une poignée
équipée à ses extrémités d’émetteurs ultrasonores. Un ensemble de
trois récepteurs mesure les différences de temps de parcours des
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
INTERFACES GRAPHIQUES
Figure 3 – Désignation en trois
dimensions avec une boule
Les "poignées"
pour attraper
les objets
Figure 4 – Aide au pointage (sous PowerPoint)
signaux émis et en déduit la position de la poignée. Il n’y a donc
aucune contrainte pour l’usager. Ces dispositifs sont utilisés princi-
palement dans les équipements de réalité virtuelle.
Le gant tactile mesure les efforts reçus lors du pliage des doigts.
Il laisse donc une grande liberté à la main. La mesure de sa position
est effectuée par le même procédé que précédemment.
Nota : le lecteur intéressé trouvera dans [6] une excellente classification des dispositifs
d’interaction.
1.1.2.3 Magnification des zones cibles
Dans certains logiciels, par exemple ceux de dessin, la géométrie
joue un rôle capital, le pointage sert à designer l’entité la plus petite
identifiable sur l’écran : le point. La précision graphique prend son
sens ici uniquement du fait que l’entité visée est petite. C’est pour
cela que, pour réduire la distance opératoire, les logiciels de dessin
utilisent des « poignées » (figure 4), sortes de carrés de taille suffi-
sante pour manipuler plus facilement les entités graphiques. Le
pointage des poignées est ainsi moins critique.
1.1.2.4 Ambiguïté de désignation
Parfois, des zones cibles correspondant à plusieurs objets sont
empilées sur l’écran. L’utilisateur peut être amené à des manipula-
tions supplémentaires pour pouvoir sélectionner l’objet d’intérêt.
Dans de nombreux cas, l’interface peut lever l’ambiguïté. Ainsi, les
poignées d’un objet sélectionné sont toujours considérées comme
présentes en surface, même si l’objet est en partie ou totalement
caché par d’autres. Lorsqu’un objet est caché par d’autres, sa dési-
gnation devient impossible. Il faut alors altérer temporairement la
structure pour permettre d’atteindre l’objet. Cela se produit fréque-
ment dans les logiciels de dessin, ainsi qu’avec les piles de fenêtres.
1.2 Regrouper et séparer l’information :
les fenêtres
Les interfaces à désignation directe organisent géométriquement
l’information sur l’écran pour que l’usager puisse la désigner. L’élé-
ment structurant le plus général est la fenêtre.
H 7 216 − 3
INTERFACES GRAPHIQUES _______________________________________________________________________________________________________________
1.2.1 Point de vue fonctionnel du fenêtrage
La fenêtre est le type d’interacteur qui est devenu le plus commun
dans les interfaces graphiques. Il est même devenu si commun qu’il
est utilisé indépendamment de la manipulation directe.
■ Fenêtrage
Fonctionnellement, le fenêtrage est une métaphore visuelle per-
mettant de séparer les flots d’échange dans un dialogue multifil.
L’écran est divisé en autant de zones qu’il y a de fils de dialogue
(figure 5). Chaque zone correspond à un fil. Un dispositif de poin-
tage permet à l’usager d’indiquer à quel fil il s’adresse. Le système
affiche les informations relatives à un fil donné dans la zone corres-
pondante.
Cette définition montre le caractère très général de la notion de
fenêtre, bien au-delà de son implémentation courante. Les premiers
systèmes à fenêtres, y compris les toutes premières versions de
MS Windows, ont été très proches de cette définition fonctionnelle
qui supporte des implémentations primaires, très différentes de ce
que nous connaissons aujourd’hui.
■ Dialogue multifil
Un dialogue est dit multifil (en anglais multi-thread) quand plu-
sieurs fils de conversation s’entrecroisent temporellement.
Exemples : la suite de phrases qui suit, prononcée en séquence
par une personne au marché, est un exemple typique de dialogue
multifil dans la vie courante.
« Bonjour, je voudrais un kilo de pommes… Brrr qu’il fait froid
aujourd’hui. Et votre père, sa santé va mieux ? Elles sont belles, mettez
m’en plutôt deux kilos. Avec ce temps là, vous devez vous geler à être
dehors comme ça, je vous plains. Ah, ça me fait plaisir de savoir qu’il va
mieux . Voilà dix euros… Merci. Au revoir.»
Le fil principal concerne l’achat de pommes. Il est entremêlé avec
deux autres flots, celui sur la pluie et le beau temps et celui sur la
santé. Les dialogues multifils sont extrêmement fréquents chez
l’humain et sont de plus en plus utilisés sur les ordinateurs grâce aux
systèmes multitâches.
Considérons maintenant un exemple de dialogue multifil informa-
tique.
Figure 5 – Pile de fenêtres typique reflétant plusieurs fils d’activité
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 7 216 − 4 © Techniques de l’Ingénieur, traité Informatique
Dans le milieu de la décennie1960, IBM avait sorti un système
d’exploitation multitâche « DOS » sur l’IBM 360. Ce système effectuait
trois tâches en parallèle, identifiées par les noms F1, F2 et BG. La con-
sole de l’opérateur, simple machine à écrire, listait de façon séquentielle
les messages provenant de ces trois tâches en les faisant précéder en
début de ligne par l’identifiant de cette tâche. Pour répondre aux mes-
sages, l’opérateur devait commencer la ligne par le nom de celui-ci. Il
s’agit typiquement d’un dialogue multifil. Le listing de la console était-il
particulièrement facile à lire ? Non !
Si, au lieu d’une machine à écrire, un écran avait été disponible, il
aurait suffit de séparer celui-ci en trois zones pour répartir les messages
en fonction de leur provenance et ainsi reconstituer la continuité des fils
de dialogue. Cela aurait constitué fonctionnellement un écran « à
fenêtres ».
Aujourd’hui, dans de nombreux logiciels, plusieurs fils de dialo-
gue sont gérés simultanément, chacun dans une fenêtre. Par exem-
ple, sous un traitement de texte, plusieurs fenêtres peuvent contenir
respectivement un texte, les propositions de correction orthographi-
que, ou encore les informations de recherche/substitution.
1.2.2 Systèmes actuels
Les premières fenêtres ayant des caractéristiques voisines des
fenêtres actuelles datent des années 1975. Elles sont issues des tra-
vaux du laboratoire de recherche de Xerox, à Palo Alto, bien que des
implémentations plus simples aient existé auparavant.
Les caractéristiques ajoutées depuis ne modifient pas le rôle fonc-
tionnel de la fenêtre mais enrichissent la métaphore d’interaction.
1.2.2.1 Métaphore de la pile de feuilles
La géométrie de « feuilles empilées » des fenêtres que nous
connaissons sur les écrans est l’aboutissement d’une évolution qui
est à l’origine même du nom de cette métaphore.
■ Historique : fenêtre et utilisation de l’écran
Les toutes premières implémentations de fenêtres ont utilisé une
partition de l’écran (ou pavage) dans laquelle la surface de celui-ci
était répartie de façon exclusive entre les différents fils du dialogue.
Cette forme géométrique très particulière est à l’origine du nom de
« fenêtre » (figure 6a).
■ Pourquoi la stratégie de la pile
L’espace de l’écran est limité. Si l’on partage sa surface entre les
différents fils de dialogue, la place accordée à chacun devient vite
trop petite pour être utile. Il faut une autre stratégie.
Zone du Zone du Fenêtre 1
fil de fil de
dialogue 1 dialogue 2
Fenêtre 2
Zone du Zone du Fenêtre 3
fil de fil de
dialogue 3 dialogue 4
a pavage b métaphore de la pile de feuilles
Figure 6 – Évolution du fenêtrage
______________________________________________________________________________________________________________
■ Comment associer un fil de dialogue et une fenêtre dans la pile
Les écrans graphiques permettent de dessiner des formes quelcon-
ques, en particulier de simuler la superposition de feuilles de papier
se masquant les unes les autres. On passe ainsi d’une mosaïque de
fenêtres pavant l’écran (en anglais tiles) au dessin d’une pile de
feuilles de papier (figure 6b). La feuille sélectionnée comme fil de dia-
logue actif est alors dessinée en surface afin de devenir visible. Les
autres peuvent ou non être cachées derrière.
■ Détails
Cette métaphore implique à la fois :
— une interaction de sélection (comment faire passer la feuille en
surface ?) ;
— une stratégie de rangement (où va une feuille qui était venue
en surface ?).
■ Variantes de sélection d’une fenêtre
De très nombreuses conventions d’interaction avec les fenêtres
ont été testées ou utilisées dans différents systèmes, en particulier
X-Windows et ses multiples windows managers (gestionnaires de
fenêtres). Aujourd’hui, une convention simple et cohérente semble
progressivement s’imposer : cliquer n’importe où dans une fenêtre
indique qu’on la sélectionne et la fait passer en premier plan.
Exemples de stratégies : certains systèmes (ou leurs windows
managers ) proposaient, pour commuter de fenêtre, d’utiliser une tou-
che du clavier qui faisait circuler les fenêtres en sommet de pile les
unes après les autres. Cette méthode a le défaut d’augmenter énormé-
ment les temps de commutation à cause d’affichages inutiles. Par
contre, elle permet d’accéder à des fenêtres qui seraient totalement
cachées et dont la sélection directe serait plus difficile. Elle était en
vogue sur les premiers écrans dont la taille était réduite et où la désigna-
tion des fenêtres cachées aurait été difficile (§ 1.1.2.4). Une variante de
ce mécanisme existe sous MS Windows, où ALT Tab affiche une petite
fenêtre contenant les symboles des vraies fenêtres, que l’on y fait défi-
ler sans réorganiser les vraies fenêtres. Le choix final est alors validé et
ne cause donc qu’un seul affichage de fenêtres, entraînant un meilleur
temps de réponse quand certaines fenêtres sont masquées sous une
pile trop importante.
Certains systèmes imposent, pour commuter de fenêtre, de cli-
quer exclusivement dans la barre de titre de la fenêtre cible. Cette
contrainte de positionnement est très lourde car cette barre peut
être cachée. Une telle restriction ne présente aucun intérêt. C’est
pour cela que presque tous les systèmes préfèrent interpréter un
clic indépendamment de sa position. Toutefois, cela pose un pro-
blème sémantique : que faire de ce clic dans une autre fenêtre ?
● Premier cas
Supposons que l’on clique dans une fenêtre qui était « en
dessous », pour la sélectionner et la faire venir en surface. Le clic a
eu lieu dans une zone de cette fenêtre qui était un bouton. Ce bou-
ton doit-il réagir ? A priori non !
● Second cas
On alterne entre deux fenêtres, celle dans laquelle est effectuée la
recherche d’un mot pour le remplacer et celle dans laquelle se
trouve le pilote de recherche avec le bouton « suivant ». En
appuyant sur « suivant », la position courante dans la fenêtre texte
sélectionne le mot cherché. On tape alors au clavier dans l’intention
de remplacer le mot. Le destinataire de ce fil de dialogue est le
texte.
Le choix d’une stratégie de commutation à la fois efficace, cohé-
rente avec la tâche et non perturbante sur le plan cognitif est très
délicat. Il est en général laissé à l’application qui peut avoir les com-
portements suivants :
— ignorer le premier clic dans une fenêtre ;
— le prendre en compte ;
— le simuler.
Le cas courant est l’ignorance du premier clic, pour éviter des
actions que l’usager ne souhaite pas. La prise en compte est utilisée
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
INTERFACES GRAPHIQUES
si les deux fenêtres sont « amies » et savent pour quelle raison se
fait leur alternance. Cela permet la réduction de la distance articula-
toire. Enfin, la simulation, c’est-à-dire l’anticipation sur l’action de
l’usager n’intervient que pour rediriger l’utilisation du clavier en
fonction du contexte. Par exemple, dans certains environnements
de programmation, un « coller » après « recherche » est sémanti-
quement anticipé : la frappe va vers la fenêtre de texte alors que la
fenêtre sélectionnée est celle qui contrôle la recherche d’informa-
tion. Il n’est pratiqué que pour des dialogues très fortement structu-
rés comme « chercher-remplacer ».
1.2.2.2 Titre
■ Rôle
En tant que séparateur de fils de dialogue, les fenêtres doivent
suggérer à l’usager le fil qu’elles représentent. C’est le rôle du titre.
■ Historique
Très vite, les fenêtres ont été équipées d’une barre de titre servant
à les identifier. Elle est désormais la seule caractéristique la plus
commune à toutes les fenêtres sur tous les systèmes. Toutefois, cer-
taines fenêtres n’ont pas de titre, c’est en général le cas des boîtes
de dialogue et des messages d’erreur. Leur contenu est par lui-
même suffisamment informatif du fil concerné.
■ Comment attribuer un titre à une fenêtre
Du point de vue de l’interaction homme-machine, le titre de fenê-
tre devrait avoir un rôle sémantique, en annonçant le contenu de la
fenêtre, un peu comme celui que joue le titre d’un chapitre dans un
livre. En pratique, le plus souvent, le nom du fichier joue ce rôle. Les
pages Web ont assez bien identifié le rôle fonctionnel du titre de
fenêtre, en prévoyant explicitement une balise « titre ».
■ Variantes
Certains systèmes affichent dans la barre de titre le chemin
d’accès du fichier (figure 7a) et parfois même le nom ou l’icône du
logiciel qui est utilisé pour y accéder (figure 7b). D’autres deman-
dent que l’on interagisse pour afficher le chemin d’accès. Ainsi, sur
MacIntosh, il faut appuyer sur « pomme » pour faire apparaître le
chemin dans la barre de titre sous forme d’un menu (figure 7c).
■ Autres usages
L’espace de la barre de titre est utilisé comme zone de commande
pour des fonctions directement liées à la manipulation des fenêtres
telles que leur fermeture, certaines opérations de changement de
géométrie, leur mise sous forme iconique, etc.
a affichage du chemin sous Windows
b affichage du nom de fichier sous Windows
c sous MacIntosh
Figure 7 – Barres de titre de fenêtre
H 7 216 − 5
INTERFACES GRAPHIQUES _______________________________________________________________________________________________________________
1.2.2.3 Changement de géométrie et déplacement
■ Pourquoi modifier la géométrie des fenêtres et les déplacer
Une feuille de papier a une dimension fixe. Tel fut aussi le cas des
premières fenêtres. Mais une fenêtre est une entité informatique
dont on peut changer facilement les propriétés pour les adapter aux
circonstances. On peut par exemple offrir à la fenêtre sélectionnée
la totalité de la surface de l’écran, ou ajuster la taille des fenêtres et
les déplacer pour satisfaire les besoins de l’usager, par exemple
pour rendre visibles en même temps des informations présentes
dans des fenêtres différentes.
■ Un problème induit
Lorsqu’une fenêtre a une taille fixe, le programmeur peut agencer
spatialement les informations au moment de la conception. Si la
taille de la fenêtre change, que devient cet agencement ? Il est pris
en compte dans tous les systèmes de façon plus ou moins systéma-
tique. X-Windows et Java l’ont bien explicité.
En pratique, on constate, sur le plan cognitif, qu’il est toujours
néfaste d’altérer la géométrie d’une fenêtre en réorganisant son
contenu pour l’adapter à la taille du contenant. En effet, le change-
ment de position détruit tous les automatismes que l’usager s’était
construits dans la lecture et l’usage des éléments du dialogue. Cette
possibilité n’est supportable que dans des textes. C’est pour cette
raison que la plupart de fenêtres de dialogue sous Windows et sous
MacIntosh ne sont pas « redimensionnables ».
Les pages Web sont souvent réorganisées par les navigateurs
lorsque l’on agrandit la fenêtre. Pour éviter ce désagrément, de
nombreux graphistes sont conduits à « bloquer » l’organisation du
contenu de la page dans un tableau fixe. C’est le cas de la plupart
des pages Web produites par des professionnels.
■ Historique
Le changement de taille des fenêtres a été réalisé de différentes
façons entre le début du fenêtrage et maintenant, en raison des
besoins en puissance de calcul et d’affichage nécessaires à la mani-
pulation directe des fenêtres. En effet, le déplacement d’une fenêtre
à l’écran ou son changement de taille mettent en jeu la mise à jour
de plusieurs millions d’octets. Si l’on veut que ce déplacement suive
en temps réel le mouvement de la souris, comme le demande la
manipulation directe, on atteint des dizaines de millions d’octets par
secondes. Une telle puissance d’affichage requise était hors de por-
tée des machines de la décennie 1980 et même de celles du début
des années 1990.
Les déplacements de fenêtres ont longtemps été simulés en mimant
le déplacement d’un cadre représentant la future position de la fenêtre,
comme sur les premiers MacIntosh. Ce n’est qu’à partir du Next qu’il
est devenu fréquent de déplacer une fenêtre en voyant son contenu
suivre le mouvement. Encore aujourd’hui, X-Windows utilise des
cadres pour suggérer l’emplacement des futures fenêtres.
■ Comment déplacer ou retailler les fenêtres
Le déplacement et le changement de taille sont accessibles soit
par un menu dans la barre de titre ( X-Windows, Windows), soit par
manipulation directe (MacIntosh, Windows). Dans ce dernier cas,
les bords de la fenêtre servent de poignées par lesquelles il est pos-
sible de l’étendre. Le curseur suggère la sémantique de l’action
(figure 8).
Dans la plupart des systèmes, le déplacement d’une fenêtre sans
changement de taille s’effectue en la « tenant » par la barre de titre.
Figure 8 – Forme du curseur et icône
suggérant la modification de taille
de la fenêtre
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 7 216 − 6 © Techniques de l’Ingénieur, traité Informatique
1.2.2.4 Forme iconique
■ Pourquoi réduire l’encombrement
Les fenêtres occupent beaucoup de place sur l’écran. Une alterna-
tive non exclusive à la métaphore de la pile de papier consiste en un
rangement temporaire et plus dense de fenêtres non utilisées dans
un espace spécialisé.
■ Comment réduire l’encombrement
Chaque fenêtre peut exister sous deux formes, sa forme ouverte
et sa forme iconique qui n’occupe qu’une place très réduite sur
l’écran, tout en restant facilement accessible.
■ Stratégies de mise en icône
La mise en forme iconique diffère selon les systèmes. Avant
l’introduction du système MacOS X, le MacIntosh réduisait la fenêtre
à sa barre de titre, là où elle était. Cela présentait le défaut de ne pas
augmenter l’accessibilité de la fenêtre qui pouvait rester cachée sous
d’autres.
Sur Windows, KDE ou MacOS X, la fenêtre est rangée, sous forme
d’une barre de titre réduite, dans une zone spécialisée de l’écran : la
barre de tâches. Sur le Next, la fenêtre prend la forme d’une icône
rangée en bas d’écran.
Sur le MacIntosh, avant MacOS X, les différentes applications
ouvertes étaient accessibles par un menu, alors que sous Windows,
la barre de tâches joue ce rôle.
1.2.2.5 Défilement du contenu et contrôle
■ Pourquoi faire défiler le contenu
Très rapidement, le contenu des fenêtres est devenu beaucoup
trop important pour que leur surface permette d’en afficher la tota-
lité. Il s’est avéré intéressant de disposer d’une autre métaphore
dans laquelle la fenêtre donne visibilité sur un paysage plus grand
qu’elle et que l’on peut explorer.
■ Historique : du temps à l’espace
Les fenêtres ont tout d’abord eu un comportement semblable à
celui qu’avaient les consoles jusqu'alors. Les données étaient
comme « imprimées » en bas de la page et disparaissaient naturel-
lement en haut, comme si la fenêtre était un petit écran à nombre de
lignes fixe. Même encore actuellement, la fenêtre DOS de Windows
98 a conservé ce comportement temporel et simule un écran de ter-
minal alphanumérique sans mémoire. Ce comportement est corrigé
sous Windows NT.
Peu à peu, le système de fenêtrage a été chargé de garder trace
des contenus antérieurement affichés. On pouvait ainsi réafficher
un contenu antérieur à partir d’une interaction au clavier « page
précédente ».
Très vite, un interacteur graphique, la barre de défilement, a été
mis au point pour piloter le contrôle de l’affichage. Il a induit un
changement de métaphore. Avant les barres de défilement, on listait
« séquentiellement » un document, le temps étant la variable princi-
pale perçue par l’humain. La commande pour explorer le document
s’appelait « more » (« j’en veux encore »). Par exemple, pour lister
un fichier, Unix affiche des tranches de vingt-quatre lignes, suivies
du mot « more ». L’usager valide pour obtenir la suite ou annule la
commande lorsqu’il en a assez lu. En revanche, il ne peut « revenir
plus haut ».
Maintenant, avec les barres de défilement, l’espace est devenu la
variable principale perçue par l’humain. On fait défiler le texte de
haut en bas ou de bas en haut ; le temps a disparu.
■ Comment faire défiler le contenu
Les barres de défilement sont des interacteurs très généraux, qui
ne servent pas que dans les fenêtres. Ils délivrent deux bornes et
une position courante entre ces bornes. Pour les fenêtres, la valeur
des bornes est définie par les limites du document.
______________________________________________________________________________________________________________
Le programme élabore le dessin (aussi bien pour un texte que
pour une image) dans un espace virtuel de dessin, sans se préoccu-
per de l’affichage effectif. Celui-ci est pris en compte par le méca-
nisme de fenêtrage. Seule une partie de l’espace de dessin est
affichée à l’écran, le reste est ignoré (clipping). Cette partie est défi-
nie par ses coordonnées dans l’espace de dessin. Elles sont contrô-
lées par les ascenseurs associés à la fenêtre. En agissant sur ceux-
ci, on déplace la partie visible au sein de l’espace de dessin. La posi-
tion de la fenêtre sur l’écran peut être quelconque et n’interfère pas
avec la position de la partie visible dans l’espace de dessin
(figure 9).
■ Variante des barres de défilement
Pour atteindre très vite une position quelconque dans une fenêtre,
on peut utiliser, à la place des barres de défilement, une image
réduite de la fenêtre, dans laquelle on désigne directement le posi-
tionnement courant souhaité pour la fenêtre. C’est une technique
peu répandue mais très rapide pour des documents longs. Elle est
utilisée en particulier pour la vidéo sous Adobe Première (figure 10)
où le rectangle vert indique la portion visible à l’écran.
La zone verte indique la portion de film visible à l’écran ; le cur-
seur rouge indique la position courante ; la largeur de cette fenêtre
représente la totalité du film. Notons le retour sémantique donnant
le time-code de la position courante. En agissant sur cette fenêtre,
on contrôle l’affichage réalisé dans la fenêtre principale. L’avantage
est que l’affichage de la fenêtre principale n’est déclenché que lors-
que la transaction dans cet interacteur est achevée, permettant ainsi
une interaction plus rapide.
Espace de dessin
Position
y Pour constituer une représentation universellement interprétable, le
de la partie
visible dans
le document
x Il existe des conventions (peu respectées) concernant le gra-
Partie visible
du dessin
Fenêtre dans
laquelle apparaît
la partie visible de
l'espace de dessin
Position de la fenêtre
dans l'écran
Figure 9 – Principe de la production d’une image dans une fenêtre
Figure 10 –
Fenêtre de navigation
dans la vidéo utilisée
sous Adobe Première
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
INTERFACES GRAPHIQUES
1.3 Raccourcis symboliques : les icônes
Dans une interface à désignation directe, une représentation sym-
bolique graphique des éléments à désigner est souvent utilisée. Ces
vignettes s’appellent des « icônes ».
1.3.1 Aspects fonctionnels
■ Définition
Une icône est une représentation graphique d’une information
qui prend valeur de symbole du fait de son usage conventionnel.
■ Rôle
Une icône permet, en général, de représenter une information
sous forme d’une image suggestive de beaucoup plus petite taille
que le message textuel correspondant.
■ Icônes et commandes
Les icônes sont le plus souvent utilisées pour identifier des commandes.
Elles remplacent avantageusement les libellés de boutons, car une image
suggestive peut être beaucoup plus petite qu’un message.
Dans la figure 11, il est intéressant de comparer la place occupée
par les quatre premières icônes, « nouveau document », « ouvrir »,
« sauver », « imprimer », et la place qu’auraient utilisée les libellés
correspondants.
■ Avantages
En concentrant l’information sur une surface réduite, l’ensemble
de l’icône apparaît sur la fovea de l’œil et peut être reconnue plus
vite qu’un message qui imposerait une saccade des yeux. Par son
caractère symbolique, une icône est interprétable indépendamment
de la langue naturelle. Elle a, de fait, un caractère universel, indé-
pendant des langues. Elle est internationale. C’est pour cela que les
panneaux de circulation routière sont iconiques et non textuels.
■ Inconvénients
graphisme d’une icône doit être à la fois simple et évocateur. Une mau-
vaise icône, mal conçue, mal dessinée, est pire qu’un mauvais texte.
phisme des icônes en usage dans les lieux publics (par exemple, le
personnage qui court vers la sortie, figure 12). Remarquez la pureté
de son graphisme et sa suggestivité.
Il n’y a pas pour l’instant de normes informatiques concernant les
icônes.
Figure 11 –
Efficacité spatiale
des icônes
Figure 12 – Suggestivité de l’icône du personnage
qui court vers la sortie
H 7 216 − 7
INTERFACES GRAPHIQUES _______________________________________________________________________________________________________________
1.3.2 Aspects techniques
■ Historique
Pour des raisons d’économie de mémoire, les premières icônes
étaient de petite taille (16 × 16 ou 32 × 32) et d’un graphisme symbo-
lique en noir et blanc. L’icône d’impression et l’icône du courrier uti-
lisées sur Xerox Star sont devenues des classiques. Les icônes du
MacIntosh, en particulier les icônes de fichiers, la poubelle, etc.,
étaient affichées en noir et blanc. Le Next disposait d’un écran à qua-
tre niveaux de gris et a introduit la mode des icônes réalistes (figure
13) de plus grande taille (64 × 64). Ce mouvement s’est, dans un pre-
mier temps, accentué avec l’apparition de la couleur. Certaines icô-
nes devenaient de véritables photos minuscules en couleur, faisant
perdre à l’icône son caractère de symbole. Typiquement, Linux (avec
KDE et Gnome) utilise encore des icônes de grande taille.
Dans la plupart des systèmes actuels, malgré l’accroissement de
taille des écrans, les icônes ont repris progressivement un gra-
phisme plus épuré et une taille plus petite, retrouvant leur rôle de
symbole abstrait. La figure 14 donne un exemple d’icônes simples
et suggestives pour symboliser des alignements.
■ Comment coder les icônes
Les icônes sont souvent gérées comme un alphabet d’idéogrammes,
ce qu’elles sont en quelque sorte. Pour faciliter leur intégration dans la
mise en page générale, elles sont affichées comme des images avec une
couche alpha pour gérer la transparence. La couche alpha, dans une
image, indique le coefficient de transparence de chaque pixel.
1.3.3 Aspects cognitifs : suggestivité
et sémantique
L’humain est plus sensible à la suggestivité visuelle des états qu’à
celle des actions, du fait du caractère transitoire de celles-ci. En
conséquence, lorsque l’on veut suggérer une action par une icône,
celle-ci représente l’une des situations possibles suivantes plutôt
que l’action elle-même :
— l’outil servant à l’action ;
— l’effet de l’action.
Exemple : l’icône symbolisant l’insertion d’image (figure 15) est ici
une instance d’image (paysage, montagne, soleil), Par contre, la mise
en retrait ou l’annulation d’un retrait sont symbolisées par l’état corres-
pondant du document plus une flèche indiquant le sens dans lequel se
fait la transformation. De façon analogue, l’icône de numérotation des
items suggère l’effet de l’action.
Figure 13 – Icônes
de grande taille, ayant
un dessin réaliste sur le Next
Figure 14 – Barre d’icônes simples mais suggestives (PowerPoint)
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 7 216 − 8 © Techniques de l’Ingénieur, traité Informatique
1.4 Organiser les commandes : les menus
Dans une interface à désignation directe, l’usager doit en particulier
designer les commandes qu’il veut adresser au système. Celles-ci
sont regroupées dans des menus, qui ont en particulier un rôle struc-
turant sur le plan cognitif en rapprochant des commandes voisines.
1.4.1 Aspects fonctionnels
Un menu est un regroupement géométrique d’items que l’usager
peut désigner.
Son affichage est généralement temporaire et disparaît dès que
l’usager a choisi un item. L’affichage du menu est déclenché par une
action de l’usager.
■ Historique
Les menus n’ont pas toujours eu leur forme actuelle. En parti-
culier, ils ont commencé par exister sur les consoles textuelles sous
forme de « pages » de menus dans lesquelles les choix étaient pré-
sentés. Ce n’est qu’avec les interfaces graphiques qu’ils ont pris une
forme extensible, ce qui a l’avantage de réduire la place consom-
mée par l’affichage des choix en ne présentant ceux-ci qu’à la
demande.
■ Pourquoi les menus
Les menus constituent un moyen simple pour structurer l’interac-
tion dans une métaphore à désignation directe. Ils ont un rôle struc-
turel en permettant de regrouper des ensembles de choix.
Ils économisent l’espace d’affichage en réduisant l’espace
consommé à celui nécessaire pour identifier un groupe de choix.
L’affichage est déclenché par une interaction et disparaît dès que
l’usager a effectué son choix. Seul reste l’interacteur, qui se réduit le
plus souvent à un bouton ouvrant le menu qui lui est associé.
L’ensemble de ces boutons est souvent présenté en ligne, que l’on
appelle une barre de menus. Lorsque les items d’un menu sont eux-
mêmes des boutons ouvrant d’autres menus, on obtient des menus
hiérarchiques.
L’interacteur ouvrant le menu n’a pas nécessairement de repré-
sentation visuelle, ce peut être une touche du clavier ou un bouton
de la souris.
Ainsi, un menu peut « surgir » (pop), à la position du curseur de la
souris (figure 16), suite à une interaction, par exemple un clic sur le
bouton droit de la souris sur PC ou un clic altéré par une touche du
clavier sur MacIntosh.
En contrepartie, à distance parcourue égale, l’accès à un item de
menu est beaucoup plus lent que celui à un bouton directement visi-
ble car deux actions élémentaires (déclenchement de l’affichage
puis sélection d’un item) se cumulent.
■ Rôle structurant
Les menus sont apparus comme un élément structurant du dialogue
en regroupant des choix par similitude conceptuelle. Ils facilitent la
remémoration des commandes. La mise en relation de la structure
visuelle et de la structure sémantique repose uniquement sur des cri-
tères cognitifs. Elle a pour but principal de réduire l’effort de mémori-
sation de l’usager, en lui permettant de percevoir directement la
structure de l’information à partir de son organisation géométrique
(figure 17).
______________________________________________________________________________________________________________
Figure 15 –
Symbolisme
des icônes
Figure 16 – Menu surgissant
au milieu d’un texte, suite
à un clic droit sous MS Word
Figure 17 – Exemple
de regroupement
de commandes par
similarité sémantique
Cette règle est trop souvent ignorée, mal comprise ou mal suivie.
On a rencontré des interfaces où les propositions faites à l’usager
étaient laissées en vrac. Même encore récemment, certains sites
Web, dans leurs débuts, négligeaient ces règles pourtant élémentai-
res.
1.4.2 Problèmes cognitifs spécifiques
■ Organisation structurelle
● Taille et organisation en menus hiérarchiques
Compte tenu de la limitation de la mémoire à court terme, il est
impossible de placer un grand nombre d’items dans un menu, sous
peine d’une augmentation considérable de la charge cognitive. Si le
nombre d’items tend à dépasser 10 (7 est une bonne valeur), on
effectue des regroupements pour utiliser des menus hiérarchiques.
Un item d’un niveau fait apparaître un menu du niveau inférieur.
● Reconfiguration par l’usager
Avec l’accroissement de la taille des écrans, on voit se modifier
l’équilibre entre économie de temps et économie de place. L’usager
peut reconfigurer son environnement de travail en plaçant des com-
mandes indifféremment dans des menus ou dans des barres de
commandes. Les commandes le plus fréquemment utilisées sont
rendues directement accessibles dans les barres, les autres sont
dans les menus (voir en particulier les possibilités offertes par
MacOS X).
■ Sémantique associée aux aspects graphiques
● Disponibilité des commandes : rôle du grisé
Pour éviter de perturber le repère cognitif de l’usager, il convient
de ne pas ajouter ou supprimer des items de menus pendant le tra-
vail, de telle sorte que l’usager puisse se remémorer l’emplacement
des commandes. Lorsqu’une commande est inaccessible dans un
état donné, on ne la retire pas, on la dessine en indiquant de façon
symbolique qu’elle est inopérante dans ce contexte, par exemple
par un grisé.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
INTERFACES GRAPHIQUES
Figure 18 – Commande
et affichage de changement
d’état dans un menu
● Utilisation pour représenter et contrôler l’état
Un menu peut être utilisé pour visualiser un état. Il suffit d’asso-
cier à un item un symbolisme représentant l’état associé (un mar-
queur par exemple). La sélection de l’item correspondant est alors
une commande dont l’effet modifie l’état correspondant. Dans le cas
d’états binaires, la commande inverse l’état affiché.
Exemple : le sous-menu « barre d’outils » (figure 18) affiche l’état
(visible/caché) des différentes barres d’outils. Notons que si le sys-
tème n’avait affiché que les barres visibles ou que les barres cachées,
l’information d’état serait transmise mais la fonction commande serait
perdue.
2. Dialogue
2.1 Principe
2.1.1 Expression des commandes par désignation
directe
Le dialogue dans les interfaces graphiques à désignation directe
doit être guidé par la machine : l’usager ne peut désigner que ce que
la machine montre. La machine a donc toujours l’initiative. Elle doit
proposer, de façon accessible, organisée et sous une forme visuelle,
l’ensemble des choix que peut faire l’usager à un instant donné.
Ces choix sont suggérés au moyen d’interacteurs, principalement
des boutons, des icônes et des menus, mais il en existe bien
d’autres. Pour le concepteur d’une interface, la décision de mettre
en place tel ou tel interacteur et de les regrouper ne relève pas uni-
quement de ses goûts personnels.
La conception de l’organisation du dialogue repose sur des règles
qui découlent de la prise en compte de contraintes cognitives. Elles
sont étudiées dans ce paragraphe. Ces règles concernent :
— la structure syntaxique du dialogue ;
— la structure visuelle des éléments du dialogue.
2.1.2 Notion d’interacteur
Les interacteurs constituent les éléments interactifs servant de
support au dialogue.
Dans une interface graphique, on appelle interacteur un élé-
ment graphique servant à l’usager à spécifier des valeurs de
paramètres ou à activer une commande. Les interacteurs jouent
dans les interfaces graphiques le même rôle que le vocabulaire
terminal dans les langages écrits.
Un interacteur est caractérisé par les éléments suivants :
— un aspect ;
— un comportement ;
— un effet ;
— une structure.
H 7 216 − 9
INTERFACES GRAPHIQUES _______________________________________________________________________________________________________________

Exemple : un bouton a un aspect (son contour, son libellé ou
son icône), un comportement (il fait mine de s’enfoncer si on
« appuie dessus » avec la souris) et un effet qui dépend du pro-
gramme. Une case à cocher a un aspect qui dépend de son état
« cochée » ou non. Son comportement consiste à changer d’état et
donc d’aspect quand on clique dessus. L’effet est à la discrétion du
programme applicatif.
■ Aspect
C’est l’ensemble des attributs graphiques (forme, couleur, épais-
seur de traits, ombres), mais aussi des animations, des signaux
sonores ou mécaniques (par exemple, retour d’effort), etc., qui
régissent la perception que l’usager a de cet élément.
■ Comportement
C’est l’ensemble des lois d’évolution de l’aspect de l’interacteur
en réaction aux actions élémentaires de l’usager.
■ Effet
C’est la transformation d’état qui résulte de l’interaction entre
l’usager et cet interacteur pour l’application qui l’utilise. La modifi-
cation d’état peut concerner l’interacteur, les autres éléments de
l’interface en relation avec cet interacteur, ainsi que des objets de
l’application. Du point de vue de l’interacteur, l’effet est notifié à
l’application (plus précisément au contrôleur de dialogue) sous une
forme abstraite (par exemple, « bouton OK sélectionné »). C’est le
contrôleur de dialogue qui est en charge de propager l’effet sur les
autres objets de l’interface et au sein de l’application [H 7 217].
■ Structure : composition des interacteurs
Un interacteur peut être simple ou construit. Par simple, on
entend qu’il est indivisible : il contrôle des transactions atomiques.
C’est typiquement le cas d’un bouton. Par construit, on entend qu’il
est composé d’autres interacteurs, simples ou non. C’est typique-
ment le cas d’une boîte de dialogue.
On dit qu’une action est atomique, à un niveau d’observation
donné, si l’usager peut l’exécuter en n’utilisant qu’une seule
action définie à ce niveau.
Exemples : un clic de souris est considéré comme atomique, bien
que le mouvement qui lui est associé implique la contraction successive
de nombreux muscles. Ces actions, plus élémentaires, existent bien
dans la réalité, mais ne sont pas considérées dans le niveau courant.
Définir un nouveau style sous Word n’est pas considéré comme ato-
mique, car pour élaborer cette commande l’usager met en jeu de nom-
breuses autres commandes (choix de police, de cadrage, de bordure,
etc.) qui ont un sens au même niveau d’observation du dialogue.
Typiquement, les fenêtres et les menus sont des interacteurs
généraux composés.
■ Bouton
La métaphore du bouton suggère que le fait d’appuyer sur le bou-
ton déclenche une action. L’objet informatique « bouton » a pour
comportement, en réponse à un clic, d’activer le traitement associé.
La forme du bouton peut être quelconque, allant d’une forme
conventionnelle fournie par défaut à une image spécifiquement
choisie.
■ Case à cocher
Cette métaphore suggère la représentation d’un état binaire,
matérialisé par une marque dans la case.
■ Zone de saisie
Elle permet à l’usager de saisir des données au clavier, dans le cas
le plus simple, une courte chaîne. Un éditeur de texte complet est
une généralisation de cet interacteur. La zone de saisie numérique
en est une spécialisation.
■ « Slider »
Le poussoir linéaire coulissant, ou slider, utilise la métaphore du
potentiomètre de table de mixage. Il fixe une valeur dans un inter-
valle en fonction de la position de l’ergot du poussoir (figure 19).
Les sliders sont utilisés pour saisir des valeurs devant rester dans un
intervalle et dont il est souhaitable que la valeur relative soit directe-
ment perçue par l’usager. Il existe de nombreuses représentations
des sliders allant des plus simples (juste un triangle sous un seg-
ment) aux plus complexes, simulant des potentiomètres avec leur
décor. Les « ascenseurs » utilisent directement cet interacteur.
■ Poussoir d’incrément/décrément
C’est un exemple d’interacteur composé. Il regroupe une zone de
saisie numérique et deux boutons dont l’effet est d’incrémenter ou de
décrémenter la valeur concernée. Il n’est utilisé à bon escient que lors-
que la plage de variation probable autour de la valeur courante est fai-
ble, sous peine d’une forte augmentation de la distance articulatoire.
C’est pour cela qu’il est couplé à une saisie directe de la valeur.
Dans une fenêtre de dialogue, plusieurs interacteurs sont couram-
ment utilisés (figure 20).
Nota : Il existe un très grand nombre d’autres interacteurs primitifs qu’il ne saurait être
question de passer en revue ici. On en trouvera d’autres exemples dans les bibliothèques
Java.awt et Javax.swing.

2.2 Principaux interacteurs

Les boîtes à outils fournissent un ensemble d’interacteurs primi-

tifs qui servent de briques de base pour construire des interfaces. Le
protocole d’interaction repose sur des métaphores simples à com-
prendre et communément admises. On rencontre deux catégories
d’interacteurs :
— des interacteurs d’usage général (§ 2.2.1) ;
— des interacteurs spécifiques (§ 2.2.2).

2.2.1 Interacteurs généraux

Ils servent de support à la réalisation de tâches générales dans le

dialogue, telles que :
— valider un choix ;
— choisir une commande ;
— définir une valeur explicitement ;
— choisir une valeur dans un ensemble, etc. Figure 19 – Exemples de représentation de poussoirs linéaires

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 7 216 − 10 © Techniques de l’Ingénieur, traité Informatique
______________________________________________________________________________________________________________
Les mois (12) sont présentés dans un menu pop-up. L'année, qui évolue
peu, est réglable par incrément, tandis que les jours (31), trop nombreux
pour un menu, sont présentés dans un calendrier pour désignation directe.
Figure 20 – Divers interacteurs utilisés dans une fenêtre de dialogue
rationnellement conçue pour définir la date
Le déplacement des onglets induit une perturbation cognitive
Figure 21 – Deux états de la même organisation d’onglets
multiétages
2.2.2 Interacteurs spécifiques
Ils dépendent directement de la métaphore choisie pour l’organi-
sation spatiale. L’interacteur « poubelle » ou les interacteurs
« dossiers » ou « fichiers » sont des interacteurs spécifiquement uti-
lisés avec la métaphore du bureau. D’autres interacteurs spécialisés
permettent le partage de l’espace des fenêtres, par exemple en
implantant la métaphore des onglets.
Ces derniers s’appuient sur la métaphore des onglets dans les
classeurs. Ils sont souvent disponibles dans les boîtes à outils,
comme spécialisation de fenêtres. Ils permettent de placer plusieurs
panneaux dans une même fenêtre et de faire passer l’un d’eux en
surface. Par contre, les onglets multiétages sont très perturbants sur
le plan cognitif, car ils provoquent une réorganisation spatiale de
l’espace de désignation (figure 21). Ils représentent typiquement
une généralisation excessive de la métaphore des onglets bien au-
delà du comportement des onglets réels.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
INTERFACES GRAPHIQUES
2.3 Structuration syntaxique
Quel que soit le style de l’interface (textuel, graphique…), le dialo-
gue homme-machine repose toujours sur un langage qui structure
les échanges entre l’utilisateur et l’application, donc le dialogue. Il
permet en particulier de spécifier ce que l’usager a la possibilité
d’exprimer dans une situation donnée. Il est défini par une gram-
maire.
Dans les interfaces à langage de commande textuelles, l’usager
doit le plus souvent apprendre les règles de grammaire. Dans les
interfaces graphiques récentes, cette grammaire est organisée de
telle sorte que l’utilisateur l’utilise sans effort, comme on parle une
langue que l’on connaît, sans devoir se reporter à sa grammaire.
Elle n’en est pas moins présente.
2.3.1 Grammaire
Une grammaire est un outil mathématique dont le rôle est de spé-
cifier des structures, en engendrant des langages. Elle est définie
par un ensemble de variables non terminales, de variables termina-
les et de règles de production indiquant comment une variable non
terminale se réécrit.
Dans le cas des interfaces, on se limite le plus souvent aux gram-
maires les plus simples du point de vue formel : les grammaires
régulières et les grammaires hors contexte.
Concernant les variables, on associe :
— une variable non terminale à une situation ou à une intention
de l’usager ;
— une variable terminale à la notation de toute partie de com-
mande considérée comme atomique.
Une règle est constituée de deux parties :
— la partie gauche représente une situation ;
— la partie droite est constituée de concaténations et de disjonc-
tions de variables terminales et non terminales ; elle représente les
actions à effectuer et les nouvelles situations.
La concaténation de variables exprime que les actions qu’elles
représentent sont à exécuter en séquence. La disjonction de varia-
bles signifie que l’utilisateur doit choisir de façon exclusive l’une des
actions qu’elles représentent.
Exemple : considérons le langage de commande d’une interface
graphique d’application bien connue, celle d’un traitement de texte et
la grammaire associée. Lorsque l’usager lance l’exécution d’un traite-
ment de texte, il peut réaliser les actions suivantes :
— ouvrir un fichier ;
— créer un fichier ;
— quitter.
Ces possibilités d’actions sont représentées par la règle :
EnEntrée → ouvrir | créer | quitter
EnEntrée est une variable non terminale qui représente une situation.
créer est une variable terminale qui représente une action élé-
mentaire.
quitter est une variable terminale qui représente une action élé-
mentaire.
ouvrir est une variable non terminale qui représente une intention
complexe de l’usager.
La notation (ouvrir | créer | quitter) représente la disjonction de ces
trois variables.
Il faut donc une nouvelle règle pour définir la variable non terminale
« ouvrir » correspondant à l’expression d’une action complexe :
ouvrir → (désigner le répertoire & désigner le fichier)* & (OK | Can-
cel)
H 7 216 − 11
INTERFACES GRAPHIQUES _______________________________________________________________________________________________________________

L’expression (désigner le répertoire & désigner le fichier) représente

la conjonction de ces variables. La notation * signifie qu’elle prend
place un nombre quelconque de fois.
Dans la seconde règle prise en exemple, l’action est composée de
plusieurs sous-actions.
L’usager peut itérer sur des sélections de répertoires et de dossiers,
puis conclure par une commande OK ou par une commande d’abandon.

2.3.2 Représentation des disjonctions

Les disjonctions dans une règle de grammaire indiquent que l’usa-

ger a le choix entre plusieurs actions. Pour matérialiser la possibilité
de choix, les interacteurs correspondant à chaque choix élémentaire
doivent être simultanément accessibles. Lorsque l’usager valide l’un
quelconque de ces interacteurs, la commande est validée.
Figure 22 – Commande d’ouverture de fichier
D’un point de vue graphique, une disjonction est souvent matéria- et sa représentation graphique
lisée par une présentation d’interacteurs dans une barres d’icônes,
un menu ou une liste à défilement. Mais il est possible d’imaginer
d’autres organisations.

2.3.3 Représentation des concaténations

Les concaténations dans une règle de grammaire – par exemple,

utilisées pour noter les paramètres d’une commande –, indiquent
que l’usager doit renseigner chacun des éléments de la règle pour
que celle-ci soit complète.

Exemple : considérons la commande d’ouverture de fichier :op

(ouvrir). Dans l’exécution de cette commande, l’usager doit sélection-
ner un répertoire puis un fichier (figure 22). Il doit faire ces deux
actions. La transaction est considérée comme complète lorsque l’usa-
L'usager peut ajuster divers paramètres avant
ger valide à l’aide du bouton « ouvrir ».
de valider l'ensemble de ses choix.

Figure 23 – Boîte de dialogue avec bouton de validation

2.3.4 Validation d’une commande
Chaque interacteur utilisé pour réaliser une action ou une com-
mande complète dispose d’un mécanisme de validation. Lorsque
l’usager valide une action, l’exécution de la commande en cours
peut progresser. Lorsque l’usager a terminé les actions élémentai-
res correspondant à la réalisation d’une commande, autrement dit
lorsque toutes les actions spécifiées par la règle de grammaire ont
été exécutées, l’usager valide de façon explicite la commande. Tant
que la commande n’est pas validée, l’interacteur qui implémente la
règle peut permettre ou non à l’usager de refaire une des actions,
par exemple modifier une valeur de paramètres. La validation expli-
cite de fin de transaction est exprimée par l’usager sous une forme
conventionnelle. Parmi ces formes, les plus fréquentes sont les sui-
vantes :
— un bouton OK ;
— un bouton Abandon ;
— tous les champs ont été renseignés ;
— un double clic sur un des interacteurs.
Mais il peut y en avoir bien d’autres.
En plus des concaténations d’actions en séquence, les interfaces
graphiques offrent souvent la possibilité d’exprimer qu’un ensem-
ble d’actions doivent être réalisées mais sans qu’il y ait d’ordre
imposé. On appelle cela un agrégat. D’un point de vue graphique,
un agrégat est matérialisé par une présentation dans une boîte de
dialogue qui reste ouverte jusqu'à ce que la validation ou l’abandon
indique que les différents constituants ont été renseignés
(figure 23). En pratique, les constituants possèdent le plus souvent
une valeur par défaut prédéfinie qui évite à l’usager de les rensei-
gner dans les cas les plus fréquents.
2.4 Structuration visuelle
De façon générale, la prise en compte des contraintes cognitives
suggère de grouper visuellement, et donc géométriquement, les
interacteurs en fonction de la grammaire du langage de commande.
Cela se fait en organisant des menus, des barres d’outils et des boî-
tes de dialogue. Ces trois entités ont pour caractéristique de rendre
explicite la relation entre un groupement de commandes et une por-
tion de l’espace graphique. Il faut remarquer que la structure
visuelle du dialogue a un rôle suggestif très important sur le plan
cognitif pour faciliter l’expression de celui-ci. Elle permet à l’usager
de comprendre l’organisation du dialogue sans devoir s’appuyer
sur une mémorisation préalable de sa structure. C’est une des
conditions nécessaires à l’utilisation de dialogues par un usager
novice, au sens « n’ayant pas reçu de formation pour ce logiciel ».
Les groupements doivent être facilement localisables et identifia-
bles dans l’espace visuel de l’usager.
■ Localisation du regroupement
L’usager sait « où se trouve » telle commande, il lui associe une
place sur l’écran dans la zone du groupement. Cela permet une
meilleure mémorisation de la commande chez les usagers pour qui
la mémoire visuelle est meilleure que la mémoire verbale.
■ Identification du regroupement
L’usager voit comme un tout un ensemble de commandes. Il est
important que le regroupement soit matérialisé de façon visuelle
pour jouer ce rôle structurant.
Exemple : les icônes ne sont pas posées en vrac mais le plus sou-
vent rangées par fonction dans des barres d’outils spécialisées.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 7 216 − 12 © Techniques de l’Ingénieur, traité Informatique
______________________________________________________________________________________________________________ INTERFACES GRAPHIQUES

2.4.1 Interacteurs de groupement et critères

de groupement

Les principaux interacteurs de groupement sont : a bon

— les barres d’outils ;
— les menus ;
— les boîtes de dialogue.
Ces interacteurs ne sont pas en eux-mêmes des déclencheurs de b mauvais
commande (tels les icônes), mais des moyens pour regrouper des
commandes ou exprimer les paramètres d’une commande. Figure 24 – Regroupement d’outils

Exemple : une icône au sein d’une barre et la barre elle-même ne

sont pas de même nature dans le dialogue. Le bouton « fichier » de la
barre de menus, qui permet d’ouvrir le menu « fichier », n’est pas de
même nature que les items « ouvrir », « sauver », « imprimer » de ce
menu « fichier ». De même, une boîte de dialogue agrège des inter-
acteurs plus élémentaires, par exemple pour spécifier les valeurs de
paramètres. a barre d'outils

La structuration visuelle du dialogue doit respecter la structura-

tion syntaxique et renforcer sa perception par l’utilisateur. D’un
point de vue syntaxique, une barre d’outils ou un menu matérialise
une structure disjonctive dans le langage de commande. En plus
des aspects syntaxiques, trois critères président à la structuration
visuelle : catégorisation, identification et similitude.
■ Catégorisation
Il est préférable de placer dans des groupes différents des com-
mandes appartenant à des catégories différentes. Cette règle
s’applique aussi bien aux menus qu’aux barres d’outils. On créera
ainsi des menus ou des barres d’outils spécialisés. Le lecteur remar-
quera que cette règle n’est pas liée à la nature de ces interacteurs,
mais à leur usage (figure 24). Menus et boîtes d’outils permettent
de choisir une commande dont la réalisation est obtenue par une
action atomique de type sélection, comme par exemple cliquer sur
un item de menu ou sur une icône appartenant à une barre d’outils.
La répartition des commandes dans des groupes différents répond
à deux exigences, l’une purement cognitive, l’autre sémantique et
cognitive. Il est conseillé, pour ne pas saturer la mémoire à court
terme de l’usager, de ne pas faire des groupes de plus de sept à dix
éléments. L’usager identifie mieux comme sémantiquement diffé-
rents des éléments qui appartiennent à des groupes différents.
b menu
■ Identification
Il est souhaitable que tout groupement soit délimité visuellement
(figure 25), par exemple au moyen d’aplats colorés. Toutefois, les Figure 25 – Délimitation
règles habituelles du niveau opératoire (voir boucle d’interaction de
Norman [H 7 215]) impliquent que ces renforcements visuels soient
le plus légers possible. 2.4.2 Barres d’outils
Exemple : au sein d’une barre d’outils, on pourra délimiter le grou- On utilise une barre d’outils ou un menu pour proposer un
pement d’outils similaires par un cloisonnement, des aplats de couleur ensemble de choix d’actions ayant des rôles voisins.
légers ou simplement des traits.
■ Définition
■ Similitude
Pour faciliter la remémoration, on placera dans un même voisi- On appelle barre d’outils un regroupement géométrique
nage des éléments ayant des rôles similaires (figure 26). d’interacteurs simples à action directe et sans paramètres.
Exemple : au sein d’une barre d’outils, on pourra placer dans un
même voisinage les icônes des outils représentant des transforma- Lorsque la barre est présente, l’ensemble des choix proposés est
tions géométriques telles que la symétrie ou l’alignement. visible.

Figure 26 – Association

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 7 216 − 13
INTERFACES GRAPHIQUES _______________________________________________________________________________________________________________
D’un point de vue cognitif, une barre d’outils regroupe des inter-
acteurs que l’usager perçoit comme faisant partie d’une même famille.
Exemple : la barre des outils de dessin, la barre de mise en page,
sont des exemples typiques de barres d’outils.
■ Avantages
Les intérêts d’une barre d’outils sont les suivants :
— structuration : l’usager sait (ou peut extrapoler) où trouver (ou
chercher) une commande à partir d’une catégorisation de sa fonc-
tion. Par exemple, la symétrie horizontale doit se trouver dans la
barre d’outils de dessin, au voisinage des autres symétries ;
— réduction de l’espace de dialogue : l’usager peut ajuster le lan-
gage qu’il utilise en masquant ou en faisant apparaître les barres de
dialogue dont il a l’usage ;
— organisation de l’espace de travail : l’individualisation des bar-
res d’outils en tant que fenêtres permet de les déplacer et d’organi-
ser l’environnement de travail en fonction des habitudes
personnelles de l’usager ;
— rapidité d’accès.
■ Inconvénients
Les inconvénients d’une barre d’outils sont les suivants :
— son encombrement, car tous les outils sont présents ;
— l’impossibilité pratique de disposer d’un grand nombre de
commandes.
2.4.3 Menus
Un menu est, d’un point de vue fonctionnel, une forme parti-
culière de barre d’outils qui n’apparaît qu’à la demande. Les méca-
nismes propres aux menus sont présentés au paragraphe 1.4.
Les intérêts des menus sont les mêmes que ceux des barres
d’outils :
— réduction de la place utilisée sur l’écran. Seul le bouton
d’appel du menu reste affiché ;
— place nulle si le menu apparaît interactivement de façon délo-
calisée (pop-up). Dans ce cas, le délai d’accès est très réduit car la
distance à traverser est très faible ;
— la structuration hiérarchique des menus rend possible la repré-
sentation de la structure du langage de commande. Elle réduit signi-
ficativement la place occupée par les menus.
Le lecteur intéressé par les propriétés détaillées des menus se
référera à [2].
2.4.4 Boîtes de dialogue
Une commande peut avoir ou non des paramètres. Une
commande sans paramètres est dite simple. Elle peut être activée
par une interaction atomique, par exemple un clic de souris. Une
icône ou un item de menu suffit pour l’activer. En revanche, une
commande avec paramètres est dite complexe. Elle nécessite une
conjonction d’interactions pour être exprimée. En ce sens, elle n’est
pas atomique Cette interaction met en jeu un dialogue structuré
entre l’usager et la machine. Celui-ci est réalisé au moyen de boîtes
de dialogue. Elles rassemblent tous les constituants de la com-
mande avant de les valider, comme cela se fait dans les commandes
avec paramètres dans les langages de commande textuels. Toute-
fois, il existe des cas particuliers où l’on réussit à regrouper en une
seule interaction atomique la définition de plusieurs paramètres.
■ Définition
On appelle boîte de dialogue une fenêtre spécialisée dans
laquelle est regroupé l’ensemble des interacteurs simples ou com-
plexes participant à l’élaboration d’une commande complexe. Une
convention fixe la validation ou l’abandon de cette commande.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 7 216 − 14 © Techniques de l’Ingénieur, traité Informatique
■ Rôle cognitif
Une boîte de dialogue a pour rôle de :
— structurer visuellement les éléments du dialogue par leurs
regroupements géométriques ;
— « parenthéser » la transaction d’élaboration d’une commande
complexe en indiquant explicitement le début et la fin de la transac-
tion.
La règle d’initialisation de tout interacteur à sa valeur par défaut
fait que la valeur par défaut d’une commande complexe exprimée
par une boîte de dialogue est fixée par l’ensemble des valeurs par
défaut de ses composants.
Exemple : une commande de compilation en Java s’exprime par
une ligne de commande, dans laquelle l’usager précise les paramètres
suivants :
— nom du fichier à compiler ;
— classpath ;
— etc.
Une boîte de dialogue rassemble les interacteurs servant à fixer cha-
cun de ces paramètres. Chacun d’eux peut être un interacteur simple
(par exemple, une case à cocher) ou complexe (par exemple, un sélec-
teur de fichier).
Lorsque l’usager n’a pas de modification à effectuer dans les
paramètres, il lui suffit de valider la commande directement. Bien
que complexe, elle est perçue comme atomique car l’usager n’est
pas entré dans une phase de planification de sa commande. La dis-
tance articulatoire est donc réduite (voir boucle d’interaction de Nor-
man [H 7 215]).
■ Dialogue modal
Il peut exister des portions de dialogue dans lesquelles l’usager
est contraint. Le système réduit temporairement très fortement son
choix.
On appelle dialogue modal une partie de dialogue dans lequel
la liberté de dialogue de l’usager est modifiée, l’interprétation de
certaines de ses actions pouvant avoir un sens différent de leur
sens usuel.
Une telle portion de dialogue est aussi appelée transaction. Son
début et sa fin sont contrôlés par des commandes spécialisées ou
des conventions propres au langage.
Exemple : certains éditeurs de texte à langage de commande tex-
tuel disposent d’une commande « insérer » qui ouvre et ferme le
mode « insérer ». Dans ce mode, tous les caractères sont entrés dans
le texte, y compris ceux qui auraient normalement été interprétés
comme des commandes. Il y a donc altération temporaire de l’interpré-
tation des commandes usuelles. Il faut sortir du mode « insérer » pour
retrouver l’accès à la totalité du langage de commande.
Exemples de dialogues modaux
■ Sur un téléphone pour enregistrer un numéro dans le répertoire, on
utilise un dialogue modal. La touche « mémoriser dans le répertoire »
supprime temporairement le comportement normal du téléphone : les
touches numériques n’appellent plus le numéro mais l’enregistrent
dans le répertoire. L’interprétation du sens habituel de la frappe d’un
numéro est donc altérée. Notons aussi l’existence d’une interaction
pour signaler la fin du mode, par exemple, l’appui sur une touche spé-
ciale ou le raccrochage du téléphone.
■ Sous MS Word, pour définir un style, on entre typiquement dans un
dialogue modal. Les autres commandes du système cessent d’être
accessibles. La barre de menu devient inopérante. Les sous-menus
relatifs au « format » prennent alors sens dans le contexte du dialogue
de définition de style et n’ont plus leur effet standard.
______________________________________________________________________________________________________________
Pour bien mettre cette nuance en évidence, et avec plus de sugges-
tivité, les versions récentes d’Office ont dupliqué le menu « format »
directement dans la boîte de dialogue au lieu de le laisser dans la barre
de menu comme c’était le cas des premières versions de MS Word.
La validation ou l’abandon de cette partie du dialogue, et le retour au
« mode normal », se fait par les boutons correspondants dans la fenê-
tre de style. Notons que la fermeture explicite de la fenêtre est inter-
prétée comme un abandon et non comme une validation.
Sous Windows, toutes les fenêtres ont le même comportement et
la même interface. Cela implique d’associer un sens particulier à sa
fermeture, celui de la commande d’abandon. Un choix différent est
fait sur MacIntosh, où les fenêtres modales n’ont pas de case de fer-
meture, ce qui oblige l’usager à expliciter son choix : « validation »
ou « abandon ».
■ Boîtes de dialogue et dialogue non modal
On peut utiliser des boîtes de dialogue pour élaborer des com-
mandes complexes sans pour autant entrer dans un dialogue
modal.
Exemple : la commande « rechercher-remplacer » est typique-
ment une commande non atomique puisqu’il faut indiquer ce que l’on
recherche, par quoi on le remplace et si la commande doit être répé-
tée. Pourtant, l’ouverture de la fenêtre de dialogue associée n’ouvre
pas un dialogue modal ; toutes les autres commandes restent accessi-
bles avec leur sens usuel. Cette fenêtre a juste pour rôle de regrouper
visuellement les paramètres de la commande.
Dans de nombreux autres éditeurs, surtout ceux destinés aux pro-
grammeurs, la commande complexe « rechercher-remplacer » est
simplement décomposée en plusieurs commandes atomiques – par
exemple, « rechercher ce qui est identique à la sélection courante »,
« chercher suivant », « remplacer » –, ce qui dispense de l’ouverture
d’une fenêtre et améliore la rapidité d’interaction.
■ Dialogues modaux sans boîtes de dialogue
L’ouverture de boîtes de dialogue modal est sécurisant pour le
débutant mais ralentit beaucoup l’interaction pour un utilisateur
expert. C’est pour cela que l’on emploie de préférence des dialogues
modaux sans boîte associée pour les transactions courtes dans des
éditeurs professionnels, par exemple des éditeurs de dessin 3D.
Exemple : pour dessiner un profilé extrudé, on doit définir sa sec-
tion, la trajectoire de l’extrusion. La transaction débute lors de la sélec-
tion de l’outil de création de profil extrudé. Le premier tracé que fait
l’usager est interprété comme étant la section. Lorsque ce tracé (qui
peut être un polygone et donc n’est pas nécessairement une interac-
tion atomique) prend fin, le tracé suivant est interprété comme la tra-
jectoire d’extrusion. La fin du second tracé clôt la transaction. Le tracé
suivant, s’il existe, serait alors interprété comme un élément de dessin
normal. On est bien dans un dialogue modal car ces différents tracés
ont des interprétations différentes.
■ Dialogues modaux guidés séquentiellement
L’usage d’un dialogue modal sans boîte de dialogue est efficace
mais perturbant pour les novices. Il s’ensuit qu’il faut généralement
adapter l’implémentation d’un dialogue modal au type d’usager.
Dans certains cas, plutôt que de laisser l’usager fixer les paramè-
tres librement, le logiciel le guide en lui présentant en séquence les
actions à effectuer. Cette technique héritée des premières interfaces
interactives est très sécurisante mais devient vite d’un emploi trop
lourd pour être utilisée par des usagers autres que des amateurs
débutants ou des usagers très occasionnels.
Exemple : l’interface du même outil dit « tampon » est implémen-
tée différemment sous deux logiciels de retouche d’image car l’un
s’adresse à des spécialistes et l’autre au « grand public ».
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique
INTERFACES GRAPHIQUES
Figure 27 – Étapes d’un dialogue guidé : l’outil tampon
L’outil tampon sert, en retouche d’image, à dupliquer des portions
d’images en indiquant la zone source, la zone destination et la forme de
la zone copiée. Sous Photoshop, par exemple, l’usager peut, à tout
moment, changer l’un quelconque des paramètres. Il n’y a pas de boîte
de dialogue. La forme de la zone est choisie dans une barre de modè-
les de pinceaux. La source est définie par un clic de souris avec la tou-
che Alt enfoncée. La destination est définie par un clic de souris et se
propage en roulant. L’interaction est très directe. Un message en bas
d’écran indique juste l’interprétation courante des actions (figure 27).
Par contre, si l’usager oublie de redéfinir une zone source, c’est la
précédente qui reste en cours lorsqu’il définit une nouvelle destination.
C’est très naturel car une retouche se fait par une succession de peti-
tes étapes.
Sous un logiciel grand public, au contraire, un dialogue modal forte-
ment guidé contraint l’usager à effectuer toutes ces opérations dans
l’ordre requis. Il n’en oublie donc pas, mais le dialogue est ralenti
d’autant. Chaque fois qu’il reprend cet outil, il parcourt obligatoirement
l’ensemble du dialogue.
3. Principales métaphores
Pour guider le dialogue, les interfaces à désignation directe font
usage de métaphores. Leur rôle est de réduire la distance articula-
toire perçue par l’usager. L’expression d’actions utilise des conven-
tions qui « évoquent » des actions que l’usager a l’habitude de faire.
C’est pour cela que la métaphore de la désignation directe est aussi
souvent appelée de façon générale la métaphore du monde réel en
raison des métaphores qu’elle permet de mettre en œuvre.
Les métaphores les plus connues sont :
— le bureau (§ 3.1) ;
— la poubelle (§ 3.5) ;
— le « copier-coller » (§ 3.3) ;
— le « glisser-déposer » (§ 3.4).
3.1 Bureau
La métaphore du bureau consiste à organiser l’écran comme une
surface de travail où se trouvent des icônes symbolisant les com-
mandes le plus souvent utilisées, par analogie avec le bureau sur
lequel se trouvent les objets dont l’usager se sert le plus souvent.
La métaphore du bureau introduit une mise en correspondance
symbolique entre des objets que l’on trouve dans un bureau et ceux
du système, et les actions que l’on peut faire sur des objets et celles
disponibles dans le système.
3.1.1 Objets et symboles associés
■ Objets
Les objets informatiques courants ont une représentation symbo-
lique suggestive.
H 7 216 − 15
INTERFACES GRAPHIQUES _______________________________________________________________________________________________________________
Les informations sont dans des documents : ils correspondent
aux fichiers. On leur associe une icône évoquant la forme d’un
document et non plus simplement un nom. L’icône suggère le type
du document, qui dans un langage textuel est souvent identifié par
l’extension du nom.
Les fichiers sont rangés dans des dossiers : ils correspondent aux
répertoires. On leur associe une icône évoquant la forme d’un clas-
seur, ouvert ou fermé.
■ Réification de commandes
Certaines abstractions correspondant à des actions sont réifiées
(transformées en objet) pour pouvoir prendre place sur le bureau.
Par exemple, « imprimer » est une action, pas un objet. Dans la
métaphore du bureau, cette action est réifiée sous la forme de
l’icône de l’imprimante qui, alors, donne accès à cette fonction.
■ Réification d’états
De même, des états de l’information sont réifiés. Ainsi, la pou-
belle contient les documents destinés à être détruits. Il s’agit d’une
représentation symbolique de l’état d’un document entre le
moment où il n’est plus considéré comme utile et celui où il n’est
plus accessible.
L’imprimante, la boîte aux lettres, le presse-papiers sur le bureau
symbolisent des actions ou des états.
■ Réification de comportements
Des comportements de l’usager sont aussi réifiés.
Ainsi, les documents sont dans des dossiers, eux-mêmes dans des
armoires (les disques). Mais l’usager peut sortir sur le bureau les dos-
siers ou les documents dont il se sert souvent. Leur icône traîne ainsi
sur l’écran comme si le dossier était déjà sur la table de travail.
3.2 Dialogue et conventions
Pour rendre utilisable la métaphore du bureau, il convient d’intro-
duire des conventions et des métaphores complémentaires pour
définir la façon dont l’usager interagit avec les éléments du bureau.
Ce sont la métaphore du « glisser-déposer » et les conventions rela-
tives à la sélection.
La quasi-totalité des interfaces graphiques a adopté un ensemble
de conventions permettant de désigner un ou plusieurs items. Tou-
tefois, ces conventions dépendent fortement du périphérique de
désignation (la souris notamment) et ne sont pas facilement trans-
posables à d’autres périphériques (tels que la dalle tactile).
■ Expression de la réceptivité à l’interaction
Suggérer à l’usager qu’un objet de l’interface est susceptible de
réagir à une interaction est utile. Cela est fait de façon très systéma-
tique en particulier dans les menus. L’objet peut manifester sa
réceptivité au moyen, par exemple, d’un changement d’aspect. Ce
changement doit être suffisant pour être perceptible, mais aussi
limité que possible pour ne pas être perturbateur. Par exemple,
l’apparition d’un cadre autour d’une icône ou un changement de
saturation ou de contraste peuvent être efficaces. Par contre, des
changements de couleur violents sont à proscrire.
■ Sélection élémentaire
La sélection peut être réalisée de plusieurs manières, soit indivi-
duelle, soit ensembliste.
Dans la sélection individuelle, l’usager clique sur l’objet à dési-
gner. Il ne peut en désigner qu’un par action élémentaire.
Dans la sélection ensembliste, l’usager « entoure » par le par-
cours du pointeur les objets qu’il veut designer. Il définit leur ensem-
ble. Généralement, un clic hors d’un objet initie une sélection
ensembliste ; tant que le bouton de la souris est pressé, le mouve-
ment définit l’ensemble concerné. Dans les cas les plus simples, la
sélection est identifiée par un rectangle englobant (Mac) ou sécant
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 7 216 − 16 © Techniques de l’Ingénieur, traité Informatique
(PC). Dans d’autres cas, le mouvement définit une courbe libre
englobant les éléments à sélectionner.
■ Opérations sur la sélection
Une sélection est souvent un ensemble d’items. Par combinaison
de sélections élémentaires, on peut étendre ou réduire une sélec-
tion. Pour cela, on dispose d’altérations ; généralement, ce sont les
touches Maj ou CTRL du clavier qui servent à indiquer que l’on
modifie la sélection courante et non qu’on la définit.
Étant donné une sélection courante, lorsque l’altération est utili-
sée conjointement à une nouvelle sélection, les éléments de la nou-
velle sélection qui appartenaient déjà à la sélection courante en sont
retirés, ceux qui ne lui appartenaient pas encore y sont ajoutés.
Nota : l’interprétation des altérations diffère au niveau de nuances entre le PC et le Mac.
L’altération CTRL est utilisée sur le PC pour forcer une désignation à être élémentaire et non
ensembliste, alors que sur le Mac, cette nuance est exprimée par la gestuelle.
■ Actions sur une sélection
L’intérêt d’effectuer une sélection est de ouvoir agir sur ses élé-
ments. Plusieurs stratégies sont utilisées pour exprimer la com-
mande à la sélection :
— menu général ;
— menu local ;
— raccourci clavier ;
— multiples clics ou altération d’un clic.
● Menu général
Cette solution est bien adaptée aux utilisateurs novices, car le
menu leur suggère directement la sémantique de la commande. Elle
est lente en raison du déplacement nécessaire pour atteindre l’item
de menu.
● Menu local
Un menu local a les mêmes avantages qu’un menu général, par
contre, il a l’inconvénient d’être moins directement explorable, en
ce sens que l’usager ne connaît pas nécessairement la commande
pour le faire apparaître (par exemple, clic droit ou « pomme »-clic).
● Raccourci au clavier
C’est la solution la plus rapide. Elle n’est utilisable que par des uti-
lisateurs confirmés se servant régulièrement du logiciel, car ils doi-
vent connaître les abréviations. Seules des abréviations usuelles
comme celles du « copier-coller » sont presque accessibles à tous.
Par exemple, il est possible de créer une abréviation pour recher-
cher un synonyme sous Word.
● Multiples clics ou altération d’un clic
L’opération la plus fréquente est souvent associée au double clic –
par exemple, l’ouverture –, mais ce n’est pas la seule. Le double clic,
en supprimant tout déplacement, est l’interaction la plus rapide sur
une sélection.
3.3 « Copier-coller »
La métaphore du « copier-coller » consiste à disposer de trois
commandes élémentaires de mémorisation sans destruction
(copier), de mémorisation avec destruction (couper) et d’insertion
de contenus mémorisés (coller).
Ces trois actions proviennent de la dissociation des actions élé-
mentaires intervenant dans les opérations de déplacement, de des-
truction, de duplication. Le « copier-coller » permet de les regrouper
librement.
Le « copier-coller » est unanimement utilisé dans tous les systè-
mes, nous ne détaillons pas plus son principe. Par contre, il est mis
en œuvre de façon très différente suivant les systèmes.
X-Windows, par exemple, utilise les touches de droite et du centre
de la souris à trois boutons pour abréger les commandes de copier
et de coller.
______________________________________________________________________________________________________________ INTERFACES GRAPHIQUES

3.6 Arbre développable

La métaphore de l’arbre développable consiste à suggérer visuel-

lement une structure arborescente sans la représenter en entier. La
présence de sous-arbres non développés est symbolisée par une
altération conventionnelle de la représentation d’une feuille.
Exemple : dans une fenêtre du « finder » du Mac ou du poste de
travail de Windows, les fichiers et les dossiers sont distingués par une
icône. Le rôle de celle-ci est de suggérer le développement possible de
l’arborescence pour les dossiers. C’est pour préserver la suggestivité
au sein de cette métaphore que la forme des icônes de dossiers est
Figure 28 – sensiblement un invariant, alors qu’il existe un très grand nombre de
« Copier-coller » formes pour les icônes de fichiers.
sous DOS
De même, dans la présentation arborescente des fichiers sur Mac
(figure 29), une flèche indique qu’il s’agit d’un élément dévelop-
À l’inverse, la fenêtre DOS de Windows ne permet le « copier- pable.
coller » que par menu (figure 28), car les abréviations usuelles utili- Exemple : cette métaphore visuelle est de plus en plus utilisée,
sent la touche CTRL qui a un autre sens sous DOS. bien qu’elle utilise un domaine source qui n’appartient pas à la vie cou-
rante mais repose sur une représentation organisée de l’information.
Windows 2000 l’utilise intensivement, y compris pour l’interface
d’administration du système (figure 30), où les valeurs des paramètres
3.4 « Glisser-déposer » sont rangées et accédées dans des structures arborescentes.

La métaphore du « glisser-déposer » consiste à sélectionner un

objet et à déplacer la souris en maintenant la sélection pour simuler
l’entraînement de l’objet jusqu'à abandon de la sélection, ce qui
dépose l’objet.
Bien que cette métaphore soit très ancienne (par exemple, dépla-
cer des fichiers ou mettre à la poubelle sur le Mac), son utilisation
n’a été généralisée que récemment.
Elle est utilisée entre applications. L’application de départ doit être
Figure 29 –
capable d’exporter la sélection sous une forme externe acceptable
Arbre développable
par d’autres, et l’application réceptrice doit être capable d’importer
de l’organisation
des données en provenance d’une autre. Les protocoles permettant
des fichiers
à une application de spécifier la nature de ce qu’elle exporte et à une
sous MacIntosh
autre d’interroger sur la nature de ce qu’on lui propose doivent être
définis entre les applications.
Une telle convention est définie dans Java, qui fournit les classes
nécessaires à l’implémentation du « glisser-déposer » entre appli-
cations.

3.5 Poubelle

La métaphore de la poubelle consiste à suggérer la destruction

par un « glisser-déposer » sur une icône symbolisant la poubelle.
C’est l’une des plus anciennes et plus célèbres métaphores des
interfaces à désignation directe. Son originalité a été de coupler à
cette métaphore celle de réversibilité : un objet mis à la poubelle
n’est pas « détruit » ; on peut le reprendre dans la poubelle. Pour la
plupart des autres commandes, la réversibilité est commandée par
un menu « défaire ». La poubelle est vue comme un dossier dans
lequel sont entreposés les documents devant être détruits. Le proto-
cole de destruction effective varie suivant les systèmes. Il est main- Figure 30 – Utilisation de la métaphore de l’arbre développable
tenant à la charge de l’usager. dans un outil d’administration système

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 7 216 − 17