Обучение работе с системой

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

(стимул), если же полной уверенности в этом нет, ожидаемая прибыль должна быть огромна. Это правило в полной мере касается и пользо# вателей.

Есть ещё одно правило: пользователь будет учиться какой#либо функции, только если он знает о её существовании, поскольку, не обладая этим знанием, он не способен узнать, что за её использование жизнь даст ему награду. Т. е. одного стимула недостаточно, если пользователь не знает, за что этот стимул дается.

Рассчитывайте на средних пользователей, а не новичков или на профессионалов: средних пользователей, как&никак, абсолютное большинство

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

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

сохранять файл автоматически, проблема в том, что произойдет это скорее поздно, чем рано, и вполне может оказаться, что и никогда. Этот способ обладает определенным своеобразием: пользователь не поймет, зачем он это делает, он будет только знать, что делать это надо. На жаргоне этногра# фов и психологов такое поведение называется ритуалом. Получившийся в результате такого обучения ритуал не будет принципиально отличаться от, скажем, плясок каннибалов вокруг волшебного дерева Тум#Тум, чтобы не было эпидемии: пользователь будет нажимать кнопку Сохранить в качестве жертвы Великому Энжэмэдэ, Богу Компьютера. К слову сказать, пользова# телей, которые пользуются компьютером с помощью ритуалов, не так уж мало.

систему маркировки кнопок. Благодаря этому пользователям для исполь# зования программы ничему не приходится учиться (и даже не приходится переучиваться, что вдвойне обидно, поскольку полностью отрицает возвращение инвестиций в обучение)1.

Рис. 5. Главный экран ОС Magic Cap. Будучи вся построена на метафорах, ОС приобрела широчайшую известность среди журналистов компьютерных изданий (они сразу всё понимали). С другой стороны, она не смогла добиться такой же любви у пользователей: они её понимали, но отказывались с ней работать из#за её неэффективности. Класси# ческий пример горя от ума. © General Magic © Susan Kare

К сожалению, метафоры отнюдь не безоблачны. У них есть несколько существенных недостатков.

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

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

В#третьих, почти всегда метафора будет сковывать функциональные возможности. Что делать, если проектируемая система обладает большим количеством функций, чем копируемый образец? Следование метафоре в таких условиях будет только вредить, поскольку совпадающим функциям будет учиться легче, а несовпадающим – сложнее (они будут слишком иначе устроены). Зачем тогда система, почему бы пользователю не воспользо# ваться её исходным образцом?

В#четвертых, совершенно необязательно, что сам по себе копируемый образец работает идеально. Если его копировать, окажется, что система не сможет быть эффективней своего прародителя. Например, Adobe PageMaker во многом копирует традиционные верстальные гранки, насле# дуя их известность пользователям вместе с их ограничениями. Благодаря этому он стал чрезвычайно популярен. Однако через некоторое время

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

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

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

Таким образом, метафора, будучи лучшим средством для избавления пользователя от обучения, не является средством хорошим. С другой стороны, метафоры иногда всё#таки работают (взять те же музыкальные программы), так что определенную пользу от них получить можно. Анализируя опыт успешных случаев их применения, можно вывести следующие правила:

■опасно полностью копировать метафору, достаточно взять из неё самое лучшее

■не обязательно брать метафору из реального мира, её смело можно придумать самому

■эффективнее всего метафорически объяснять значение отдельных объектов: например, для графической программы слои можно пред# ставлять как положенные друг на друга листы стекла (этот пример подходит и для предыдущего пункта)

■если метафора хоть как#то ограничивает систему, от неё необходимо немедленно отказаться.

Суммируя, можно сказать, что применять метафору можно, но с большой осторожностью. Не надо забывать, что большинство систем, сильно бази# рующихся на метафоре, проиграли конкурентам. Таков уже упоминавшийся PageMaker, таковой была операционная система Magic Cap, таковой была оболочка MS Bob, в которую было вложено множество денег, и которая была прикрыта после нескольких месяцев микроскопических продаж (это самые шумные падения, были и другие).

. Термин введен Дональдом Норманом (Donald Norman. The Design of Everyday Things).

. Частично в качестве перевода подходит слово наглядность, но изEза того, что в нём упор ставится на зрение (глядеть), предпочесть его я не решился.

Рис. 6. Отсутствие аффорданса в дизайне кухонной плиты. Слева стандартный вариант, недостаток которого заключается в том, что невозможно умозрительно определить, какой диск управляет какой конфоркой. В центре и справа варианты с аффордансом, не имеющие этой проблемы, при этом работающие по#разному. В центральном при# мере расположение регуляторов повторяет расположение рабочих объектов (конфо# рок), благодаря чему неоднозначность исчезает. В правом примере каждому объекту соответствует отдельный регулятор. Эти два способа уничтожения неопределенности являются основными в экранном дизайне.

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

приспособленность к человеческой анатомии (пистолет, например, трудно держать неправильно) оказываются за бортом. Это ограничение приводит к тому, что доступными оказываются всего несколько способов передачи аффорданса, из которых самыми значительными являются четыре:

■маппинг, или повторение конфигурации объектов конфигурацией элементов управления (этот способ работает хорошо в реальном мире, но не очень хорошо на экране, поскольку предпочтительней непос# редственное манипулирование)

■видимая принадлежность управляющих элементов объекту

■визуальное совпадение аффордансов экранных объектов с такими же аффордансами объектов реального мира (кнопка в реальном мире предлагает пользователю нажать на неё, псевдотрехмерная кнопка предлагает нажать на неё по аналогии)

■изменение свойств объекта при подведении к нему курсора (бледный аналог тактильного исследования).

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

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

Как я уже сказал, стандарт штука мощная, но зато ненадежная. Он очень хорошо работает, когда популярен, в противном случае не работает вовсе. Так, с одной стороны, при появлении стандартизированных графических интерфейсов количество программ на душу пользователя увеличилось на порядок (т. е. пользователи получили возможность с тем же уровнем усилий изучать больше программ), с другой стороны, множество хороших вещей так и не было реализовано, поскольку в нужный момент подходящих стандартов не было.

Таким образом, чтобы стандарт заработал, он должен быть популярен. Популярен же он может быть двумя способами: во#первых, он может быть во всех системах, во#вторых, он может быть популярен внутри отдельной системы. Например, стандарт интерфейса MS Windows популярен почти во всех программах для Windows, именно поэтому его нужно придерживаться. С другой стороны, этот стандарт оставляет неопределенным очень многое (никто да не обнимет необъятного), и это многое в разных системах трактуется по#разному. Бесполезно пытаться найти общий знаменатель во всех системах, гораздо эффективнее установить собственный стандарт, не противоречащий стандарту ОС, но дополняющий его; после чего этого стандарта надо придерживаться.

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

Конечно, разработка собственного стандарта дело довольно тяжелое. С другой стороны, сказать, что она совсем уж невозможна, тоже нельзя.

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

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

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

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

Система должна индицировать все свои состояния

Сообщения об ошибках. Это тема настолько многогранная, что о ней отдельно (см. «Каким должно быть сообщение об ошибке» на стр. 42).

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

Бумажная книга. На одном листе может быть сконденсировано очень много материала, легко позволяет читателю получить большой объем материала за один сеанс, наилучшим образом работает при последова# тельном чтении. Сравнительно плохой поиск нужных сведений. Объем практически всегда лимитирован.

Справочная карта. Отдельная краткая бумажная документация, демонстрирующая основные способы взаимодействия с системой (quick reference card). Будучи реализована на едином листе бумаги, позволяет пользователю повесить её перед собой. Хороша как средство обучения продвинутым способам взаимодействия с системой и устройству навигации в системе.

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

Плохо подходит для показа крупных изображений, зато в неё могут быть легко интегрированы видео и звук.

Фрагменты пространства интерфейса, показывающие справочную информацию. Занимают пространство экрана, но пространство огра# ниченное. Отвлекают внимание, как минимум один раз воспринимаются всеми пользователями. Как правило, неспособны передавать большой объем информации.

Рис. 7. Пример пространства интерфейса, выделенный на показ справочной информации. Обратите внимание, что даже обычная подпись к полю ввода также является таким пространством.

Всплывающие подсказки. Хорошо справляются с ответом на вопросы «Что это такое» и «Зачем это нужно», при условии, что объем ответов сравнительно невелик. Поскольку вызываются пользователями вручную, в обычном режиме не занимают пространства экрана и не отвлекают вни# мания пользователей. С другой стороны, очень легко вызывают отвыкание – после первого же случая неудовлетворения пользователя подсказкой, пользователь перестает вызывать и все остальные подсказки.

А теперь те виды справочных систем, за которые ответственен дизайнер интерфейсов, можно разобрать более детально.