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 livre de loi. 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é.

Construisez pour une experience "prêt à l'emploi"

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

Éviter le jargon technique et envisager un bagage technique faible ou absent. Ceci rendra votre application auto-documentée.

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, fournissez-lui à l'aide d'un écran d'accueil simple des action qu'ils puisse effectuer. Permettez-lui d'ouvrir un document, ajouter un compte, importer un CD, ou quoi que ce soit qui ait un sens dans le contexte de votre application.

Remettre à zéro l'application

Si votre utilisateur "réinitialise" explicitement votre application (par exemple en effaçant toute les chansons d'un bibliothèque musicale ou en supprimant tous les comptes d'un client de messagerie), celle-ci devrait revenir à son état initial.

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

Lorsqu'un utilisateur lance votre application, il devrait savoir exactement ce qu'il a à faire. Vous pouvez accomplir ceci en suivant les autres bonnes pratiques pour l'interface (rendre votre application cohérente avec les autres) et en soumettant à votre utilisateur des actions explicites dès le départ. Si votre application expose des "éléments", comme des chansons ou des emails, laissez l'utilisateur y accéder en les affichant lors de l'ouverture. S'ils n'y a pas d'éléments à afficher, proposez à l'utilisateur d'en ouvrir ou d'en créer un nouveau (comme un document) en utilisant un écran d'accueil.

É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é

Les utilisateurs doivent se sentir confiants en utilisant elementary ; ils doivent savoir que tout ce qu'ils voient est sauvegardé et à jour.

Les applications dans elementary doivent fonctionner dans un état toujours sauvegardé. Cela signifie que les modifications apportées par l'utilisateur sont instantanément appliquées et visibles, et que faire que l'utilisateur sauvegarde manuellement est un comportement ancien ou spécialisé.

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

Il n'est pas désirable que la fenêtre d'une application se minimise au lieu de se fermer quand l'utilisateur essaie de la fermer. Au contraire, la fenêtre devrait être "cachée". S'il faut qu'une tâche se termine (comme un téléchargement, une lecture de musique, ou l'exécution d'une commande dans un terminal), l'application devrait continuer d'exécuter cette tâche dans le fond et se fermer quand elle est terminée. Si l'utilisateur ne peut pas savoir spontanément que la tâche est terminée, l'application peut notifier l'utilisateur de sa terminaison. Dans le cas de la musique, par exemple, une telle notification n'est pas nécessaire.

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

.desktop files follow the freedesktop.org Desktop Entry Specification. They should be installed in /usr/share/applications. Users may create their own launchers by putting .desktop files in ~/.local/share/applications.

Le contenu des fichiers .desktop doit suivre cette structure :

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

Titre

Vous ne devez pas inclure de mot descriptifs dans votre titre. Par exemple, Dexter est appelé "Dexter", et pas "Carnet d'adresses Dexter". Midori est juste "Midori", pas "Navigateur internet Midori". À la place, utilisez l'attribute GenericName du fichier .desktop de votre app pour un nom générique, et l'attribut Comment pour une plus longue phrase descriptive.

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

Vous ne devez pas inclure d'articles (le, un, une) ou les mots "programme", "app" ou "application" dans le nom générique de votre app.

Le nom générique devrait être cas du titre et doit être utilisé partout dans le système pour mieux 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 :

An app's comment should be in sentence case, not include terminal punctuation (periods, exclamation points, or question marks), and should be as short as possible while describing the primary use case of the app.

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 is a service and a protocol for exposing services easily between apps. It lets apps interact with other apps and services without hardcoded support for them. You simply add Contractor support, and then any service registered with Contractor is now available for your app to use. Your app can integrate with Contractor in two different ways:

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

Make progress bars unambiguous by referring to a single, specific task. For example, use progress bars to indicate the status of lengthy processes like file transfers and encoding. Do not use progress bars to compound the progress of different types of action.

Badges

A badge shows a count of actionable items managed by your app. Its purpose is to inform the user that there are items that require user attention or action without being obtrusive. This is a passive notification. A badge should not show totals or rarely changing counters. If the badge is not easily dismissed when the user views your app, it is likely that this is not a good use of a badge.

Indicateurs système

Les indicateurs sont des petites icônes placées dans la bar du haut. Ils offrent au 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 à cliquer

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

The indicator area is prone to clutter and inconsistent paradigms. Given that users will probably install many third-party apps, we must be careful about the number of indicators we show and how they behave. Keep in mind that only a very small set of applications need or benefit from an indicator. Avoid adding an indicator if:


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
Dialog warning icon

Primary text providing basic information and a suggestion

Secondary text providing further details. Also includes information that explains any unobvious consequences of actions.

24
Retour
Action Suggérée

Un texte d'alerte

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

The primary text contains a brief summary of the situation and offer a suggested action. This text should use the CSS class primary.

The secondary text provides a more detailed description of the situation and describes any possible side effects of the available actions. It's important to note that a user should only need the primary text to make a decision and should only need to refer to the secondary text for clarification. This text should be placed one text line height beneath the primary text using the default font size and weight.

Make both the primary and secondary text selectable. This makes it easy for the user to copy and paste the text to another window, such as an email message.

Ordre des bouttons

"OK" n'est pas 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

Preference dialogs should be made Transient, but not Modal. When a user makes a change in a preference dialog, the change should be immediately visible in the UI. If the dialog is modal, the user may be blocked from seeing (and especially from interacting with) the change. This means they will have to close the dialog, evaluate the change, then possibly re-open the dialog. By making the dialog transient, we keep the dialog on top for easy access, but we also let the user evaluate and possibly revert the change without having to close and re-open the preference dialog.


Voir aussi :

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

Popovers

Popovers are like a contextual dialog. They display transient content directly related to something that was clicked on and close when clicked out of, like menus.

A popover should be used when a user wants to perform a quick action without getting out of the main UI. Some examples of where a popover could be used are adding a contact from an email, adding a bookmark in a browser, or displaying downloads or file transfers.

Popovers should not be used when displaying only a simple list of items; instead, use a menu. Likewise, don't use a popover if the user would spend more than a few seconds in it; instead, use a dialog. Remember that popovers are contextual and should directly relate to the UI element from which they spawn.

Barre d'outils

A Toolbar is useful for providing users with quick access to an app's most used features. Besides Buttons, a Toolbar is one of the most frequently used UI elements. It may seem like a simple container, but it is important to remain consistent in its use and organization.

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

Toolbar items should be organized with the most significant objects on the left and the least significant on the right, with the AppMenu always on the far right of the Toolbar. If you have many toolbar items it may be appropriate to divide them into groups with space in between each group. Keep in mind that when viewed with RTL languages, your toolbar layout will be flipped.

UI Toolkit Elements

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

Une erreur très classique pour les développeurs est de créer des contrôles qui manifestement ne servent à rien. Gardez à l'esprit que nous voulons présenter un environnement dans lequel les utilisateurs peuvent naviguer le plus simplement possible. Un utilisateur curieux va interagir avec un contrôle attendant une réaction immédiate. Lorsqu'un contrôle ne semble pas provoquer de réaction, cela provoque une confusion et peux sembler effrayant. (Pensez, "Oh je ne sais pas ce qui s'est passé!"). Dans certains cas, les contrôles inertes sont simplement une pollution et ajoutent de la complexité à votre interface utilisateur.

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.

Sensibilité

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

Widgets cachés

When a widget only makes sense in a certain context (not as an indicator of an action to be performed) sometimes it does make more sense to hide it. Take hardware requirements for example: It may not make sense to show multi-display options if the system only has a single display. Making multi-display options insensitive is not really a helpful hint on this system. Another exemption to this rule is a widget that a user will only look for in context, like the clear button example above. Finally, Keep in mind that insensitive items will still be recognized by screen readers and other assistive tech, while hidden widgets will not.

Espacement

Alignement


See also: Form Label Proximity: Right Aligned is Easier to Scan by 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 de bienvenue

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

Utilisation

Typically a Welcome Screen is used for apps like Noise or Scratch where you have to import or create objects in a library before you can interact with them. This provides your users with a clear path to getting started and points out any immediate steps they must take before your app becomes useful.

If your app lets users clear its library, make sure that it returns to the Welcome Screen instead of an empty list.

Étiquetage

L'écran de bienvenue est composé de deux ensembles d'étiquettes:

iconographie

Grouped with each action is an icon that helps to quickly visualize it. Most of the time these will be Action icons, but you can use Places icons when importing or setting a location and even Apps icons if you must open a configuration utility.

Liste de sources

A source list may be used as a high-level form of navigation. Source lists are useful for showing different locations, bookmarks, or categories within your app.

Sections

A source list may be separated into different collapsible sections, each with its own heading. For example, a file manager might have a section for bookmarked locations, a section for storage devices attached to the computer, and a section for network locations. These sections help group related items in the source list and lets the user hide away sections they might not use.

Avoid nesting expandable sections within a source list if possible; if you find yourself wanting to do this, you may need to rethink the sections.

Hierarchie

Hierarchy is important with source lists, both within the widget itself and within the broader scope of your app.

Sections in the source list should be sorted from most important at the top to least important at the bottom. If you're having a hard time deciding the relative importance of each section, think about which section a user is likely to use more often. Sorting the sections this way ensures that the most important items are always visible, even if the source list is too short to fit all of the items, though of course items at the bottom will still be accessible via scrolling.

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 Outils

Étiquetage

Tool Buttons are almost always icon-only and do not provide a button border. They should not be accompanied by a label.

Infobulles

All Tool Buttons should have tooltips, since they do not contain a label. This assists users with disabilities as well as giving a translation for an unrecognized icon. Tooltips should be done in Sentence Case.

Like text button labels, a tooltip should clearly describe what will happen when the button is pressed.

Boutons de texte

Étiquetage

L'étiquette du bouton "Texte" devrait être faite dans la case "Titre"

Like menu items, Text Button labels should consist of an Action or a Location but not a status. Make sure that a button's label clearly describes what will happen when it is pressed.

"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

Linked Buttons are used to group actions that are either similar in nature or mutually exclusive. For example, they could group text options like Bold, Italic, and Underline. Or they can be used to group mutually exclusive states like Grid, List, or Column view.

Étiquetage

Linked Buttons should never contain colored icons. Only 16px symbolic icons OR text. Do not mix icons and text.


  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? on 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 widget. Même si la plupart des autres application 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

Apps that support the searching or filtering of content should include a search field on the right side of the app's toolbar. This gives users a predictable place to see whether or not an app supports searching, and a consistent location from which to search. Gtk+ provides a convenient complex widget for this purpose called 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

If it is possible to include search functionality within your app, it is best to do so. Any list or representation of multiple pieces of data should be searchable using a search field that follows these rules:

Étiquetage

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!"

Case à Cocher & Interrupteurs

Cases à Cocher

Checkboxes present a way for users to select items from a list.

Utilisation

Use checkboxes when users are making a selection of items. Make sure that a user can toggle the state of the checkbox by clicking on the label associated with the checkbox.

Étiquetage

Labels associated with Checkboxes should usually be nouns or nounal phrases.

Interrupteurs

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

Utilisation

Don't use switches to include related items as part of a list, instead use a checkbox. Think of switches as acting on independent services and checkboxes as including objects in a list. This is an important distinction to make.

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.

Étiquetage

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


See also: 3 Ways to Make Checkboxes, Radio Buttons Easier to Click by 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 peux dans la plupart des cas contenir 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

Iconography is a key part of elementary OS. Icons make up the majority of the UI that your user will be actively engaging with; they're what bring the system to life and cater to the powerful recognition engine of the human brain.

Forme

Your icon should have a distinctive shape/silhouette to improve its recognition. This shape should not be too complicated, but the icon should not always be a rounded rectangle.

Warning dialog iconChat iconPhotos iconVideos iconOnline accounts iconTerminal icon

Métaphores

If you're creating an icon for a hardware device or a file type (such as those for MimeType or Device icons), its shape is typically a visual representation of its real-world counterparts. For example, the icon for a camera is a stylized camera.

Camera iconIcône du disque durIcône de la sourisPackage iconHTML Text iconIcô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écedenteIcône SuivanteIcône d'exportation de documentsIcône d'ImpressionIcône d'enregistrementIcône de suppressionCut iconIcône d'annulationIcône d'inversionIcône jouer la musiqueNew tag iconIcône du menu

If your app makes use one of these common actions, reference its corresponding icon instead of creating your own. This ensures a consistent user experience and aids in user recognition of common functions.

If your app has a unique action, you may need to create your own. When doing this, try to follow the look and feel of existing action icons, and include it along with your app.

Taille des icônes

elementary OS uses six main icon sizes throughout the OS and it's best to include all six as part of your 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 pixels128 pixel Terminal icon
16 24 32 48 64 128
128 pixel Terminal icon
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 webPhotos iconNetwork iconIcô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".

Symbolic Icons

Symbolic icons are common system icons, that symbolize files, devices, or directories and are also used to represent common actions like cut, copy, and save.

Each symbolic icon is a reduced form of its full-color counter part. This minimal design ensures readability and clarity even at small sizes.

Icônes symboliques vs colorées

Icônes colorées vs symboliques

The use of full-color and symbolic icons is not interchangeable, both have appropriate uses.

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

Keeping these lines in mind while designing, means you can place elements along them so icons appear more consistent when put together. For example, notice how some elements in both the Terminal and Videos icon above relate to the mean line.

Common Measurements

If you're designing a square-shaped icon, like the one for Terminal seen above, then consider using these common measurements (in pixels) for each icon.

Canvas Size Base Line x-Height Mean Line Height
16x16 1 14 8
24x24 2 20 12
32x32 2 26 16
48x48 3 40 24
64x64 4 56 32
128x128 9 104 64

Des Exceptions

However there are exceptions. Many icons (especially mimetype icons) have ascending and descending elements, which are those elements that extend beyond the base line and x-height line (shown here in orange.)

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

Rounder components will generally require some overshoot, to compensate for the optical illusion that makes them look smaller than their rectangular counterparts.

Contours & Contraste

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 Example of contrast in elementary Settings icon

To further improve contrast, strokes are also semi-transparent. This ensures that icons appear sharp against a variety of backgrounds. Also, if the element is near-white, this stroke acts as a border and contains, rather than overlaps, its corresponding element. See the above icon for an example of this.

Tons foncés & clairs

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.

Edge Highlight

To apply the edge highlight effect to your icon, draw a subtle, 1 pixel, inner stroke as a highlight. This outline is slightly brighter at the top and the bottom than it is at the edges.

Edge highlight example in elementary OS Music icon

Ombre projetée

To draw the shadow, you'll start by drawing a rectangle. Then fill it with a linear gradient that is perpendicular to the bottom margin of the icon. The gradient has three stops, the first and last of which have zero opacity. Then this entire shape is set to 60% opacity.

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.

Pictogram Shadow

If your icon has a pictogram, such as the play triangle in the icon below, you can give it a drop shadow to make it stand out from the background of the icon.

To do this, first duplicate the pictogram, fill it with solid black and set it to 15% opacity. Next, shift it 1 pixel down and place it below the pictogram. Create a copy of this shadow and give it a 1 pixel stroke (also black) and adjust this element to 7% opacity.

Icon Materials

You are free to add gloss (extra highlights) to your icon but this is only a good idea if you're emulating a surface that is more-reflective in real life (such as plastic, glass, etc.) For instance, a sheet of paper is not glossy therefore a icon emulating paper would not be either.

À 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

Ne donnez pas à l'utilisateur un long texte à lire ; une longue phrase peut paraître intimidante et peut le décourager de lire votre message. Proposez plutôt à l'utilisateur un texte court et concis.

Pensez Simple

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

Aller à la dernière ligne

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.

Seulement la première lettre de la phrase et la première lettre des noms propres sont capitalisées. Utilisé 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.

Capitalisez le premier et le dernier mot. Tous les noms, pronoms, adjectifs, verbes, adverbes et conjonctions subordonnées (comme, parce que, bien que) sont capitalisés. Utilisé pour les titres, boutons, menus, et une grande partie des autres widgets.

Notes/Exceptions

Les noms propres doivent toujours être capitalisés correctement : cela signifie que, par exemple, Google doit toujours être affiché comme "Google", elementary doit toujours être affiché comme "elementary" et MPEG doit toujours être affiché comme "MPEG". Si vous ne savez pas comment un certain pronom doit être officiellement capitalisé, référez-vous à la documentation du pronom en 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

Traits d'Union & Tirets

Trait d'Union (-)

Utilisez \u2010 dans votre code. Utilisé pour :

En Dash (–)

Dans le code, utiliser \u2013. Utilisé pour:

Em Dash (—)

Dans le code, utilise \u2014. Utilisé pour:


If in doubt, refer to Butterwick's Practical Typography.

Ces règles sont applicables a la langue anglaise; les autres langues peuvent aussi avoir leurs propres conventions qui doivent être suivis par des traducteurs.

Utilisation des points de suspension

The ellipsis character (…) is used in the interface for two primary reasons: informing the user of an additional required information and letting the user know text has been shortened.

Informations Additionnelles

An ellipsis should be used to let a user know that more information or a further action is required before their action can be performed. Usually this means that the user should expect a new interface element to appear such as a new window, dialog, toolbar, etc in which they must enter more information or make a selection before completing the intended action. This is an important distinction because a user should typically expect an instant action from buttons and menu items while this prepares them for an alternate behavior. More specifically, an ellipsis should be used when the associated action:

Texte Raccourci

Ellipses should be used when shortening text that cannot fit in any specific place. For example, if a playlist's name is longer than the space available in the sidebar, truncate it and use an ellipsis to signify its truncation. There are two ways to use an ellipsis when shortening text:

If you're unsure, it's best to use middle truncation as it keeps both the beginning and end of the string in tact. It's also important that you do not ship your app with any truncated text; truncation should only be the result of a user action such as resizing a sidebar or entering custom text.

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 du Menu

Menu items should have names that are either actions or locations, never descriptions. Make sure menu items are concise, but also fully describe the action that will be performed when they are clicked.

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