Рекомендации по дизайну интерфейса

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:

Чтобы помочь вам достичь этих целей, руководство охватит основные элементы интерфейса — как эффективно использовать их вместе и как удачно интегрировать ваше приложение с окружением рабочего стола. Главное помнить, что данное руководство сделает процесс создания нового приложения легче, а не сложнее.

Однако имейте в виду, что это рекомендации, а не свод правил. Новые, потрясающие парадигмы взаимодействия появляются каждый день и многие из них только предстоит открыть. Это «живой» документ, который может и будет меняться.

Для разделов, о которых еще не было написано, пожалуйста, обратитесь к GNOME HIG

Философия дизайна

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

Мифы о дизайне

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. Дизайн — это не что-нибудь, что вы добавляете после того, как завершили разработку продукта. Осознаете вы или нет, но в процессе разработки вы постоянно «дизайните». Это неотъемлемая часть создания чего-либо. Дизайн — это не просто внешний вид. Это не просто цвета и шрифты. Дизайн — это принцип работы. Когда вы решаете добавить кнопку для какого-то действия, то это дизайн. Вы принимаете решение выделить кнопку иконкой или размером и цветом. Решения — это дизайн.

  2. Дизайн — это не только твое мнение, чувак. Дизайн проходит тестирование. Один дизайн решит определенную задачу лучше, чем другой. Рассмотрим разные типы велосипедов. Складной велосипед предназначен для решения определенных задач, отличных от задач горного велосипеда. Такие вещи как вес, размер и рисунок протектора шин являются важными факторами в достижении целей конечного пользователя. Хотя мы понимаем, что дизайн — это решение конкретной задачи, нужно также понимать, что мы можем объективно сравнивать эффективность двух разных дизайнов в решении определенных задач.

  1. Дизайн — это не только внешность. — Арал Балкан (Aral Balkan)
  2. Дизайн не субъективен. — Джефф Ло (Jeff Law)

Краткость

Всегда делайте приложение понятным. Главная функция приложения должна быть ясна с первого взгляда. Перед вами несколько путей, но к лучшему всегда ведет краткость.

Меньше функций — меньше проблем

Велик соблазн добавлять в программу новые и новые возможности. Однако важно помнить: всему своя цена. В часности, каждый раз, когда вы дарите своему детищу новую «фичу»:

Мыслите модулями

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

Меньше настроек

Если это возможно, избегайте предоставления любых настроек или конфигураций в вашем приложении. Реализация настроек — это легкий способ уйти от самостоятельных дизайнерских решений. Но вместе с этим приходят не только такие проблемы, как раздувание функциональности программы, но и увеличение количества кода, багов, необходимости дополнительного тестирования и общего увеличения сложности приложения.

Разрабатывайте по принципу «из коробки»

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.

Обращайтесь к операционной системе

Получайте информацию автоматически насколько это возможно. Вместо того, чтобы спрашивать у пользователя его имя или местоположение, спросите это у системы. Это сократит количество действий, которые должен сделать пользователь и даст вашему приложению вид умного и интегрированного в систему.

Вам действительно это нужно?

Задайте себе вопрос, нужны ли опции, которые вы добавляете и имеют ли они смысл для пользователя. Никогда не задавайте пользователю вопросы, связанные с устройством программы или ее дизайном.

Когда это действительно нужно

Всякие вещи должны быть в контексте. Вместо того, чтобы прятать настройки в диалоговые окна, подумайте над тем, чтобы отображать их в контексте объекта, на который они влияют (подобно тому, как функции перемешивания и повторения, находятся рядом с музыкальной библиотекой).

Если ваше приложение нуждается в настройке перед использованием (как например почтовый клиент), разместите эти настройки внутри главного окна, как на экране приветствия. Еще раз убедитесь, что эти настройки необходимы. Добавление ненужных экранов настроек отвлекает пользователей от того, что они хотели делать, изначально открывая ваше приложение.


Смотрите также:

  1. Флажки, которые убивают ваш продукт от Алекса Лими (Alex Limi)
  2. Не давайте вашим пользователям дерьмовой работы от Зака Холмана (Zach Holman)
  3. Мастер антишаблонов от Стефа Уолтера (Stef Walter)

Минимум документации

Большинство пользователей не хотят читать документацию перед использованием приложения. Вместо этого, они ожидают, что ваше приложение будет интуитивным и простым для понимания без посторонней помощи.

Используйте понятные выражения

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

Предоставьте пользователю понятные разъяснения нетехнического характера вместо загадочных сообщений об ошибках. Если что-то пошло не так, должно быть предоставлено упрощенное описание того, что произошло, и как это исправить.


Для получения дополнительной информации смотрите стиль написания.

Рабочий процесс пользователя

Видимый дизайн является основной частью общих впечателний пользователя, но также он определяет его рабочий процесс или другими словами — как пользователь взаимодействует с приложением:

Опыт первого запуска

Необходимость настройки

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.

Скорость запуска

Первый запуск вашего приложения — это первое впечатление пользователя о нем, это шанс блеснуть его дизайном и скоростью. Если ваше приложение должно что-то настраивать в фоновом режиме перед запуском, то создается впечатление, что приложение медленное или ему требуется много времени для старта. Вместо этого сосредоточьте внимание на том, чтобы окно приложения появлялось быстро и было готово к работе, и только затем выполняйте фоновые задачи. Если фоновая задача является блокирующей (т. е. пользователь не может выполнять определенные задачи до ее завершения), выведите информацию о том, что выполняется фоновая задача, а также сделайте неактивными элементы интерфейса, отвечающие за заблокированные функции (см. концепты виджетов).

Приветствие пользователя

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

Сброс приложения

Если пользователь явно «сбрасывает» приложение (например удаляет все песни из музыкальной библиотеки или удаляет все аккаунты в почтовом клиенте), то это должно привести приложение в состояние первого запуска.

Повседневный запуск

Когда пользователи запускают приложение, они производят очевидные действия и ожидают быструю, чаще всего немедленную реакцию на них. Вы должны сфокусироваться на трех ключевых областях при запуске приложения: скорость, очевидность дальнейших действий и состояние приложения.

Скорость

Как было сказано ранее, скорость очень важна, особенно при запуске приложения. Задержка между тем, когда пользователь решает запустить приложение, и когда оно готово к работе, должна быть настолько мала, насколько это возможно. Если ваше приложение нуждается в экране загрузки, то вы делаете его неправильно.

Очевидность

При запуске вашего приложения пользователи должны точно знать, к чему приступать дальше. Достигайте этого благодаря интерактивным руководствам (при условии, что ваше приложение совместимо с другими) и предложениям по пошаговым действиям: от подготовки до запуска. Если в приложении есть какие-либо "вещи": музыка или электронная почта – отобразите их для пользователей и откройте к ним доступ. В случае отсутствия предварительно отрытых окон, позвольте пользователям создать новые предметы (например, документы), используя приветственное окно.

Статистика

Если пользователь уже работал с вашим приложением, лучше при новом запуске вернуть его к тому месту, из которого он выходил. Для музыкальных проигрывателей это значит открыть последние прослушанные им мелодии и/или записи, поставленные на паузу. Для редакторов документов – открытие того же файла с точным местом на странице, и помещение курсора мышки в место последнего пребывания, с которого был произведен выход.

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 let the user undo the action for an appropriate amount of time. Some prime examples of when this behavior is useful are:

Данное поведение рассчитано на использование в крайних случаях и реализуется за счет запаса времени между тем, что приложение показывает пользователю и тем, что оно действительно выполняет. Чтобы сохранить отзывчивость, приложение должно всегда отображать действия пользователя сразу же, как только пользователь их выполняет.

Этот механизм демонстрирует наилучший способ держать пользователя подальше от необдуманных действий. Важно сохранить отмену действий ненавязчивой, но в то же время простой и интуитивно понятной; основной способ сделать это - использовать информационную панель, хотя другие методы также могут подойти.


Смотрите также: Never Use a Warning When you Mean Undo by Aza Raski

Всегда Сохранять

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

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

Например, диалоговое окно информации Музыка должно обновлять информацию о треке мгновенно без необходимости нажатия пользователем кнопки сохранить, пользовательские настройки должны быть применены, как только пользователь осуществляет действия с соответствующим виджетом, и закрытие приложения должно означать, что возобновление его работы будет возвращено к точке, где пользователь остановился.

Закрыто

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.

Сохранение состояния

Приложения должны сохранять их текущее состояние после закрытия, для того что бы запустив их заново пользователь лицезрел их в сохраненном состоянии. В идеале закрытие и повторное открытие приложения должны быть неотличимы от традиционной концепции минимизации и унимизации приложения; то есть, все элементы должны быть сохранены в том числе открытых документов, их положение прокрутки, история отмен и т.д.

Фоновые задачи

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.

Закрытие окна приложения

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.

Открыть заново окно приложения

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.


Смотрите также: Мы закончили Мэтью Пол Томас

Интеграция рабочего стола

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

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.

Содержимое файлов рабочего стола должно соответствовать формуле:

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

Название

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

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. 

4. Комментарии

The system uses 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.

Категории

The following categories may be used to aid with searching or browsing for your app. Keep in mind that you can add more than one and you should add all that apply:

Больше информации на FreeDesktop.Org menu entry spec.

Ключевые слова

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) separated by semicolons.


See also: Desktop Entry Specification from 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:

Отображение результатов Подрядчика

Contractor results are typically presented to users in menu form. Keep the following in mind when presenting Contractor results:

Интеграция с панелью быстрого запуска

Integrate your app with Pantheon's dock communicate to communicate its status to the user at a glance.

Индикаторы выполнения

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.

Значки

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.

Системные индикаторы

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


See also: Farewell to the Notification Area by Matthew Paul Thomas

Контейнер Виджетов

Windows

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.

Заголовок окна

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:

Диалоги

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
Отменить
Suggested Action

Предупреждение

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

Порядок кнопок

"Ок" это не Окей

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.

Диалоговое окно настроек

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.


Смотри также:

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

Панель инструментов

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.

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 Элементы инструментария

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.

Концепт виджета

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!

Элементы управления, которые ничего не делают

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. 

Чувствительность

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

Скрытые Виджеты

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.

Интервал

Выравнивание


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

Информационные панели

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:

Экран Приветствия

Экран приветствия поможет пользователям начать работать с вашим приложением.

Использование

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.

Ярлыки

Экран приветствия состоит из двух ярлыков.

Иконография

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.

Список источников

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.

Разделы

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.

Иерархия

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 are an incredibly important widget to understand since your app will undoubtedly contain them. 

Tool Buttons

Ярлыки

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

Подсказки

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 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 has incorrect capitalization and unnecessary punctuation. The other two labels do not indicate what will happen as a result of clicking the button.

Подсказки

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

Связанные кнопки

Использование

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.

Ярлыки

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 является дополнительным меню, которое открывается по значку шестеренки в дальнем углу приложения инструментов. Она обеспечивает соответствующие пункты меню в место традиционного "Файл, Правка, Вид..." в строке меню.

Использование

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

Если добавляете элемента на AppMenu, соблюдайте следующее:

Поисковое поле

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.

Distinguish Between Search and Find

Search is for filtering the contents of a library, i.e. Music or Videos, to the matching items. Search is typically initiated when typing anywhere in a library view.

Find is for highlighting matching instances of a string, i.e. in a text editor, web page, or Terminal. It is triggered by a keyboard shortcut (Ctrl+F) or with a search icon. The find bar appears in a revealer below the headerbar with relevant actions such as find next, find previous, highlight all, etc. The revealer may also contain other relevant actions such as replace or go to line.

Поведение

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:

Ярлыки

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 present a way for users to select items from a list.

Использование

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.

Ярлыки

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

Переключатели

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

Использование

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.

Ярлыки

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 are a type of widget that lets apps show one of multiple pages (also colloquially referenced as "tab bars").

Статический блокнот

Статический блокнот - это маленький набор неизменных вкладок, в основном наблюдаемых в параметрах или настройках дисплеев. Вкладки выглядят как связанные кнопки по центру в верхней части области содержимого. В основном статический блокнот содержит от двух до пяти вкладок.

Динамический блокнот

Динамический блокнот - это способ наделения приложений функциональностью управляемых вкладок, в основном наблюдаемый в веб-браузерах. Вкладки представлены прикрепленными к панели инструментов на собственной панели вкладок над соответствующим содержимым. Вкладки возможно переставлять и закрывать, также кнопка "новая вкладка" расположена слева от виджета блокнота.

Иконография

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.

Образ

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.

Значок предупрежденийЗначок чатаЗначок ФотографийЗначок ВидеоЗначок учётных записей в ИнтернетеЗначок Терминала

Metaphors

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.

Значок КамерыЗначок жесткого дискаЗначок КурсораЗначок ПакетовЗначок HTML текстаЗначок Компьютера

Значки действия

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.

Значок НазадСледующее изображениеDocument export iconPrint iconSave iconDelete iconCut iconUndo iconInverse iconPlay iconNew tag iconMenu icon

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.

Размеры значков

elementary OS uses six main icon sizes throughout the OS and it's best to include all six as part of your application.

16 pixel Terminal icon24 pixel Terminal icon32 pixel Terminal icon48 pixel Terminal icon64 pixel Terminal icon128 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.

Цветовая палитра

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.

Mail iconRSS Reader iconWeb browser iconЗначок ФотографийNetwork iconCalendar icon

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.

Symbolic vs. colored icon

Colored vs. Symbolic Icons

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

Full color icons are best used for:

Symbolic icons are best used:

Структура

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.

Общие размеры

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.

Размер холста Base Line -Высота 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

Исключения

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 оранжевый.)

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.

Outlines & Contrast

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

Example of contrast in elementary OS Calendar icon 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.

Тени и подсветка

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

Drop Shadow

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.

Материалы значка

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.

Dos and Don'ts

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

Текст

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.

Стиль написания

Используйте следующие правила, чтобы ваш текст выглядел чётким и понятным:

Будьте кратки

Не давайте пользователю кучу текста сразу: длинные предложения могут оттолкнуть от чтения. Пишите кратко и лаконично.

Мыслите просто

Допускайте, что пользователь умный, но не технически. Избегайте длинных и необычных слов, сосредотачивайтесь на использовании общих, простых глаголов, существительных и прилагательных. Используйте простые конструкции. Никогда не используйте технический жаргон.

Get To The Bottom Line

Помещайте важную информацию вначале текста. Если пользователь прекратит читать, он уже будет знать то, что нужно.

Не повторяйтесь сами

Повторения раздражают и добавляют лишнюю длину вашему тексту.

Используйте визуальную иерархию

Визуальная иерархия помогает читать и понимать текст. Используйте заголовки и другое форматирование.

Язык

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:

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.

Примечания / исключения

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.

Знаки препинания

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

Дефисы & Прочерки

Дефис (-)

Используйте \u2010 в коде. Используется для:

Короткое тире (–)

Используйте \u2013 в коде. Используется для:

Длинное тире (—)

Use \u2014 in code. Used for:


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

Эти правила применимы к английскому языку. Другие языки могут иметь свои особенности, которые должны соблюдаться профессиональными переводчиками.

Using Ellipses

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.

Дополнительная информация

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:

Сокращенный Текст

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.

Если не использовать многоточие


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

Именованные элементы меню

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.