 |
Vendredi 06 juin 2025 - 12:18 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Note : traduction par David Brunet.
Introduction
La nature visuelle d'AmigaOS a toujours encouragé l'utilisation d'interfaces graphiques (GUI) comme moyen principal d'interaction entre l'utilisateur et le logiciel. Il a fallu un certain temps pour définir et affiner la direction dans laquelle l'API de programmation d'interfaces graphiques Amiga se dirigeait, avec même un "faux départ" complet (Intuition 1.x) et un cul-de-sac appelé GadTools. Il est certain que le programmeur est maintenant bien mieux loti avec BOOPSI/ReAction ; cependant la puissance, la sophistication et le confort de la boîte à outils ne garantissent rien. La qualité de l'interface graphique est déterminée par la qualité de la pensée de son concepteur - la boîte à outils elle-même est un facteur secondaire. Vous pouvez tout aussi bien créer une interface graphique minable avec ReAction, MUI ou Zune !
Cet article se concentre sur les problèmes courants de conception d'interface graphique, car même les meilleures fonctionnalités ne serviront à rien si l'application se comporte ou s'exprime de manière incorrecte. J'ai sélectionné quinze problèmes particuliers dans cinq groupes ; j'en ajouterai peut-être d'autres à l'avenir s'il y a de l'intérêt. L'article est basé sur une recherche assez approfondie et distille des informations provenant de nombreuses sources, dont la plus utile (et la moins académique) est probablement GUI Bloopers 2.0 de Jeff Johnson, un livre que je peux recommander comme un matériel de référence parfait pour une étude plus approfondie.
Les interfaces graphiques sont conçues pour (et par) les humains, et la qualité de l'interface utilisateur peut donc être perçue de manière subjective. Plutôt que de prêcher ce qui est bon et ce qui est mauvais (je n'ai de toute façon aucune autorité pour le faire), cet article tente d'expliquer pourquoi une solution particulière peut dégrader l'expérience de l'utilisateur ou entraver le flux de travail. Pour illustrer mon propos, j'utilise autant que possible des exemples tirés de logiciels Amiga réels. Il ne s'agit pas de critiquer ou de tourner en dérision les auteurs de programmes individuels, alors ne vous offusquez pas si vous trouvez que votre logiciel est critiqué ici. L'idée est de vous aider à améliorer votre logiciel, tout comme les commentaires des lecteurs m'aideront à améliorer cet article.
Premier groupe de problèmes : bêtises dans le nommage et les textes
1. Utilisation excessive de jargon
Malgré tous les efforts modernes de "convivialité", il est impossible d'éviter l'utilisation du jargon dans les logiciels : on supposera toujours qu'il y a des connaissances spécialisées. Il y a deux types de jargon que l'on trouve typiquement dans les interfaces graphiques de l'Amiga :
- Le jargon technique ("technicalais"), qui se réfère à l'informatique en général.
- Le jargon Amiga ("amigalais"), qui décrit spécifiquement les éléments internes et les concepts d'AmigaOS.
Réfléchissez donc à votre utilisation de l'amigalais dans votre logiciel. Essayez d'imaginer l'utilisateur comme quelqu'un qui, contrairement à vous, n'a pas des années d'expérience avec AmigaOS. Adoptez la pensée de l'utilisateur et non celle du programmeur. Utilisez des termes et des descriptions plus généraux, dites et nommez les choses clairement. N'encombrez pas votre interface graphique de termes et d'abréviations qui prêtent à confusion, ne faites pas référence à des éléments internes du système d'exploitation à moins que vous n'y soyez obligé. Efforcez-vous de valoriser l'information.
Un exemple ? La capture d'écran ci-dessous à gauche provient de l'ancien éditeur AmigaAMP Prefs (aujourd'hui obsolète). Comme vous pouvez le voir, son menu suppose que l'utilisateur sait ce que sont "ENV:" et "ENVARC:", comment ils sont utilisés dans le système d'exploitation, et qu'ils ont quelque chose à voir avec les paramètres du programme. Or, il s'agit là de connaissances plutôt spécialisées, bien en deçà du niveau Workbench/Interface Utilisateur ! Résultat ? Un utilisateur moins expérimenté se demande pourquoi il y a tant d'options de chargement/sauvegarde, ce qu'elles font réellement et laquelle il convient de choisir.
L'autre capture d'écran montre le tiroir des préférences d'AmigaOS 4.1. Vous voyez le nombre d'abréviations utilisées ? Eh bien, on peut certainement s'attendre à trouver des choses techniques dans les paramètres du système, et on peut supposer qu'un utilisateur d'ordinateur peut avoir entendu parler de "GUI", "USB", "URL" ou "DOS" ? Mais avons-nous vraiment besoin de cacher notre système audio et nos requêtes de fichiers sous les cryptogrammes "AHI" et "ASL" ? (cette question est d'autant plus absurde qu'il semble que très peu d'amigaïstes sachent ce que signifie l'acronyme ASL). Pourquoi ne pas utiliser des noms plus descriptifs ?
2. Imprécision, redondance, manque d'intérêt
Soyez clair et précis. Il est utile de fournir davantage d'informations sur ce qui va se passer, en particulier pour les requêtes qui requièrent l'attention et/ou la confirmation de l'utilisateur. Économisez le temps et les neurones de l'utilisateur, ne lui demandez pas simplement "Êtes-vous sûr ?" ou "Continuez ?". Des questions aussi vagues peuvent créer une certaine confusion quant à ce que l'utilisateur est en train de confirmer. Résistez à la tentation d'être drôle dans les messages des requêtes, c'est une attitude ringarde qui ne fait que donner à votre logiciel un aspect non professionnel. Soyez instructif et informatif, gardez votre esprit pour le vendredi soir avec votre petite amie.
La redondance (c'est-à-dire la répétition d'informations) peut parfois être utile comme moyen mnémotechnique, mais un excès de redondance crée un trop-plein d'informations et peut être source de distraction. Il n'est vraiment pas nécessaire de répéter le mot "paramètres" dans un menu qui s'appelle "Paramètres". Cela ne fait qu'alourdir le menu (la capture d'écran provient de l'émulateur VICE) :
Si vous devez utiliser des styles de texte (gras, italique, souligné) dans votre interface graphique, faites-le avec parcimonie. Il est tout à fait acceptable d'afficher le titre de requête en gras parce que c'est logique et esthétique, mais il existe généralement d'autres façons de présenter l'information et de faire ressortir les choses. Par exemple, un bouton pour une fonction dangereuse fournira un meilleur (et plus sûr) repère visuel si vous l'agrandissez et le détachez des autres gadgets.
N'utilisez pas l'italique pour un texte principal ou long, car il sera difficile à lire. Le rendu logiciel de l'italique (tel qu'il est utilisé dans le sous-système des polices Amiga) ne donne pas toujours des résultats satisfaisants pour certaines polices. Et non, le texte en italique pour les noms des icônes du Workbench dans le thème par défaut d'AmigaOS 4 n'était vraiment pas une bonne idée.
Deuxième groupe de problème : contrôles de l'interface graphique mal utilisés
4. Cases à cocher mal utilisées
La case à cocher - qu'elle soit utilisée sous la forme d'un gadget CheckBox, d'un élément de menu à cocher ou d'un noeud ListBrowser à cocher - semble être un élément d'interface graphique très simple et direct. Mais ne vous laissez pas tromper : vous seriez surpris de voir combien de bêtises d'interface utilisateur sont liées à l'utilisation de cases à cocher. Pour comprendre ce que vous faites peut-être mal, vous devez d'abord comprendre comment la case à cocher est censée fonctionner. La case à cocher est un contrôle graphique qui indique un état ou un attribut dans une relation binaire de deux valeurs opposées. Un interrupteur dont l'état coché implique une valeur de "oui/activé/vrai", tandis que l'état non coché implique "non/désactivé/faux" (l'analogie est 1 et 0 en logique numérique). En d'autres termes, les deux états se réfèrent à des oppositions claires et logiques.
C'est donc un comble lorsque la case à cocher est utilisée pour des réglages autres que marche/arrêt. Par exemple, le menu de l'éditeur de texte GoldEd propose un réglage du mode de saisie sous la forme d'un élément à cocher intitulé "Mode d'insertion" (voir la capture d'écran ci-dessous). Qu'y a-t-il de mal à cela ? Eh bien, ce qui se passera si l'élément est coché est assez clair (l'éditeur fonctionnera en mode insertion), mais ce n'est pas très clair lorsqu'il s'agit de le décocher : quel est donc le contraire de "Mode insertion" ? On ne peut pas s'attendre à ce que l'utilisateur sache qu'il s'agit du "Mode d'écrasement", car il ne s'agit pas d'oppositions claires, sémantiques ou naturelles : la seule logique ici est une certaine convention utilisée dans les éditeurs de texte. Plutôt que d'être opposés, les deux modes de saisie doivent être considérés comme deux options mutuellement exclusives, de sorte qu'une implémentation plus appropriée du paramètre utiliserait deux éléments de menu (boutons radios) mutuellement exclusifs étiquetés respectivement "Mode d'insertion" et "Mode d'écrasement".
Les gadgets de sélection (ou "sélectionneurs") sont des contrôles d'interface graphique populaires car ils peuvent afficher de nombreuses options tout en occupant très peu d'espace. Leur popularité les rend également susceptibles d'être mal utilisés dans la conception d'interfaces utilisateur.
Un gadget de sélection est un peu moins intuitif qu'un bouton radio : vous devez faire apparaître ou défiler les options du gadget de sélection, alors que le bouton radio les affiche toutes en même temps. La contrepartie du gadget bouton radio est qu'il nécessite plus d'espace. Pensez donc à votre interface graphique particulière : à moins que vous ne soyez confronté à des contraintes d'espace, préférez les boutons radio pour les choix comportant jusqu'à trois ou quatre options. Utilisez le gadget de sélection pour les listes d'options plus longues.
N'utilisez jamais, au grand jamais, un gadget de sélection à deux étiquettes pour un paramètre on/off : utilisez plutôt une CheckBox. L'exemple ci-dessous montre Exchange, un composant AmigaOS qui contrôle les commodités. Il comporte un gadget de sélection avec deux options, "Actif" et "Inactif", ce qui est une paire d'opposés logiques et, par conséquent, une relation binaire claire. Il s'agit d'un commutateur à deux états, qui aurait donc dû être implémenté comme un gadget CheckBox (ou, alternativement, comme un bouton poussoir), mais certainement pas comme un gadget de sélection.
Troisième groupe de problème : contrôle du clavier
6. Absence de raccourcis clavier
L'accès par le clavier aux principales caractéristiques du programme et aux fonctions courantes accélère le flux de travail et rend les utilisateurs expérimentés heureux. Utilisez le système de menus et/ou la balise GA_ActivationKey de BOOPSI pour vous aider à configurer les raccourcis - les deux méthodes sont faciles. Certains raccourcis sont même standardisés (voir également la section 8 ci-dessous). Devinez ce qui manque dans le menu du programme suivant ?
7. Gaspillage de mnémotechniques
D'un autre côté, il n'est pas nécessaire de fournir des raccourcis clavier pour chaque fonction de votre programme : l'utilisateur ne pourrait de toute façon pas s'en souvenir ! De plus, les raccourcis clavier fonctionnent mieux s'ils sont mnémotechniques : "S" pour "Sauver", "P" pour Print (imprimer), etc. Par conséquent, gardez les mnémoniques pratiques pour les fonctions courantes et vraiment importantes, ne les gaspillez pas pour des fonctions secondaires. Par exemple, beaucoup d'éditeurs de préférences AmigaOS 4.x implémentent des raccourcis pour des paramètres on/off qui ont rarement besoin d'être changés : l'utilisateur utilisera les raccourcis une ou deux fois dans sa vie. C'est un gaspillage complet :
Selon le Guide de Style de l'Interface Utilisateur Amiga (maintenant disponible et en cours de mise à jour à travers le Wiki de la documentation AmigaOS), vous devriez utiliser le système de menu pour implémenter au moins les raccourcis clavier suivants (à condition que votre programme implémente les fonctions respectives) :
- Amiga Droite + N : Nouveau
- Amiga Droite + O : Ouvrir...
- Amiga Droite + S : Enregistrer
- Amiga Droite + A : Enregistrer sous...
- Amiga Droite + ? : A propos de...
- Amiga Droite + Q : Quitter
- Amiga Droite + X : Couper
- Amiga Droite + C : Copier
- Amiga Droite + V : Coller
- Amiga Droite + Z : Annuler
Il devient maintenant évident qu'une révision des raccourcis réservés est nécessaire. Avant tout, il n'y a pas de raccourci clavier standardisé pour Iconify, une fonction maintenant présente dans la plupart des applications : certains programmeurs implémentent "Amiga Droite + I" tandis que d'autres semblent préférer "Amiga Droite + H" ("Hide", cacher). De même, l'utilisation de "Amiga Droite + A" comme raccourci réservé pour "Enregistrer sous" est très discutable - la mnémonique conviendrait mieux aux opérations de type "Sélectionner tout", comme c'est habituellement le cas sur d'autres systèmes d'exploitation.
Quatrième groupe de problèmes : mise en page
9. Mises en page encombrées ou désordonnées
Un trop grand nombre de gadgets ou de groupes de gadgets rend les présentations de l'interface graphique encombrées et difficiles à trouver. Utilisez l'onglet cliquable et placez les éléments connexes dans des pages séparées. Les gadgets apparentés doivent être regroupés et une certaine correspondance visuelle - telle qu'un alignement commun - doit être établie entre eux. Les deux captures d'écran suivantes proviennent de ClassMate, un ancien constructeur d'interface graphique pour la boîte à outils ClassAct. Il est ironique de constater qu'un programme censé vous aider à construire des interfaces graphiques possède l'une des interfaces utilisateur les plus maladroites que j'aie jamais vues. La capture d'écran de gauche montre un groupe de gadgets mal alignés ; celle de droite montre une fenêtre de sélection dans une implémentation que je n'arrive toujours pas à croire (notez aussi l'absence de distance/séparation entre le bouton "Cancel" (Annuler) et les autres gadgets) :
Les gadgets qui n'ont aucune relation fonctionnelle ou logique ne doivent pas être placés dans un même groupe. La requête ASL d'AmigaOS est un contrevenant évident. Comme vous pouvez le voir, il place quatre boutons dans un groupe horizontal bien qu'ils aient une fonction et un champ d'action différents : les boutons "OK" et "Cancel" contrôlent l'ensemble de la requête alors que "Volumes" et "Parent" contrôlent la liste des fichiers. Leur regroupement est illogique, et les boutons "Volumes" et "Parent" devraient être placés à côté de la liste des fichiers.
11. Cécité en matière de localisation
Il se peut que votre programme soit localisé à un moment donné (si ce n'est pas dès le départ). Lors de la conception de l'interface graphique, tenez compte du fait que les étiquettes de texte localisables peuvent être de longueur variable (en fonction de la langue) et que, par conséquent, les gadgets peuvent devenir très larges. Soyez prudent lorsque vous placez des gadgets à côté d'autres gadgets : préférez les empiler verticalement. Vous pouvez vous contenter d'une rangée de quatre boutons (voir ci-dessous à gauche), car les étiquettes des boutons sont généralement courtes. Cependant, d'autres gadgets (les cases à cocher, par exemple) peuvent utiliser des étiquettes plus longues et plus descriptives ; évitez donc de les placer comme dans la capture d'écran de droite :
Les interfaces graphiques de ReAction sont évolutives : les gadgets peuvent changer de taille en fonction de la taille courante de la fenêtre. Toutefois, lorsqu'il n'y a pas de réel avantage à redimensionner, il est préférable de limiter l'extensibilité. Regardez la capture d'écran suivante, qui montre deux pages individuelles dans la fenêtre des préférences de Debug101, mon outil de débogage de code préféré. Ces pages ne contiennent que des gadgets RadioButton et CheckBox, c'est-à-dire des gadgets dont l'image ne grandit jamais dans une fenêtre redimensionnable. Par conséquent, le redimensionnement vertical de la fenêtre n'a aucun sens dans ce cas, car les gadgets seraient dispersés dans la fenêtre et perdraient leur relation visuelle. Une telle fenêtre redimensionnée ne ferait que gaspiller un espace précieux sur l'écran. Il serait donc judicieux de limiter l'extensibilité verticale en passant WINDOW_LockHeight à "TRUE" (vrai) dans la définition de la fenêtre.
13. Le programme n'indique pas qu'il est occupé
Lorsque votre programme entre dans un état d'activité (c'est-à-dire qu'il exécute une opération ou une fonction qui bloque les actions ultérieures de l'utilisateur), il faut afficher un pointeur d'activité. Ne supposez pas que l'opération sera trop rapide pour que le pointeur d'activité mérite d'être affiché : le système de l'utilisateur peut être plus lent que le vôtre, ou il peut être devenu temporairement moins réactif en raison d'une tâche consommatrice de temps processeur qui s'exécute en arrière-plan. Si vous craignez que l'opération s'exécute si rapidement que le changement de pointeur passera inaperçu, utilisez "WA_PointerDelay, TRUE" dans la définition de votre fenêtre pour empêcher les clignotements extrêmement brefs du pointeur occupé.
Cela n'est peut-être pas évident, mais les pointeurs occupés ont également une fonction de navigation. Qu'est-ce que cela signifie ? Si vous cliquez sur une fenêtre et qu'un pointeur occupé s'affiche, cela signifie en fait que vous ne pouvez pas utiliser cette fenêtre pour le moment, car une autre fenêtre requiert votre attention. Il s'agit d'un indice de navigation important, donc lorsque vous ouvrez une requête ou une sous-fenêtre qui nécessite une entrée de l'utilisateur avant que le programme ne puisse continuer, affichez un pointeur occupé pour sa fenêtre parente. Le fait que les fenêtres Amiga doivent toujours être non bloquantes est un mythe.
Les programmeurs de ReAction devraient noter que le pointeur occupé est supposé être défini par SetAttrs() sur l'objet fenêtre, et non en appelant SetWindowPointer() ou SetWindowAttrs() - ces deux dernières fonctions sont destinées aux fenêtres non-BOOPSI.
14. (Mauvaise) utilisation de l'ellipse dans les étiquettes de gadgets et de menus
Au début des années 1980, lors du développement du système d'exploitation de son ordinateur Lisa, Apple a introduit une convention utilisant l'ellipse (...) pour distinguer les commandes qui demandent d'abord plus d'informations de celles qui s'exécutent immédiatement. Depuis, l'ellipse a été adoptée, utilisée et détournée dans pratiquement tous les systèmes d'exploitation.
Le guide original de l'interface utilisateur de l'Amiga publié par Commodore (1991) a introduit une interprétation assez large de la convention de l'ellipse. Il stipulait ce qui suit :
"Lorsqu'un élément de menu fait apparaître une fenêtre ou une requête, une ellipse (trois points) doit être ajoutée à l'étiquette de l'élément de menu.C'est clair et bien défini, mais ce n'est pas vraiment ce qu'Apple avait en tête. Le résultat positif est que dans les logiciels Amiga, vous trouverez rarement l'ellipse manquante dans les endroits où elle est appropriée. Le résultat négatif est que l'ellipse a tendance à être surutilisée. Le critère d'utilisation de l'ellipse n'est pas de savoir si la commande particulière fait apparaître une fenêtre mais si elle s'exécute immédiatement : c'est ainsi que l'ellipse est standardisée dans les directives d'interface graphique de tous les principaux systèmes d'exploitation. Les commandes immédiates exécutent une action qui ne nécessite aucune autre entrée de la part de l'utilisateur, aucune information ou sélection supplémentaire. De ce point de vue, il n'y a pas de différence entre, par exemple, les fonctions "Aide", "À propos", "Copier" ou "Coller" : elles sont exécutées sans aucune étape intermédiaire ; ce qui se passe (copier/coller du texte, ouverture de la requête, etc.) est leur résultat final. Les libellés des gadgets ou des menus pour ces commandes ne doivent pas se terminer par "...".
"Lorsqu'un gadget d'action fait apparaître une autre fenêtre ou une autre requête, l'étiquette doit se terminer par une ellipse (trois points).
Si vous regardez la capture d'écran d'AmiUpdate ci-dessus, vous verrez que le bouton "Info" (qui ouvre une sous-fenêtre contenant des informations sur la mise à jour) n'ajoute pas d'ellipse. Il s'agit d'une utilisation correcte dans ce cas particulier. De même, RunInUAE est conforme en n'utilisant pas d'ellipse pour "Aide" et "À propos" dans son menu "Projet" :
15. Requêtes ennuyeuses
Une requête de confirmation est certainement une mesure de sécurité, mais il gêne et ralentit le flux de travail. Si vous voulez que votre logiciel soit détesté, ne cherchez pas plus loin et saupoudrez-le de requêtes ! Plus sérieusement. Ne demandez pas de confirmation pour des actions qui ne présentent aucun risque, ou au moins faites en sorte que la requête soit configurable. Si votre programme ne crée aucune donnée (une calculatrice, un dictionnaire, un lecteur multimédia, etc.), ne demandez pas "Voulez-vous vraiment quitter ?" avant de... euh... quitter. Si l'utilisateur quitte un tel programme par erreur, il le redémarrera, ce n'est pas grave. Ne les traitez pas comme des idiots qui appuient sur des boutons au hasard et ne savent pas ce qu'ils font.
Et il y a mieux : la tendance actuelle dans la conception des logiciels est une fonction d'annulation universelle, c'est-à-dire une fonction qui ne s'applique pas uniquement aux fonctions de type édition. S'il existe un moyen de toujours revenir sur une opération, qui sur Terre a besoin de requêtes de confirmation ? Il y a peut-être là matière à réflexion.
|
