We're Crowdfunding on IndieGoGo Back Us

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Первый запуск

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

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 или что-либо еще в контексте приложения.

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

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

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

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

Скорость

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

Очевидность

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

Состояние

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

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

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

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

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


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

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

Люди должны чувствовать себя уверенно при использовании elementary. Они должны знать, что все, что они видят — сохранено и актуально.

Приложения в elementary должны всегда функционировать вокруг «всегда сохраненного» состояния. Это означает, что изменения, вносимые пользователем, применяются и становятся видны мгновенно. Сохранение изменений вручную является устаревшим методом и может применяться только в исключительных случаях.

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

Закрытие

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

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

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

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

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

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

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

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

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


Смотрите также: 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. 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

Вы не должны включать описание в заголовок. Например, Dexter это «Dexter», а не «Dexter Address Book». Midori это просто «Midori», а не «Midori Web Browser». Вместо этого используйте атрибут GenericName в файле .desktop для общего названия и атрибут Comment для описательной фразы.

GenericName

Если приложение легко описывается общим названием, вы должны использовать его для атрибута GenericName в .desktop файле. Скажите «Мое приложение — это ____» и то, что можно поставить взамен пропуска, может быть названием. Например Maya — это календарь, а его общее название «Календарь».

При использовании английского языка вы не должны употрелять артикли (the, a, an) и слова «program», «app» или «application» в общем названии вашего приложения.

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

Comment

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

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

Категории

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

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

Keywords

Вы также можете включить ключевые слова в ваш лаунчер для облечения поиска вашего приложения. Это соответствует конвенции «X-GNOME-Keywords» (для лаунчера приложения) и «X-AppInstall-Keywords» (для установщика приложения). Например, веб-браузер может включать ключевое слово «Internet», несмотря на то, что его нет ни в имени приложения, ни в общем названии, ни в описании приложения. Если пользователь будет искать «Internet», он найдет ваше приложение. Еще примеры:

Ключевые слова должны являться отдельными словами (в «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.

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

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

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

«Хорошо» — не хорошо

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. Их применение создает целостную концепцию для восприятия пользователем и сокращает количество сообщений об ошибках!

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

Общая ошибка для разработчиков — создание ненужных элементов, которые ничего не делают. Запомните, мы хотим предоставить рабочую среду, где пользователь чувствует себя уверенно. Он взаимодействует и ожидает немедленного ответного действия. Когда это не так, появляются мысли: «А что собственно я только что сделал?!». Избегайте лишнего и не создавайте ненужную сложность в интерфейсе.

Рассмотрим кнопку «Очистить» в поле поиска. Она должна появляться при необходимости. Не имеет смысла нажимать на нее, если стирать нечего, т. к. поле пусто.

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

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.

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

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

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

Расстояния

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


Смотрите на английском: 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.

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

Иерархия

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

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

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

Кнопки

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

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

Метки

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

Подсказки

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

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

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

Метки

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

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

«Удалить Аккаунт», «Копировать в ноутбук Васи» и «Импортировать 20 Песен» — хорошие значки.

"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

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

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

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

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

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

Поле поиска

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

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

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

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

Поведение

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

Метки

Поля для поиска должны содержать подсказки для поиска. Информация о настройке: "placeholder_text".

Формат для полей поиска должен быть таким: «Искать ОБЪЕКТЫ», где ОБЪЕКТЫ — это контакты, аккаунты и т. п.

Если происходит взаимодействие между полем поиска и поисковиками, то текст подсказки должен содержать их название: «Яндекс», «Google».

Флажки и переключатели

Флажки

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

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

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

Метки

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

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

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

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

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

Например «Записать с микрофона» — это прекрасный кандидат для переключения. Вы включаете или выключаете запись.

Однако, если присутствуют например две опции «Записать звуки системы» и «Записать с микрофона» — вы имеете дело со списком и должны использовать флажки.

Метки

Старайтесь называть сервисы существительными. Не используйте слов, описывающих состояние виджета «Enable Multitouch», «Use Multitouch», или «Disable Multitouch». Просто «Multitouch» — для избежания путаницы.


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

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

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

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

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

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

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

Иконография

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

Форма

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

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

Метафоры

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

Значок фотоаппаратаЗначок жесткого дискаЗначок мышиЗначок пакетаЗначок HTMLЗначок компьютера

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

Значки действия символизируют обычные операции пользователя: «удалить», «воспроизвести», «сохранить» и т. п. Эти значки зачастую присутствуют в панели инструментов, а также повсюду в OS.

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

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

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

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

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

16-пиксельный значок терминала24-пиксельный значок терминала32-пиксельный значок терминала48-пиксельный значок терминала64-пиксельный значок терминала128-пиксельный значок терминала
16 24 32 48 64 128
128-пиксельный значок терминала
128

Лучше всего проектировать значки разных размеров отдельно. Не пытайтесь создав один, растянуть его до размера остальных. Для большей информации о («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-агрегатораЗначок веб-браузераЗначок ФотографииЗначок сетиЗначок календаря

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

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

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

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

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

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

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

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

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

Структура

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-высоты для компенсации за оптическую иллюзию - они выглядят меньше объектов прямоугольной формы.

Контуры и контраст

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

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

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

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% непрозрачность.

Затем, создайте два прямоугольника поменьше для «подпорки» большого. Заполните каждый аналогичным градиентом, но сделайте его радикальным. Центром радикального градиента будет короткий край с каждой точкой прямо на ближайшем краю — смотрите пример ниже. В обоих прямоугольниках настройте 60% непрозрачность.

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

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

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

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

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

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

Ниже представлены правила, которым вы должны следовать при значка для своего приложения.

Текст

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

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

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

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

Соответствующие существительные должны начинаться с заглавной буквы. Яндекс должен быть всегда написан как «Яндекс», elementary как «elementary», MPEG как «MPEG». Если вы не уверены, то ознакомьтесь с документацией.

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

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

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

Дефисы и тире

Дефис (-)

Используйте \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:

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

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


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

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

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

«Найти Страницу...» — хорошее название, т. к. оно описывает действие при нажатии. «Приложение Обновлено» — плохое, потому что непонятно что же произойдет.