Процесс проектирования Ribbon.

Предисловие.

Помниться, когда я опубликовал в блоге справочник по Ribbon Controls у меня тогда созрела идея при создании второй части справочника (или при переработки первой в более основательный справочник) уделить отдельное внимание программам, написанным в Delphi с использованием Ribbon Controls.

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

В процессе переработки уже существующей версии программы, её доработки с учетом просьб и предложений пользователей, я решил обратиться к материалам статей из MSDN по Ribbon UI. Там, конечно, с роду не было примеров хотя бы отдаленно напоминающих работу с Ribbon в Delphi, но зато есть очень много информации именно по процессу проектирования, о том как правильно располагать команды на ленте, делать точные подписи и т.д.. Вот я и решил – почему бы вторую часть справочника по Ribbon не дополнить такой информацией? Лишней она явно не будет, особенно для тех. кто впервые сталкивается с Ribbon UI. И как обычно, первым делом решил публиковать отдельные материалы из будущего справочника в блоге.

Тот текст, который представлен под катом назвать переводом в прямом смысле, думаю, нельзя. Я не ставил перед собой целью переводить текст 1 в 1. Скорее это изложение материала из MSDN максимально приближенное к оригинальному тексту, немного дополненное для использования разработчиками, которые используют Delphi. Жаль, конечно, что я решил воспользоваться советами из MSDN довольно поздновато, когда программа была уже практически готова :)

Итак, что нам говорят умные люди по поводу процесса проектирования интерфейса Ribbon.

Процесс проектирования Ribbon

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

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

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

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

Миграция команд из диалоговых окон

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

Например, в Microsoft ® Word, исследование данных показывает, что диалоговое окно настройки шрифта является одним из наиболее часто используемых в программе. Дополнительные данные показывают, что такие функции как superscript , subscript и зачеркнутый текст часто вручную добавляются в панель инструментов форматирования. Кнопки Увеличить шрифт и Уменьшить шрифт часто используются в Microsoft ® PowerPoint, где эти команды появились на панели инструментов по умолчанию.

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

Во многих случаях, вы обнаружите, что в версии «пользовательской панели инструментов» функция не существует. Например, в Microsoft Excel 2003, чтобы выделить все ячейки с условным форматированием, пользователи должны были открыть диалоговое окно Перейти…, нажать кнопку Специальный …, (прим. — в русской сборке кнопка Special носит название «Выделить») затем выбрать Условные форматы и, наконец, нажмите кнопку OK, чтобы увидеть результаты. Это диалоговое окно было единственным местом в котором существовала функция. Не существовало эквивалента команды, которая могла бы быть добавлена в меню или панель инструментов пользователя. Чтобы добавить команду для ленты в Office 2007, эта версия панели инструментов должна была быть перестроена.

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

Это означает, что все элементы управления (в ленте) должны работать самостоятельно, и они никогда не могут использовать дополнительные элементы управления. Например, вы никогда не будете выбирать шрифт, а затем размер шрифта, а затем нажимать кнопку ОК, чтобы одновременно подтвердить все изменения. В ленте Ribbon никогда не может быть команд ОК или Отмена. Это не означает, что элементы управления не могут влиять друг на друга. Например, в группе Абзац, выбрав выравнивание по правому краю, снимается выделение с команды «выравнивание по левому краю».

Маркировка команды

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

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

Только несколько очень известных команд могут быть без подписи по умолчанию. Это будут такие команды, как Bold и Cut и они почти наверняка будут на вкладке Главная.

Не используйте многоточие (…) чтобы показать, что команда требует более одного ввода. Непосредственно на ленте многоточия используются только для усечения текста. (Однако, многоточие до сих пор является традиционным значением в раскрывающемся меню.) На лента многоточие автоматически вставляются в конце подписи (прим. — когда название команды не умещается в группе). Когда вы попытаетесь уместить несколько кнопок на вкладке, то увидите, что команды пытаются автоматически занять всё доступное пространство.

Стабилизация пользовательского интерфейса

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

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

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

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

Сделайте так, чтобы пользователи полюбили ленту

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

Чтобы пользователи полюбили вашу ленту:

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

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

Собираем все вместе

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

1. Сделайте таблицу всех команд в вашей программе. Потратьте время, чтобы получить этот список, вы будете некоторое время зависеть от этого списка.
   • Этот список включает в себя все команды из элементов меню, панели инструментов, контекстных меню, и любые настройки пользовательского интерфейса.
   • Для каждой команды, вы необходимо:
     • Информация по ID команды из панели управления (TCID)
     • Подпись
     • Используемые данные
2. Отфильтруйте команды, которые относятся к стандартизированным вкладкам программы:
   • Домой
   • Вставить
   • Разметка страницы
   • Аннотация
   • Просмотр
   • Разработчик
   • Стандартизированные Контекстные вкладки
3. Отфильтруйте команды, которые относятся к контекстным вкладкам.
4. Отфильтруйте команды, которые относятся к стандартизированным группам:
   • Буфер обмена
   • Шрифт
   • Абзац
   • Редактирование
   • Таблицы
   • Иллюстрации
   • Темы оформления
   • Параметры страницы
   • Упорядочить
   • Правописание
   • Комментарии
   • Просмотр документа
   • Показать/скрыть
   • Масштаб
   • Окно
   • Макросы
5. Организуйте остальные команды в небольшие группы функций по их функциональности:
   • Группа со специфичными для программы командами.
   • Поговорите с вашим юзабилити-специалистом для выполнения тестов «Сортируйте это» с пользователями.
6. Организация групп в общей сложности по 5-10 задачам на вкладку.
   • Начните создавать прототип вкладки. Попробуйте использовать ваш прототип пользовательского интерфейса.
   • Тестируйте ваши разработки с пользователями.
   • Чего не хватает? Есть ли функции, которые должны быть перемещены из диалоговых окон?
   • Где можно использовать галереи, чтобы лучше выражать значение и цель функции или набор функций?
   • Могут ли пользователи смотреть на ваши вкладки и знать для чего они предназначены? Есть ли у каждой вкладки очевидная цель?
   • Подумайте об обобщении вкладок. Могут ли пользователи, читая подписи вкладок понимать, что ваша программа делает?
   • Подумайте о будущем вашей программы. Будут ли вкладки, которые вы выбрали иметь смысл для следующих нескольких версий? Соответствуют ли они общей направленности вашей программы?
7. Создавайте новые возможности и добавляйте их к вашим вкладкам.
   • Пока вводятся новые функции, вы будете иметь дело с большими проблемами в конструкции ваших вкладок.
   • И, что еще хуже, когда что-либо выбрасывается, вы также будите получать те же проблемы постоянно. Подумайте об этом заранее. Новые возможности в программе могут сократить время на дальнейшую разработку, и вы будете иметь дело с ними быстро.
8. Тестируйте организацию ваших фич.
   • Сделайте это по всему циклу развития, а не только на крупных бета-тестах.
   • Попробуйте использовать ваши прототипы самостоятельно.
   • Дайте другим использовать ваш прототип и сделать отзыв.
   • В максимально возможной степени перенесите «быстрые» клавиши и подписи команд для совместимости с предыдущими версиями программы.
   • Постарайтесь получить отзывы о длительном использовании, а не только о первоначальных реакциях.
9. Итерация, итерации, итерации.
   • Убедитесь, что все (в том числе разработчики, тестеры, и соответствующие руководители) планируют постоянные итерации по организации команды.
   • Изменения легко вносить, так как в основе макета лежит простой XML (прим. — только не в Delphi).
   • Но, документировать текущие планы трудно. Будьте осторожны и не позволяйте вашим разработчикам бежать впереди своих тестеров.

Оригинальный текст MSDN —  “Ribbon Design Process”.

Послесловие

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

В целом, если говорить в нескольких словах, то в Ribbon (ленте):

1. Не должны использоваться элементы, создаваемые в run-time. Думаю, что единственным исключением для этого правила может быть компонент RibbonComboBox на ленте, потому как даже если мы будем динамически дополнять его список Items, то общий вид как группы, так и вкладки на которой располагается элемент управления страдать не будут.
2. Должно быть максимум информации по командам – точные подписи.
3. Не должно быть никаких мельтешений подписей – одна кнопка = одна функция.
4. Должна быть максимальная совместимость по возможностям с предыдущими версиями.
5. Должна быть организована удобная работа с ключами (KeyTips). Честно сказать, довольно редко использую горячие клавиши за пределами Delphi IDE, однако при работе с Ribbon надо приложить максимум усилий для разработки удобного маршрута по ленте с использованием KeyTips’ов.

По этому списку я насчитал у себя в программке 4 из 5 несоответствий :). Конечно до KeyTips я пока не добрался, но тем не менее подобное обстоятельство сподвигло меня на практически полную переработку интерфейса приложения. Теперь буду знать, как делать правильно :) Надеюсь, что узнаете и Вы, если только знакомитесь с интерфейсом Ribbon.