Bonnes pratiques pour l’IHM (Interface homme-machine)

Il est important de suivre les bonnes pratiques d’agencement et de design d’interfaces graphiques qui suivent, dans l’objectif d’amener de la consistance dans l’affichage des éléments d’interface ainsi que pour permettre aux utilisateurs d’utiliser instinctivement les boîtes de dialogue.

  1. Regrouper les éléments liés entre eux en utilisant des boîtes de groupe: Essayer d’identifier les éléments qui peuvent être regroupés ensemble et utiliser ensuite des boîtes de groupe avec une étiquette permettant d’identifier le sujet du groupe. Éviter d’utiliser des boîtes de groupe avec un seul élément/contrôle à l’intérieur.
  2. Mettre en majuscule uniquement la première lettre dans les étiquettes: Les étiquettes (ainsi que celles de boîtes de groupe) doivent être rédigées sous forme d’expression avec la première lettre en majuscule. Les autres mots doivent être écrits avec la première lettre en minuscule.
  3. Ne pas mettre de caractère deux-points à la fin des étiquettes des contrôles ou des boîtes de groupe: Ajouter le caractère deux-points perturbe la vision et n’apporte aucune signification supplémentaire; ne pas les utiliser. Il peut être fait exception à cette règle lorsque vous avez deux étiquettes qui se suivent; par exemple: Étiquette1 Extension (Chemin): Étiquette2 [/chemin/vers/extensions].
  4. Éloigner les actions dangereuses des actions sans incidence: Si vous avez des actions de “suppression” ou “d’effacement”, etc. essayez d’imposer un espace adéquat entre les actions dangereuses et les actions sans conséquences de manière à ce que les utilisateurs ne cliquent pas par inadvertance sur l’action dangereuse.
  5. Utiliser toujours un QButtonBox (boîte à boutons) pour les boutons “Ok”, “Annuler”, etc: Utiliser une boîte à boutons permet de s’assurer que l’ordre des boutons “Ok”, “Annuler”, etc. sera cohérent pas rapport au système d’exploitation, la langue, l’environnement du bureau utilisé par l’utilisateur final.
  6. Les onglets ne doivent pas être imbriqués. Si vous utilisez les onglets, suivez le style des onglets de QgsVectorLayerProperties / QgsProjectProperties, etc., c’est à dire, des onglets en haut avec des icônes de 22x22.
  7. Les empilements de contrôles de formulaire doivent être évités le plus possible. Ils causent des problèmes de mise en page et des re-dimensionnements inexplicables (pour l’utilisateur) pour afficher les contrôles non visibles.
  8. Eviter d’utiliser des termes techniques et utiliser plutôt des équivalents simples, ex: utiliser le mot “Transparence” plutôt que “Canal Alpha”, “Texte” à la place de “Chaîne de caractères”, etc.
  9. Utilisez une iconographie cohérente. Si vous avez besoin d’icône ou d’éléments d’iĉones, merci de contacter Robert Szczepanek sur la liste de diffusion pour de l’assistance.
  10. Placer les longues listes de contrôles dans des boîtes à défilement (scroll). Aucune boîte de dialogue ne doit mesurer plus de 580 pixels de haut et 1000 pixels de large.
  11. Séparer les options avancées des fonctions basiques. Les utilisateurs novices doivent être capables d’accéder facilement aux éléments indispensables aux activités basiques sans être inquiétés par la complexité des fonctionnalités avancées. Les fonctionnalités avancées devraient être placées en dessous d’une ligne de séparation ou placées dans un onglet séparé.
  12. Ne pas ajouter d’option dans le seul objectif d’avoir de nombreuses options. Lutter pour conserver l’interface utilisateur minimaliste et utiliser des options par défaut adaptées.
  13. Si un bouton doit ouvrir une nouvelle boîte de dialogue, des points de suspension (…) doivent être ajoutés en suffixe du texte du bouton.

Auteurs

  • Tim Sutton (auteur et éditeur)
  • Gary Sherman
  • Marco Hugentobler
  • Matthias Kuhn