GNOME Style Guide

une citation d'un participant...

La philosophie "un mécanisme, pas une politique" de X, a laissé le monde de X dans une jungle d'applications -- chacune avec sa propre définition d'interface utilisateur. Afin de résoudre ce problème, le projet Gnome veut mettre en place un ensemble de règles qui faciliteraient la construction d'un ensemble d'applications offrant une interface utilisateur unifiée et cohérente. Nous avons trouvé l'ensemble le plus mature sur le site du projet KDE et décidé de l'adopter comme point de départ de Gnome. Les applications Gnome se sentiront "chez elles" sur une installation KDE, et vice-versa. Nous encourageons la communauté X à s'unir dans ce but, peu importe les outils utilisés pour le développement de leurs applications. Nous remercions l'équipe du projet KDE pour ses avancéees significatives. Toutes remarques bienvenues.

Directives générales

Toute application

Licence

Documentation

Conception d'une interface utilisateur GNOME

Pensez à votre interface. Faites-vous quelque chose de stupide ? Oui, pour sûr. C'est inévitable la plupart du temps, mais peut-être pouvez-vous faire quelque chose pour réduire le nombre de ces choses stupides. La conception d'interface utilisateur n'est pas une chose facile; vous savez probablement ce que vous voulez, mais si vous essayez de rendre votre programme utile à d'autres personnes que vous seul, vous voudrez sans doute faire quelques essais avant même de commencer à coder.

Les prototypes peuvent être très importants. Dessinez votre interface sur le papier. Demandez à quelqu'un d'essayer de l'utiliser; non, demandez à plusieurs personnes d'utiliser votre version papier. Demandez à une personne n'utilisant pas d'ordinateur, ou au moins à une personne non impliquée dans la conception. Pouvez-vous faire une interface qui leur convienne ?

une remarque de Federico

J'ai trouvé l'ensemble Guile+Gtk très utile pour le prototypage d'interface. Réaliser un prototype en Scheme demande beaucoup moins de travail qu'en C, et vous pouvez modifier les choses aisément. Si vous avez quelque chose contre Scheme (de toute façon vous devriez l'apprendre), essayez d'utiliser Guile+Gtk. Si votre application est suffisamment simple, vous devriez pouvoir l'écrire entièrement en Scheme, ce qui est l'un des buts de GNOME.

À quoi va servir votre programme ? Dans quel contexte ? Vous devez en tenir compte. Écrivez toutes ces choses en détail. Par exemple, si vous réalisez une interface pour un programme de manipulation d'images, vous devez songer à ce que les utilisateurs vont en faire. Heureusement, Peter et Spencer ont fait un travail formidable avec GIMP. Mais le programme parfait n'existe pas, et si nous l'analysons en fonction de ses utilisations, alors nous découvrons que certaines choses pourraient être améliorées.

Voici un exemple de scénario :

C'est un long scénario, comme un scénario doit l'être. Je le garderai court pour simplifier :

Maintenant, il y a au moins un problème ici. Pourquoi ai-je besoin de convertir en indexé ? Que se passe-t-il si je saute cette étape ? Comme les GIF sont obligatoirement sauvées indexées, GIMP devrait automatiquement faire la conversion pour vous, mais quand vous récupérez l'image sur laquelle vous travailliez elle devrait encore être au format RGB.

Après avoir fait ceci plusieurs fois, interrogez-vous de nouveau. Dans l'idée précédente, j'ai fait en sorte que GIMP exécute une conversion secrète que l'utilisateur ne voit pas. Mais doit-il afficher l'utilitaire de conversion quand je demande une sauvegarde qu format GIF ? Je pense que je n'y ai peut être pas réfléchi assez..

Essayons à nouveau : quand vous essayez de sauvegarder une image RGB au format GIF, GIMP devrait vous dire que ce n'est pas possible. Mais dans la même boite de dialogue, il devrait vous demandez si vous souhaitez que l'image soit automatiquement convertie en indexé (et vous avertisse qu'il va changer la version de travail), puis le sauvegarder.

Celà semble bien mieux. Mais même ainsi, c'est la réflexion d'une seule personne, ce qui constitue souvent une erreur en soi-même.

Gardez à l'esprit un certain nombre de principes quand vous travaillez sur de telles conversions

Ne cachez rien ! Si un utilisateur ne le voit pas, c'est que ca n'y est pas. Si la seule manière d'ouvir une fenêtre est CTRL-W, vous avez échoué [rappelez-vous quand même les dangers du "syndrome du cockpit du Boeing 747" Si vous affichez toutes les options d'un programme simultanément, les utilisateurs seront perdus. Utilisez des outils d'organisation tels les "notebooks", les "expanding dialogs", et les "panels" pour organiser les éléments tout en les gardant facilement accessibles.]
Faites des raccourcis. Les utilisateurs avancés veulent des outils puissants. Suivre Emacs n'est pas une mauvaise idée, mais pensez aussi à ceux qui n'ont jamais utilisé Emacs..
Essayez de ne pas utiliser de modes. C'est difficile, mais important. À moins que vous en ayez réellement besoin, n'ayez pas un seul mode dans votre programme. Si vous devez utilisez les modes, faites en sorte que le mode en cours soit évident. Pensez aux nouveaux utilisateurs et à vi..

Généralités à garder à l'esprit

"Le principe de moindre surprise"

De la cohérence avant toute chose

L'interface utilisateur doit être configurable; Mais il faut une limite entre changer l'apparence de l'interface et sa manière de fonctionner. Pouvoir agrandir une fonte ou changer la couleur d'un bouton sont de bonnes idéees. Déplacer un bouton dans une autre boite de dialogue ou le transformer en "slider" n'est probablement pas une bonne chose.