разработка симуляторов и тренажёров программного обеспечения (ПО), юзабилити эл. курса, интерфейс эл. курса, методология разработки эл. курсов
В этой заметке рассмотрим ряд факторов, влияющих на то, насколько пользователю будет комфортно работать с симулятором/тренажёром ПО. Такими факторами являются:
- реалистичность поведения симулятора,
- визуальная идентичность симулируемой программы,
- отсутствие отвлекающих элементов в интерфейсе.
Реалистичность поведения симулятора:
- поведение кнопок и других интерактивных элементов,
- демонстрация развития событий в случае неправильно выполненного действия пользователем,
- поддержка горячих клавиш.
1) Поведение кнопок и других интерактивных элементов. Чтобы пользователь воспринимал кнопку как кнопку, она должна реагировать на действия пользователя как реальная кнопка (например, подвёл указатель к кнопке - её внешний вид изменился, как в реальной программе).
Зачем? Пользователь должен понимать, что поведение симулятора соответствует поведению изучаемой программы. Он должен поверить в то, что это действительно полноценная симуляция, и в то, что в этой симуляции можно отработать тот или навык. Так у пользователя вырабатывается определенный уровень доверия к симулятору (у пользователя появляется уверенность в том, что симуляция идентична поведению реального ПО).
Обязательно ли делать интерактивными все кнопки, даже если их 30 и больше?
Для режима "инструктаж", в котором пользователь выполняет задание с помощью пошаговых инструкций, допустимо сделать интерактивными только те элементы, которые являются необходимыми для продолжения выполнения задания. Например, все кнопки, по которым пользователю нужно щёлкнуть для перехода на следующий этап операции, а также те элементы, которые визуально и функционально с ними связаны.
Для режима "тренажёр", в котором пользователь должен выполнить задание самостоятельно без подсказок, желательно запрограммировать реакцию всех доступных интерактивных элементов (кнопки, пункты меню, выпадающие списки). Таким образом при наведении указателя мыши на любой интерактивный элемент, он визуально поменяется (отреагирует). Если же этого не сделать, то пользователю будет достаточно "поводить" по слайду мышкой, пока указатель мыши не отреагирует на один единственный интерактивный элемент. Выполнить любое задание тогда будет довольно-таки просто, тупо тыкая мышкой по всем кнопкам.
С другой стороны, для разработчика курса будет очень муторно прописывать поведение сразу для всех элементов. Если интерактивных элементов очень много, то это уже нецелесообразно. Можно поступить проще: поверх всех элементов повесить объект, при наведении указателя мыши на который он изменит своё значение на pointer (курсор-палец). Это отличное решение для кнопок и всех элементов, которые подразумевают нажатие/щелчок. Но для элементов, реагирующих на наведение указателя мыши, такое решение уже не подходит (например, для пунктов меню, тайлов или flat-кнопок).
2) Демонстрация развития событий в случае неправильно выполненного действия пользователем. Пример: при попытке отправки пользователем не до конца заполненной формы появляется точно такое же сообщение, которое появляется в реальной программе (визуально идентичное).
Неудачный вариант - выдавать такие обратки в системных "алерт-окнах" (тех, которые формирует операционная система). Почему? В этом случае не происходит имитации узнаваемого интерфейса программы + внешний вид "алерт-окна" будет различаться в зависимости от того, в какой операционной системе запущен курс (некоторых пользователей это может сбить с толку, так как может быть не сразу понятно, это сообщение курса или программы).
3) Поддержка горячих клавиш (переходы на следующее поле по нажатию на клавишу TAB, переходы между слайдами по нажатию на сочетание клавиш и т.д.).
Зачем? Многие пользователи активно используют горячие клавиши, так как зачастую это гораздо удобнее щелчков по кнопкам интерфейса, которые к тому ещё нужно отыскать. У многих уже сформирована привычка выполнять ряд действий в программе именно с помощью горящих клавиш. Игнорирование этого фактора при разработке симулятора может негативно отразиться на обучающем процессе. В этом случае пользователь лишается комфортных для него условий работы в программе, и ему нужно будет дополнительно сосредоточиться на том, как выполнить то или иное действие вопреки сформированной привычке.
Визуальная идентичность симулируемой программы
По большей части визуальная идентичность достигается за счёт качества скриншотов и исключения посторонних/отвлекающих элементов в интерфейсе симулируемого ПО, а также в интерфейсе самого курса.
Казалось бы, про качество скриншотов говорить особо нечего. Всем должно быть интуитивно понятно, каким образом их следует "вырезать" и размещать в курсе. Однако я видел довольно много странных реализаций симуляторов, например, в одних скриншоты сохранялись в "пережатом" JPEG:
unknown
unknown
В других не менее странных реализациях скриншоты были сохранены в значительной степени уменьшены в масштабе. В последнем случае идентичность на самом деле сохраняется, но глазам пользователя от этого не легче.
unknown
i-eLearning
eLearn2b
Небрежность в обучающих курсах, на мой взгляд, чревата, поскольку пользователи очень легко распознают халтурный характер работы. В свою очередь, отношение пользователей к обучению может быть таким же небрежным. Поведение человека таково, что, будучи окружённым эстетически неприемлемыми для нормальных людей объектами, он порой склонен действовать с пониженным чувством ответственности. Многие из нас привыкли к хорошему дизайну и комфортному взаимодействию с веб-ресурсами. Поэтому курс, слепленный кое-как, пользователь с большей вероятностью пройдёт спустя рукава по принципу "вы не старались, и мне оно тоже не надо".
Как адаптировать интерфейс, сохранив его визуальную идентичность (узнаваемость)
Бывает так, что в интерфейсе симулируемой программы столько всего, что скриншот интерфейса не удается уместить в рамках слайда. Допустимо ли в этом случае изменить интерфейс?
С одной стороны, интерфейс по своему виду должен полностью походить на настоящий, с другой стороны, его можно чуть-чуть изменить, но так, чтобы узнаваемость интерфейса сохранилась. Как правило, в интерфейсах куча незанятого места, лишние строки и пр. - их можно смело удалять с помощью фотошопа. Также можно сократить длину строк и полей для ввода данных, интервалы между элементами, тем самым добиваясь компактности содержимого интерфейса.
Зачем следует удалять всё это "хозяйство"?
1) В ряде случаев это решает проблему экономии пространства.
2) Пользователь не будет отвлекаться на незначительные элементы и не будет дезориентирован лишними кнопками, некорректными датами и пр.
3) Пользователь будет избавлен от возможности совершать нежелательные или лишние действия.
Этот момент является довольно-таки спорным, так как многим кажется, что изменение интерфейса влечет за собой дальнейшую неузнаваемость пользователем интерфейса в реальной программе. Однако речь идёт лишь о тех изменениях, которые не приведут к нарушению восприятия заданного шаблона. К примеру, если убрать кнопки закрытия окна, то катастрофы не будет.
Вспомним также и то, что пользователь имеет возможность менять размеры окна программы, из-за чего произойдет смещение ряда элементов, уменьшение строк в размерах (если интерфейс адаптируемый) и пр.
Подводя итог, следует просто помнить о том, что всё хорошо в меру. Если удалить из интерфейса кусок с функциональными кнопками, поменять какие-то кнопки местами, изменить цвет кнопок, стиль (хотя в зависимости от операционной системы и пользовательский установок на ней, стиль так или иначе может поменяться), то это уже перебор.
Допустим, пользователь видит кнопку закрытия окна и предполагает, что по щелчку по ней окно закроется, а после этого ничего не происходит. Скорее всего, у него возникнет вопрос "в чём моя ошибка". А ведь никакой ошибки с его стороны нет. Поэтому наличие таких кнопок может сбить пользователя с толку и лишний раз его фрустрировать (тем более, что часть пользователей любят поиграться с интерфейсом, чтобы проверить, насколько в нём всё реалистично).
Реальный пример. В некоторых курсах приходилось наблюдать по 3-5 кнопок закрытия. Многие пользователи скрупулезно щёлкали по каждой из них, чтобы закрыть окно. А ведь у многих пользователей эта куча бессмысленных действий может вызвать досаду и раздражение, так как они ожидали совершенной другого поведения от симулируемой программы.
unknown
Рассмотрим то, что можно убрать в интерфейсе программы типа "1С Рарус":
- информацию в заголовке окна (всю или только часть),
- строку состояния, где мелькает информация о загрузках документов, подсказки, текущая дата и пр.,
- кнопки закрытия окна,
- панель быстрого доступа (та, которая с пиктограммами) в том случае, если в ней нет необходимости.
Вот ещё пример. Как можно скрыть (закрасить) лишние кнопки закрытия окна + сделать интерфейс чище:
Исключение отвлекающих элементов в интерфейсе
Нельзя допускать замусоривания интерфейса:
- разнообразными подсказками, например, когда помимо пошаговой инструкции появляются новые типы сообщений для пользователя (подробнее),
- посторонними визуальными излишествами (например, пиктограммы-кнопки, при щелчке по которым что-то должно появиться - комментарии или еще нечто, на что по каким-то причинам пользователь должен обратить внимание),
- персонажами,
- элементами навигации по курсу (кнопки "Далее" или "Назад"),
- названиями этапа, части курса и пр. посторонними надписями,
- графическими объектами, иллюстрирующими то, что пользователю легко приставить без дополнительного визуального сопровождения (смс-ка в телефоне, номер кредитный карты и пр.).
unknown
Почему? Внимание пользователя должно быть сконцентрировано на пошаговой инструкции и на самой симулируемой программе. И потом следует учитывать, что среди пользователей найдутся такие чайники, которые запросто поверят в то, что такой мусор (например, подсказки) - составляющая интерфейса реальной программы. Даже в персонажа могут поверить, так как опыт встречи с вордовской скрепкой был у многих.
unknown
unknown
Использование в симуляторах персонажей - это отдельная песня, поэтому остановимся на ней подробно.
Представим ситуацию, когда персонаж о чём-то вещает и "припадочно" реагирует на действия пользователя (пляшет, строит рожи и пр.). Чем это плохо?
- Дополнительные визуальные элементы поверх интерфейса сами по себе являются излишествами. Они скрывают собой часть интерфейса, и вне зависимости от того, полезная часть информация загорожена ими или нет, пользователь об этом узнать не сможет, просто потому что эта часть скрыта. У ряда пользователей это может взывать раздражение, ведь ему мешают посмотреть, как целиком выглядит интерфейс программы (конечно, это не относится к случаям, когда персонажа можно сдвинуть мышкой, хотя я таких примеров никогда не видел).
- Персонаж вроде как создает положительный эмоциональный фон (и то не факт, ведь каждому не угодишь - кого-то персонаж будет выбешивать одним своим видом), но при этом он мешает сконцентрировать внимание пользователя на самом главном - на интерфейсе симулятора и пошаговой инструкции (ведь для многих персонаж наверняка интереснее, особенно, если он ещё и как-то реагирует).
Amedium
Amedium
Есть даже персонажи, которые выполняют роль указателя. Нужно представить себе эту ситуацию и задать вопрос: на что в большей степени пользователь обратит внимание - на такой указатель или на то, на что он указывает? Более вероятно, что именно на указатель.
unknown
Размещение поверх интерфейса сканов документов (паспорта, накладных, чеков и пр.).
Писал про это раньше (смотрите здесь).
Выделение интерфейса симулируемой программы:
1) отделить от границ окна курса интерфейс симулируемой программы,
2) сделать затемнение позади этого интерфейса.
Зачем? Визуальное выделение интерфейса симулирумой программы от интерфейса курса, в которое оно встроено, позволяет лучше сфокусировать внимание пользователя на интерфейсе программы и на пошаговой инструкции. При этом у пользователя остаётся доступной возможность использовать кнопки управления курсом + пользователь может видеть название темы/этапа. При этом элементы интерфейса курса визуально "отходят" на второй план.
Чуть подробнее - здесь.
