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

In order for all graphical user interface elements to appear consistant and to all the user to instinctively use dialogs, it is important that the following guidelines are followed in layout and design of GUIs.

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. Capitalise first letter only in labels: Labels (and group box labels) should be written as a phrase with leading capital letter, and all remaining words written with lower case first letters

3. 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]

4. 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 users is less likely to inadvertantly click on the harmful action.

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

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

8. Try to avoid technical terms and rather use a laymans equivalent e.g. use the word ‘Transparency’ rather than ‘Alpha Channel’ (contrived example), ‘Text’ instead of ‘String’ and so on.

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. If clicking a button will spawn a new dialog, an ellipsis (...) should be suffixed to the button text.