Bonnes pratiques pour l'interface utilisateur

These guidelines are designed to help developers and designers create a beautifully consistent experience on the elementary OS desktop. They were written for interface designers, graphic artists and software developers who will be working on elementary OS. They will not only define specific design elements and principles, but will also instill a philosophy that will help you decide when it is appropriate to deviate from the Guidelines. Adhering to the suggestions contained here will provide many benefits:

Pour vous aider à atteindre ces objectifs, ces lignes directrices couvriront les éléments de base de l'interface, comment les utiliser et les agencer de manière efficace, ainsi que la conception d'une application s'intégrant correctement avec le bureau. La chose la plus importante à retenir est que ces directives rendront la conception d'une nouvelle application plus facile, et non plus compliquée.

Cependant, gardez à l'esprit qu'il s'agit de lignes directrices, pas d'un code inflexible. De nouveaux et étonnants modèles d'interaction apparaissent chaque jour et d'autres attendent toujours d'être découvert. Ceci est un document vivant qui peut et sera changé.

Pour les sections qui n'ont toujours pas été rédigées, veuillez vous référer au GNOME HIG

La philosophie du design

The elementary OS HIG isn't just about a set of concrete rules; it's meant to be flexible and extensible. As such, this very first portion of the guideline is all about the guiding philosophy we employ. For a quick crash course, we like "The User is Drunk":

Ce que le design n'est pas

Before we get into all the things that make up elementary OS apps, there is a clarification that needs to be made. We need to understand what exactly design is about, but more importantly we want to smash two major myths:

  1. Le design n'est pas quelque chose que vous ajoutez après que vous ayez terminé un produit. Que vous le réalisiez ou non, vous êtes constamment en train de designer tout ce que vous construisez. C'est une partie intrinsèque de la création. Le design n'est pas seulement ce à quoi quelque chose ressemble. Ce n'est pas que couleurs et polices. Le design est la façon dont tout fonctionne. Lorsque vous décidez d'ajouter un bouton qui fait quelque chose, c'est du design. Vous avez pris la décision d'ajouter un bouton avec une icône ou une étiquette, la position de ce bouton, ainsi que sa taille et sa couleur. Chaque décision est un élément de design.

  2. Le design n'est pas, genre, juste ton opinion, mec. Le design peut être testé. Un design satisfera mieux qu'un autre un objectif précis. Imaginons différentes sortes de vélos. Un vélo pliable n'est pas conçu pour la même utilisation qu'un vélo tout terrain. Le poids, la taille, les rainures des pneus, sont autant de facteurs à prendre en compte pour aider l'utilisateur ciblé à remplir ses objectifs. Parce que nous comprenons que le design sert a résoudre des problèmes spécifiques, nous nous devons aussi de comprendre que nous pouvons comparer objectivement l'efficacité de deux designs différents pour résoudre ces problèmes.

  1. Le design n'est pas du vernis, Aral Balkan
  2. Le design n'est pas subjectif, Jeff Law

Concision

Travaillez toujours à rendre votre application compréhensible de façon immédiate. La fonction principale de votre application doit être immédiatement apparente. Vous pouvez faire ceci d'un certain nombre de façons, mais l'un des meilleurs moyens est de rester fidèle à un principe de concision.

Évitez le trop-plein de fonctionnalités

Il est souvent très tentant d'ajouter toujours plus de fonctionnalités à votre application. Cependant, il est important de reconnaître que chaque nouvelle fonctionnalité a un prix. Plus précisément, chaque fois que vous ajoutez une nouvelle fonctionnalité :

Pensez en terme de modules

Build small, modular apps that communicate well. elementary OS apps avoid feature overlap and make their functions available to other apps either through Contractor or over D-Bus. This both saves you time as a developer (by other apps making their functions available to you), and is a courteous gesture towards other developers (by making your app's functions available to them).

Évitez la configuration

Si possible, évitez même complètement de présenter quelque réglage ou configuration que ce soit. Laisser l'utilisateur choisir est généralement la solution de facilité pour éviter d'avoir à décider du comportement de votre application. Mais de la même manière qu'un trop plein de fonctionnalités, laisser les paramètres accessibles génère plus de code, bugs, tests, documentation, et plus de complexité.

Build for the "Out of The Box" Experience

Design with sane defaults in mind. elementary OS apps put strong emphasis on the out of the box experience. If your app has to be configured before a user is comfortable using it, they may not take the time to configure it at all and simply use another app instead.

Interrogez le système d'exploitation

Obtenez autant d'informations automatiquement que possible. Au lieu de demander à un utilisateur son nom et sa localisation, sollicitez le système d'exploitation pour ces informations. Ceci réduit le nombre de choses qu'un utilisateur a à effectuer et donne à votre application une apparence intelligente et intégrée.

Est-ce vraiment nécessaire?

Demandez-vous si l'option que vous ajoutez est vraiment nécessaire ou a un sens pour votre utilisateur. Ne demandez jamais à vos utilisateurs de prendre des décisions d'ingénierie ou de design.

Lorsque c'est absolument nécessaire

Maintenez les options dans le contexte. Au lieu de cacher les options dans un menu de configuration, pensez à les afficher au côtés des objets qu'ils modifient (un peu comme les options aléatoire et répéter apparaissent au coté de votre lecteur de musique).

Si votre application nécessite d'être configurée avant d'être utilisée (comme un client de messagerie), présentez cette configuration au sein de la fenêtre principale, à la manière d'un Écran d'Accueil. Encore une fois, assurez-vous que cette configuration est réellement nécessaire. Ajouter des écrans de configuration inutiles empêche l'utilisateur d'effectuer ce pour quoi il a ouvert votre application en premier lieu.


Voyez aussi:

  1. Les Cases à Cocher qui tuent votre produit par Alex Limi (en)
  2. Ne donnez pas du Travail de Merde à vos utilisateurs par Zach Holman (en)
  3. L'Anti-Modèle de l'Installeur par Stef Walter

Documentation minimale

La plupart des utilisateurs ne veulent pas parcourir toute la documentation avant d'utiliser votre application. Ils s'attendent plutôt à ce que votre application soit assez intuitive et simple pour qu'ils puissent la comprendre sans avoir besoin d'aide.

Utilisez un vocabulaire compréhensible

Avoid technical jargon and assume little-to-no technical knowledge. This lets your app be "self-documenting."

Fournissez des explications non techniques plutôt que des messages d'erreur énigmatiques. Si un imprévu survient, une explication simplifiée de ce qu'il s'est passé et une solution doivent être affichés.


Pour plus d'informations, voir Style d'écriture.

Le Flux de l'Utilisateur

Le design visible est une majeure partie de l’expérience utilisateur, mais le "flux" de l'utilisateur, ou la façon dont ils interagissent avec votre application, est tout aussi important. Dans cette section, nous couvrons quelques étapes importantes d'une navigation type:

L'expérience du premier lancement

Configuration requise

When a user first launches an app, they should be able to get down to business as quickly as possible. If configuration is not absolutely required for the first use, they should not be required to configure anything. If configuration is required, they should be presented with a clean and simple welcome screen within the app. Avoid separate configuration dialogs when launching.

Vitesse de lancement

Le premier lancement de votre application est la toute première impression pour votre utilisateur; c'est une occasion de montrer le design et la rapidité de votre application. Si elle doit configurer des choses au préalable avant d'être visible ou utilisable, l'utilisateur aura l'impression que votre application est lente, ou met du temps à se lancer. Essayez au contraire de faire rapidement apparaître la fenêtre de votre application et de la rendre immédiatement prêt à l'emploi, puis effectuez les tâches nécessaires en arrière-plan. Si une tâche en cours bloque l'utilisateur (c'est-à-dire qu'il ne peut effectuer d'autres actions avant qu'elle ne s'achève), utilisez un indicateur pour lui signifier qu'un travail à lieu et faites en sorte que l'interface utilisateur bloquée semble insensible (voir: Concepts des Widgets).

Accueillir l'utilisateur

S’il n'y pas de contenu à montrer à l’utilisateur, ajoutez un écran d’accueil avec les actions simples qu’il peut effectuer: ouvrir un document, ajouter un compte, importer un CD, quoi que ce soit qui ait un sens dans le contexte de votre application.

Remettre à zéro l'application

If a user explicitly "resets" the app (ex. by deleting all songs in a music library or removing all mail accounts in a mail client), it should return to its first-launch state.

Lancement normal

Quand votre utilisateur lance une application, il effectue une action explicite et s'attend à une réponse rapide, voir immédiate. Vous devez vous concentrer sur trois points clés du lancement: rapidité, évidence des actions suivantes, et état de votre application.

Vitesse

Comme cela a été dit précédemment, la rapidité, notamment lors du lancement d'une application, est cruciale. Il devrait y avoir aussi peu de délai que possible pour l'utilisateur entre sa décision d'utiliser et l'utilisation effective d'une application. Si votre application nécessite un écran de démarrage, vous ne vous y prenez pas correctement.

Évidence

When a user launches your app, they should know exactly what to do next. This is achieved by following the other interface guidelines (ensuring your app is consistent with other apps) and by offering up explicit actions from the get go. If the app typically displays "items," such as songs or emails, let the user get at those items by displaying them when the app opens. If there are no previously-opened items, you should offer to open or create a new item (such as a document) by using a welcome screen.

État

Si l'utilisateur a précédemment utilisé votre application, restorer son état au moment de sa réouverture est généralement mieux. Votre application réapparaît ainsi exactement comme votre utilisateur l'a laissé, de sorte qu'il puisse reprendre son travail immédiatement. Pour un lecteur de musique, l'utilisateur doit retomber sur la dernière chanson en pause dans la dernière fenêtre qu'il a vu. Pour un logiciel de traitement de texte, ce sera ouvrir sur le même document défilé à la même ligne avec le curseur au même endroit.

Donnez toujours la possibilité d'annuler

Parfois un utilisateur va effectuer une action qui peut être destructive ou traditionnellement irréversible. Plutôt que de lui présenter une alerte, les applications devraient permettre à l'utilisateur d'annuler l'action pendant un laps de temps approprié. Les principaux exemples de quand ce comportement est utile sont :

Ce comportement devrait être implanté en dernier recours en fournissant un délai entre le moment où l'application montre à l'utilisateur ce qui a eu lieu et la réalisation de l'action. Pour conserver une impression de réactivité, l'application devrait toujours donner l'impression que l'action a eu lieu dès que l'utilisateur l'a initié.

Ce comportement vise à atteindre l'équilibre entre ne pas gêner l’utilisateur et s'assurer qu'il ne fait pas quelque chose d'involontaire. Il est important de rendre l'annulation discrète, simple et intuitive; une manière générale de le faire est d'utiliser une barre d'information, même si d'autres méthodes peuvent aussi être appropriées.


Voir aussi : Never Use a Warning When you Mean Undo par Aza Raskin

Toujours Sauvegardé

Users should feel confident when using elementary OS; they should know that everything they see is saved and up to date.

Apps in elementary OS should operate around an always-saved state. This means that changes the user makes are instantly applied and visible and that making the user manually save things is a legacy or specialized behavior.

Par exemple, la fenêtre de configuration d'une chanson doit mettre à jour instantanément les informations de la piste sans que l'utilisateur aie à appuyer sur un bouton pour sauvegarder, les préférences utilisateur doivent être appliquée aussitôt que l'utilisateur modifie le widget adéquat, et fermer une application doit impliquer qu'à sa réouverture elle reviendra là où l'utilisateur s'est arrêté.

Fermeture

Quand un utilisateur ferme une application, cela signifie souvent qu'il a fini de l'utiliser et qu'il veut qu'elle se mette hors de son chemin.

Enregistrer l'état

Les applications doivent enregistrer leur état à la fermeture afin que l'utilisateur puisse les retrouver exactement comme il les a laissées. Idéalement, fermer et ouvrir une application devrait être indissociable des concepts plus traditionnels de minimiser et maximiser; c'est-à-dire que tous les éléments, tels que les documents, la position du défilement, l'historique des modifications... doivent être enregistrés

Tâches de fond

Si il est nécéssaire pour une app de terminer des tâches de fond après la fermeture de la fenêtre, cest tâches doivent être complétées peu après la fermeture de la fenêtre. Si l'app effectue des tâches de fond répétées (comme un client mail), ces tâches doivent être prise en charge par un daemon qui n'est pas liée à l'ouverture de l'app elle-même.

Fermer la fenêtre de l'application

It is not desirable for an app window to simply minimize rather than close when the user attempts to close it. Instead, the app window should be "hidden". If it makes sense to continue a process in the background (such as downloading/transferring, playing music, or executing a terminal command) the app backend should continue with the task and close when the task is finished. If it's not immediately apparent that the process has completed (as with the file download/transfer or terminal command), the app may show a notification informing the user that the process has completed. If it is apparent, as with the music, no notification is necessary.

Ré-ouvrir le fenêtre de l'application

Si l'utilisateur ré-ouvre l'application tandis que le processus en arrière-plan est toujours en cours d'éxécution, l'application doit se situer exactement à l'endroit où la fenêtre aurais été ouverte à cet instant. Par exemple, le terminal doit afficher une sortie terminal, le lecteur de musique doit s'ouvrir à l'endroit exact où il a été fermé, et le navigateur doit s'ouvrir avec la ou les pages ouvertes précédement. Pour plus d'informations, consulter la discussion traitant de l'état d'une application lors d'un Lancement Normal.


Voir également:That's It, We're Quitting par Matthew Paul Thomas

L'Intégration Bureau

An important advantage that developers have when choosing the elementary OS platform is the ability to seamlessly integrate their application with the default desktop. Outlined below are the several ways in which you can make your application feel beyond native in elementary OS. This section will cover things like:

Lanceurs d'application

La principale méthode pour découvrir et utiliser votre application se fait au travers d'un lanceur d'application que l'on trouve dans Slingshot ou dans le dock. Pour pouvoir être utilisé par ces lanceurs d'application, vous devez fournir un fichier .desktop approprié avec votre application. Il inclut le nom que le lanceur d'application affichera, la catégorie dans laquelle il doit la ranger, quelle icône il doit afficher, etc.

Les fichiers .desktop suivent la spécification d’élément du bureau, Desktop Entry Specification, de freedesktop.org. Ils doivent être installés dans /usr/share/applications. Les utilisateurs peuvent créer leurs propres lanceurs et ajoutant des fichiers .desktop dans ~/.local/share/applications.

Le contenu des fichiers .desktop doit suivre cette structure :

Title est un(e) GenericName qui permet de Comment.

Titre

You should not include descriptive words in your title. For example, Dexter is called "Dexter," not "Dexter Address Book." Midori is just "Midori," not "Midori Web Browser." Instead, use the GenericName attribute of your app's .desktop file for a generic name, and the Comment attribute for a longer descriptive phrase.

Nom Générique

If your app is easily categorized or described with a generic name, you should use that for the GenericName attribute in your app's .desktop file. If you can say, "My app is a(n) ____," then whatever fits in that blank could be the generic name. For example, Maya is a calendar, so its generic name is "Calendar."

You should not include articles (the, a, an) or the words "program," "app," or "application" in your app's generic name.

Le nom générique devrait être casse du titre et doit être utilisé partout dans le système pour bien décrire ou catégoriser votre application.

Commentaire

Le système utilise un attribut de commentaire dédié à l'application (accessible dans le fichier .desktop) pour permettre à un utilisateur ce qui peux être effectué avec l'application. Ce doit être une courte phrase ou remarque commençant par un verbe et contenant un nom commun simple que votre application utilise. Ci-après, quelques exemples de commentaires :

Le commentaire d'une application devrait être en casse de la phrase, ne pas avoir de ponctuation finale (point, point d'exclamation ou point d'interrogation), et devrait être aussi court que possible tout en décrivant la principale utilisation de l'application.

Catégories

Les catégories suivantes peuvent être utilisées pour aider à rechercher et trouver votre application :

Pour plus d'informations, référez-vous aux spécifications FreeDesktop.Org sur le menu application.

Mots clés

You may also include keywords in your launcher to help users find your app via search. These follow the convention of "X-GNOME-Keywords" (for in the app launcher) and "X-AppInstall-Keywords" (for in the app installer). For example, web browser might include "Internet" as a keyword even though it's not in the app's name, generic name, or description. As a result, a user searching for "Internet" will find the app. Here are some more examples:

Les mots-clés doivent être des mots simples (en casse de titre) et séparés par des points-virgules.


Voir aussi : Desktop Entry Specification sur FreeDesktop.org

Contractor

Contractor est un service et un protocole qui facilite l'utilisation de services entre applications. Il permet aux applications d'interagir avec d'autres applications ou services sans coder en interne leur support. Ajoutez simplement le support Contractor, et tout service enregistré sur le Contractor est alors accessible pour votre application. Votre application peut s'intégrer à Contractor de deux façons différentes:

Afficher les résultat de Contractor

Les résultats de Contractor sont généralement présentés à l'utilisateur sous forme d'un menu. Gardez à l'esprit les choses suivantes quand vous affichez les résultats de Contractor :

Intégration du dock

Intégrez votre application avec le dock de Pantheon pour communiquer son statut en un clin d'œil.

Barres de progression

Levez toute ambiguïté pour les barres de progression en indiquant une seule tâche spécifique. Par exemple, utilisez une barre de progression pour indiquer le statut de processus longs comme les transferts de fichiers ou l'encodage. N'utilisez pas de barres de progression pour suivre l'avancement combiné de plusieurs type d'actions.

Badges

Un badge affiche le nombre d'éléments actionnables gérés par votre application. Son but est d'informer l'utilisateur au sujet des éléments qui requièrent son attention ou une action, sans être obstructif. C'est une notification passive. Un badge ne devrait pas afficher de totaux et rarement des décomptes en cours. Si le badge ne peut être supprimé facilement lorsque l'utilisateur affiche votre application, il est probable que ce soit une utilisation inadéquate d'un badge.

Indicateurs système

Les indicateurs sont des petites icônes placées dans la bar du haut. Ils offrent aux utilisateurs une place pour obtenir rapidement des informations sur divers paramètres ou événements. Cliquer sur une icône affiche un petit menu permettant à l'utilisateur d'effectuer des actions en rapport avec l'icône sur laquelle il a cliqué.

Votre application a-t-elle besoin d'un Indicateur ?

La zone indicateur est propice au fourre-tout et à l’inconstance. Étant donné que les utilisateurs vont probablement installer de nombreuses applications tierces, il faut être précautionneux quant aux nombres d’indicateurs affichés et à leur comportement. Gardez à l'esprit qu'un ensemble très restreint d'applications nécessitent ou bénéficient d'un indicateur. Évitez l’ajout d'un indicateur si:


Voir aussi : Farewell to the Notification Area par Matthew Paul Thomas

Conteneur de widget

Fenêtres

Windows form the foundation of your app. They provide a canvas with basic, built-in actions such as "closing" and "resizing". Although users may see windows as being all the same, elementary OS has several distinct window types. It's important to understand the types of windows available to you, window behavior in general, and behavior that is specific to a certain window type. This section will cover the different types of windows available in elementary OS. Although each type of window is a bit different, think of them all as a subclass of a window. Unless otherwise stated, they all behave as an average window.

Titres de fenêtre

Lorsqu'il s'agit de travailler avec les titres de fenêtres, prenez en compte le fait que leur usage principal est de permettre de faire la différence entre une fenêtre et une autre. Un titre de fenêtre adéquat fournira une description permettant à un utilisateur de faire un choix. Gardez en tête cela tandis que vous traitez les éléments suivants:

Dialogues

24
Icône de dialogue d’alerte

Texte principal avec information concise et suggestion

Texte secondaire détaillé, qui informe sur les conséquences de l’action.

24
Retour
Action Suggérée

Un texte d'alerte

Une alerte contenant à la fois un texte principal et un texte secondaire.

Le texte principal contient un bref résumé de la situation et suggère une action. Ce texte devrait utiliser la classe CSS primary.

Le texte secondaire décrit avec plus de détails la situation et informe sur tous les effets de bord possibles des actions disponibles. Il est important de noter qu’un utilisateur ne devrait avoir besoin que du texte principal pour prendre une décision, et ne devrait avoir à se reporter au texte secondaire que pour des raisons de clarification. Ce texte devrait être placé à une hauteur de ligne de texte au dessous du texte principal et utiliser la police de caractères par défaut en taille et en graisse.

Rendez le texte principal et le texte secondaire sélectionnable. Ceci permet le copier-coller pour l’utilisateur, qui peut ainsi recopier le contenu dans une autre fenêtre, un courriel par exemple.

Ordre des bouttons

"OK" is not Okay

When presenting a dialog to a user, always use explicit action names like "Save..." or "Shut Down". Consider how "OK" lets users proceed without understanding the action they are authorizing. Not all users will read the question or information presented to them in a dialog. Using specific action names will make it harder for a user to select an unintended action and may even encourage them to read the presented information before making a selection.

Fenêtre des paramètres

Les fenêtres de paramètres devraient être temporaires et non modales. Lorsqu’un utilisateur fait une modification dans une fenêtre de paramètres, cette modification devrait être immédiatement visible dans l’interface graphique. Si la fenêtre est modale, l’utilisateur pourrait ne pas voir la modification, et surtout ne pas revenir sur cette dernière. La conséquence en serait qu’il devrait fermer la fenêtre, constater la modification, et potentiellement rouvrir la fenêtre. En utilisant une fenêtre temporaire, nous gardons cette dernière au-dessus de toutes les autres pour un accès facile, et nous laissons également la possibilité à l’utilisateur d’évaluer et d'annuler ses modifications sans avoir à fermer et rouvrir cette fenêtre.


Voir aussi :

  1. Why 'Ok' Buttons In Dialog Boxes Work Best On The Right par UX Movement
  2. Why The Ok Button Is No Longer Okay par UX Movement
  3. Should I use Yes/No or Ok/Cancel on my message box? sur UX StackExchange
  4. Where to Place Icons Next to Button Labels par UX Movement

Fenêtres infobulles

La fenêtre infobulle est semblable à une fenêtre contextuelle. Elle affiche un contenu temporaire directement relié à un élément cliqué, et se ferme lorsque l’on clique en dehors, à la manière des menus.

Une fenêtre infobulle devrait être utilisée lorsqu’un utilisateur souhaite effectuer une action sans quitter l’interface principale. Quelques exemples d'utilisations: ajouter un contact depuis un courriel, ajouter un signer dans un navigateur, afficher des téléchargements ou des transferts de fichiers.

Les fenêtres infobulles ne devraient pas être utilisées pour afficher une simple liste d’éléments, utiliser un menu à la place. De même, ne les utilisez pas si l’utilisateur doit y rester plus de quelques secondes, utilisez alors une fenêtre de dialogue. Souvenez vous que les fenêtres infobulles sont contextuelles et doivent être reliées directement à l’élément qui a déclenché leur ouverture.

Barre d’outils

Une barre d’outils procure à l’utilisateur un accès rapide aux fonctionnalités les plus utilisées. De même que les boutons, la barre d’outils compte parmi les éléments d’interface graphique les plus employés. Elle ressemble à un simple conteneur, mais son utilisation et son organisation doivent être consistantes.

Ordonner les éléments de la barre d'outils

Les éléments de barre d’outils doivent être ordonnés du plus important sur la gauche vers le moins important sur la droite, avec le menu de l’application toujours à l'extrême droite de la battre d’outils. S’il y a beaucoup d’éléments dans la barre d’outils, groupez les en laissant un espace entre chaque groupe. Gardez à l’esprit qu’un affichage avec une langue RTL renversera l’interface.

Éléments de la boite à outils de l’interface graphique

elementary OS uses consistent user interface (UI) elements to bring a unified and predictable experience to users, no matter what app they're using. When used properly, this ensures a small (or nonexistent) learning curve for your app.

Concepts des Widgets

Avant de nous pencher sur tous les widgets disponibles dans elementary OS, il est nécessaire de détailler quelques concepts de base s'appliquant à tout widget. L'utilisation adéquate de ces concepts permettra de bénéficier d'une expérience transparente pour tous les utilisateur et vous évitera de devoir gérer un nombre important de rapports d'erreurs!

Contrôles qui ne font Rien

A very common mistake for developers to make is creating controls that seemingly do nothing. Keep in mind that we want to present an environment where users feel comfortable exploring. A curious user will interact with a control expecting there to be some immediate reaction. When a control seemingly does nothing, this creates confusion and can be scary (Think,  "uh-oh I don't know what happened!"). In some cases, controls that do nothing are simply clutter and add unnecessary complexity to your UI.

Consider the "clear" button present in search fields. This button only appears when it is relevant and needed. Clicking this button when the field is already clear essentially does nothing. 

Activation

Sometimes it doesn't make sense for a user to interact with a widget until some pre-requisite is fulfilled. For example, It doesn't make sense to let a user click a browser's "Forward" button unless there is forward history available. In this case, you should make the "Forward" button insensitive or a user may click it, expecting a result, and be confused when nothing happens.

It's usually better to make a widget insensitive than to hide it altogether. Making a widget insensitive informs the user that the functionality is available, but only after a certain condition is met. Hiding the widget gives the impression that the functionality is not available at all or can leave a user wondering why a feature has suddenly "disappeared".

Composants cachés

Lorsqu’un composant n’est pertinent que dans un contexte donné (pas dans le sens d’une indication sur une action à exécuter), il est parfois plus judicieux de le cacher. Prenez les prérequis matériel par exemple: il est illogique de présenter des options sur l’affichage multiple si le système ne dispose que d’un seul écran. Désactiver ces options n’apporte aucune aide sur ce système. Une autre exception à cette règle est un composant qu’un utilisateur ne verra qu’en contexte, tel le bouton « Effacer » cité dans l’exemple précédent. Pour finir, gardez à l’esprit qu’un composant désactivé sera reconnu par un lecteur d’écran ou tout autre logiciel d’assistance technique, ce qui n’est pas le cas d’un composant caché.

Espacement

Alignement


Voir aussi Proximité des libellés de formulaire: l’alignement à droite facilite le parcours par UX Movement.

Barres d'information

Les barres d'information fournissent une information contextuelle et des actions à l'utilisateur à différents niveaux d'importance.

Il est important de déterminer l'importance ou le type de barre d'information à employer. Il existe quatre types de barres disponibles:

Écran d’accueil

L'écran d’accueil est une manière agréable d'aider les utilisateurs à prendre en main votre application.

Utilisation

Un écran d’accueil est généralement utilisé dans les applications de type Noise ou Scratch où vous devez importer ou créer des objets dans une bibliothèque avant de pouvoir les utiliser. Ceci donne à vos utilisateurs une direction claire pour démarrer et énonce les étapes nécessaires avant qu’ils ne puissent utiliser votre application à leur avantage.

Si votre application autorise les utilisateurs à supprimer leur bibliothèque, assurez qu’ils seront redirigés sur l’écran d’accueil plutôt que sur une liste vide.

Libellé

L'écran d’accueil est composé de deux textes:

Iconographie

Une icône est associée à chaque action de manière à l’identifier rapidement. La majorité des icônes correspondent à des actions, mais certaines décrivent des emplacements lorsque vous importez un contenu ou que vous devez spécifier une destination. Il existe aussi des icônes d’application, présentes dans les utilitaires de configuration.

Liste de sources

Parcourir une liste de sources est une forme de navigation. Les listes de sources présentent utilement des emplacements, des signets ou encore les catégories de votre application.

Sections

Une liste de sources peut être divisée en plusieurs sections affichables, chacune avec son propre titre. Par exemple, un gestionnaire de fichier peut présenter une section pour les signets faisant référence à des emplacements, une section pour les appareils de stockage connectés à l’ordinateur, et une section pour les emplacements réseaux. Ces sections regroupent de manière utile les éléments de la liste de sources et permettent à l’utilisateur de cacher celles qu’il n’utilise pas.

Évitez si possible d'imbriquer les sections dans une liste de sources; si vous vous retrouvez dans ce cas, essayez de repenser la composition de vos sections.

Hiérarchie

La hiérarchie est importante dans une liste de sources, au sein du composant lui même et dans le périmètre plus large de votre application.

Ordonnez les sections de votre liste de sources de la plus importante en haut à la moins importante en bas. Si vous peinez à définir l’importance relative des sections entre elles, privilégiez la section qu'un utilisateur emploiera le plus souvent. Ce tri assure que les éléments les plus importants seront toujours visibles, même si la liste de sources est trop petite pour contenir tous les éléments, qui restent néanmoins accessibles au moyen de la barre de défilement.

A source list goes at the left side of a window (or right side for right-to-left languages). Because the user reads in this direction, the sidebar is reinforced as being before (and therefore at a higher level than) the app's contents.

Boutons

Buttons are an incredibly important widget to understand since your app will undoubtedly contain them.

Boutons outil

Libellé

Les boutons outil sont représentés dans la grande majorité des cas par une simple icône et n’ont pas de bordure. Ils n'ont en principe pas de libellé.

Infobulles

Tous les boutons outil devraient avoir des infobulles, puisqu’ils n’ont pas de libellé. Elles sont nécessaires aux utilisateurs de logiciels d’assistance technique et donne la signification d’une icône inconnue. Les infobulles devraient être rédigées en casse de phrase.

Comme les libellés de boutons texte, une infobulle devrait décrire ce qu’il se passe lorsque le bouton est pressé.

Boutons texte

Libellé

Le libellé d’un bouton texte devrait être rédigé en casse de titre.

Tout comme les éléments de menu, un bouton texte devrait consister une action ou un emplacement mais pas un statut. Assurez vous que le libellé du bouton décrit clairement ce qu’il se passe lorsqu'il est pressé.

"Remove Account", "Transfer to Jim's Laptop", and "Import 20 Songs" are good labels.

"OK", "Get more storage!", and "Low Battery" are not good button labels. The "Get more storage!" label has incorrect capitalization and unnecessary punctuation. The other two labels do not indicate what will happen as a result of clicking the button.

Infobulles

Puisque les boutons texte ont une libellé clair et explicite, il est en général inutile de leur ajouter une bulle d'aide.

Boutons liés

Utilisation

Les boutons liés regroupent des actions de même nature ou mutuellement exclusives. Par exemple, ils peuvent regrouper des options typographiques telles que gras, italique ou souligné. Ou bien regrouper des états mutuellement exclusif tels que affichage en grille, liste ou colonne.

Libellé

Les boutons liés ne devraient jamais contenir d’icônes colorées. Seules des icônes symboliques de 16px ou du texte. Ne mélangez pas des icônes et du texte.


  1. Pourquoi le bouton OK n'est plus OK par UX Movement
  2. Should I use Yes/No or Ok/Cancel on my message box? sur UX StackExchange

Menu d'application

The AppMenu is an optional menu which is opened using the gear-shaped icon on the far-right of an app's toolbar. It provides relevant menu items in place of the traditional "File, Edit, View..." menu bar.

Utilisation

Demandez-vous d’abord si votre application a réellement besoin de ce composant. Même si la plupart des autres applications en ont un, la votre n’a pas nécessairement besoin d’un menu.

Lorsque vous ajoutez des éléments à votre menu, tenez compte des point suivants :

Champs de recherche

Les applications qui supportent la recherche et le filtrage de contenu devraient inclure un champ de recherche à la droite de la barre de l’application. L’utilisateur constate ainsi rapidement grâce à cet emplacement standard si l’application a une fonction de recherche ou non. Gtk+ fournit un composant complexe de recherche très utile appelé Gtk.SearchEntry.

Faire la distinction entre rechercher et trouver

Rechercher filtre le contenu d'une bibliothèque, par exemple de musiques ou de vidéos, pour ne retenir que les éléments correspondants. Le recherche est en général déclenchée par une frappe clavier dans l'affichage d'une bibliothèque.

Trouver surligne les occurrences d'une chaîne, par exemple dans un éditeur de texte, une page web, ou un Terminal. Le déclencheur est un raccourci clavier (Ctrl+F) ou une icône de recherche. La barre Trouver apparaît sous la barre de titre avec les actions associées telles que trouver l'occurrence suivante, précédente, tout surligner, etc. . La barre peut également contenir d'autres actions telles que remplacer ou aller à la ligne.

Comportement

S’il est possible d’inclure une fonctionnalité de recherche dans votre application, faîtes le. Cette fonctionnalité devrait accompagner toute liste ou représentation de contenu multiple au moyen d’un champ de recherche qui respecte les règles suivantes:

Libellé

Search fields should contain hint text that describes what will be search. You can set this using the entry property "placeholder_text".

Most search fields should use the format "Search OBJECTS" where OBJECTS is something to be searched, like Contacts, Accounts, etc.

If the search field interacts with a search service, the hint text should be the name of that service such as "Google" or "Yahoo!"

Checkboxes & Switches

Cases à cocher

Les cases à cocher permettent à l’utilisateur de sélectionner les éléments d’une liste.

Utilisation

Utiliser des cases à cocher lorsque l’utilisateur doit sélectionner des éléments. Assurez vous qu’il puisse également basculer l’état en cliquant sur le libellé correspondant.

Libellé

Les libellés correspondant aux cases à cocher devraient être des noms ou des phrases nominales.

Interrupteurs

Switches present a way for users to toggle certain features or behaviors "on" or "off".

Utilisation

N’utilisez pas d’interrupteur pour sélectionner les éléments d’une liste, utilisez une case à cocher. Les interrupteurs agissent sur des services indépendants tandis que les cases à cocher sélectionnent les éléments d’une liste. Il est important de faire la distinction.

Notice that the option "Record from microphone" is a great candidate for a switch. You are enabling and disabling this recording service.

However, if there are two options "Record system sounds" and "Record from microphone" you are now dealing with a list of related items to include as part of a larger recording service (who's on and off state is independent of what services it includes). In this case, a checkbox is more appropriate to denote this inclusion.

Libellé

When possible, directly call out the service you are acting on. Do not use words that describe the state that the widget is describing like "Enable Multitouch", "Use Multitouch", or "Disable Multitouch". This can create a confusing situation logically. Instead, simply use the noun and write "Multitouch".


Voir également: 3 façons de réaliser des cases à cocher et des boutons radio faciles à cliquer par UX Movement.

Notebooks

Notebooks are a type of widget that lets apps show one of multiple pages (also colloquially referenced as "tab bars").

Notebook statique

Un notebook statique est une petite série d’onglets qui ne changent pas, souvent utilisés dans les préférences. Les onglets sont présentés sous la forme de boutons centrés en haut de la zone du contenu. Un notebook statique contient dans la plupart des cas deux à cinq onglets

Notebook dynamique

A Dynamic Notebook is a way for an app to provide user-managable tabbing functionality, commonly seen in web browsers. The tabs appear attached to the toolbar on their own tab bar above the relevant content. Tabs are able to be rearranged and closed and a "new tab" button is at the left ot the notebook widget.

Iconographie

L’iconographie représente une partie cruciale de elementary OS. Les icônes composent la majorité de l'interface graphique avec laquelle l'utilisateur interagit sans cesse; elles apportent le souffle vital au système et donne au puissant moteur de reconnaissance visuelle du cerveau humain de quoi se repaître.

Forme

Votre icône doit avoir une forme ou silhouette distincte pour améliorer sa perception. Tandis que la forme ne doit pas être trop complexe, elle n’est pas nécessairement un rectangle aux coins arrondis.

Icône de fenêtre d’alerteIcône de ChatIcône de PhotosIcône de VidéosIcône de comptes en ligneIcône Terminal

Métaphores

Si vous créez une icône pour un appareil physique ou un type de fichier (comme celles pour MimeType ou les icônes appareil), sa forme correspond à la représentation de son équivalent réel. Par exemple, une icône pour un appareil photo est un appareil photo stylisé.

Icône CaméraIcône du disque durIcône de la sourisIcône de paquetIcône Texte HTMLIcône de l'ordinateur

Actions

Action icons are used to represent common user actions, such as "delete", "play", or "save". These icons are mostly found in app toolbars, but can be found throughout the OS.

Icône PrécédenteIcône SuivanteIcône d'exportation de documentsIcône d'ImpressionIcône d'enregistrementIcône de suppressionIcône CouperIcône d'annulationIcône d'inversionIcône jouer la musiqueIcône Nouvelle étiquetteIcône du menu

Si votre application utilise l’une de ces actions communes, utiliser la référence de l’icône correspondante plutôt que de créer la votre. L’expérience utilisateur n’en sera que plus consistante et ce dernier sera plus à même de reconnaître les fonctions communes.

Si votre application exige une action spécifique, vous devrez créer votre propre icône. Tâchez lors de sa conception de suivre l'aspect et la convivialité des icônes existantes, et incluez la dans votre application.

Taille des icônes

elementary OS utilise six tailles principales d’icônes au sein du système et il est conseillé de toutes les inclure dans votre application.

Icône du Terminal 16 pixelsIcône du Terminal 24 pixelsIcône du Terminal 32 pixelsIcône du Terminal 48 pixelsIcône du Terminal 64 pixelsIcône du Terminal 128 pixels
16 24 32 48 64 128
Icône du Terminal 128 pixels
128

Design each icon for the size it's meant to be viewed at. In other words, do not design one icon and resize it to fill the remaining sizes, the best result is when each icon is designed individually. For more information about this practice (called "pixel-fitting") and its importance, we recommend reading Dustin Curtis' article, Pixel-fitting.

Palette de couleurs

Color, don't be afraid to use it! Many of the elementary OS icons use vibrant colors; it's best to reserve muted tones and greys for boring system icons.

Icône des mailsIcône du lecteur RSSIcône du navigateur webIcône de PhotosIcône RéseauIcône du calendrier

Colors do have their connotations, so be cognisant of this when picking them. For instance: red is usually associated with error or "danger" and orange with warnings. But you can use these color connotations to help convey your icon's meaning, such as green for "go".

Icônes symboliques

Les icônes symboliques sont des icônes système communes, qui symbolisent les fichiers, appareils ou répertoires, ou des actions telles couper, copier ou sauvegarder.

Toutes les icônes symboliques sont une forme simplifiée de leur version en pleine couleur. Ce dessin minimal assure la lisibilité et la clarté, y compris à de petites tailles.

Icônes symboliques vs colorées

Icônes colorées vs symboliques

L’utilisation d’une icône en version pleine couleur ou en version symbolique n'est pas équivalente, toutes deux ont une utilisation appropriée.

Les icônes colorées sont plus utilisées pour :

Les icônes symboliques sont plus utilisées pour :

Composition

There are three aspects to note when designing an elementary OS icon:

Composition breakdown of elementary OS Videos icon Composition breakdown of elementary OS Terminal icon

Tenir compte de ces lignes lors de la conception signifie placer des éléments de dessin le long de celles ci, de telle sorte que plusieurs icônes alignées aient plus de consistance ensemble. Remarquez par exemple comment des éléments des icônes Terminal et Vidéos ci-dessus sont placés le long ou autour de la ligne centrale.

Tailles standard

Si vous créez une icône carrée, comme celle du terminal vue précédemment, veuillez utiliser ces tailles standard (en pixel) pour chaque icône.

Taille du dessin Ligne de base Hauteur d’x Ligne de hauteur moyenne
16x16 1 14 8
24x24 2 20 12
32x32 2 26 16
48x48 3 40 24
64x64 4 56 32
128x128 9 104 64

Exceptions

Il y a cependant des exceptions. Beaucoup d’icônes (surtout les icônes de type MIME) ont des éléments ascendants et descendants, ces éléments qui vont au delà de la ligne de base et de la hauteur d’x (montrés ici en orange.)

Composition exception example in elementary OS Video icon Composition exception example in elementary OS Terminal icon

Les éléments ronds requièrent généralement un petit dépassement, pour compenser l’effet d'illusion optique qui les rend plus petits que leurs équivalents rectangulaires.

Outlines & Contrast

All elementary OS icons have a thin outline (stroke) to improve their contrast. The width of this stroke is one pixel for all icons, at every size. The color of the outline is a darker variant (30% darker) of the primary color of the icon. For instance, in the calendar icon below, the green header has a stroke of a darker green.

Example of contrast in elementary OS Calendar icon Exemple de contraste dans l’icône Paramétrage d’elementary

Pour améliorer le contraste, le contour est également à demi transparent. La netteté des icônes sur plusieurs types d'arrière-plan en est améliorée. De plus, si l’élément est quasi blanc, ce contour devient une bordure et contient plus qu’il n’étend son élément correspondant. Voyez l'icône précédente pour un exemple de cet effet.

Shadows & Highlights

If you picture an icon sitting on a shelf, facing you, with a light source above it, you may see a small fuzzy shadow near the bottom. Also, since the edges of an object tends to reflect more light due to your position relative to it and to the light source, they will have a highlight. Both these effects are something elementary OS icons emulate in their design to lend them a degree of realism.

Arête en surbrillance

Pour appliquer l’effet d’arête en surbrillance à votre icône, tracez un trait subtil de 1 pixel d’épaisseur pour représenter la surbrillance. Ce trait est légèrement plus clair au sommet et au bas que sur les côtés.

Edge highlight example in elementary OS Music icon

Ombre projetée

Pour dessiner l’ombre projetée, commencez par dessiner un rectangle. Puis remplissez le d’un dégradé linéaire perpendiculaire à la marge du bas de l’icône. Ce dégradé a trois étapes, la première et la dernière ont une opacité de zéro. Puis l’opacité de cette forme en entier est spécifiée à 60%.

Next create two smaller rectangles to "bookend" the larger. Fill each with a gradient identical to the first, but make it radial instead. Center the radial gradient in the middle of a short edge with each stop directly out to the nearest edge—see below for an example. Both these rectangles are also set to 60% opacity.

Ombre de pictogramme

Si votre icône a un pictogramme, tel le triangle symbolisant la lecture dans l’icône ci-après, vous pouvez y ajouter une ombre projetée pour la distinguer de l’arrière-plan de l’icône.

Pour ce faire, dupliquez le pictogramme, remplissez le de noir et spécifiez l’opacité à 15%. Puis décalez le de 1 pixel vers le bas et placer le sous le pictogramme. Créez une copie de cette ombre et ajoutez-y un trait de 1 pixel d’épaisseur (également noir) puis ajustez l’opacité de cet élément à 7%.

Effet de luminosité

Vous êtes libre d’ajouter un effet de brillance (lumières supplémentaires) à votre icône mais ce n’est une bonne idée que si vous imitez une surface brillante dans la réalité (telle que le plastique, le verre , etc.). Par exemple, une feuille de papier n’est pas brillante en général et de ce fait une icône représentant le papier ne devrait pas l’être.

À faire et à ne pas faire

Below are some "do and don't" examples to consider when creating icons for your app.

Texte

Although elementary OS primarily uses graphics as a means of interaction, text is also widely used for things like button labels, tooltips, menu items, dialog messages, and more. Using text consistently and clearly both in terminology and format is an extremely important part of designing your app and helps add to the overall cohesiveness of the elementary OS platform.

Style d'écriture

Respectez les règles suivantes pour garder votre texte compréhensible et cohérent :

Soyez bref

N’étouffez pas l’utilisateur avec une tartine de texte ; une longue phrase peut paraître intimidante et décourager la lecture de votre message. Écrivez plutôt un texte court et concis.

Restez simple

Supposez que l’utilisateur est intelligent, mais pas technique. Évitez les mots longs et peu communs, préférez leurs des verbes, noms et adjectifs simples. N’utilisez jamais de jargon technique.

Allez à l’essentiel

Mettez les informations les plus importantes au début de votre texte. Si l'utilisateur arrête sa lecture, il aura tout de même ce dont il a besoin.

Ne vous répétez pas

La répétition peut être fatigante et ajoute une longueur inutile à votre message.

Utilisez une hiérarchie visuelle

Une hiérarchie visuelle aide les utilisateurs à lire et comprendre votre texte tout en sachant ce qui est important. Utilisez les titres et autres styles de texte correctement.

Langue

While much of elementary OS is developed in English, there are many users who do not know English or prefer their native language. While putting text into your app, keep the following in mind:

Capitalisation

Tous les éléments textuels de l'interface, tels que les labels, boutons et menus, doivent utiliser l'un des deux styles de capitalisation suivants: casse de la phrase ou casse du titre.

Casse de la phrase

La casse de la phrase signifie que vous capitalisez comme dans une phrase normale.

Seules la première lettre de la phrase et la première lettre des noms propres sont capitalisées. Utilisée pour les labels et textes descriptifs.

Casse du titre

La casse du titre signifie que vous capitalisez comme pour un titre de livre ou d'article.

Cette casse est identique à la casse de phrase en français. Elle est différente en anglais par exemple (il faut capitaliser tous les mots).

Notes/Exceptions

Proper nouns should always be capitalized properly; this means that, for example, Google should always be shown as "Google," elementary should always be shown as "elementary," and MPEG should always be shown as "MPEG." If you're unsure how a certain pronoun should be officially capitalized, refer to the documentation of the pronoun in question.

Ponctuation

Une typographie adéquate est importante au sein d'elementary OS. Non seulement pour la consistance du système d'exploitation, mais aussi pour suivre les conventions et offrir une image sérieuse et professionnelle de la plateforme.

Éviter les erreurs courantes

Hyphens & Dashes

Trait d'union (‐)

Utilisez \u2010 dans votre code pour :

Tiret moyen (–)

Dans le code, utilisez \u2013 pour :

Tiret long (—)

Dans le code, utilisez \u2014 pour :


Dans le doute, consultez la page conventions typographiques de Wikipédia.

Ces règles sont applicables à la langue française; les autres langues ont aussi avoir leurs propres conventions qui doivent être suivies par des traducteurs.

Utilisation des points de suspension

Les points de suspension (…) sont utilisés dans l’interface pour deux raisons principales: prévenir l’utilisateur d’un besoin d’information supplémentaire ou bien indiquer qu’un texte est affiché en version raccourcie.

Informations additionnelles

Les points de suspension sont utilisés pour informer l’utilisateur qu’un supplément d’information est attendu ou qu’une action est requise avant que l’action en cours ne puisse‐t‐être exécutée. Cela indique généralement que l’utilisateur doit s’attendre à l’apparition d’une nouvelle fenêtre, barre d’outils, etc. dans la laquelle il devra renseigner des informations ou faire une sélection, avant de pouvoir compléter son action initiale. C’est une distinction importante car un utilisateur attendrait à un résultat immédiat après avoir cliqué sur un bouton ou un élément de menu, tandis que les points de suspension le prévienne d’un comportement alternatif. De façon plus précise, les points de suspension devraient être utilisés lorsque l’action :

Texte raccourci

Un texte abrégé par manque de place doit être suivi de points de suspension. Par exemple, si un titre dans de liste de lecture est trop long pour la barre latérale, abrégez le et signalez cette opération avec des points de suspension.Il y a deux manières d’utiliser les points de suspension lorsque l’on abrège un texte :

Si vous hésitez, tronquez au milieu pour garder le début et la fin du texte intacts. Il est important de ne pas livrer d’applications avec du texte tronqué. Le raccourcissement doit résulter d’une action utilisateur telle que le redimensionnement d’une barre latérale ou bien de la saisie d’un texte personnalisé.

Quand ne pas utiliser de points de suspension


Assurez-vous d'utiliser le vrai caractère de points de suspensions (…) plutôt que d'utiliser trois points (.) consécutifs.

Nommer les éléments de menu

Les éléments de menu doivent avoir des noms qui sont soit des actions soit des emplacements, jamais des descriptions. Assurez vous qu’ils soient concis mais aussi qu'ils décrivent pleinement l’action exécutée lorsqu’ils sont cliqués.

"Find in Page..." is acceptable as it clearly describes the action that will be performed when the item is clicked. "Software Up to Date" is not acceptable. What happens if I click this item? Where will it take me? What will it do? The outcome is uncertain.