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

Контроль удобства программного обеспечения

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

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

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

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

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

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

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

  Количество действий пользователя сущностном варианте использования
   EE = ____________________________________________________________________  * 100%
        Количество действий пользователя в соответствующем реальном сценарии

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

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

  Сущностная эффективность Интерфейса, предназначенного для решения многих задач, определяется как сумма произведений сущностных эффективностей выполнения отдельных задач на частоты их выполнения:

  
• Согласованность задач показывает соответствие между частотами выполнения задач и скоростью их выполнения в данном интерфейсе. Вычисляется она следующим образом:
  • Задачи располагаются в порядке убывания частоты их возникновения на практике.
  • Оценивается количество действий пользователя, необходимое для выполнения каждой задачи.
  • Вычисляется индекс согласованности: для каждой пары задач, если порядок в этой паре, в соответствии с трудоемкостью их выполнения, совпадает с их порядком по частоте использования, к индексу прибавляется 1, иначе — из индекса вычитается 1.
  • Итоговая согласованность задач оценивается как процентное отношение индекса согласованности к общему количеству различных пар задач, т.е. к n(n–1)/2, где n — число различных задач.

  Значение этой метрики колеблется от –100% (полная несогласованность) через 0% (отсутствие корреляции) до 100% (полная согласованность).

Для контроля эффективности работы пользователя с данным интерфейсом часто используется метод количественной оценки, основанный на выделении целей пользователя, операторов, методов и правил их выбора, в качестве названия которого используется аббревиатура GOMS (Goals, Operators, Methods, and Selection Rules) [8,9].

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

Основан GOMS на правилах разбиения задач на отдельные действия пользователя и на таблице заранее определенных длительностей выполнения этих действий. В качестве таких действий рассматриваются следующие:

• Нажатие на любую клавишу на клавиатуре, оценивается в 0,28 с.
• Нажатие на кнопку мыши, оценивается в 0,1 с.
• Перемещение указателя мыши, оценивается в 1,1 с.
• Переход от использования клавиатуры к мыши или обратно, оценивается в 0.4 с.
• Выбор очередного действия, оценивается в 1,2 с.

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

  Время реакции системы при выборе пункта меню или элемента раскрывающегося списка обычно не учитывается, но учитывается время открытия окон.

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

Тестирование проводится обычно в отдельном помещении, в котором пользователь может целиком сосредоточиться на работе с программой. Кроме того, все действия пользователя, ответные реакции системы и реакции пользователя на то, что он видит, протоколируются. Для этого удобно использовать съемку на видеокамеру со спины пользователя, так, чтобы были видны его действия и происходящее на экране. Для фиксации реакций пользователя можно установить зеркало, с помощью которого та же камера может снимать выражение его лица. Это помогает пользователю впоследствии объяснить, чем именно были вызваны его затруднения в данном месте. Кроме того, для протоколирования событий, которые видеокамера может и не зафиксировать, необходимо присутствие наблюдателей-людей, которые, однако, никак не должны влиять на действия пользователя (даже похмыкиванием, вздохами или ерзаньем на стуле, что пользователь может истолковать, часто обоснованно, как какие-то намеки на "неправильность" его действий, или наоборот, одобрение).

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

Об удобстве использования можно говорить еще очень долго, например, рассказать о проектировании и применении отдельных элементов интерфейса, а также об особенностях проектирования интерфейса различных видов ПО. Из-за ограниченности объема лекции мы остановимся здесь, а читателям, интересующимся данными вопросами, рекомендуем обратиться к специальной литературе по удобству использования ПО [3,4,7,10,11,12,13].