Ergonomie de GNOME 3.x

L'ergonomie est « l'étude scientifique de la relation entre l'homme et ses moyens, méthodes et milieux de travail » et l'application de ces connaissances à la conception de systèmes « qui puissent être utilisés avec le maximum de confort, de sécurité et d'efficacité par le plus grand nombre. »¹⁾

Le bureau GNOME Shell (2011) fut le premier, dans le petit monde du logiciel libre, à proposer une ergonomie brisant les habitudes des utilisateurs, et si vous venez de Windows par exemple (ou pire encore si vous venez d'Unity), quelques explications peuvent être les bienvenues.

Depuis les années 2000, des études tentent de comprendre les grands principes qui régissent l'ergonomie des interfaces graphiques en informatique, et de mieux connaître les habitudes des utilisateurs.

Certaines de ces études ciblent les interfaces GNU/Linux, et notamment GNOME²⁾, à l'époque en version 2 : souvent complexes voire brouillonnes, les interfaces des programmes libres proposaient trop souvent des fonctionnalités redondantes, l'interface des logiciels elle-même prenant le pas sur le contenu qu'elles présentent et qui intéresse l'utilisateur. Les menus étaient nombreux et longs à explorer, l'espace était alors mal optimisé sur les petits écrans, et à partir de la fin des années 2000, les usages commencent à changer en terme de matériel avec l'arrivée des netbooks, et du tactile.

Inaccessibles à certains débutants, nécessitant parfois une fastidieuse personnalisation pour les utilisateurs déjà convaincus, les environnements disponibles sur Ubuntu suivent alors un certain traditionalisme : des panneaux avec des applets et des lanceurs, des menus déroulants imbriqués, et des applications reprenant à l'identique les principes de design de Windows.

Frappant un grand coup, la fondation GNOME lance GNOME 3 : outre le bureau GNOME Shell, de nombreuses applications sont retravaillées, voire créées, pour expérimenter divers principes ergonomiques, quitte à parfois déboussoler les utilisateurs.

Cette initiative en lancera d'autres en réponse : Unity, MATE, Cinnamon, la version 4 de KDE, … autant d'exemples d'environnements pleins d'idées différentes et souvent innovantes nées suite à ce tremblement de terre que fut Gnome 3.

Après plusieurs années à "se chercher", GNOME a finalement abouti à un ensemble plutôt cohérent et réfléchi de principes d'organisation de l'interface.

Les interfaces GNOME ne ciblent pas que les ordinateurs de bureau : ultrabooks, netbooks, ordinateurs portables, notebooks, et même tablettes dans une certaine mesure (théoriquement).

Sur des petits écrans, et sur des machines gérées au touchpad voire à l'écran tactile, les contraintes sont parfois différentes, que ce soit en terme de lisibilité ou de contrôle, et cela a été pris en compte au mieux, notamment dans le choix du thème par défaut (Adwaita) qui propose des boutons larges et clairs.

Ces principes sont des vérités générales, sans lien avec un environnement en particulier.

• L'utilisateur doit faire le minimum d'effort pour arriver à son objectif. Cela concerne par exemple :
  • la quantité de déplacement de souris
  • le nombre de frappes au clavier
  • le nombre de clics.

• L'utilisateur doit voir en priorité ce qui l'intéresse, qu'il s'agisse du contenu (document, média, page web) ou de l'interface (boutons, menus).

• L'interface d'un logiciel doit au maximum mettre en valeur le contenu (document, page web, média) plutôt que le logiciel en lui-même (barres, boutons, menus).

• L'interface ne doit pas contenir de contrôles, de menus ni d'informations superflues, ni de fonctionnalités redondantes, pour faciliter la familiarisation de l'utilisateur avec le logiciel. Les fonctionnalités spécifiques à une situation n'apparaissent souvent que dans cette situation.

• Fournir un moyen de rechercher les choses, qu'il s'agisse de contenu ou de fonctionnalités. Il ne faut pas exiger de l'utilisateur qu'il fouille tout le logiciel.

• De nos jours, les écrans sont en format 16:9 et l'espace vertical est donc plus précieux que jadis : excepté pour les logiciels très riches en fonctionnalités (clients mails, logiciel de traitement de texte, tableur, …) qui en ont besoin, il est conseillé de ne pas cumuler une barre de fenêtre + une barre de menus + une barre d'outils. Le format conseillé est la "headerbar", qui regroupe les boutons de fenêtre (minimiser, maximiser, fermer) et les fonctionnalités essentielles (généralement entre 1 et 5 boutons, une recherche, un menu "sandwich").

Partant du principe qu'un utilisateur travaillant sur un logiciel A n'est pas intéressé dans l'immédiat par le fait de voir une barre des tâches avec le logiciel B et C, et ayant étudié qu'un grand nombre d'utilisateur passaient de toutes façons d'une application à l'autre sans utiliser cette barre, les concepteurs de GNOME Shell ont remis en question son utilité :

Théoriquement, pour le cas d'applications au milieu de l'écran, en terme de déplacement de souris, passer par la vue "Activités" ne rallongerait pas significativement les déplacements de souris et n'exigerait aucun clic supplémentaire par rapport à l'utilisation d'un dock vertical comme Unity.

Ceci dit les utilisateurs n'aiment légitimement pas qu'on cherche à trop chambouler leurs habitudes, et chaque utilisateur ayant des habitudes différentes, les développeurs de GNOME encouragent chacun à s'approprier l'interface GNOME Shell par l'usage d'extensions.

Concernant les applications, certaines modifications de Nautilus ou d'Epiphany par exemple ont été vécues comme des régressions voire des pertes de fonctionnalités, que les développeurs ont mis plusieurs années à combler. Le développement de GNOME se concentre maintenant plutôt sur de nouvelles applications (d'après leurs noms anglais : Builder, Games, Boxes, Recipes, Softwares, Photos, Calendar, …) plutôt que sur la modification d'applications existantes.

Bien entendu, toutes les applications ne sont pas concernées de la même manière. Evolution ou Abiword par exemple n'ont guère changé suite à l'adoption de ces principes. D'autres comme Empathy par exemple ont essayé d'intégrer ces principes sur la forme sans pour autant les respecter sur le fond.

Les applications indépendantes du projet GNOME, comme LibreOffice, fournissent parfois un "appmenu" par souci d'intégration harmonieuse, mais n'appliquent pas à la lettre les conventions présentées ci-après, et ont leurs propres principes de design.

Notez tout de même que des idées comme "réunir les fonctionnalités secondaires dans un menu sandwich situé à droite" ne sont pas spécifiques à GNOME, puisqu'il s'agit d'une convention courante parmi les navigateurs internet par exemple.

Certaines de ces conventions viennent parfois aussi du développement pour plateformes mobiles (smartphones et tablettes) – comme la présentation des notifications et des paramètres systèmes dans la barre supérieure, la présentation des applications, le "mode sélection", … – et devraient ne pas être totalement inconnues aux utilisateurs d'Android par exemple.

Quelques captures d'écran :

GNOME Photos	Gedit

Avec GNOME Shell, ce menu (parfois appelé "appmenu") est par défaut situé dans la barre supérieure, mais il peut être déplacé dans la headerbar comme c'est déjà le cas avec le bureau Budgie par exemple.

Ce menu contient les fonctionnalités liées à l'application elle-même : l'aide, le résumé des raccourcis claviers, les préférences, parfois l'ouverture d'une nouvelle fenêtre, le "à propos", …

Exemples :

Elle contient des boutons, souvent avec du texte sans icônes, concernant les fonctionnalités principales : dans Nautilus, ou Gnome Web il s'agit avant tout de la navigation, dans Gedit il s'agira de "nouveau", "ouvrir" et "enregistrer" par exemple.

Dans le cas des applications ayant plusieurs vues, la headerbar contiendra les "onglets" pour passer d'une vue à l'autre. Par exemple, voir le cas du "Moniteur Système", de "Horloges" (onglets "monde, "alarme", "chronomètre", "minuteur"), ou dans le cas ci-dessus de Gnome Photos, il y a 3 "onglets" : Photos, Albums, Favoris.

La headerbar contient aussi :

Usuellement situé à droite, de la headerbar, et symbolisé par 3 traits horizontaux, il contient des fonctionnalités secondaires, utiles mais trop peu utilisées pour justifier qu'elles aient un bouton dédié.

Ce sont des fonctionnalité liées au contenu ouvert par l'application (document, image, page web, dossier, …), à l'opposé de l'appmenu qui contient des fonctionnalités liées à l'application.

Usuellement situé à droite, de la headerbar, et symbolisé par une loupe, il s'agit la plupart du temps de rechercher parmi le contenu, mais dans le cas des paramètres système ou de l'outil de personnalisation, il s'agit de rechercher un paramètre par exemple.

Usuellement situé à droite, de la headerbar, et symbolisé par un symbole ✅ ("v"), il permet de sélectionner des items pour leur appliquer un traitement particulier (envoi par mail, suppression, ajout à un album/une playlist/un dossier, ajout d'un tag, …).

Souvent, les fonctionnalités apparaissent dans une barre en bas de l'écran.

C'est utilisé entre autres dans GNOME Logiciels, GNOME Notes, GNOME Photos, GNOME Musique, GNOME Machines, GNOME Builder, etc.

Des fonctionnalités sont très souvent présentes dans le menu contextuel du clic droit, elles peuvent dépendre d'où on clique, de ce qui est sélectionné, etc.

Avec certaines applications, le clic droit active le "mode sélection".

Traduction complète quoique approximative des principes de design issus du wiki de GNOME à destination des développeurs d'applications. Bien que destinées aux développeurs, ces informations ne sont pas inintéressantes pour l'utilisateur.

Des buts clairs et bien définis dès le départ sont la clé d'un bon design. Les applications doivent fournir un ensemble clair et conceptuellement cohérent de fonctionnalités à fournir, attention à ne pas en dériver. Une application qui tente de faire plein de choses disparates finira par être complexe et source de confusion chez l'utilisateur.

Les meilleures applications fournissent une solution élégante dans un domaine spécifique.

Chaque contrôle ou information ajoutée à l'interface de l'application génère un travail d'apprentissage ou de compréhension supplémentaire pour les utilisateurs, augmentant la complexité de l'interface – la rendant potentiellement moins plaisante voire plus difficile à utiliser.

Par ailleurs, n'incluez que les contrôles et informations essentiels dans votre interface : en ajoutant quelque chose, demandez-vous toujours si c'est vraiment nécessaire.

Cela évite que l'utilisateur ait à naviguer parmi des contrôles qui ne peuvent pas lui servir. Montrer les contrôles lorsqu'ils sont requis rend l'application plus simple, tout en proposant la même quantité de fonctionnalités.

Il y a plusieurs moyens de faire ça, par exemple avec différentes vues, différents modes, ou en montrant des contrôles flottants ou transitoire lorsque du contenu ou un item est sélectionné.

Une application laborieuse à utiliser peut devenir source d'irritation, donc efforcez-vous de faire marcher votre logiciel pour les utilisateurs (plutôt que ce soient les utilisateurs qui le fasse marcher pour vous).

À chaque fois que l'application requiert une entrée de la part des utilisateurs (utiliser un contrôle ou fournir une information), il faut se demander si on peut le faire pour eux : essayer d'éviter les écrans de réglages manuels ou les assistants, et rendre facile le retour aux contenus récemment utilisés.

Les gens ont tendance à "lire" l'interface de gauche à droite, et de haut en bas. Les items rencontrés en premier sont perçus comme dominants par rapport à ceux qui viennent ensuite. Utilisez cette hiérarchie implicite pour communiquer quelles parties et fonctionnalités de votre application sont les plus importantes.

Positionner les contrôles les plus importants est vers le coin supérieur-gauche de la fenêtre, et placer les contrôles dominants avant les autres qu'ils affectent. Voir ici pour plus de détails.

Une application présente généralement un contenu (images, texte, messages, ou des données plus complexes). C'est ce contenu qui intéresse l'utilisateur, et trop de contrôles, donc des éléments d'interface envahissants, distraient l'utilisateur de l'objet de son attention.

Donner au contenu le maximum d'espace possible dans l'interface, en réduisant le bombre de contrôles affichés.

Les gens font des erreurs. Les anticiper va prévenir des conséquences désastreuses, et rendra l'application davantage plaisante et satisfaisante à utiliser. La première ligne de défense ici, est de concevoir l'application de telle sorte que les erreurs ne puissent pas être faites. Deuxièmement, si une erreur est faite, il faut qu'elle soit facile à rattraper.

Il faut automatiquement corriger les entrées potentiellement invalides, et toujours rendre possible l'annulation des opérations destructives.

Les interruptions causent de la frustration et de l'irritation, et empêchent les gens de se concentrer. Concevoir les applications telles qu'elles n’interrompent pas l'utilisateur lorsqu'elles sont inutilisées.

Utiliser les notifications avec modération, et toujours éviter les fenêtres de dialogue surgissant spontanément sans que ce ne fut l'intention de l'utilisateur. De manière générale, minimiser les mécanismes de feedback gênants comme les boîtes de dialogue.

La recherche est un mécanisme puissant pour trouver rapidement du contenu. Il faut en proposer dès qu'on a une grande quantité de contenu, que ce soit sous forme de liste ou de grille. Il est vital que cette recherche soit aussi immédiate que possible, et retourne des résultats visibles par l'utilisateur.

Gnome Shell propose un moyen de faire des recherches intégrées. Intégrer la recherche de l'application à Gnome Shell donne aux utilisateurs un moyen rapide et simple d'accéder au contenu proposé par l'application.

La plupart des gens ne verront jamais ces options de configuration. Ajouter des options ressemble souvent à une rustine : plutôt que d'ajouter des options, il faut faire en sorte que le comportement par défaut de l'application satisfasse autant de personnes que possible.

Le nom et l'icône sont les 2 aspects les plus expressifs de l'application, ils doivent communiquer sa fonction et son identité.

Les gens devraient pouvoir comprendre le but de l'application à partir de son nom, et la reconnaître à partir de son icône, qui fait partie de l'identité visuelle de l'application : belle, distincte, attractive.

Utilisé pertinemment, cela peut épicer l'expérience fournie par l'application, et aider à établir une relation positive avec l'utilisateur. Il ne faut pas abuser de ces techniques, bien entendu : souhaiter la bienvenue dans l'application la première fois, ou dédramatiser la situation quand il y a un problème, peuvent être de bonnes idées.

Les "guidelines" de développement complètes.

Contributeurs : roschan