Каким должно быть сообщение об ошибке

Теперь можно рассказать, каким должно быть сообщение об ошибке, тем более, что ничего сложного в создании идеального сообщения нет. Напротив, всё очень просто. Идеальное сообщение об ошибке должно отвечать всего на три вопроса:

- В чем заключается проблема?

- Как исправить эту проблему сейчас?

- Как сделать так, чтобы проблема не повторилась?

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

Итак, старое сообщение об ошибке гласило: «Не удается сохранить файл «D:\Только для чтения.doc». Файл с этим именем уже существует и доступен только для чтения. Сохраните файл под другим именем или в другой папке». Это довольно неплохое сообщение, во всяком случае, оно гораздо лучше, чем «Указано неверное число». Но и его можно улучшить. Сначала надо разобраться, в каких случаях оно появляется. Это несложно: оно может появляться, если пользователь попытался сохранить файл на компакт-диске, или же пытается сохранить файл, незадолго перед этим скопировав этот файл с компакт-диска. Случаи, когда файл заблокирован сознательно, в жизни редки, так что их чаще всего можно не учитывать. Главный враг – компакт-диск.

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

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

- Диски, на которые ничего нельзя записать, не показываются в диалоговом окне сохранения файлов.

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

- При попытке записать документ поверх заблокированного, появляется сообщение об ошибке примерно такого вида:

Рис. 15. Улучшенное сообщение об ошибке. Обратите внимание, что кнопка Закрыть выбрана по умолчанию, чтобы снизить вероятность перезаписи важных файлов. Конечно, лучше всего было бы, чтобы ОС сама снимала с копируемых с компакт-диска файлов метку Read Only. Многие проблемы при этом бы исчезли, поскольку защищенными от записи остались только действительно важные для ОС файлы.

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

Рис. 16. Пузырь в его лучшем проявлении (не обращайте внимания на текст).

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

К сожалению, пузыри имеют и недостатки. Во-первых, в них не может быть никаких элементов управления, так что использовать пузырь в предыдущем примере, например, было невозможно. В Windows пузыри вообще реализованы довольно бедно. Во-вторых, пузырей вообще нет в интернете. Так что правило тут простое –используйте пузыри всегда, когда это возможно, и рыдайте, когда их нет.

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

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

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

И обратно: поскольку единственным способом создания действительно трудноподбираемых паролей является генератор случайных чисел, каковые числа (символы, по необходимости) невозможно запомнить, пользователи либо будут записывать их на бумажке (в этом случае пароли еще легче украсть), либо будут забывать, что дорого стоит. Я, например, вынужден пользоваться четырьмя действительно случайными паролями, причем тремя из них не реже раза в неделю. При этом, несмотря на то, что я пользуюсь этими паролями не менее года, я не помню ни одного. В результате, все четыре пароля записаны у меня на бумажке, которую увидеть может любой (я её не прячу). Какая уж тут защита?

Рис. 17. Стандартный способ человеколюбивого использования паролей: слева во время регистрации, справа в дальнейшей работе.

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

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

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

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

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

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

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

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

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

ЛЕКЦИЯ №4

ТЕМА: Критерии качества интерфейса (окончание)

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

Память

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

Кратковременная память

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

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

Изменение содержимого.Другая интересная особенность КВП заключается в том, что смена содержимого в ней происходит скорее из-за появления новых стимулов, нежели чем просто от времени. С одной стороны, это значит, что без новых стимулов КВП остается неизменной. С другой стороны, поскольку отсутствие стимулов есть труднодостижимый идеал, содержимое КВП постоянно меняется. Практический смысл этого наблюдения состоит в том, что нельзя допускать, чтобы пользователь отвлекался, поскольку новые стимулы при отвлечении стирают содержимое КВП. Но и это есть только мечта. Приходится удовлетворяться тем, чтобы максимально облегчать пользователю возвращение к работе.

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

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

Оценивать объем КВП применительно к интерфейсу как всеобъемлющие 7±2 элементов не вполне правомерно. Во-первых, как уже было сказано, в КВП информация хранится преимущественно в звуковой форме.

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

С практической точки зрения важно еще и следующее. Если на интерфейс смотрит опытный пользователь, почти вся необходимая ему информация содержится не в кратковременной, но в долговременной памяти, а значит, специально про КВП думать не надо. Более того, зачастую и для неопытных пользователей объем КВП не важен. Предположим, такой пользователь смотрит на раскрытое меню. Поскольку контекст его предыдущих действий никто не отменял, пользователь знает, чего он хочет, но не знает еще, как этого добиться. Он сканирует меню и, найдя наиболее многообещающий элемент, выбирает его, при этом ни один из ненужных ему элементов в КВП не попадает. Проблемы с КВП начинаются только тогда, когда ни один элемент не кажется ему более желанным, чем другие. При этом пользователю необходимо поместить все элементы меню в КВП и сделать выбор. Соответственно, большинство таких проблем может быть пресечено визуальной организацией элементов (чтобы убедиться, что пользователь смотрит именно в то меню, что ему нужно) и правильным наименованием отдельных элементов (чтобы по тексту элемента сразу была понятна его применимость). Впрочем, слишком большой объем элементов неопытным пользователям всё-таки вредит: если пользователь долго сканировал список в поиске нужного элемента, некоторая часть списка всё-таки попадет в КВП и испортит контекст, так что увлекаться большим набором возможностей тоже не стоит.

Так что значительно эффективнее считать, что объем кратковременной памяти равен пяти (шести, из которых один в запасе) элементам. Не более, но и не менее.

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

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

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

Долговременная память

Долговременная память, вообще говоря, лучше поддается интроспекции, так что рассказ о ней будет короче. Как все мы знаем (и пока еще не забыли), объем ДВП очень велик, информация, попавшая в ДВП, хранится, судя по всему, вечно и так далее. С точки зрения дизайна всё это не представляет особого интереса. Интерес представляют два вопроса:

- При каких условиях информация попадает в ДВП?

- Сколько «стоит» вспоминание?

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

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

С повторением всё просто. Чем больше повторений и чем меньше времени проходит между повторами, тем больше шансов, что информация будет запомнена. Для нас как «людей просто» это ясно и неинтересно, но зато с точки зрения дизайна интерфейса это наблюдение вызывает очень простую эвристику: если системой придется пользоваться часто, пользователи ей обучатся, деваться-то им некуда. Это очень утешительное наблюдение.

С семантической обработкой дела обстоят интереснее. Дело в том, что информация хранится в ДВП в сильно структурированном виде (например, похоже, что зрительные воспоминания на самом деле хранятся не в виде картинки, а как список объектов, находящихся в изображении, изображения же отдельных объектов хранятся отдельно). Так что для обращения к воспоминаниям мозг выполняет работу, сходную с поиском книги в библиотеке (только более сложную; попробуйте методом самонаблюдения вспомнить, например, всех своих одноклассников). Соответственно, когда человек вспоминает, он углубляется в свою память и находит всё больше признаков искомой информации. Но верно и обратное: чем больше человек думает о какой-либо информации, чем больше он соотносит её с другой информацией, уже находящейся в памяти, тем лучше он запомнит то, о чем думает (т.е. текущий стимул). Это тоже очень утешительное наблюдение: если пользователь долго мучается, стараясь понять, как работает система, он запомнит её надолго, если не навсегда.

Несколько помогает понять устройство механизма запоминания его антипод, а именно забывание. Современная наука утверждает, что забывание обусловлено одним из трех факторов (или всеми тремя), а именно затуханием, интерференцией и различием ситуаций. Самое простое объяснение имеет затухание: когда информация не используется долгое время, она забывается. Несколько сложнее с двумя оставшимися факторами. Предполагается, что если сходной семантической обработке подверглись несколько фрагментов сходной информации, эти фрагменты перемешиваются в памяти, делая практически невозможным воспроизведение поврежденного фрагмента, т.е. фрагменты интерферируют друг с другом. Иначе обстоит дело с различием ситуаций. Предполагается, что для успешного воспоминания требуется соответствие признаков во время кодирования с признаками во время воспроизведения. Невозможно неслучайно вспомнить «то, не знаю что». Это всё равно как потерять книжную карточку в библиотеке – книга в целости и сохранности, но найти её нет никакой возможности.

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

Цена вспоминания.Является общим местом, что обращение к ДВП стоит довольно дорого. Поспорить с этим невозможно, поскольку в утверждении содержится слово «довольно», обладающее крайне размытым значением.

На самом деле всё сложно. Разные понятия вспоминаются с разной скоростью, слова, например, вспоминаются быстрее цифр, а визуальные образы – быстрее слов. Очень сильно влияет объем выборки, т.е. вспомнить одно значение из десяти возможных получается быстрее, нежели из ста возможных. Наконец, частота вспоминания влияет на скорость вспоминания (т.е. на скорость вспоминания сильно влияет тренировка).

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

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