особенности разработки симуляторов и тренажёров по работе с программным обеспечением, уровни сложности прохождения симуляторов ПО, своевременная обратная связь в электронном курсе
Вспомним, как обучить пользователя работе в ПО?
1) Сначала даём возможность пользователю пройти задание в симуляторе в режиме "инструктаж" (в этом режиме он выполняет задания с помощью пошаговых инструкций).
2) После этого предоставляем пользователю возможность пройти симулятор в режиме "тренажёр" (в этом режиме он выполняет задания уже без подсказок), чтобы у него сформировался и/или закрепился навык.
В этой заметке я хочу рассмотреть некоторые особенности разработки именно тренажёров. Вариантов реализации тренажёров может быть много. Вариации отчасти будут зависеть от того, насколько разработчик захочет сделать его сложным в прохождении.
Для пользователя лёгким в прохождении тренажёром будет тот, в котором:
- задание само по себе простое, так как включает себя элементарные, легко запоминающиеся действия,
- любая операция состоит из небольшого количества этапов,
- интерфейс программы интуитивно понятен и содержит встроенные подсказки для пользователей, из-за чего практически исключается возможность совершения пользователем ошибки.
Кстати, во всех этих случаях создавать тренажёр нет необходимости. Чтобы обучить пользователя простым операциям вполне может быть достаточным "пропустить" его через симулятор в режиме "инструктаж".
Сложным для прохождения тренажёром будет тот, в котором:
- операции состоят из большого количества этапов,
- для выполнения задания следует учитывать большое количество различных условий,
- однотипные операции могут выполняться различными способами в зависимости от заданных условий.
В этих случаях как раз и требуется разработка тренажёра. Потому что после прохождения симулятора в режиме "инструктаж", даже неоднократного, нет никакой гарантии, что у пользователя сформируется навык.
И бывает так, что разработчики сталкиваются с соблазном создать дополнительную сложность на пустом месте, аргументируя это тем, что дополнительный фактор сложности будет способствовать формированию и закреплению навыка. В результате получается сложность ради сложности (на выходе курс-пустышка). Собственно, ниже будет идти речь о тех случаях, когда разработчики создают мега-тренажёры, которые за счёт своей исключительной сложности на самом деле не оказывают должного обучающего эффекта.
Начнём по порядку. Чем изначально вызвана потребность в дополнительном усложнении прохождения тренажёра?
Возьмём какой-нибудь среднестатистический тренажёр. В этом тренажёре пощёлкать можно только по тем кнопкам и пунктам меню, которые нужны для выполнения определенной операции - то есть, той, которую нужно выполнить для успешного завершения задания. Часть кнопок в симуляторе работают как "настоящие", а часть - нет. Пользователь подводит курсор к "мёртвым" кнопкам → они никак не реагируют (не реагирует вместе с тем и сам курсор). Порой только одна-две кнопки отзываются на действия пользователя. Таким образом пользователю их довольно-таки легко вычислить (поводил мышкой по экрану → где курсор поменялся на pointer, туда и щёлкать). В этом случае задача пользователя максимально упрощается (и многим будет удобнее выполнить задание методом тыка).
Вот конкретный пример "узкого места". Обойти его можно. Есть разные способы. Но не все они одинаково полезны.
Рассмотрим тот, что совсем-совсем неполезный (пример, кстати, реальный). Допустим, разработчик решает сделать усложнение задачи для пользователя. В тренажёре теперь при наведении указателя реагирует каждая кнопка и каждый пункт меню. Дальше у разработчика появляется соблазн утяжелить всё это возможностью предоставления пользователю пройти дальше после того, как он делает неправильный выбор (выбирает не ту кнопку или пункт меню). К примеру, вместо кнопки "А" пользователь щёлкает по кнопке "D" → появляется окно для проведения операции "D" (вместо "А") → пользователю предоставляется возможность до конца выполнить эту операцию. В данном случае симулятор его не "остановит", хотя критическую ошибку пользователь уже допустил. И вот когда пользователь завершит неверно выбранную операцию, симулятор наконец-таки сообщит про допущенную где-то там ошибку. Попробуйте сейчас прерваться от чтения и представить себе, как это в реальности выглядит.
Что в этот момент происходит с рабочей памятью пользователя? Какова вероятность того, что пользователь вспомнит, где была допущена ошибка? Особенно, если большинство операций происходят не в 2-3 этапа, а в 10 и больше. Велика вероятность, что "след" в памяти будет затираться последующими этапами выполнения неверно выбранной операции.
Главный вопрос: как пользователь вообще поймёт, что ошибся он где-то в самом начале, а не в тот момент, когда программа сообщила об ошибке?
К сожалению, формальный подход к разработке обучающих программ ("Нужно предоставить пользователю полную свободу действий, ведь на то он и симулятор") приводит к игнорированию рисков, связанных с возникающими психологическими эффектами, которые никак не способствуют обучению.
Кстати, следует учесть и то, что пользователь может не ошибиться в выборе кнопки, а всего лишь промахнуться. Так как это всего лишь бездушная программа, то никто это никак не проверит. Раз выбрал не ту кнопку, значит, ошибся (якобы по незнанию того, куда тыкать мышкой).
Теперь попробуйте представить себе, что происходит в голове пользователя, который знает, как выполнить конкретную операцию, но в симуляторе тупо промахивается и щёлкает на рядом расположенную кнопку и, не замечая промаха, продолжает выполнять задание. Откуда у нас может быть уверенность в том, что пользователь самостоятельно сможет разобраться, в чём его ошибка? Ведь для него такое поведение симулятора наверняка окажется неожиданностью (пользователь будет справедливо удивлён тем, что ему позволено завершить любую операцию). Поскольку вариантов у пользователя много, то рассчитывать на то, что он станет размышлять о том, где он допустил ошибку, не стоит.
Итак, пользователь должен понять, что было им сделано неправильно своевременно. В описанном же примере важность обратной связи собственно ушла на задний план. Чем дальше пользователь продвигается по ошибочному пути, тем больше он запутывается. Если ему сразу не сообщают о том, что он совершил ошибку, значит, во время обучения у него не сформируется понимание того, что конкретные его действия ошибочны.
Обратная связь должна предоставляться своевременно, а не с запозданием. Вспоминать то, что было сделано неправильно когда-то тогда пользователю будет сложно из-за количества совершенных действий и прошедшего с момента совершения ошибки времени. Допустим, в симуляторе-тренажёре нужно где-то проставить галочку, а далее выполнить ряд других действий. Правильно предупредить пользователя о допущенной им ошибке сразу после простановки им галочки, а не по завершению им выполнения всего ряда действий, когда уже про галочку он, может, и не вспомнит.
Чтобы усложнить прохождение тренажёра достаточно добавить возможность отклика всех кнопок и пунктов меню. Это достигается (если это courselab) развешиванием на все элементы "областей нажатия" (прямоугольников-выделений) с прописанными в них триггерами на событие "щелчок", но которые ни к чему приводить не будут. В результате при наведении на них указателя мыши, курсор просто изменит свой внешний вид (состояние).
