Important

La traduction est le fruit d’un effort communautaire auquel vous pouvez vous joindre. Cette page est actuellement traduite à 81.82%.

2. 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. Capitalize first letter only in labels, tool tips, descriptive text, and other non-heading or title text: These should be written as a phrase with leading capital letter, and all remaining words written with lower case first letters, unless they are nouns

  3. Mettre en majuscule la première lettre de tous les mots contenus dans un titre (boîte de groupe, onglet, entête de vues…), les fonctions (éléments de menus, boutons) et tous les éléments sélectionnables (éléments de liste déroulante, de tableaux…): tous les mots hormis les prépositions de moins de 5 lettres (par exemple “with” mais “Without”), les conjonctions (par exemple, “and” ou “but”) et les articles (a, an, the). Cependant, il faudra toujours mettre en majuscule la première lettre des premier et dernier mots.

  4. Ne pas mettre de caractère « deux-points » à la fin des étiquettes, des widgets 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: Label1 Plugin (Path:) Label2 [/path/to/plugins]

  5. Keep harmful actions away from harmless ones: If you have actions for “delete”, “remove” etc, try to impose adequate space between the harmful action and innocuous actions so that the user is less likely to inadvertently click on the harmful action.

  6. Utiliser toujours un QButtonBox 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.

  7. Tabs should not be nested. If you use tabs, follow the style of the tabs used in QgsVectorLayerProperties / QgsProjectProperties etc. i.e., tabs at top with icons at 22x22.

  8. Les empilements de widget 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 widgets non visibles.

  9. Try to avoid technical terms and rather use a layman’s equivalent e.g., use the word “Opacity” rather than “Alpha Channel” (contrived example), “Text” instead of “String” and so on.

  10. 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.

  11. 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.

  12. 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é.

  13. 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.

  14. 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. Assurez-vous de bien utiliser le caractère « U+2026 » du point de suspension et non trois points consécutifs.

2.1. Auteurs

  • Tim Sutton (auteur et éditeur)

  • Gary Sherman

  • Marco Hugentobler

  • Matthias Kuhn