Исходная статья по адресу: 
http://gnomejournal.org/article/44/three-simple-tips-for-interface-design-you-should-know
21 апреля 2006, Клаус Шварм (Claus Schwarm)
Руководство по созданию интерфейса пользователя GNOME (HIG – Human Interface Guidelines) всегда вызывало споры среди поклонников GNOME и сторонних разработчиков. В своей статье Клаус Шварм (Claus Schwarm) рассказывает, почему HIG важен, а так же раскрывает несколько простых способов использования советов HIG.
Когда участники проекта GNOME начали работать над второй версией рабочего окружения GNOME ни какие изменения в проекте не вызвали столько непонимания, недовольства и раздражения сколько вызвало «Руководство по созданию интерфейса» (HIG). До сих пор находятся люди, которые не согласны с существующими направлениями развития GNOME.
В конце концов, такой вещи как «превосходное руководство» просто не существует, хотя бы потому, что руководства пишут люди, а они порой допускают ошибки. Различная интерпретация принципов эргономики может привести к ошибочным или неверным заключениям. Они возникают из-за того, что разработка руководства велась энтузиастами и добровольцами в разных условиях.
Фундаментальные идеи HIG не должны обсуждаться только с точки зрения принципов эргономики. Такие дискуссии могут ввести в заблуждение: многие люди начинают путают понятия «удобство использования» и «использование», и поэтому каждый защищает свою точку зрения. Нельзя выводить общее правило из одного наблюдения – это классическая ошибка человеческого мышления.
HIG – это не просто сборник принципов создания удобного интерфейса, это своего рода неофициальный стандарт, и важно воспринимать его именно так. Так, во многих странах принято левостороннее движение, что кажется неправильным для людей из стран с правосторонним движением. Это ни правильно и ни неправильно – главное, чтобы в одной и той же стране все придерживались одного режима.
Практический подход к использованию GNOME HIG таков: не задумывайтесь правильно это или неправильно. Когда вы в Риме поступайте как римлянин.
Инструментарии GNOME, GTK+ и огромное количество привязок не налагают ни каких ограничений на разработку интерфейса. А свободе сопутствует разнообразие и разрозненность. GNOME HIG служит для координации общих усилий и помогает избежать нежелательной разрозненности приложений. Следующие три простых рекомендации служат отправной точкой для разработчиков и дизайнеров интерфейса.
В руководстве по созданию интерфейса пользователя GNOME рассматривается два типа окон: первичные и вторичные окна. Первичными обычно являются главные окна, в которых располагается основное содержимое необходимое пользователю.
Существуют разные типы первичных окон, например: в gEdit и Mozilla Firefox используется одно окно с табами внутри, в Inkscape также одно окно, но для разных документов используется несколько его экземпляров, а в GIMP вообще используется многооконный интерфейс. Выбор типа первичного окна зависит от аудитории для которой создается программа, и в большей степени зависит от специфики самой создаваемой программы.
Менее специфичен вид вторичных окон. Такие окна не отображают информации, которая все время находиться в центре внимания пользователя. Во всех приложениях, наверное, за исключением только самых простых, обычно много вторичных окон. Их использование позволяет разработчикам легко и без особых трудностей сделать интерфейс своей программы удобнее.
Часто, все вторичные окна называют диалогами. В принципе это правильно, но в случае с GNOME HIG это ведет к небольшой путанице, так как в HIG слово «диалог» закреплено за определенным типом вторичного окна. В руководстве рассматривается пять типов вторичных окон:
Служебные окна (Utility Windows)
Диалоги (Dialogs)
Предупреждения (Alerts)
Окна прогресса (Progress Windows)
Помощники (Assistants)
Смешивание этих типов или элементов дизайна этих окон является типичной ошибкой, которая приводит к бесполезной работе, заканчивающейся созданием неудачного интерфейса, путающего пользователей.
Что же это за такие элементы дизайна? Во первых, это общий для всех вторичных окон тип окна. Во-вторых, кнопки внизу окна для взаимодействия с ним. Кроме того существует ряд общих для всех вторичных окон вопросов: нужна-ли надпись в заголовке окна, показывать-ли его на панели в списке окон и обязательно-ли оно будет отображать текст. Итак, в зависимости от типа окна эти элементы как-то используются или не используются вообще. Таблица ниже помогает узреть основные отличия рассмотренных типов окон.
| Тип окна | Надпись в заголовке | Текст | Отображение на панели |
| Служебные окна | Есть | Нет | Нет |
| Диалоги | Есть | Нет | Нет |
| Предупреждения | Нет | Есть | Нет |
| Окна прогресса | Есть | Есть | Есть |
| Помощники | Есть | В зависимости от помощника | Может быть |
Служебные окна обычно используют для отображения настроек и параметров документов и приложений. Например, в текстовом редактор gedit используется несколько служебных окон: Правка > Параметры, Сервис > Показать статистику документа, Справка > О программе. В отличии от служебных окон, диалоги вызываются пользователем для выполнения определенной задачи. Возвращаясь к gedit, примерами диалогов являются: Файл > Открыть, Файл > Сохранить, Файл > Печать и Поиск > Найти.
Служебные окна и диалоги без родительского окна не нужны пользователю. Поэтому, обычно их не отображают на панели в списке окон. Кроме того, они вызываются пользователем и поэтому их появление не взывает у него удивления. Поэтому, нет необходимости в подробном объяснении причин их возникновения и, как следствие, наличия первичного и вторичного текста, достаточно использовать лишь текст в заголовке окна.
Все эти умозаключения не работают в отношении других двух типов окон: предупреждений и окон прогресса. Такие окна пользователь сам не вызывает.
Окно предупреждения предупреждает пользователя, что произошло что-то важное. С точки зрения пользователя это является новостью и требует объяснений. Поэтому, использование первичного и вторичного текста позволяет гарантировать, что пользователь в курсе того, что случилось. Аналогично окна прогресса также не нужны пользователю: он полагает что все произойдет немедленно. Необходимость ожидания компьютера – неудобство. Опять же, первичный и вторичный текст позволяет понять что происходит.
Существует небольшое различие между предупреждениями и окнами прогресса, а именно в том как пользователи реагируют на их появление. Предупреждения обычно читают и сразу закрывают. При этом нет нужды в использовании надписи в заголовке или появления этого окна на панели в списке окон. Оба этих элемента были бы лишними для чего-то что будет существовать лишь несколько секунд.
Реакция пользователей на появление окна прогресса немного другая. Обычно в таких случаях кака-либо операция требует времени и нет возможности ускорить выполнение действия. Пользователи должны иметь возможность идентифицировать это окно если они на время ожидания переключаться на решение другой задачи. Поэтому, окна прогресса имеют надпись в заголовке и появляются на панели в списке окон.
Последний тип окон упоминаемый в HIG – помощники. В плане рассуждений, это наиболее простой тип, и по нему особенно нечего сказать, кроме того что его использования по возможности следует избегать. Если, после тщательного раздумья вы решите что нет другого пути кроме, того как использовать помощник, GTK+ 2.10 предоставит вам удобный и простой виджет для его создания.
Первые четыре типа окон могут быть разделены по роли пользователя: активен ли он и окно было вызвано? Или пользователь пассивен и это программе нужно показать окно? В первом случае вам нужно служебное окно или диалог, во втором предупреждение или окно прогресса.
Смешивание этих типов может привести к созданию неудобного и запутанного интерфейса пользователя. При скрещивании предупреждения и служебного окна вы просто повторите информацию. Это может выглядеть так:
Более «тяжелый» случай получается при смешивании служебного окна и окна прогресса, при этом возникает достаточно необычная комбинация кнопок, которая может запутать пользователя. Яркий пример такого смешивания показан ниже. В изображенный диалог поиска, необходимо ввести информацию до начала, а сам поиск может занять некоторое время.
Есть два сравнительно простых способа избежать такой ситуации. Первый заключается в том, чтобы разбить одно окно на два: на простое служебное окно, в котором пользователи смогут установить необходимые значения, и второе обычное окно прогресса. При этом на время показа окна прогресса можно прятать служебное окно. Второй способ наглядно продемонстрирован на примере стандартного диалога поиска GNOME (Переход > Поиск файлов), в нем действие по умолчанию меняется в зависимости от ситуации, а процесс поиска отображается с помощью иконки (в левом верхнем углу).
За исключением панелей инструментов, все вторичные окна должны иметь хотя бы одну кнопку. Все надписи на кнопках должны быть в повелительном наклонении, и кратко описывать то, что произойдет после их нажатия. Кнопка с основным предлагаемым действиям должна находиться в нижнем правом углу окна.
Эту рекомендация HIG вызывает много обсуждений, здесь надо вспомнить что HIG – это что-то вроде стандарта. Не имеет значения плохо это или хорошо, правильно или неправильно, слева или справа. Когда вы в Риме, поступайте как римляне.
Многие пользователи GNOME использующие приложения совместимые с HIG, наверное заметили, что в они быстро закрывают окна в этих приложениях. При этом не требуется особых интеллектуальных усилий. Этот факт объясняется, использованием мускульной памяти людей – пользователи привыкают, что кнопка наиболее подходящего действия всегда находиться в правом углу.
Водители машин с ручной коробкой передач знакомы с этим эффектом: однажды пройдя небольшой курс тренировки, они перестают задумываться над тем как переключать передачи. Движение руки происходит само собой. Привыкнуть к использованию утвердительной кнопки в нижнем правом углу еще проще.
Но это еще не все. Вот еще одно правило в помощь разработчику: если у вас не получается определить какая кнопка у вас выполняет утвердительное действие по отношению ко вторичному окну, остановитесь и еще раз подумайте о дизайне своей формы. Возможно где-то вы допустили ошибку и не последовали первому нашему совету о типах вторичных окон.
Допустим, разработчики показанного выше диалога «Create thumbnails» попытались бы воспользоваться нашим советом относительно кнопки утверждения-действия, они бы заметили, что что-то неправильно: во-первых вы вызвали диалог, но получается, что его надо сразу закрыть. А ведь перед этим вы наверняка захотите произвести какие-нибудь действия. С точки зрения HIG, более правильным был бы такой порядок расположения кнопок «Stop», «Close», а затем «Start». Следующее замечание, утвердительным действием окна предназначенного для создания пиктограмм скорее всего будет является «Create» (создать), а не «Start»(начать). Поместив кнопку с утвердительным действием в правый нижний угол, разработчики смогли бы сэкономить свое время, потраченное на объяснения что делать «Click Start to begin» (для начала нажмите Start).
Дополнительно, они могли бы назначить клавишу Enter этой кнопке – основная рекомендация всем предупреждениям, диалогам и помощникам с утвердительными кнопками для продолжения. Исключением из этого правила является случай, когда ошибочное нажатие кнопки Enter, может вызвать необратимые действия, например для кнопки «Форматировать диск» лучше не назначать Enter.
Почему-же так важно как названы кнопки? Использование глаголов помогает вам как разработчику правильно сформулировать вопрос окна и делает использование диалога более простым. В качестве неудачного названия, я предлагаю взглянуть на следующий скриншот, где смысл ответа зависит от одного (скрытого) слова:
Вероятно вы можете предположить что это за слово. В то же время вы уверены что это не «Cancel»?
Реально доступное пространство экрана весьма ограничено, одновременно разработчики пытаются наделить свои приложения максимальной функциональностью. Как результат, возросшее количество элементов пытается поделить между собой ограниченное количество пикселей и форма становиться переполненной. Чтобы разделить отдельные элементы разработчики добавляют новые элементы, что приводит к визуальному засорению формы.
В отличии от принятой практики, в GNOME HIG рекомендуется при расположении элементов использовать отступы в 6 пикселей. Например, использовать границу шириной в 12 пикселей во вторичном окне. В Glade это реализуется путем установки границы окна в 6 пикселей и границы внутреннего контента в 6 пикселей. Должно получиться что-то похожее на это:
Это пример несложного размещения. Разделитель, который обычно используют между нижними кнопками и содержимым, как рекомендовано GNOME HIG, отсутствует. Одна вещь сразу становиться понятной: дизайн пока не превосходен. Однако он демонстрирует некоторые принципы размещения элементов в служебных окнах и диалогах.
Для размещения содержимого использован элемент vertical box с 3 строками. Свойство spacing (промежуток) установлено в 12 пикселей, так что каждая часть визуально отделена. Элемент frame используется в каждой строке, причем вид границы (свойство Shadow) установлено в «none», а название выделено жирным. Кроме того, вокруг кнопок тоже есть граница.
Внутри каждого фрейма, элемент alignment помогает расположить внутреннее содержимое. Свойство left padding (отступ слева) установлено в 12 пикселей, свойство top padding (верхний отступ) в 6 пикселей. По возможности содержимое выравнивается по левому и правому краям. Например, это может быть сделано по отношению к элементу combo box, который используется для выбора единиц измерения.
Получившийся, дизайн выглядит приемлимо. При этом, вам наверное будет интересно узнать, что этот диалог копирует диалог «Export to bitmap», используемый в Inkscape 0.42. Вот как он выглядел до редизайна:
Ни каких интерактивных элементов удалено не было. Все что здесь было то и осталось. Применение основных рекомендаций HIG по проектированию форм, возможно без снижения функциональности, а необходимые для этого усилия не велеки. В то же время, они улучшают обзор для пользователя и возможно даже не только для того, который живет в Риме.
Руководство этими тремя простыми рекомендациями не сделает мгновенно все ваши приложения легкими в использовании. Но они помогут вам начать думать, о том как сделать ваши приложения более простыми в использовании. Тем не менее, абсолютно точно, что вреда от них не будет, по крайней мере если вы не создаете приложение для Microsoft Windows в его стиле.
GNOME HIG предлагает множество советов как сделать приложение лучше с точки зрения удобства использования. Некторые из них полезны во всех ситуациях, к примеру, хорошим тоном является отсутствие сложных компьютерных терминов в приложении, правда это труднодостижимая цель. Над некоторыми из этих советов можно не задумываться, в то время как другие требуют анализа и приобретают значение только в определенных ситуациях. Особое внимание, конечно, необходимо уделять приложениям предназначенным для профессионалов, людей которые на протяжении всего дня работают с одной программой.
Если вы сомневаетесь об удобстве использования какого-либо дизайна, список рассылки по эргономике GNOME всегда к вашим услугам. Есть еще канал IRC #usability на irc.gnome.org где можно задать вопрос, правда участники на нем не очень активны. Будет не лишним получить помощь от других людей и настоящих дизайнеров – это наверное самая важная рекомендация GNOME HIG.