Как делать интерфейс на Ribbon-панели: опыт ижевских разработчиков

avatar Павел
Овчинников
23.05.2014, 11:44
комментировать

От редакции: Сегодня у в гостях у Ижайти Анна Долганова, программист из НПО «Компьютер». Ее статья довольно необычна для нашего бложика: она расскажет про то, как проектировался интерфейс в новой версии системы Directum. Опыт довольно интересный хотя бы потому, что разработчикам пришлось менять свой подход к созданию интерфейса. Уверен, многие читатели Ижайти что-то да знают про проектирование таких вещей и с удовольствием поучаствуют в обсуждении. А теперь слово Анне.

O

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

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

Итак, при разработке мы опирались на основные принципы разработки интерфейса:

  1. Приоритетность действий.
  2. Доступное пространство.
  3. Контекст действий.
  4. Стремление к единообразию.
  5. Однозначные формулировки.

Ниже расскажу подробнее о принципах, и как мы их применяли.

Приоритетность действий

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

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

Лично мне нравятся большие кнопки. Большая кнопка сразу бросается в глаза, привлекает внимание к себе. Но много больших кнопок теряют свою прелесть и особенность.

Доступное пространство

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

  • Группы на ленте не должны сворачиваться: изменить размеры прикладной формы простые пользователи не смогут. Дабы избежать этого, можно либо увеличить по размерам карточку, либо распределить кнопки на нескольких вкладках, удалить ненужные кнопки с ленты.
  • Название кнопок влияет на ширину ленты. Например, у маленьких кнопок заголовок всегда будет отображаться в одну строку. Поэтому не рекомендуется использовать кнопки с названием из 4-5 слов. Да и пользователь устанет это читать. Но если все-таки возникает острейшая необходимость сделать длинный заголовок, уменьшить его занимаемое место можно за счет использования большой кнопки. В этом случае сработает автоматический перенос слов:

1 ribbon

  • Как можно заметить на скриншоте выше, одна маленькая кнопка в группе смотрится непрезентабельно. Лучше добавить в пару к ней хотя бы ещё одну. А уже при использовании маленьких кнопок лучше, когда заголовки в одном столбце не сильно отличались по длине.

2 ribbon

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

Контекст действий

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

3 ribbon

Стремление к единообразию

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

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

Необходимо придерживаться выбранной терминологии. Например, использование терминов «e-mail», «email», «mail», «мыло» в разных элементах разработки выглядит небрежно.

Однозначные формулировки

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

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

Посмотрим, как сделано

Теперь использование принципов вкратце рассмотрим на одном небольшом примере.

Как было:

4 ribbon

Как стало:

5 ribbon

Итак, вот несколько советов, которые я могу дать всем, кто собирается делать что-то подобное:

  1. Учитывайте место. Больше места выделили под email, адреса и паспортные данные.
  2. Приоритетность действий. Все прикладные действия расположили на главной вкладке, правее –работу с изображением, потому что это же корпоративная система, а не Instagram – фотографии меняются не так часто.
  3. Контекст действий. Рядом с полем Личный email оставили гиперссылку Отправить письмо, чтобы при отправке пользователь мог быстрее проверить соответствие между содержимым поля и непосредственно созданным письмом. К слову, размещение спорное, допустимым было бы и расположение на ленте. Зато на форме мы можем добавить глагол к заголовку, что сделает действие более понятным для пользователя.
  4. Стремление к единообразию. Отказались от формулировок e-mail/e mail и прочих в пользу email, аналогичные изменения коснулись всех упоминаний адреса почтового ящика. Иконки используем в соответствии с остальными справочниками.
  5. Однозначные формулировки. Лента широкая, поэтому не поскупились на слова и использовали «Официальная переписка» вместо «Переписка» и других коротких аналогов.

Вот как-то так. Спасибо за внимание, буду рада рассказать что-то еще!

Не скупитесь на ретвиты ↓
  • Ivan Steblenko

    Судя по приведенному примеру — неоднозначное улучшение. Если раньше кнопки олдскульны, некрасивы и не зависят от контекста, но зато поля большие, текст читаем. А теперь и картинка большая, и кнопки большие, но поля маленькие, а текст вообще не читаем.

    Собственно вопрос — а какую задачу решали внедрением риббона? Быть в тренде или же упростить работу пользователей?

    Конечно, вполне может быть, что пример такой попался некрасивый.

    • http://twitter.com/apodkin Andrew Podkin

      >> Судя по приведенному примеру — неоднозначное улучшение.

      Да.

      >> поля маленькие, а текст вообще не читаем

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

    • Mariya Makartseva

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

    • Anna Dolganova

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

      >> Быть в тренде или же упростить работу пользователей?

      Считается, что риббоны упрощают работу пользователей, и в принципе я с этим согласна. Наряду с удобством уделялось тщательное внимание и эстетическому виду ^_^.Так что не тренда ради, а пользователей для, скорее всего.

    • Михаил Романов

      >> Конечно, вполне может быть, что пример такой попался некрасивый

      Пример не то что бы не красивый, а скорее не показательный. В нем Ribbon, используется как обычный toolbar, т.е. просто набор кнопок-команд с картинками и надписями.

      Здесь нет, таких вещей, как contextual tabs, galleries и live preview. И скорее всего их к задачам Directum особо и не прикрутишь — они нужны при редактировании контента (ну разве что contextual tabs задествованы для разных типов объектов, но в примере и этого нет).

      Более того, Ribbon становится реально полезен и необходим, когда объемы возможных действий в системе начинают зашкаливать. Ради интереса можно посмотреть выступление Jensen Harris на Mix08 (channel9.msdn.com/Events/MIX/MIX08/UX09) об истории создания нового интерфейса Office и Ribbon в частности.

      Там, например, говорится, что в Word 2003 был аж 31 (!) toolbars.

      Кроме того, если мне не изменяет память, здесь уже нарушены некоторые рекомендации Microsoft по проектированию Ribbon-интерфейса: добавлена команда «Создать запись», которая никак не соотносится с содержимым текущей карточки (по рекомендациям, такие действия должны быть в окне уровнем выше или в Backstage).

      В любом случае, в сравнении со старыми old school кнопками, новый Ribbon выглядит привлекательнее.

  • Mariya Makartseva

    отзывы пользователей уже есть? для них ведь старались ))

    • Anna Dolganova

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

  • Михаил Романов

    Паш, все же, когда перепубликуете статьи, делайте ссылку на первоисточник, а то я, например, все не мог отделаться от ощущения deja vu, пока не сравнил статью здесь и на club.directum.ru

    • izhit

      Вот это поворот. Мне присылали статью, как эксклюзивную :(

      • Михаил Романов

        Ну, статьи не идентичные, например, формулировки в повилительном наклонении «выбирайте», заменены на «выбираем». Сменились часть картинок, вступление другое...

        Но основное содержание совпадает с club.directum.ru/post/Raz...bmen-opytom.aspx, поэтому я и говорю было ощущение «ранее виденного», а не твердая уверенность.

        P.S. Хотя я вот теперь сам не уверен, можно ли считать переработанную статью (пусть и не радикально) перепубликацией? Сорри, если был не прав.

  • Arthur

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

    • Anna Dolganova

      Ограничения платформы не позволяют делать менюшечки, выпадающие списки и прочее.

      Скрывать неактивные кнопочки — не самый хороший вариант, пользователь может подумать что у него просто всё сломалось. Недоступность кнопочки должна объясняться, и в теории это выглядит как «Список работников не означен» на кнопку «Связанные работники»

Get Cloud PHP Hosting on CatN