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

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. Design Is Not Veneer, Aral Balkan
  2. Design is Not Subjective, 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).

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

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

Build for the "Out of The Box" Experience

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

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

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

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

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

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

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

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


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

  1. Checkboxes That Kill Your Product от Alex Limi
  2. Don't Give Your Users Shit Work от Zach Holman
  3. The Wizard Anti-Pattern от 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.

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

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

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

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

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

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.

Обычный запуск

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

Скорость

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

Очевидность

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.

Состояние

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

Возможность всегда отменить

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

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

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


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

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

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.

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

Закрытие

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

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

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

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

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

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

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.

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

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


Смотрите также: That's It, We're Quitting от Matthew Paul Thomas

Интеграция с окружением

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:

Лаунчеры приложений

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

.desktop файлы следуют спецификациям freedesktop.org (Desktop Entry Specification). Они должны быть установлены в /usr/share/applications. Пользователи могут создавать свои собственные лаунчеры, размещая .desktop файлы в ~/.local/share/applications.

Содержимое .desktop файлов должно соответствовать следующей формуле:

Название (Title) — это имя (GenericName)которое позволяет оставить комментарий (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, 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.

Общее название должно быть написано в «title case».

Comment

Система использует атрибут приложения Comment (найденный в файле .desktop) для краткого информирования пользователя о том, для чего предназначено приложение. Это должна быть короткая фраза или небольшое предложение, описывающее ваше приложение. Например:

Комментарий должен быть написан в «sentence case», не должен содержать точек, восклицательных или вопросительных знаков, должен быть коротким и описывать основное назначение приложения.

Категории

Следующие категории могут быть использованы для помощи в поиске вашего приложения:

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

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:

Ключевые слова должны являться отдельными словами (в «title case») и разделяться точкой с запятой.


Смотрите также спецификации Desktop Entry на FreeDesktop.org

Contractor

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

Отображение результатов Contractor

Как правило результаты Contractor предосталяются пользователю в виде меню. При предоставлении этих результатов имейте ввиду следующее:

Интеграция с док-панелью

Интеграция вашего приложения с док-панелью даст пользователю наглядное представление о своем текущем статусе.

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

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

Значки уведомлений

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

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

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

Нужен ли вашему приложению индикатор?

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

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

Если обратить внимание на заголовки, то хороший позволяет пользователю сделать правильный выбор. Обдумайте следующее:

Диалоги

24
Значок диалога-предупреждения

Основной текст содержит базовую информацию и рекомендации

Второстепенный текст предоставляет детали, также включает в себя информацию о неочевидных последствиях.

24
Отмена
Рекомендуемые действия

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

Предупреждение содержит основной и второстепенный текст.

Текст резюмирует ситуацию и рекомендует определенное действие. Должен использоваться класс CSS primary.

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

Оба текста должны быть выделяемыми для копирования например в почтовое сообщение.

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

"OK" is not Okay

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

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

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

Всплывающие окна

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

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

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

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

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.

Очередность элементов панели инструментов

Наиболее важные элементы должны располагаться слева, AppMenu — всегда на правом краю панели. Если элементов много, можно разделить их на группы, разделяя их пространством. Помните, что при использовании языков, читаемых справа налево, панель должна быть соответственно перевернута.

Элементы пользовательского интерфейса в панели инструментов

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.

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

Рассмотрим основные концепции, применимые ко всем виджетам elementary OS. Их применение создает целостную концепцию для восприятия пользователем и сокращает количество сообщений об ошибках!

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

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

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

Когда виджет нужен только в определенном случае (не как индикатор процесса) иногда лучше скрыть его. В системных требованиях не нужно показывать возможности для нескольких дисплеев, если используется один. Оставлять в каком случае ненужное — не практично. Другой пример с кнопкой «Стереть» описан выше.

Расстояния

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


Смотрите на английском: Form Label Proximity: Right Aligned is Easier to Scan by UX Movement

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

Информационные панели предоставляют контекстуальную информацию разной степени потенциальной опасности и действия для пользователя.

Важно обозначать степь, отсюда четыре типа инфо-панелей:

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

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

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

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

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

Метки

Экран приветствия состоит из двух групп меток:

Иконография

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

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

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

Разделы

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.

Избегайте помещения расширяемых разделов в списке источников или можно переделать отображение разделов.

Иерархия

Иерархия виджетов и вообще в рамках приложения в списках источников также важна.

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

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

Кнопки

Кнопки без сомнений необходимы для приложения и потому важны для понимания.

Кнопки инструментов

Метки

Такие кнопки представляют собой значки и не содержат надписей.

Подсказки

Все они должны иметь всплывающие подсказки. Это поможет пользователям с проблемами со здоровьем и просто объяснит значение непонятного значка.

Подсказки должны четко объяснять функцию кнопки — что произойдет при нажатии.

Кнопки с текстом

Метки

Каждое слово в названии кнопки должно начинаться с заглавной буквы.

Также как и элементы меню, кнопки с текстом должны содержать информацию о «действии» или «направлении», но не о статусе. Убедитесь, что надпись на кнопке четко описывает что произойдет при нажатии.

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

Подсказки

Для кнопок с текстом не нужны всплывающие подсказки.

Кнопки вида

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

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

Метки

Также они не должны содержать цветных значков. Только 16px символические значки или текст. Не используйте и значки и текст.


  1. Советы на английском Why The OK Button Is No Longer Okay от UX Movement
  2. Should I use Yes/No or Ok/Cancel on my message box? on UX StackExchange

Меню приложения

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.

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

Примите решение, — нужен ли виджет вашему приложению. Хотя многие имеют, вашему приложению AppMenu может быть не нужен.

При добавлении элемента в AppMenu соблюдайте следующее:

Поле поиска

Приложения, поддерживающие поиск или фильтрация должны включать в себя поле поиска в правой части панели инструментов. Пользователь запоминает расположение и в будущем видит поддерживает или нет приложение поиск. GTK+ предоставляет удобный и продвинутый виджет для этой цели Gtk.SearchEntry

Различия между «Искать» и «Найти»

«Искать» подходит для поиска совпадающих элементов в библиотеках, например с музыкой или видео.

«Найти» — для подсветки найденных частей строк, например в текстовом редакторе, веб-странице, терминале. Вызывается сочетанием клавиш (Ctrl+F) или с помощью значка. Панель поиска всплывает внизу экрана и содержит такие действия: найти следующее совпадение, предыдущее совпадение, подсветить все совпадения и т. п. Также могут присутствовать возможность замены, перехода к строке.

Поведение

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

Метки

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

Флажки

Флажки предоставляют возможность для пользователя выбрать из списка.

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

Используйте флажки для выбора элементов. Убедитесь что пользователь может их переключать по клику на названии, связанным с флажком.

Метки

Они должны быть существительными, либо фразами

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

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

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

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

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


Смотрите советы от UX Movement здесь

Записные книжки

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

Статическая записная книжка

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

Динамическая записная книжка

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.

Иконография

Иконография является ключеной частью elementary OS. Значки состовляют основную часть пользовательского интерфейса, с которой пользователь взаимодействует. Они приносят жизнь в систему и задействуют мощный механизм распознования в мозгу человека.

Форма

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

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

Метафоры

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

Значок фотоаппаратаЗначок жесткого дискаЗначок мышиЗначок пакетаЗначок 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.

Значок НазадЗначок СледующееЗначок экспортирования документаЗначок печатиЗначок сохраненияЗначок удаленияЗначок вырезанияЗначок отменыЗначок инвертированияЗначок воспроизведенияЗначок нового тегаЗначок меню

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

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

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

В elementary OS используется шесть основных размеров значка, их следует включить в ваше приложение.

16-пиксельный значок терминала24-пиксельный значок терминала32-пиксельный значок терминала48-пиксельный значок терминала64-пиксельный значок терминала128-пиксельный значок терминала
16 24 32 48 64 128
128-пиксельный значок терминала
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.

Значок почтыЗначок RSS-агрегатораЗначок веб-браузераЗначок ФотографииЗначок сетиЗначок календаря

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

Символические значки

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

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

Символический или цветной значок

Цветной или символический значок

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

Полноцветные значки следует использовать для:

Символические значки следует использовать для:

Структура

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

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

Стандартные размеры

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

Размер холста Базовая линия x-Высота Высота средней линии
16x16 1 14 8
24x24 2 20 12
32x32 2 26 16
48x48 3 40 24
64x64 4 56 32
128x128 9 104 64

Исключения

Есть исключения. У многих значков (особенно значков mimetypes) есть «восходящие» и «нисходящие» элементы, которые выходят за рамки линий x-высоты и базовой линии соответственно (показаны здесь оранжевым.)

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

Значки с закруглениями нуждаются в выходе за рамки базовой линии и линии x-высоты для компенсации за оптическую иллюзию - они выглядят меньше объектов прямоугольной формы.

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 Пример контраста значка параметры системы elementary

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

Shadows & Highlights

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

Подсветка края

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

Edge highlight example in elementary OS Music icon

Отбрасывание тени

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

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

Тень пиктограммы

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

Делаем тень: копируем пиктограмму, заполняем ее черным цветом, устанавливаем 15% непрозрачности, сдвигаем на 1 пиксель вниз от оригинальной пиктограммы, не смещая накладываем оригинальную пиктограмму поверх черной, копируем тень, устанавливаем контур в 1 пиксель, применяем на этом элементе 7% непрозрачноти.

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

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

Можно и нельзя

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.

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

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

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

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

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

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

Зри в корень

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

Не повторяйтесь

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

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

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

Язык

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:

Использование заглавных букв

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

Sentence Case

Предложение начинается с заглавной буквы.

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

Title Case

Этот стиль означает использование прописных букв как в названии книги или статьи.

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

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

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.

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

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

Избегайте ошибок

Hyphens & Dashes

Дефис (-)

Используйте \u2010 в коде. Применяется для:

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

Используйте \u2013 в коде. Применяется для:

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

Используйте \u2014 в коде. Применяется для:


Для справок: Butterwick's Practical Typography.

Справочно-информационный портал.

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

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

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

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

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

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:

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

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


Используйте (…), а не три (.).

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

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

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