Human Interface Guidelines

These guidelines are designed to help developers and designers create a beautifully consistent experience on the elementary 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 allow you to decide when it is appropriate to deviate from the Guidelines. Adhering to the suggestions contained here will provide many benefits:

To help you achieve these goals, these guidelines will cover basic interface elements, how to use them and put them together effectively, and how to make your application integrate well with the desktop. The most important thing to remember is that following these guidelines will make it easier to design a new application, not harder.

However, keep in mind that this is a guideline, not a rulebook. New, amazing interaction paradigms appear every day and more are waiting to be discovered. This is a living document that can and will be changed.

For sections that have not yet been written, please refer to The GNOME HIG

Design Philosophy

The elementary 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":

What Design Is Not

Before we get into all the things that make up elementary 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. Design is not something you add on after you've completed a product. Whether you realize it or not, you are constantly designing anything you build. It is an intrinsic part of creating something. Design is not just what something looks like. It's not just the colors and fonts. Design is how it works. When you decide to add a button that does a thing, that is design. You made a decision to add a button with an icon or a label and where that button went and the size and color of that button. Decisions are designs.

  2. Design is not just, like, your opinion, man. Design is testable. One design will meet a specific goal better than another design. Consider different types of bicycles. A folding bicycle has a different set of design goals than a mountain bicycle. Things like weight, size, and tire tread are important factors in helping the intended user reach their goals. Because we understand that design is about solving specific problems, we must also understand that we can objectively compare the effectiveness of two designs at solving those problems.

  1. Design Is Not Veneer, Aral Balkan
  2. Design is Not Subjective, Jeff Law

Concision

Always work to make your app instantly understandable. The main function of your app should be immediately apparent. You can do this in a number of ways, but one of the best ways is by sticking to a principal of concision.

Avoid Feature Bloat

It's often very tempting to continue adding more and more features into your application. However, it is important to recognize that every new feature has a price. Specifically, every time you add a new feature:

Think in Modules

Build small, modular apps that communicate well. elementary 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).

Avoid Configuration

If possible, completely avoid presenting any settings or configuration in your app. Providing settings is usually an easy way out of making design decisions about an app's behavior. But just like with problems of feature bloat, settings mean more code, more bugs, more testing, more documentation, and more complexity.

Build for the "Out of The Box" Experience

Design with sane defaults in mind. elementary 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.

Ask the Operating System

Get as much information automatically as possible. Instead of asking a user for their name or their location, ask the system for this information. This cuts down on the amount of things a user has to do and makes your app look intelligent and integrated.

Do You Really Need It?

Ask yourself if the configuration option you are adding is really necessary or makes sense to a user. Don't ever ask users to make engineering or design decisions.

When You Absolutely Have To

Keep things contextual. Instead of tucking away preferences in a configuration dialog, think about displaying them in context with the objects they affect (much like how shuffle and repeat options appear near your music library).

If your app needs to be configured before it can be used (like a mail client), present this configuration inside the main window much like a Welcome Screen. Once again, make sure this is really necessary set-up. Adding unnecessary configuration screens stops users from doing what they wanted to do when they opened your app in the first place.


See Also:

  1. Checkboxes That Kill Your Product by Alex Limi
  2. Don't Give Your Users Shit Work by Zach Holman

Minimal Documentation

Most users don't want to read through help docs before they can use your app. Instead, they expect that your app will be intuitive and simple for them to understand without assistance.

Use Understandable Copy

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

Provide non-technical explanations instead of cryptic error messages. If something goes wrong, a simplified explanation of what happened and how to fix it should be presented. 


For more information, see Writing Style.

User Workflow

Visible design is a large part of the user experience, but so is the user's workflow, or how they interact with an app. In this section, we cover a few important steps of a typical workflow:

First-Launch Experience

Required Configuration

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 (like in Postler), they should be presented with a clean and simple welcome screen within the app (again, like Postler). Avoid separate configuration dialogs when launching.

Speed of Launch

Your app's first launch is the user's first impression of your app; it's a chance to really show off its design and speed. If your app has to configure things in the background before visibly launching, it gives the user the impression that the app is slow or will take a long time to start up. Instead, focus on making the application window appear fast and ready to be used, then do any background tasks behind the scenes. If the background task is blocking (ie. the user is unable to perform certain tasks until it's complete), show some type of indication that a background process is happening and make the blocked user interface items insensitive (see: Widget Concepts).

Welcoming the User

If there is no content to show the user, provide actions they can act upon by using a simple welcome screen. Allow them to open a document, add an account, import a CD, or whatever makes sense in the context of the app.

Resetting the App

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.

Normal Launch

When a user launches an app, they're performing an explicit action and expecting a fast, oftentimes immediate response. You should focus on three key areas for app launching: speed, obviousness of what to do next, and state.

Speed

As has been said before, speed, especially when launching an app, is very important. There should be as little delay as possible in between the time a user decides to launch an app and the instant they can begin using it. If your app requires a splash screen, you're doing it wrong.

Obviousness

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.

State

If the user has previously used your app, it's typically best to restore the state of the app when opening it again. This means the app comes up to right where the user left off so they can pick up their work again. For a music player, this means opening up with the view where the user left it and the song paused where the user closed the app. For a document editor, this would mean opening up with the same document scrolled to the same spot with the cursor in the same spot on the page.

Always Provide An Undo

Sometimes a user will perform an action which could possibly be destructive or traditionally irreversible. Rather than present the user with a warning, apps should allow the user to undo the action for an appropriate amount of time. Some prime examples of when this behavior is useful are:

This behavior should only as a last resort be implemented by providing a buffer time between when the app shows the user what happened and actually performing the action. To keep the experience responsive, the app should always look as if it performed the action as soon as the user initiates it. 

This behavior strikes the best balance of keeping out of the user's way while making sure they don't do something unintended. It's important to keep the undo action unobtrusive yet simple and intuitive; a common way of doing so is by using an info bar, though other methods may also be appropriate.


See also: Never Use a Warning When you Mean Undo by Aza Raskin

Always Saved

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

Apps in elementary 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.

For example, a Song Info dialog should update the track information instantly without a user having to press a save button, user preferences should be applied as soon as the user manipulates the relevant widget, and closing an app should mean that reopening it will return to where the user left off.

Closing

When a user closes an app, it's typically because they're done using it for now and they want to get it out of the way.

Saving State

Apps should save their current state when closed so they can be reopened right to where the user left off. Ideally closing and reopening an app should be indistinguishable from the traditional concept of minimizing and unminimizing an app; that is, all elements should be saved including open documents, scroll position, undo history, etc.

Background Tasks

If it makes sense for an app to complete background tasks after the window is closed, the tasks should be completed soon after the window is closed. If the app performs repeat background tasks (such as a mail client), the background tasks should be handled by a separate daemon that does not rely on the app itself being open.

Closing the App Window

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.

Re-Opening the App Window

If the user re-opens the app while the background process is still executing, the app should be exactly where it would be if the window had been open the whole time. For example, the terminal should show any terminal output, the music player should be on the same page it was when closed, and the browser should come back to the page it was on previously. For more details, see the discussion of app state on a Normal Launch.


See also: That's It, We're Quitting by Matthew Paul Thomas

Desktop Integration

An important advantage that developers have when choosing the elementary 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:

App Launchers

The primary method of discovering and using your app will be through an app launcher found in Slingshot or in the dock. In order to provide these launchers you must install an appropriate .desktop file with your app. This includes giving your launcher an appropriate name, placing it in the correct category, assigning it an icon, 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.

The contents of .desktop files should follow this formula:

Title is a(n) GenericName that lets you Comment.

Title

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, utilize the GenericName attribute of your app's .desktop file for a generic name, and the Comment attribute for a longer descriptive phrase.

GenericName

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.

The generic name should be in title case and may be used around the system to better describe or categorize your app. 

Comment

The system utilizes an app's Comment attribute found in the .desktop file to succinctly inform a user what can be done with the app. It should be a short sentence or phrase beginning with a verb and containing the primary nouns that your app deals with. For example, the following are appropriate comments:

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.

Categories

The following categories may be used to aid with searching or browsing for your app:

For more info, see the FreeDesktop.Org menu entry spec.

Keywords

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:

Keywords should be single words in title case and seperated with a semicolon.


See also: Desktop Entry Specification from FreeDesktop.org

Contractor

Contractor is a service and a protocol for exposing services easily between apps. It allows an app to interact with various other apps/services without hardcoding 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:

Displaying Results from Contractor

The most typical way to present Contractor results to users is in menu form. Keep in mind the following things when presenting contractor results:

Dock Integration

By integration with Pantheon's dock, apps are able to communicate their status to the user at a glance.

Progressbars

A progressbar must be unambiguous in it's use, referring to a single specific task. For example, a progressbar can be used to indicate the status of a file transfer or of a lengthy process like encoding. A progressbar should not be used to compound the progress of multiple types of actions.

Badges

A badge shows a count of actionable items which your app manages. It's 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.

System Indicators

Indicators are small icons that live on the top panel. They give users a place to glance for a quick indication of various settings or events. Clicking the icon shows a small menu with related actions available to the user.

Does Your App Need An Indicator?

The indicator area is notorious for becoming cluttered and having inconsistent behavior. Given that users will probably install many third party apps, we need to be careful about how many indicators we're showing and how they behave. Keep in mind that not every application needs an indicator. Only a very small set of apps will benefit from one. You do not need an indicator if:


See also: Farewell To The Notification Area by Matthew Paul Thomas

Container Widgets

Windows

Windows are the foundation that your app is built on. They provide a sort of canvas with basic actions built in such as closing an app, resizing it, etc. Although users may see all windows as being the same, there are several distinct types of windows in elementary OS. 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.

Window Titles

When dealing with window titles, consider that their main use is in distinguishing one window from another. A good window title will provide a description that helps a user make a selection. Keep that in mind as you consider the following:

Dialogs

A generic alert dialog

Alert Text

An alert contains both primary and secondary text.

The primary text contains a brief summary of the situation and offer a suggested action. This text should be displayed in a bold font that is slightly larger than the default.

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.

Button Order

"OK" is not Okay

When presenting a dialog to a user, always use explicit action names like "Save...", "Shut Down", etc. Consider that using "OK" enables users to proceed without understand 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 information presented before making a selection.

Preference Dialogs

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 allow the user to evaluate and possibly revert the change without having to close and re-open the preference dialog.


See also:

  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.

Toolbars

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 it's use and organization.

Ordering Toolbar Items

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

Widget Concepts

Before we get into all the widgets available in elementary OS, we need to cover some basic concepts that apply to all widgets. Employing these concepts correctly will create a more seamless experience for your users and help you avoid sifting through bug reports!

Controls That Do Nothing

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. 

Sensitivity

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 allow a user to click the "Forward" button in a browser 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".

Hidden Widgets

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.

Spacing

Alignment


See also: Form Label Proximity: Right Aligned is Easier to Scan by UX Movement

Infobars

Infobars provide contextual information and actions to the user with varying levels of severity.

It is important to determine the severity or type of infobar to use. There are four types of infobars available:

Welcome Screen

The Welcome Screen is a friendly way to help users get started with your app.

Usage

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.

Make sure that if your app allows its library to be cleared that the Welcome Screen is shown again instead of an empty list.

Labeling

The Welcome Screen consists of two sets of labels:

Iconography

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.

Source List

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 allows the user to 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.

Hierarchy

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. 

Buttons

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

Tool Buttons

Labeling

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

Tooltips

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.

Text Buttons

Labeling

Text Button labels should be done in Title Case.

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 uses incorrect capitalization and unnecessary punctuation. With the other two labels, It's not very clear what will happen when these buttons are clicked.

Tooltips

Since Text buttons have a clear and explicit label, it's usually unnecessary to give them a tooltip.

Linked Buttons

Usage

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.

Labeling

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


  1. Why The OK Button Is No Longer Okay by UX Movement
  2. Should I use Yes/No or Ok/Cancel on my message box? on UX StackExchange

AppMenu

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.

Usage

You should first consider if your app needs this widget. While most apps may have one, your app may not necessarily need an AppMenu.

When adding items to your AppMenu, consider the following:

Search Fields

Apps that support the searching or filtering of content should include a search field on the right side of the app's toolbar (to the left of the AppMenu). 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.

Behavior

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:

Labeling

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

Checkboxes

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

Usage

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.

Labeling

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

Switches

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

Usage

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.

Labeling

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 allow showing one of multiple pages in an app, also colloquially referred to as "tab bars."

Static Notebook

A Static Notebook is a small set of unchanging tabs, commonly seen in preferences or settings screens. The tabs appear as linked buttons centered at the top of the content area. A Static Notebook should typically contain two to five tabs.

Dynamic Notebook

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.

Icons

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.

Style

elementary Icons have a distinctive visual style that is inspired in part by the Tango Icons. Icons on elementary share several common design elements.

Design Elements

Shape

Icons should have a distinctive shape/silhouette to improve recognition. The shape should not be too complicated, but not every icon should be a rounded rectangle.

Outline

All elementary Icons, and shapes within the icons, are stroked with a thin outline to improve contrast. At low resolutions the stroke size is 1px. The stroke should not scale along with the icon, it should remain 1px.

The color of the outline is a dark variant of the key color of the icon. This is done by creating a stroke at 30% opacity of black such that the border of the background lines up at half pixels. This is what allows icons with a stroke to appear sharp on dark backgrounds as well as light ones.

Highlights

The edges of objects tend to reflect light more due to the fact the position of the observer relative to the light source is almost always ideal for the reflection. We produce a subtle second inner outline of the object as a highlight. This stroke is very subtle and may not be apparent on some matte objects.

Limited glossy reflections

Use glossy reflection only on objects that have a reflective surface in real life (plastic, glass, some metal, et cetera). A sheet of paper should not be glossy.

Lighting and Perspective

elementary Icons have a consistent light source and perspective to keep a similar look throughout the system. The icons have been designed with the UI theme in mind, meaning everything shares a cohesive feel and a subtle amount of realism.

Lighting

Icons are lit from above. Items may produce a small, fuzzy shadow toward the bottom of the icon as if the icon is sitting on a shelf facing the user.

Perspective

Icons should have the perspective of looking at an object on a shelf at eye level. This means the icons are front-on, not from above and not tilted to the side. This also has an effect of giving icons slightly less depth than their real-world counterparts.


Portions of this page have been adapted from the Tango Icon Theme Guidelines.

Launcher Icons

A launcher icon is a graphic that represents your app. Launcher icons appear in the app launcher and on the user's dock. Launcher icons may show up in other places in the OS, such as in a notification or when being referenced by another app.

You should create separate icons for all possible display sizes, including 32, 48, 64, and 128 pixels. This ensures that your icons will display properly throughout the OS without being blurry or oddly weighted.

Goals of the Launcher Icon

App launcher icons have three primary goals:

  1. Promote the brand and tell the story of the app.
  2. Help users discover the app in the software center.
  3. Function well in the OS.

Promote the brand story

App launcher icons are an opportunity to showcase the brand and hint at the story of what your app is about. Thus, you should:

Help users discover the app in the software center

App launcher icons are the first look that prospective users will get of your app in the software center. A high quality app icon can influence users to find out more as they scroll through lists of apps.

Quality matters here; a well-designed icon can be a strong signal that your app is of similarly high quality. Consider working with an icon designer to develop the app’s launcher icon.

Function well in the OS

A successful app launcher icon will look great in all situations: on near-white when in the the app launcher, partially over any background when on the dock, and next to any other icons and app widgets. To do this, icons should:

Do's and Don'ts

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


Portions of this page are derived from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.

MimeTypes

MimeType icons are used to visually represent files and types of files. Users will come across them in the file browser and when saving or opening a file.

Actions

Action icons are graphics used to represent user actions. Action icons are most commonly found in app toolbars, but can be found throughout the OS.

If your app has an action that can be described by an existing system action icon, reference that icon. This ensures a consistent user experience and aids in user recognition of common functions.

If your app has a unique action not easily described by an existing icon, you may need to create your own icon. Follow the look and feel of existing system icons and install the icon along with your app.

Size and Alignment

Icons come in all kinds of shapes. To keep a coherent flow, we try to adopt principals of type design when sizing and aligning our icons. For a 48px icon, we do as follows.

X-Height and Base Line

A 48px icon as an x-height of 40px. The base Line starts 3px above the bottom of the canvas.

Mean Line

The mean line goes right through the center of the canvas. Its primary use is in aligning floating elements. If an element's height is an odd number, align 1px below the mean line.

Ascent and Descent

Some icons need to extend past the X-height. Your standard ascenders and descenders should be just 2px past the x-height. This is useful when you need to use more space to convey the same overall area (such as with circle icons) or you need to overlay a smaller icon (such as when conveying an action performed on an object).

Exceptions

Not every icon follows the rules perfectly. Mimetype icons ascend to the top of the canvas.

If you need to break the rules, you can still use the established lines to keep with the general cadence.

Scaling

Contrary to popular belief, you cannot supply a single high resolution version of an icon and expect it to scale properly. Your icon will appear blurry or heavy and may have illegible pieces. It is always best to begin designing an icon at it's expected display size (which will be provided for you as we talk about different kinds of icons).

Text

Although elementary 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 platform.

Writing Style

Use the following rules to keep your text understandable and consistent:

Be Brief

Don't give the user a bunch of text to read; a lengthy sentence can appear daunting and may discourage users from actually reading your messaging. Instead, provide the user with short and concise text.

Think Simple

Assume the user is intelligent, but not technical. Avoid long, uncommon words and focus on using common, simple verbs, nouns, and adjectives. Never use technical jargon.

Get To The Bottom Line

Put the most important information at the beginning of your text. If the user stops reading, they'll still have what they need in mind.

Don't Repeat Yourself

Repetition can be annoying and adds unnecessary length to your messaging.

Use Visual Hierarchy

Visual hierarchy aids users in reading and comprehending your text as well as knowing what is most important. Use headings and other text styles appropriately.

Language

While much of elementary 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:

Capitalization

All textual user interface items, including labels, buttons, and menus, should use one of two capitalization styles: sentence case or title case.

Sentence Case

Sentence case means you capitalize like in a standard sentence or phrase.

Only the first letter of the phrase and the first letter of proper nouns are capitalized. Used for labels and descriptive text.

Title Case

Title case means you capitalize like a book or article title.

Capitalize the first and last words. All nouns, pronouns, adjectives, verbs, adverbs, and subordinate conjunctions (as, because, although) are capitalized. Used for titles, buttons, menus, and most other widgets.

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.

Punctuation

Proper typography is important throughout elementary OS. Not just for consistency within the OS, but for following proper convention and presenting ourselves as a serious, professional platform.

Prevent Common Mistakes

Hyphens & Dashes

Hyphen (-)

Use \u2010 in code. Used for:

En Dash (–)

Use \u2013 in code. Used for:

Em Dash (—)

Use \u2014 in code. Used for:


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

These rules apply to the English language; other languages may have their own conventions which should be followed by translators.

Using Ellipsis

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.

Additional Information

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:

Shortened Text

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 that it's been truncated. 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.

When Not to Use Ellipsis


Be sure to use the actual ellipsis character (…) rather than three consecutive period (.) characters.

Naming Menu Items

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.